NetBSD IPsec FAQ

このページは作成中ですので、 コメントや提案を歓迎します。

IPsec FAQ

• はじめましょう
• IPsec = AH + ESP + IPcomp + IKE
• トランスポートモードとトンネルモード
• IPsecポリシー管理
• IPsecカーネルの設定
• 設定例: ホスト間の暗号化
• 設定例: ホスト間の認証
• 設定例: ホスト間の暗号化+認証
• 設定例: IPsec VPN
• 設定例: 葉ノードトンネル
• IKEによるAH/ESP鍵の設定
• ブート過程で IPsec 手動鍵とポリシーを設定する
• ipfilter との相互の影響
• 処理順序
• ありがちな落とし穴と、デバッグの技巧
• 既知の問題
• 標準化、互換性への適合
• 他のIPsecスタックとのAPI互換性
• 書籍その他の読みものは ?

他のリンク

• 雑多なリンク

---

IPsec FAQ

はじめましょう (トップ)

IPsec (IP security protocol) は、 NetBSD 配布物の一部として含まれており、 IPsecが提供するパケット毎の認証/機密性は、IPsecを使用して通信するpeer間通信を保護します。 IPsecは IPv6とIPv4で利用可能です。

しかしIPsecを使用するには、カーネルの再構成が必要であることに注意して下さい。 それはGENERICカーネルでは有効にはなっていません。

ユーザーランドにはIPsecサポートコードが含まれていますが、 IPsecをサポートするカーネルからサポートしていない カーネルに切り替えても、ユーザーランドの再コンパイルは必要ありません。

IPsec = AH + ESP + IPcomp + IKE (トップ)

IPsecは以下に挙げられる別々のプロトコルで成り立っています。

AH、ESP、IPcompはカーネルに実装されています。 IKEはユーザーランドでデーモンプロセスとして実装されています。 カーネルとユーザーランドは、鍵管理テーブルを通して協調しています。

IKEはオプションです。AH/ESPのために手作業で鍵を構成することができます。 しかし、同じ鍵をずっと使い続けることはできないことを理解して下さい。 もし長い間同じ鍵を使うなら、トラフィックが危険にさらされる可能性がますます高くなります。

ふたつの RFC が出ています: RFC1825 による古い IPsec と、 RFC2401 による新しい IPsec です。 NetBSD ではいずれも実装していますが、新しい IPsec を使うよう推奨します。

        userland programs               IKE daemon
          ^ | AF_INET{,6} socket          ^ | PF_KEY socket
========= | | =========================== | | ======== Kernel/user boundary
          | v                             | v
        transport layer, TCP/UDP        key management table
          ^ |                             ^ | key information
          | |                             | |
          | v                             | v
        IP input/output logic <-------> AH/ESP/IPcomp logic
          ^ |
          | v
        Network drivers (ethernet)

トランスポートモードとトンネルモード (トップ)

AH, ESP そして IPcompにはトランスポートモードとトンネルモードの2つの操作モードがあります。 トランスポートモードは、通常のピア間の通信を暗号化します。 トンネルモードは、パケットを新しいIPv4/6ヘッダーの中にカプセル化します。 トンネルモードは、VPNゲートウェイで使用できるように設計されています。

[[トランスポートモード]]
my host ======== peer's host
        transport
        mode

packets: [IP: me->peer] ESP payload
                        <---------> encrypted


[[トンネルモード]]
        (a)                  (b)                        (c)
my host ---- my VPN gateway ======== peer's VPN gateway ---- peer's host
                            tunnel mode

packets on (a): [IP: me->peer] payload
packets on (b): [IP: mygw->peergw] ESP [IP: me->peer] payload
                                   <------------------------> encrypted
packets on (c): [IP: me->peer] payload

IPsec“ポリシー”管理 (トップ)

カーネルはパケットをセキュアーにする方法を知っていますが どのパケットがセキュリティーを必要とするか知りません。 我々はどのパケットをセキュアーにするかをカーネルに示す必要があります。 IPsec“ポリシー”設定によりそれらを指定します。

