*メインモードとアグレッシブモード*


メインモードとアグレッシブモードについての一般的な話を紹介します。
以下、2人の会話をご覧ください


後輩 せんぱ~い (^ー^)
先輩 フェーズ1には、メインモードとアグレッシブモードがある。
後輩 な、、、
なんですか、いきなり。。。
先輩 さっそく本題に入ってみた。
斬新じゃね?
後輩 まぁ、斬新には違いないですけど。
もうちょっとホラ、先輩と後輩の交流というか、いつもみたいに和やかな雰囲気があったほうがよくないですか?
先輩 先輩と後輩の交流ねぇ~、、、
ビジネスの世界に、そんなものは不要なのだ。
後輩 ビジネスですか、、、
確かに、「先輩」っていう日本語を英語に訳すのは難しいみたいですし、文化が違うのかもしれませんが。
先輩 うん、そうらしいね。
自分から言っといてアレだけど、仕事に関係するカタカナ語って、実はあんまり好きじゃないんだ~。
後輩 あ~、なんとなく分かります。
「ビジネス」っていうと響きがよくて、理不尽なことでも感情抜きで許されちゃうことありますよね。
先輩 実際、ほぼイコールで「金儲け」の意味なんだけど、なんだか崇高なもののように聞こえて錯覚を起こす。
ストレートに金儲けって言われると、躊躇するのにね。
後輩 単にカッコつけるために使ってる人もいませんか?
キーパーソン、カウンターパート、リスクヘッジ、コーポレートガバナンス。
先輩 ディスクロージャ、マーチャンダイジング。。。
うーん、聞いていてイラッとする言葉ばかりだなぁ、、、
後輩 日本語で言え、っていうカンジですか。
自分から使うことはなさそうですけど、やっぱり少しは知らないとマズいですか?
先輩 新卒の人は、社内研修とかで勉強しないんだ?
後輩 ビジネスマナーみたいなのは結構しっかりやったんですけど、用語講座は特になかったです。
先輩 みんな、どうやって言葉と意味を知るんだろうね。
やっぱり、「いまさら聞けないビジネス用語」みたいな本を買うんだろうか?
後輩 う~ん、、、
必要に迫られないと絶対に手に取らないような、全く魅力を感じないタイトルです。
先輩 でも、日常会話では出て来ないし、なにかネタがないと、、、
必要になったときには、もう遅いし。
後輩 完全に聞き手に回っていれば、よく分からなくても適当に頷いてスルーしとけばいいですけど。
でも、使ってる本人が意味を間違えてたら、さらに始末が悪いですよね。
先輩 確かに、ソレは困るねぇ。
大抵そういう言葉を使ってるのは組織の偉い人だから、誰も否定できないよ。
後輩 プッ
って、心の中で笑うしかないですネ。
先輩 まぁ、用語という意味では我々のような技術者も一緒だよ。
一般的な技術用語は知っておかないと、時には恥ずかしい思いをすることがあるからね。
後輩 はは、耳が痛いです。
早く一人前になるために、先に進みましょう。
先輩 というわけで、フェーズ1にはメインモードとアグレッシブモードがある。
後輩 あ、今回の本題ですね。
どういう使い分けですか?
先輩 モードの話をする前に、少しリアルな話をする必要がある。
実際にIPsecを使うネットワークって、どんな環境だろうか?
後輩 環境ですか?
少し前に閉域網で使うっていう話も出てましたけど、やっぱり基本はインターネットなどの公衆網でしょうね。
先輩 うん、そだね。
一方、インターネットに接続するにはグローバルIPアドレスが必要だ。
後輩 はい。
先輩 インターネットを経由してトンネルを張るには、お互いのグローバルIPアドレスを知っておく必要がある。
後輩 相互認証で相互接続なので、そうでしょうね。
インターネットで相手を識別する、唯一の情報ですし。
先輩 そそ。
そうなると、どちらもグローバルIPアドレスは常に固定値を持つ必要がある。
後輩 はい、当然です。
先輩 まずは、これが基本形。
この場合はメインモードを使う。
後輩 ん、、、
まだよく分かんないけど、とりあえず分かりました。
先輩 一方で、片方向に限定するという条件で、片方だけはIPアドレスが変動してもいいという接続方法もある。
後輩 えっ?
そんなのアリなんですか?
先輩 拠点間VPNだったら正式に回線を敷設してゲートウェイ装置を置けばいいんだけど、リモートVPNの場合はユーザが色々な環境から接続するので、IPアドレスは識別子に出来ないんだよ。
この場合、アグレッシブモードを使う。
後輩 最初から、リモート接続のように不特定な要素がある用途も想定した仕組みがあるわけですか。
でも、アグレッシブモードでは相手を事前に特定できないことで、何かを犠牲にすることはないんですか?
先輩 当然、あるよ。
まず、接続を受ける側としては相手を一意に識別できないわけだから、門前払いをすることが出来なくなる。
後輩 え~と、、、
たとえば、あらかじめ登録しておいたIPアドレス以外を無条件に弾くという判断が出来ない、ということですか?
先輩 そそ。
あとは、当たり前といえば当たり前だけど、受け側から接続しにいくことは出来ない。
後輩 どっちも、無視できない問題ですネ。
前者はセキュリティ的な問題、後者は機能的な問題。
先輩 前者に関しては相手を識別する部分が完全に欠けてしまうわけではなくて、代わりに「PeerID」という識別子を使う。
接続相手ごとの個別な対応は出来ないけど、PeerIDが合っている相手なら交渉を開始してもいい、という判断は出来る。
後輩 なんか、急に難しくなってきましたネ。
相手と接続するための設定を、メインモードの場合は相手のIPアドレスごとに、アグレッシブモードの場合はPeerIDごとに作るイメージですか?
先輩 おぉ、すごい想像力!
実際、そのとおりだよ。
後輩 やった!
でも、きっと実際は拠点の接続ポリシーって全体で共通にしちゃうでしょうから、固定のIPアドレスの場合でもほとんど同じ設定がズラッと並ぶだけじゃないんですか?
先輩 まぁ、それに近いだろうね。
実際の中身がほとんど一緒でも、接続する可能性があるIPアドレスを事前に登録しておくというところに意味があるわけだ。
後輩 そっか。
アグレッシブモードの場合は相手のIPアドレスを書かないから、代わりにPeerIDが一致した設定が選択されるんですね。
先輩 うん、そう。
後輩 そうなると、PeerIDが合っていないと接続できないんですね。
メインモードと比べて、そんなにセキュリティのレベルは落ちないと考えてよいですか?
先輩 いや、それは甘いぞ。
IPアドレスもPeerIDも、これから接続のための交渉をしてもよい相手かどうか判断するための識別子、であることを忘れちゃいけない。
後輩 あうぅ~
も、もうちょっとヒントください。
先輩 これから接続しようとしている人は、自分に権利があることを受け側に主張しないといけない。
今の話の場合は、IPアドレスかPeerIDのいずれか。
後輩 はい。
先輩 IPアドレスの場合は、主張したIPアドレスを使って通信が成立していれば、いやでも権利が認められるくらいの効果がある。
逆にいえば、事前に設定されていないIPアドレスのパケットは、中身を見るまでもなく門前払いできる。
後輩 はい、そうですね。
グローバルIPアドレスのなりすましは、かなり大変でしょうし。
先輩 この「門前払いできる」というのが大事。
交渉する必要がない相手であることを、要求の一発目で分かる、ということ。
後輩 なるほど、門前払いっていうのはそういうことですか。
そうなると、PeerIDは要求の一発目に書いておかないといけないんですネ。
先輩 そそ。
交渉の前の要求だから、まだトンネルのようなものは出来ていなくて、平文で書いておかないといけない。
後輩 なるへそ、分かりましたヨ。
パケットを見ればPeerIDが分かって、それさえあればIPアドレスが何であろうと交渉の権利を得られてしまう、というところが問題なわけですか~。
先輩 おぉ、正解だ!
もともと暗号化しないと安全ではないという前提の経路なので、平文で書かれている情報に鍵としての機能はない。
後輩 さっき設定の話が出たとき、どうせ拠点の接続ポリシーは一緒だからアグレッシブモードにして設定をひとつにしたら楽なんじゃないか、なんて考えてたんですが。
あさはかでした。。。
先輩 実際にパケットを見るのは難しいかもしれないけど、本気でやろうと思えば出来る。
そういうわけなので、PeerIDがあるからアグレッシブモードでも安全、とは考えないように。
後輩 なっとくです。
ついでに、「識別子」という言葉にはパスフレーズの意味合いがない、っていうことも分かりました。
先輩 ある仕組みの中で結果的にパスフレーズとして使われることもあるかもしれないけど、それは単に使い方の問題。
たとえば、機器などの識別番号であるシリアル番号を思い浮かべてもらえれば、パスフレーズとは関係ないっていうことが分かるだろう。
後輩 確かに。
言葉の微妙なニュアンスの違いが、けっこう大事なんですねぇ。
先輩 微妙な使い方の例だと、「ユーザID」っていう言葉は紛らわしいね。
識別子なんだけど、認証情報として扱われることが多い。
後輩 あ、なるほど~。
なんとなく勘違いされやすいのは、それのせいですね。
先輩 いつもユーザIDはパスフレーズとセットで扱われるから、そう見えちゃうんだろう。
後輩 ユーザIDはユーザを特定するための識別子で、名前と同じような使い方なので、もともと隠すような情報じゃないんですよね。
ユーザ自身がそのユーザIDの持ち主であることを証明するために必要な情報がパスフレーズで、隠さなきゃいけないのはこっちだけです。
先輩 確かに名前すら分からなければ、なりすますキッカケも得られないので、ユーザIDを隠すことに効果があるのは間違いないんだけどね。
でも名前を隠し続けることなんて出来ないから、努力する方向性が少し違うワケ。
後輩 隠すと安全になるっていうところも、パスフレーズと一緒に考えちゃう一因になってるんですネ。
先輩 そうだね。
一般的にユーザIDの文字列を複雑にしないのは、システムを作る人がその辺を理解しているからだよ。
後輩 大抵、社員番号とか苗字と名前とか、ユーザに関連がある文字列を使うことが多いです。
それは認証情報としての効果よりも、ユーザIDがユーザ本人と結び付きが強いことを示すほうが大事だから、ということですね。
先輩 はい、完璧な解釈です。
なんか言葉の説明が多くなっちゃったけど、PeerIDについてはこんなところかな。
後輩 あとは、、、
片方向しか接続できない、っていう話でしたっけ?
先輩 まぁ、片方はIPアドレスが変動するわけだから、当然といえば当然だよね。
いずれの拠点も、常に接続を受けるだけ、または接続しにいくだけ、のどっちか。
後輩 受けるだけの拠点のIPアドレスを、固定にするんですね。
で、IPアドレスの代わりにPeerIDで識別すると。
先輩 うん、そう。
後輩 実際、これで困りません?
先輩 まぁ、困らないっていうことはないだろうけど、、、
回線費用と利便性のトレードオフだねぇ。
後輩 IPアドレスが固定かどうかで、値段って結構違うものです?
先輩 結局こういうのって、チリも積もれば山となる、なんだよ。
拠点がたくさんあったり、使い続ける限り毎月の回線費用に上乗せされるから、単価の差が少なくても掛け算で響いてくるデショ。
後輩 う、う~ん。
おカネの話、苦手です。。。
先輩 拠点あたり1000円の違いでも、100拠点あれば10万円、年間で120万円か。
もし機能面で支障がないなら、検討する価値がある値段じゃないかな。
後輩 イメージ湧きました。
拠点間接続でも片方向で大丈夫な場合って、どんなのですか?
先輩 クライアントサーバ的な構成の場合、かな。
一度トンネルが出来れば、向きに関係なく通信できるので、拠点にクライアントだけしかなければ大丈夫。
後輩 そうか。
常に拠点から通信が始まるような構成なら、問題ないんですネ。
先輩 大抵は本社とかデータセンターにシステムが集まってるから、大体はこのパターンになるんだよ。
後輩 拠点間の通信フローが把握できていれば、安くできるかもしれないんですねぇ。
先輩 基本的には、どうなってもいいように固定IPアドレス取得を提案するけどね。
まぁ、客先環境の構成次第かな。
後輩 あれ、いまさらですけど、、、
IPsecって一対一の接続ですけど、拠点がたくさんある場合はどうやってつなぐんですか?
先輩 あ~、言ってなかったね。
ちょうど構成の話が出たし、次はその話にしようか。
後輩 は~い(*´▽`)

これで、メインモードとアグレッシブモードの話は終了です。
以下、「IPsecによる構成モデル-その1-」につづく。。。

ネットワークセキュリティ関係者の部屋 > ネットワークセキュリティ実践劇場 > メインモードとアグレッシブモード