無印吉澤（※新エントリはhatenablogに掲載中）

■[NAT]IPsecのNAT越えに関するRFC

NAT機器を挟んだノード間でIPsec通信をするための方法に関する2つのインターネットドラフトが、ようやっとRFCになりました。このドラフトについては以前のサイトでもTeredo関係の話題として取り上げたことがありますが、ここで改めて振り返ってみます。

RFC 3947: Negotiation of NAT-Traversal in the IKE
http://www.ietf.org/rfc/rfc3947.txt

こちらは、IPsecのNAT越えを実現するために必要なIKE（Internet Key Exchange）の拡張について書かれたRFCです。IKEのシーケンス中にNAT機器の有無を検査し、ノード間にNAT機器が存在する場合にIPsecのUDPカプセル化へ移行するための手順が書かれています。要点は以下の通り。

• Phase 1でNAT機器の有無を検査し、後に続くQuick ModeでUDPカプセル化に必要な情報を交換する
• NATの存在を検知するための、NAT-Dペイロードを新たに定義する
• NAT変換前のアドレス（Original Address）を通知するための、NAT-OAペイロードを新たに定義する
• 一部NAT製品の特殊な機能（IPsecパススルーなど）を避けるために、シーケンスの途中からポート番号を500から4500に切り替える

RFC 3948: UDP Encapsulation of IPsec ESP Packets
http://www.ietf.org/rfc/rfc3948.txt

IPsecのNAT越えと言っても、正確に言うとIPsec ESPでなければNAT機器を越えた通信は実現できません*1。こちらは、RFC 3947のシーケンスで取得した情報を利用して、IPsec ESP暗号化されたペイロードをUDPヘッダでカプセル化するための方法について書かれたRFCです。要点は以下の通り。

• RFC 3947のシーケンスで利用したポート4500番を引き続き用いて、UDPカプセル化されたパケットを送受信する
• トンネルモードの場合は、カプセル解放後に別途NAT変換が必要な場合がある
• トランスポートモードの場合は、カプセル化されたパケットを受信した側でトランスポートヘッダのチェックサムを再計算する。この計算にはRFC 3947のシーケンスで通知されたOriginal Addressを用いる
• ESPヘッダによって暗号化されたトランスポートヘッダのポート番号は、各ノードが勝手に選択したものである。そのため、あるNAT機器の背後にある複数のノードが同時に特定の外部サーバへアクセスした場合、カプセル解放後のポート番号がノード間で重複する可能性がある

最後の話はこの説明だと分かりづらいと思うので、詳しく知りたい方は本文の方を参照してください。また、こちらのRFCについては日本語訳がYAMDAS Projectにて公開されています。

yomoyomo氏による、RFC3948の日本語訳
http://www.yamdas.org/column/technique/rfc3948j.txt

----

（2004/01/14追記）
"UDP Encapsulation of IPsec ESP"日本語訳のリンク先を、最新のものに修正しました。

■[Web]グループウェアAipo

ここの普段の話題とはあまり関係がないのですが、学生時代の友達がベンチャー企業を立ち上げてグループウェアを開発・販売し始めたと聞いたので、ここでも宣伝しておきます。

グループウェア 『Aipo（アイポ）』
http://aipo.aimluck.com/

Windowsでソフトウェアをインストールするだけで、簡単にグループウェアを運用できるソフトウェアです。僕も試しに自宅のマシンに導入してみたのですが、このサイトに書いてある「3分」もかからずにインストール終了しました。

ユーザ管理や情報共有（スケジュールやToDo）など、グループウェアに必要な機能は一通り揃っているようですので、少しでも興味を持たれた方は是非お試し下さい。最初の60日間は無料で使えて、それ以降はライセンスを購入しての利用になるそうです。

あ、ちなみに僕はお金とか貰ってませんよ。ただ、今週末に大学OBの飲み会があるので、その時は期待してますけどねぇ……（意味ありげに）。

参考：Aipo開発者のブログ - グループウェア 『Aipo』ブログ
http://aipo.aimluck.com/blog/