IPsecポリシーは、パケット毎またはソケット型毎に設定できます。

IPsecポリシーはパケットに対して使われるプロトコル(AH、ESPまたはIPcomp)を決定します。 パケットに対してAH、ESP、IPcompのどの組み合わせを使用するカーネルなのかを構成することができます。 ひとつのパケットに対して、多数のESPオペレーションのような、 同じプロトコルを複数回にわたって適用することができます。 多数のESPオペレーションが役に立つかどうかはわかりません。しかしテスト/デバッグには興味深いのですが。

IPsecカーネルの設定 (トップ)

作成手順の詳細はNetBSD-currentの追跡を参照して下さい。

ユーザーランドのツールはデフォルトで IPsec サポートを含んでおり、 また、ユーザーランドの再構築は不要です。

さらに、 NetBSD 附属の racoon(8) を使ったり、 security/isakmpd をインストールしたりするのもよいかもしれません。

設定例: ホスト間の暗号化 (トップ)

もしマニュアルで設定した鍵でホスト間の暗号化(トランスポートモード)を行うなら、 下記の構成で充分です。マニュアルで鍵を設定するために setkey(8) を 使用します。

#! /bin/sh
#
# packet will look like this: IPv4 ESP payload
# the node is on 10.1.1.1, peer is on 20.1.1.1
setkey -c <<EOF
add 10.1.1.1 20.1.1.1 esp 9876 -E 3des-cbc "hogehogehogehogehogehoge";
add 20.1.1.1 10.1.1.1 esp 10000 -E 3des-cbc 0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;
spdadd 10.1.1.1 20.1.1.1 any -P out ipsec esp/transport//use;
EOF

最初の2つの行は、ESPで使用する鍵を設定しています。 4番目の数字は SPI(セキュリティー・パラメーター・インデックス)と呼ばれています。 この値はESPパケットに付加され、受信した側でパケットから鍵を見つけるために送られます。 この値はノード上でユニークである必要があります。

最終行はノードのパケット毎のIPsecポリシーを設定しています。 この設定で、node(10.1.1.1)からpeer(20.1.1.1)に送られるパケットは暗号化されます。鍵はカーネル内部 で構成されます。 この設定は、20.1.1.1から10.1.1.1に届く暗号化されていないパケットを禁止していません。 もし暗号化されていないパケットを拒否したい場合、次の行を追加して下さい。

spdadd 20.1.1.1 10.1.1.1 any -P in ipsec esp/transport//require;

もう一方の (20.1.1.1) では、次のように設定します。 “spdadd” 行のアドレスを入れ換える必要がある一方、 “add” 行は入れ換えないことに注意してください。

#! /bin/sh
#
# packet will look like this: IPv4 ESP payload
# the node is on 20.1.1.1, peer is on 10.1.1.1
setkey -c <<EOF
add 10.1.1.1 20.1.1.1 esp 9876 -E 3des-cbc "hogehogehogehogehogehoge";
add 20.1.1.1 10.1.1.1 esp 10000 -E 3des-cbc 0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;
spdadd 20.1.1.1 10.1.1.1 any -P out ipsec esp/transport//use;
EOF

ポリシー設定の構文は ipsec_set_policy(3) で述べられています。

回線上の暗号化されたパケットを見るために tcpdump(8) を実行して下さい。 パケットは暗号化されます。それらのパケットを盗聴することはできません。

上記の例は人間が読むことができる鍵を使います。 しかしながら、人間が読むことができる鍵の使用がバイナリー鍵より危険であることから、 実際のオペレーションでは、バイナリー鍵を使用する方がいいでしょう。

鍵の長さはアルゴリズムによって決定されます。 3des-cbcでは、鍵は 192 ビット(=24バイト)でなければなりません。 もしそれより短いまたは長い鍵を指定するなら、 setkey(8) はエラーになるでしょう。

