IPv6biz meeting #4 date: 2001/10/12(Fri) 18:30〜 ---------------------------------------------------------------------------- 18:30〜 Agendaに書かれているのは省略します。 0. 全体 　前回は、議題としてはネットワーク関係の話 ルーティング 認証はどうするか？→これは今回の議題になる。 などをやった。 　宿題→MLの82番 - 何人かが自社のネットワークをv6化するためのモデルを考えてくる 　ことになっている。 →藤本さんはコンビニのネットワークのようなものを想定 →今回６番目の議題として議論する。 1. IPSec 　- 企業のセキュリティの方向性は、通信の中身をみてセキュリティを保つ 　　ようになってきている。 →CodeRedやNimdaなどがあっため。 →このような状況では、IPSecでのホスト-ホスト間で暗号化すると 　いうのは受け入れられがたいのではないか？ →ポリシを集中的に管理して、それを各ホストに配布して、ホスト 　　　　　-ホスト間のセキュリティを維持しつつネットワークのポリシを 　維持するという製品も出てきている。 →ただしV4での話し。 →こういうのはv6でも必要になるのか？ 　- 多くの企業がNATなどで一旦そこで終端して外と通信している。 →そもそも、企業としてトランスペアレントの通信をゆるすのか？ →NATも介在しない。 →管理者としてはセキュリティは分ける。 →外からどうまもるか →自社内でのセキュリティ 　- v6によってネットワークの形態が変わるのであれば、セキュリティの 　　考え方はかわるのか？ →せっかくv6になるのだから、v6ならではのセキュリティを導入 　したい。 →そうはいっても今のネットワークがそのままv6になるのであれ 　ば、セキュリティに対するニーズはかわらないはずである。 →基本的なユーザニーズは、Point to Pointである。 →この場合、外から中はあるのか？ →必要なのは、中から外である。つまり、接続方向によって 　許す許さないなどの例が多い。 →管理者としては、どことどのような通信をしているのかを見たい。 →FWのログは実際に問題があった場合の約に立っていることは間違い 　ない。 　- 管理者として管理したい項目 1. アクセス制限管理 2. 何をやっているかの情報を管理したい →ペイロードの中身を見たいということ →誰が誰にどういうアクセスをしたか？という管理をしたい。 　メールの中身を保持している企業もある。 →このような状況では、暗号化はもってのほかである。 　→SSLはどうする？という問題がある。 　→最大の問題はウイルスチェックである。 →特定の場所に対するアクセスというニーズはある。 →別にネットワークを引いてセキュリティを維持している。 →これは利便性を犠牲にしていることになる。 →本質は特定のネットワークとのセキュアな通信なので、 　ここに対する暗号化通信などは、管理者としても有効である。 →つまりは、管理できることが重要である。 →ランダムな相手に対する暗号化はもってのほかというのが現実 　　　　→end-to-end通信を維持するためにセキュリティを犠牲にすることは 　ありえない。 →文化の変化などで、個人個人でセキュリティを維持するように 　なるのだろうか？もし、そうならありえる。 →現実問題として、会社のネットワークという上では、会社の責任 　を問われる可能性がある以上、ありえないだろう。 →ニーズとして、出張先などから、自社内の自分のホストにアクセスして 　メールをよむなどはある。そういう意味でのトランスペアレントな 通信は必要であろう。 →現状、社内ネットワークに対するダイアルアップなどで対応し 　ている。 →管理者としては、入ってきているものがきちんと管理できれば 　よいので、それは方法は何でもよい、管理ができればよい。 →イントラアクセスをVPNで構築する場合にv4よりもv6のほうがやりやすい 　方法も考えられる。 →VPNで接続してきたときに今はプールアドレスなどを使って 　いるが、v6であれば、アドレスがたくさんあるので、アドレス 　をみると端末が特定できるので、管理が可能と言う意味で 　メリットが見出せる可能性がある。 →モデルとしてFWで終端するモデルと、トランスペアレントな通信して 　必要に応じて止めるモデルの二つがある。これらに違いはあるのか？ →本質的な差はない。ただ、会社の中がすべて見えてしまうことは 　問題であろう。 →セキュリティが完全であれば問題はないが、個々のホストが 　見えてしまうことはそもそもセキュリティが完全でない。 →個々のホストの情報が見えるなど、個人のプライバシー 　の保護もあれば、ここのホストの情報がわかることに 　よって、アタックしやすくなるなどの懸念もある。 →そもそも、end-to-endの方が楽なことは確かである。 →終端することによって生じるデメリットのほうが多い。 →v6はプロトコルが整理されているので、いろいろな面で管理が楽に 　なる可能性はある。 →CodeRedの例をあげると、社内でグローバルアドレスを使っていると 　そこに向かってどんどんアクセスがくる。これによって、ネットワーク 　　　　　が崩壊する。（DOSアタックのようなもの）そういういみでは、 　グローバルアドレスは少ないほうがよい。 　現実にあった問題である。 → ○ 　- FWはあるという前提で考える。この場合に、 　 - イントラのアドレスは何をつかうか？ →グローバルアドレスを使う。 →サイトローカルしかついていないホストが存在する。 →状況に応じて、グローバルアドレスを配るという方法がある。 →この場合の「状況」について議論する必要がある。 - 守らなくてはならないものはなにか？ EUI-64の問題 個人のアドレスが出て行くのは、さけたい。 どこかであきらめないといけない部分が出てくるのではないか グローバルアドレスが割り当てられることで、受け入れなければ ならない部分を議論する必要がある。 ベンダとしてどのくらいまで実装をするか はじめのうちは実装をした。 実装をうまく使ってくれる方向に進むとよいなー ハードの性能問題がある - 要求があればつくる。 - ルータを通る全トラフィックを暗号化なんていうのはさけたい。 - loginの際には必要だけど。 - できれば、専用の箱へ。 IPSecが意外と軽くなってきてる。 - 処理能力が上がってきているのは事実。 IPv6があるところにIPSecがあるとはいいきれないのは事実。 ○相互接続 IPv4とおなじくらいにはやる - headerが違うので、ちょっとたいへん IPv4はいまでもちゃんとつながっていないよぉー - IPv6になったからといって問題は解決しない - でも変わる可能性はある 今作られているのは、端末がアクセスしてくる形態のもの - ネットワークが接続されることはいまのところ想定されていない PKIのような非対称型の認証は管理が楽。 ○next セキュリティ その次でトランジション？ ゴールはなに？ - IPv6になったらこうなるというのをだしたい。 今日の議論である程度はかけるから、それで足りない部分を今度。 セキュリティ合宿〜♪ だれかがまとめてかいて、それをMLでsurveyして、最終形にする。 - 大項目からわけていって、「こうなるぜっ」というのができるといいなぁ IETFのWGの議論をみる？ たたき台をMLになげて、1ヶ月後ぐらいに集中討議をする＠丸一日やる？ - 11/2 13:00 〜 endless（倒れるまで:-) ＠IIJ（暫定）