他のアルゴリズムを使う場合、設定はほとんど同じです。 rijndael-cbc (AES としても知られる) を使う場合の例を示します。 rijndael-cbc の秘密鍵は、 128、 192、または 256 ビットとなります。 ここでは、 128 ビットの鍵を使うことにします。

#! /bin/sh
#
# packet will look like this: IPv4 ESP payload
# the node is on 10.1.1.1, peer is on 20.1.1.1
# rijndael-cbc with 128bit key
setkey -c <<EOF
add 10.1.1.1 20.1.1.1 esp 9876 -E rijndael-cbc "hogehogehogehoge";
add 20.1.1.1 10.1.1.1 esp 10000 -E rijndael-cbc 0xdeadbeefdeadbeefdeadbeefdeadbeef;
spdadd 10.1.1.1 20.1.1.1 any -P out ipsec esp/transport//use;
EOF

設定例: ホスト間の認証 (トップ)

ESPと同じように、AHを設定することができます。

#! /bin/sh
#
# packet will look like this: IPv4 AH payload
# the node is on 10.1.1.1, peer is on 20.1.1.1
setkey -c <<EOF
add 10.1.1.1 20.1.1.1 ah 9877 -A hmac-md5 "hogehogehogehoge";
add 20.1.1.1 10.1.1.1 ah 10001 -A hmac-md5 "mogamogamogamoga";
spdadd 10.1.1.1 20.1.1.1 any -P out ipsec ah/transport//use;
EOF

設定例: ホスト間の暗号化+認証 (トップ)

もしAHとESP双方で鍵を設定した場合、双方とも使うことができます。 IPsecのドキュメントでは、AHの後にESPを適用することを推奨しています 。

#! /bin/sh
#
# packet will look like this: IPv4 AH ESP payload
# the node is on 10.1.1.1, peer is on 20.1.1.1
setkey -c <<EOF
add 10.1.1.1 20.1.1.1 esp 9876 -E 3des-cbc "hogehogehogehogehogehoge";
add 20.1.1.1 10.1.1.1 esp 10000 -E 3des-cbc 0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef;
add 10.1.1.1 20.1.1.1 ah 9877 -A hmac-md5 "hogehogehogehoge";
add 20.1.1.1 10.1.1.1 ah 10001 -A hmac-md5 "mogamogamogamoga";
spdadd 10.1.1.1 20.1.1.1 any -P out ipsec esp/transport//use ah/transport//use;
EOF

設定例: IPsec VPN (トップ)

まず最初に、いくつかのIPsec VPN設定に関しての注意点があります。

以下の例は以下のようなネットワークの設定を仮定しています。 この例の最終目的は:

((( 10.0.1.0/24 )))     東京支店オフィスのVPNネットワーク
  |10.0.1.1
gateway 1
  |20.0.0.1
  |IPsec tunnel
  |20.0.0.2
gateway 2
  |10.0.2.1
((( 10.0.2.0/24 )))     ニューヨーク本社のVPNネットワーク

以下のテキストはgateway 1の設定を示します。

#! /bin/sh
#
# Note that routing should be set up in advance, i.e. for this example:
#       route -n add -net 10.0.2.0 10.0.2.1
#       route -n add 10.0.2.1 10.0.1.1
# packet will look like this: IPv4 ESP IPv4 payload
# the node is on 10.0.1.1/20.0.0.1, peer is on 10.0.2.1/20.0.0.2
setkey -c <<EOF
add 20.0.0.1 20.0.0.2 esp 13245 -E blowfish-cbc "blowfishtest.001" ;
add 20.0.0.2 20.0.0.1 esp 13246 -E blowfish-cbc 0xdeadbeefdeadbeefdeadbeefdeadbeef;
spdadd 10.0.1.0/24 10.0.2.0/24 any -P out ipsec esp/tunnel/20.0.0.1-20.0.0.2/require ;
spdadd 10.0.2.0/24 10.0.1.0/24 any -P in ipsec esp/tunnel/20.0.0.2-20.0.0.1/require ;
EOF

(この項は Per Harald Myrvang の寄贈によるものです)

設定例: 葉ノードトンネル (トップ)

トンネルモードは、ある葉ノードからの全トラフィックを次ホップのルーターまで 暗号化し、逆にルーターからのトラフィックは平文化する、 という状況で使うことができます (たとえば、 802.11 WEP では不十分なので、 ワイヤレスノードからルーターまでの間で使うなど) 。

葉ノードでは、以下のように使います:

#! /bin/sh
#
# the node is on 10.0.1.5, router is on 10.0.1.1
setkey -c <<EOF
add 10.0.1.1 10.0.1.5 esp 1011 -E rijndael-cbc "rijndaeltest.001" ;
add 10.0.1.5 10.0.1.1 esp 1012 -E rijndael-cbc 0xdeadbeefdeadbeefdeadbeefdeadbeef;
spdadd 10.0.1.5/32 0.0.0.0/0 any -P out ipsec esp/tunnel/10.0.1.5-10.0.1.1/require;
spdadd 0.0.0.0/0 10.0.1.5/32 any -P in ipsec esp/tunnel/10.0.1.1-10.0.1.5/require;
EOF

ルーターでは、 spdadd コマンドの “out” と “in” を逆にします。

IKEによるAH/ESP鍵の設定 (トップ)

まずは下記の設定について説明します:

どうか慎重に下記の手順をふんでください。 tcpdump(8) を使い、 2 ノード間でどのようにパケットが交換されているか調べます。 “netstat -sn” による統計情報も、 カーネルの IPsec 部がどのように動作しているか知るために有用です。

racoon は、ポリシー定義に基づいて鍵を交渉します。 ポリシー定義を変更することで、これ以外のケースに対しても容易に設定できます。 次の例は、下記の状況向けに鍵を設定するものです:

設定するうえでなにか問題があったら、フルデバッグログ (racoon -dddddd) をしっかり見て、どこが原因か調べてください。 いかなる設定の違いも、交渉の失敗につながります。

ブート過程で IPsec 手動鍵とポリシーを設定する (トップ)

rc.conf(5) には、 “ipsec” という IPsec 用のエントリーがあります。 ipsec=YES とすると、ブート時に、すべてのネットワークが有効になってから 次のコマンドを実行します:

/sbin/setkey -f /etc/ipsec.conf

たとえば、 /usr を暗号化して NFS マウントすることができます。 /etc/ipsec.conf の内容は、正当な setkey(8) コマンドでなければ なりません; 上記の設定例から、 setkey -c <<EOF と EOF の部分を除いた部分のようにします。

ipfilter との相互の影響 (トップ)

NetBSD は、 Darren Reed による ipfilter、 ipf(4) を実装しています。 ipf(4) はパケットをふるいにかけ、また、 IPsec ポリシーの作用は本質的に パケットフィルターと同じものです。 したがって、これらの実装は機能的に衝突します。 ipf(4)/IPsec 相互の影響は、以下のとおりとなっています: ipf(4) は、ネイティブのワイヤーフォーマットのパケットのみを監視します。 ipf(4) は、入ってくるパケットは IPsec の処理前のものを、 出てゆくパケットは IPsec の処理後のものを監視します。

この処理順序のもとでも、以下のことを知っておいてください:

処理順序 (トップ)

下記の図は、受信側の新しい処理順序をまとめたものです。

入ってくる場合の処理:
        userland programs               IKE daemon
          ^ AF_INET{,6} socket            ^ | PF_KEY socket
========= | ============================= | | ======== Kernel/user boundary
          |                               | v
        transport layer, TCP/UDP        key management table
          ^                               ^ | key information
          |                               | |
          |                               | v
  +-----IP input/output logic <-------> AH/ESP/IPcomp logic
  v       ^          ^                      |
tunnel    |          +----------------------+ decapsulated IPsec packets
devices   |
  |     ipfilter rule
  |       ^
  +------>|
          |
        Network drivers (ethernet)

下記の図は、送信側の新しい処理順序をまとめたものです。

出てゆく場合の処理:
        userland programs               IKE daemon
            | AF_INET{,6} socket          ^ | PF_KEY socket
=========== | =========================== | | ======== Kernel/user boundary
            v                             | v
        transport layer, TCP/UDP        key management table
            |                             ^ | key information
            |                             | |
            v                             | v
  +---->IP input/output logic <-------> AH/ESP/IPcomp logic
  |         |                           (incl. IPsec tunnel encapsulation)
tunnel      |
devices     |
  |     ipfilter rules
  |         |
  +---------+
            v
        Network drivers (ethernet)

ありがちな落とし穴と、デバッグの技巧 (トップ)

既知の問題 (トップ)

標準化、互換性への適合 (トップ)

KAMEのIPsecの実装(NetBSDツリーに含められる)が、最新のIPsec標準に適合しています。 KAME の NetBSD 実装ノート には、実装するための包括的な標準化文書があります。

他の実装との互換性が、さまざまな場所で確認されました。 KAME の NetBSD 実装ノート に含まれる実装は、過去に互換性は確認されたものです。 しかし、互換性のテスト後にコードは変更される可能性がありますので、互換性がなくなっている可能性もありますので注意して下さい。 NetBSDデバイスとpeerデバイスがある特定の構成のみで互換性をとることも可能です。

もし他の実装でNetBSDデバイスを設定する場合、そのIPsecの仕様/実装には多くの難点があることに注意してください。 互換性を取るためにはpeerのデバイスと同じデバイスでNetBSDデバイスの構成を設定する必要があります。

他のIPsecスタックとのAPI互換性 (トップ)

IPsecの知識がありユーザーランドのコードを書きたいなら、あなたはIPsecプラットフォーム間のAPI互換性について知りたくなるでしょう。

我々はカーネル内に鍵データベースを操作するために RFC2367 PF_KEY APIを持っています。 このAPIの基本的な部分は他のUNIXベースのIPsecスタック上で利用可能であり、そしてある程度(例えば、OpenBSDが同様にPF_KEY APIを実行する)の互換性があるかも知れません。 かめIPsecスタックが、他のグループがそうするのと同じように、ある特定の方法でこれを拡張します。 拡張された部分は他の(非かめ)IPsecスタックと両立できません。

IPsecポリシー管理APIの仕様書ドキュメントはありません。 それ故に、IPsecポリシー管理APIで(非かめ)IPsecスタックとの互換性を想定することができません。

設定ファイルの書式の標準がありません。 NetBSD 以外の IPsec デバイスとの間で設定をコピーしたい場合は、設定ファイルの書式を変換する必要があるでしょう。

NetBSDとFreeBSDは同じ原点(かめ)からIPsecコードベースを共有するため、API互換性があります。 しかしながら、異なった日付のかめコードをマージした時点で、NetBSDとFreeBSDのIPsecコードには違いが生じます。 標準的なユーザーランドアプリケーションがその違いを認識する必要はありません。 ただし、 IPsec key management daemons の実装をするのであれば、 PF_KEY API の差異を考慮する必要があるでしょう。

NetBSD 1.4 から 1.5 までの NetBSD-current の開発において、 KAME の IPsec 部分を 3 度にわたって導入しました。 この導入には、後方非互換な API の変更を含んでいます。 1.4 から 1.5 までの NetBSD-current を使う場合は、 それが最新のコードを使っているか確認してください。 NetBSD 1.5 では、 NetBSD 1.5 で提供される API について、 完全なバイナリー互換または API バージョンチェックを実現する予定です。

書籍その他の読みものは ? (トップ)

文字どおり、山ほどの書籍が出ています。

---

他のリンク

雑多なリンク (トップ)

---

Back to  NetBSD ドキュメンテーション: ネットワーク