==== the racoon framework consideration ==== o システムの要求事項 + 鍵交換プロトコルに関する要求事項 - IETFでは複数の鍵交換プロトコルが提案されて標準化されようとしている。 これらは用途に応じて使い分けられるが、それらを繋ぐゲートウェイでは 複数の鍵交換プロトコルを扱う必要がある。 Q. ほんと？SAをSGWで終端するの？ + MIP6に関する要求事項 - MIP6では、home registrationのために HoA-HA間にSAを必要としている。よって IKEは IKE-SAとして CoAを使い IPsec-SAは HoAを設定する必要がある。 - IKE-SAの設定コストを削減するために一旦確立したIKE-SAを移動後も使い 続けること要求している。このため、IKE-SAのアドレス CoAを別の認証済の アドレス CoA'に置き換えられなければならない。 - Optimizedされていない通信において、移動後も通信を維持するために IPsec-SAと SPの CoAを共に CoA'に置き換える仕組みと、それを IKEに知らせる 仕組みが必要である。 - Optimizedされている通信において、移動後も通信を維持するために IPsec-SAと SPの HoAを共に HoA'に置き換える仕組みと、それを IKEに知らせる 仕組みが必要である。 + KAME実装の問題点と要求事項 - SPDのセレクタとしてアドレスやポートの範囲が指定できない。 これはレンジを分解して個別に設定するかプレフィクスを使えば、静的に設定する 場合は目的の動作が期待できると判断したからだった。しかし、IKEv2では、範囲を 正確に相手に伝え、これを文字列として比較しなければならない。また、IKEv1でも 多くの実装は文字列として比較しているので、KAME IPsec実装と相互接続性に問題が あった。 - 静的なSAを使う場合はsetkey(8)でSAとSPを設定し、SAを自動設定する場合は setkey(8)でSPを設定し racoon(8)を起動する。ユーザから見ればIPsecの 使用方法が違うので混乱を引き起こす可能性がある。 - 通信を始めようとする相手のアドレスが変わる事に対応できない。 設定ファイルに FQDNは書けるが、ファイルを読み込んだ時にしか変換しない。 - IKEしかサポートしていないので通信相手毎にプロトコルを変えられない。 - 管理ポートがないので racoon(8)のステータスを知る手立てがログを解析する しかない。 - 実際にパケットが出るまで鍵交換がはじまらない。 静的なVPNでSAを自動設定したい場合に不都合がある。 - per-socket policy baseのSA交換ができない。 - KINKは起動パラメータとしてprincipal name(FQDN)とIPアドレスのペアが必要だが、 racoonは起動にPF_KEYv2のACQUIREメッセージを使っているので IPアドレスしか 受け取れない。 - 透過性がゆえに本当にIPsecが使われているのかユーザには見えない。 「IPsecは、IP層でセキュリティ機能を実現しているので、ユーザは意識せずに 安全な通信ができる。」と矛盾していが… - アルゴリズムやプロトコルの組合せに自由度があるので、逆にユーザは混乱する。 ある程度のセットを定義した方がよいかも。 - racoonの設定ファイルが書き変わった場合、racoonを再起動しなければいけない。 この挙動が良いのか悪いのか。 - racoonが終了すると設定したSAを全て消してしまう。 この挙動が良いのか悪いのか。 - OpenSSLに依存している。static linkすると巨大になる問題と OpenSSLに 依存してていいのか問題。 - NAT-T, XAUTH, mode-configに対応していない。 o アーキテクチャの考察 1つのプラットフォームに複数の鍵交換プロトコルを動かすために、 カーネルからのSA設定要求を受け取り、どのプロトコルで処理するかを 判断するための共有モジュール(racoon)を作る。 複数のモジュールがSA設定要求をカーネルから直接受け取る場合、 どのモジュールでそれを処理するかを、それぞれのモジュールですることになる。 これは管理者がそれぞれを矛盾しないよう設定する必要があるので煩わしい。 racoon は、適切な鍵交換プロトコルを設定ファイルから決定し、 適切なプロトコルモジュールへ要求を出す。 新しい鍵交換プロトコルが出来た場合に備え、各プロトコルモジュールは 別プロセスで実装する。ただし、IKE/IKEv2はポート番号が同じなので 一つのプロセスで実装する。 要求は、racoonメッセージを用いる。 再送ロジックは KINKとIKEv3では異るので別実装にする。 + IKEv2 ポート番号は IKE: 500, 4500 v1, v2 とも 500 番なので、別プロセスに分けると大変。 少なくともネットワーク周りの部分は共通化? IKE-SAが消えたらIPsec-SAも消す IPCOMP TSはレンジだけ lifetimeはポリシ依存。ネゴフィールドがない。 + IKE main mode + pre-shared key では相手のアドレスを事前に知ってる必要がある + KINK ポート番号は決まっていない KINK でも、単に、今まで通りアドレスが下から上がってくるのでは だめなのか? この前は、実装問題だという結論になった。 いや、SPD にポリシーが設定されていないので、 上がってこない。 super daemon が設定ファイルを読み込んだ時点で、 名前を引いて SPD に設定しておくと、、、 相手のアドレスがころころ変わるような状況では 嫌かも。 とりあえず下から address が上がってくるとすると、 KINKは、その起動パラメータにFQDNが必要である。 一方カーネルでは FQDNは IPアドレスに変換されているので この情報をSA設定要求に含める事ができない。 また、カーネル内のSPDにマッチしないので、そもそもSA設定要求を上げることが できない。 これを解決するために共通部分はIPアドレスとFQDNの対応表を持つ。 対応表は名前解決サブモジュールから通知される。 IPアドレスとFQDNの対応が分かった時点でカーネルにSPを設定する。 カーネルからのACQUIREと対応表を照らし合わせてFQDNを取得する。 KDC と client の間の通信は KINKモジュールがやる。中身は plain Kerberos 共通部分からは見えなくてもよい。 Kerberos における principal name や ticket 等の管理は KINKモジュールで 閉じているので共通部分は知らなくてよい。 同じ SPI を使って、IPsecパラメータを書き換えなくてはならない状況がある。 IKE phase 2は getspi <-- ----------------------> spiA spiA使ってね proposal1 2 3 setspi --> spiB <--------------------- spiB使ってね proposal1 ---------------------> ack getspi <-- ------------------------> spiA spiA proposal1 2 3 getspi --> spiB <----------------------- spiB 1 でなく、prop 3 を選んだら? SA:prop3 に書き換える spiA のまま -----------------------> ack + per-socket based SA per-socket policyだと、どの daemon を起動すればよいかわからない。 per-socket policyするアプリが racoonにお願いできる I/F を用意しておく。 99.99 % くらいの人は、バイパスするかしないかくらいしか使わない ので本当にやるかどうかも決める。 2 つの方向。 - プログラム (ライブラリ?) を一から書き始める。 - あるプロセスの子プロセスとして動かす。(per-process になるけど) そのプロセスの下のプログラムはまとめて制御できる。 LD_PRELOAD とかする話? 今の枠組は racoon に穴が合いていて、あるプロセスから このポリシーお願いねといいつつ、パケットを投げる。 per-socket の場合、lib を呼ぶと、lib にポリシーお願いねと いいつつパケットを投げる、という仕組みにすればうまく行きそうだが、 src と dst のポートが決まっていないとうまく行かない。 per-socket で、socket に policy をぶら下げる。 その policy は SPD には入っていない。 racoon に必要なのは、何をするかなので、 「何か」が分かり、下から上がってくる src + dst とその「何か」を 結びつけることができれば何とかなる。 | V appが「src + dst」っぽいのが来たら、このパラメータでお願い というのを racoon にお願いしておく。kernel から上がってきたら、 「src + dst」と、そのパラメータを結びつければよい。 socket を identify する何らかの id をプロセスがとれれば 解決。 ******** 単に「app はパラメータと socket id を racoon に渡す」で OK。 ******** per-process なら pid を渡す? ipsecexec みたいなのをかませて、ppid を見て判別する? --> 宿題 HUP + per-socket policy SA が消えるだけで何も起きない。 アプリケーションはポリシーを racoon2 に渡しているつもりなので、 本当に何も起きなくて、まずい。 アプリケーションからのリクエストは どこかにキャッシュしておく必要がある。 resolver からの (FQDN, addr) 情報と一緒。 racoon が落ちた場合も HUP した場合も、 そのキャッシュを読み直せば、動き続けられる。 後からで考えるでいい + manual keying 先週の話では、 racoon2 + setkey2 racoon2 + manualkeyd + config file の 2 パターンが出た。 setkey の場合にポリシーだけ入れられて、SA がない場合困る。 SPD と SA の対応は racoon (or racoon を叩くコマンド) が責任を持つ。 普通の KEd は、SPD に相当するものを自分でもって、kernel に設定する。 setkey2 では、SA と SPD に相当するものを一緒に racoon に渡して、 セットする。 kernel の中に auto か manual かの区別を持たせて、 manual だったら acquire しないというのはどうか? --> 一番の負荷は SAD をなめることなので、kernel がそのフラグを 持つのは意味がない。 それよりは、setkey などの、前の方の段階でエラーをチェックする方がいい。 /48 でポリシーを書くけど、実際に存在するホストは少しなので、 SA も少ししか設定しない場合、 SA が足りないと言ってエラーになる、というのは嫌。 少なくとも 1 つ SA があれば OK にする。 | V そうした場合、SA がないのにポリシーに引っかかった場合、どうなる。 - acquire があがって、KE しようとして失敗して、次へ進む。 - kernel に no-acquire flag を立てて acquire があがらないようにする。 どちらがいいか。 manual 設定にも 2 つあって、最初から分かっているものと、 あとから追加したいもの。 - 最初から分かっているものは racoon/manual ディレクトリに ずらずら書いておく。 - あとからのものは、 * setkey2 するか * 設定ファイルを書き換えて reload するか | V 設定ファイルを書き換えて reload する方がよい。 setkey2 要らない。 manual の場合でも PF_KEYd が必要? SPD と SAD を同時につっこめとする。 setkey する場合は、SPD と SAD は両方つっこめと言う? backward compatibility: 鍵交換を前提として setkey する人が困る。 - 全く別のものとすればいいのではないか。 racoon2 と setkey2 にしてしまう。 古いのを使いたい人は racoon + setkey にする。 - setkey spdadd は全部 PF_KEYd に投げる setkey1 で SPD だけセットされて、acquire が上がってきたら、 どうするか。setkey1 + racoon2 の組合せは許さないようにする? そもそも setkey2 で、ポリシーと SA 一緒じゃないと突っ込めないようにする というのは、どうやって判断するのか? ポリシーが range になっていたときに、SA が足りないのをどうやって 判断するか。range 分の SA が入っていないと弾くようにする? その range にすべてホストが存在するわけではないので、SA をすべて 書くのは不可能。 e.g.) sp dst=A:/24 で、 sa dst=A::1 A::2 だけの場合、A::3 などがないので、弾くのか? setkey2 は直接行かないで、PF_KEYd にお願いするようにすると 解決するのではないか。 setkey2 する人は racoon2 が必須になるが。 そもそも manual の場合は、setkey1 とか setkey2 とかは使わないことにし、 racoon2 + manualkeyd + manualkeyd.conf で使うように変えてしまうのは? + liveness check on CHILD-SA (draft-ietf-ipsec-ikev2-04.txt) racoon2 の仕組みでやるとしたら、 kernel から racoon2 を通って IKEv2 に liveness check しろ というメッセージをあげられるようにしないといけない。 IKEv2 は自分が交換した SA は覚えておくものか? logic: 生パケットが来て、ポリシーを見て、 SA がなければ捨てる。SA があれば、liveness check する。 のだろう。 だが、「こいつ SA もってるから生パケット投げてやる」のような アタックが可能。 IPsec しているやつに生の echo request を投げる。 インターフェイスとしてはあってもよい。 必要なければ kernel や daemon が無視すればよいだけ。 そのシグナルは PF_POLICY?, PF_KEY? PF_POLICY だと相手が一意に決まらない可能性があるのでだめ。 PF_KEY で上げる。 logic: 生パケットが来たら PF_KEY にフラグを立てる。 上で liveness check する。 - 相手が生きていたら、生パケットが来ることがおかしいので無視。 - 反応がなければ - そんな SA は知らんぞといわれたら rekey する? SA は消してもよさそう。 SA に index を振るというのは、 複数のポリシーが一つの SA とくっつく可能性があるのでできない。 ポリシー 1 にひっかかって SA1 が作られる。 ポリシー 2 に引っかかった時に、SA1 が使えるならそのまま使われる。 そういう SA が expire して、下からあがってきた場合どうする。 ポリシー 1 が使われるだけ。 192.168.0.10 IKEv1 192.168.0.0/24 IKEv2 だと、 ほかのところで、勝手に SA を消されたりして、 困らないのか。 たぶん大丈夫。 + 設定ファイル この相手とは IKE するとか書いておく SPLに準じた設定ができるようにしる。 ユーザの利便性を考え racoonの設定ファイルと静的なSAの設定ファイルを 1つに扱えるようにする。 設定ファイルは、各プロトコルモジュール、racoon で1つにする。 これにより各プロトコルに優先順位をつける等の柔軟な設定も可能になる。 通信相手毎にポリシと鍵交換プロトコル固有のパラメータ等を設定する。 通信相手とはFQDNまたはIPアドレスで識別する。 VPNの様にSAの相手のアドレスが変わらない環境では、racoonが起動時に 設定ファイルを読み込みアドレスに変換して SPD に設定する。 相手のアドレスが変わる場合は、FQDNで記述し名前解決サブモジュールからの 通知によりアドレスが変わっていればカーネルに再設定する。 FQDNで通信相手を記述していて、かつ、DNSのラウンドロビンをしていると、 毎回アドレスが変わってしまうが、これはユーザが予め予想するべきである。 foo.bar が 10.0.0.1, 10.0.0.2 の時に、 telnet foo.bar telnet 10.0.0.1 では挙動が変わる問題。 名前解決のタイミングでSPを設定すると、例えば dig をすると その度に鍵交換が初めってしまうように思われるが、実際は パケットが出る時にSA設定要求が出るので、これは起きない。 しかし、SPは設定ファイルにあれば設定されてしまう。 設定は、各 KEd が持つのではなく、少なくともポリシーの部分は racoon 本体が持つ。 一つにしたいのは、フィルターとしてルールを書いていると、 そのルールが分散していると分かりにくいので。 racoon が読んで、KEd も読むのか、 racoon が読んで、KEd と何らかの通信するのか。 イメージ S1, D1 ESP... IKEv2 des ...パラメータ S2, D2 AH ... KINK S3, D3 ESP... IKEv1 アルゴリズム (sainfo に相当するもの) も policy に含めて書く。 racoon.conf 書き換えて SIGHUP 送ったらどうなる 1 kernel --HUP--> racoon 2 racoon は racoon.conf を reload 3 新しいエントリがあった場合、 --> 今もっているテーブルと比較して判断する。 update を作ろうという話もあった。 新しい config ファイルを使って update する。 --> 今までのエントリは update される。 --> 古いエントリは、いずれ timeout で消える。 結論: 真面目に比較する。 4 SA は全部消す? timeout があるからといって、放っておくわけにもいかない。 DES じゃなくて AES にしたいと config を変更した場合など。 AES, DES という設定で、DES の SA ができたとする。 config が AES, 3DES, DES になって 3DES できる場合、 DES は消してやり直すべき。 古い config file を残しておいて、少しでも変わっていたら SA は消す。 無くなったエントリも判断して SA を消す。 フィルタの順番が変わった場合、どうするか。 1, 2, 3 --> 3, 2, 1 になったら? --> ユーザが番号 (index) を付けられるようにする。 - 「新しいエントリ」が面倒なので、全部忘れる。 SAD, SPD もリセット。 それだと HUP の意味は少ない。 ただの restart。 SPD が消えるのは悲しい。ひねっているつもりが生で出てしまう。 + XAUTH secure id を使おうとして、 wrapper process (ipsec-agent) (ssh-agent みたいなの) を作った時、 鍵交換デーモンとユーザプロセスとのインタラクションが必要。 i.e. challenge が返ってきて、それに応答する必要がある場合。 ipsec-agent は、自分から racoon につなぎにいって、 つなぎっぱなし。 例えば、DISPLAY とか使って、ユーザと 。 2 人が、foo.wide.ad.jp にいて、sh.wide.ad.jp に ログインしようとしたとする。 問題 1. トリガーがかかると、なんとかして、それぞれの ipsec-agent に振る必要がある。 問題 2. でも、2 本の SA を張りにいく、 頑張って、kernel に突っ込もうとする。A, B とする。 foo.wide で A, B の順でつっこもうとした。 sh.wide で B, A の順で突っ込もうとした。 --> 問題なし。 *** ちょっとまて *** ユーザの認証の元で SA を入れたのに、 今の SAD の構造では、せっかく入った SA が、誰が作った ものかという情報が失われてしまう。 今の SA のなかに、ユーザの情報が必要か? road-warrier の場合はなくてよい。 secure id 認証機構を使って張った SA は、 そのユーザが出すパケットすべてに適用したい。 1 ホスト 1 ユーザ (切替えは可かも) という制限を掛けるのが楽? 1. XAUTH は road warrier の問題を解くため「だけ」だと思っていいか? yes 2. そうだとすると、1 ホスト 1 ユーザだと思っていい? yes なら、ipsec-agent は、1 プロセスしか動かないようにしておくだけでよい。 XAUTH が必要なら、そのプロセスに投げる。 ipsec on みたいな操作 1. ポリシーを racoon に突っ込むという操作だと思うと、それでいい。 2. ipsec on で SA も張ってしまうと思うユーザもいるかも。 例えば、ipsec on したあと、パスワードを入れようと 待ち構えているんだけど、パケットを出さないので、 いつまでたってもダイアログが出てこない。 user が racoon をつつくと、acquire があがるというのは? 制限を掛ける必要がある。 port 単位、user 単位なら ok くらいの制限 「つつく」のは policy を突っ込むだけ。 acquire は管理者が行なう。 user が host ベースの SA を張ることを許すかどうかを racoon で設定できるようにする。 racoon で multiuser mode / road-warrier mode を切替える。 multiuser mode の場合、user 単位や port 単位で しか SA を張れないようにする。 multiuser のときに、ipsec on dest=sh.wide.ad.jp みたいなことを するなら、SA にユーザはいる。 policy にユーザを入れるのでも構わないか? 可能か? 管理者が入れた policy とユーザが入れた policy の整合性を とる問題は、また別の問題として存在する。 policy id と SA id (SPI ではない) は別。 policy id はフィルタの順番。 厳密にいうと、SA id は、SPI を抜いた src, dst で一意。 A ------| +-SGW ----5-----> SGW ---- B | ----6-----> A' -----| policy id SA id 1 A -->B 5 2 A'-->B 6 + mode config アドレスをプールするか DHCP relayをサポートしないといけない o source address selection 問題 i1+-----+i2 i3+-----+i4 ------| GW1 |=========| GW2 |------ +-----+ +-----+ 1. i2-i3間で i1,i4のためのSAをはる 2. GW1からGW2 i4 に pingすると生で出ちゃう ipsec のせいじゃない。 source address selection の問題。 無視していい? --> 無視 o mibile-ipv6 のSA Mobile NodeとHome Agent間にtunnel modeとtransport modeの2つのSAが張られる。 +-------------+ +------------+ +--------------+ | Mobile Node | | Home Agent | | Corres. Node | +-------------+ +------------+ +--------------+ CoA HoA HA CN | | transport mode | | | +======================+ | +=============================+ tunnel mode transport mode の SA KMPのパケットは CoA <=> HA間 SAを通るパケットは HoA <-> HA next header = 62 ※extension headerの最後が 62 でしたっけ？ tunnel mode の SA KMPのパケットは (CoA または HoA) <=> HA 間 HoAを使うと: Mobility Headerが必要なので帯域を使う。 3GPP側で受け入れられない。 CoAを使うと: 移動するとIKE-SA交換をしなおさなければいけない。 ただし CoA は変わるのでメタな文字列で表現する SAを通るパケットは HoA <-> CN MN では以下の SP を設定する HoA HA 62 -P out ipsec esp//transport/require; HA HoA any -P in ipsec esp//transport/require; HoA CN any -P out ipsec esp/CoA-HA/tunnel/require; CN HoA any -P in ipsec esp/HA-CoA/tunnel/require; HA では以下の SP を設定する HA HoA any -P out ipsec esp//transport/require; HoA HA any -P in ipsec esp//transport/require; CN HoA any -P out ipsec esp/HA-CoA/tunnel/require; HoA CN any -P in ipsec esp/CoA-HA/tunnel/require; KMPで使う相手の識別子(例えば IKEのphase1) HA の識別子は IPアドレス(HA) MN の識別子は IPアドレス(HoA) API KMPデーモンが Mobile Nodeの CoAを知る仕組みが必要 ==== the racoon2 specification ==== o racoon2 framework カーネルからの要求を各プロトコルデーモンに振り分けるモジュールと 各プロトコルデーモンに分けられる。前者を racoonと呼ぶ。 カーネルからの要求は PF_KEYv3 を使う。 racoonと各プロトコルデーモン間のメッセージは racoon I/Fを使う。 1. 各 KEd が自分の管理する key (名前/addr) を PF_KEYd に登録する。 2. PF_KEYd に hostA: KINK addrX: IKEv1 hostB: IKEv2 のような表ができる。 一番簡単な場合、 telnet sakane.tanu.org した場合、 その人は、sakane.tanu.org の root telnet --> resolver --> DNS proxy --> PF_KEYd FQDN, addr PF_KEYd は表を見て FQDN があれば、SPD に設定。 SPD に設定したら返事を返す。 アプリケーションから見ると、単に名前を引くのが少し遅くなるだけ PF_KEYd は名前(なんらかの index)とaddrのペアを覚えておく。 2 回目移行はそのペアに変化がなければ、SPD はいじらなくてよい。 PF_KEYd の cache はいつ消すの? 単に timeout すればよいのでは? SPD はいつ消すの? 消す必要がある? SPD が永遠に増え続けるという仮定でいいのか。 アドレスが変わった場合、 PF_KEYd が古いのを消して、新しいのを入れる。 PF_KEYd が cache を持っていなくて、 SPD が timeout するんだったら簡単。 PF_KEYd が名前/addr のペアを cache しておいたとしても、 なぜ SPD を消せないのか。 - DNS round robin あるプロセスが yahoo と通信している時、 他のプロセスが yahoo を引くと、 前のアドレスが抜かれて、困る。 expire したら? どの SA が expire したかが上がってくるので、policy を見てうにゃ。 IKEv1 に A::/56 と書いてあったとする。 A::1 に対する通信が発生したら、 A::1 が上がってきたら、PF_KEYd の cache を先に見て、 ホスト名にし、デーモンポリシーを見て検索するのか? オプションにする? どのポリシーにマッチして設定されたのかを覚えていて、 acquire 時にそれも一緒にあがってくると、 一発で検索できてうれしいのではないか? expire したときは? 複数のポリシーから参照されている SA だと? manual だとありえる。 自動鍵管理だとありえないか? SA --> ポリシーが一意に決まれば便利ではないか? telnet sakane.tanu.org した時に PF_KEYd addr table sakane.tanu.org --> 192.168.1.1 PF_KEYd daemon policy 192.168.1.0/24 --> IKEv2 SPD 192.168.1.0/24 --> appl app が 192.168.1.1 を使うと SAD を引いて、ないので acquire が上がってくると、もう一度 daemon policy を引くのは面倒。 daemon policy *.tanu.org --> KINK 192.168.5.6 (.tanu.org にあるとする) だけ --> IKEv2 みたいな書き方をしたい? これをやろうとすると、 今の policy は一つで、設定は各 KEd にまかせるのがよい? 直接 setkey すると? rekey どのポリシーを使ったのかという関連づけを用意すればできる。 KAME は関連づけている (acquire の中に入れる) racoon は SPD が変化したタイミングでポリシーを吸い上げている。 racoon2 では、kernel のコピーをもつというよりは、 kernel にコピーを突っ込むという感じ。 で、normal な場合はいいが、 socket base になると、kernel が本体ではないので、破綻しそう。 ユーザがポリシーまで指定できるのか、 confidentiality flag, authentication flag をつけるだけなのか。 + integrity flag も。 telnet shoichi@sakane.tanu.org acquire が上がる。 PF_KEYd の pocicy table にはポリシーがないので、 どうしていいか分からない。 ポリシーが見つからない場合、 カーネルに聞きに行くという仕組みにしておくと、どうだろう。 or kernel にポリシーの master copy を置いておいて、 いつも聞きに行くのは? アプリケーションが KINK 使いたいとか、そこまで指定する場合が あるか? 今の枠組で行くなら、lib を一つ作って、 関数の引数で daemon を指定できるようにしてみる。 --> 次回これも検証。 racoon2 が落ちたら? 起動したら一旦 SPD を消しにかかる? manual 消してしまわないか? 何も考えずに、普通の起動シーケンスが動いて、 上書きしにかかればいいのではないか。 手で setkey2 するオペレーションは無しにして、 設定ファイルを書けということにすると、できる。 再起動した時は、kernel から SPD を吸い上げて、racoon2 が 管理しているものと比べて conflict していないものは残すという のが出来れば、親切か。(面倒だが) SPD を上書きするモードを作るのは? PF_KEY には add, del しかない。update はない。 add してみて EEXIST が返ってきたら、manual か何かが あると思って、置いておく。 正常終了する場合は SPD をクリアして終る。 --> これは、本当に真? これが真なら、異常終了の場合もクリアしていいような気がする。 では、異常終了したあと、設定を書き換えられて、再起動されたら? bypass ルールなんかが残るのは嫌。 manual の場合も PF_KEYd を通るので、 全部クリアで OK。 ポリシインデックスは 1 - 0x7fffffff は管理者が使える。 0x80000000 - 0xfffffffe はカーネルが使う。 0 を指定するとカーネルが勝手に割り振る o 設定ファイル TS payload 1. 設定ファイルにはレンジを書いておく。 i.e. policy 100 10.1.0.1 10.0.0.1-1.0.0.3 out esp ... ※ 100はポリシID 2. カーネルにはこれまでの様にばらして設定する i.e. spdadd 10.1.0.1 10.0.0.1 out -P ipsec esp ... /unique:100 spdadd 10.1.0.1 10.0.0.2 out -P ipsec esp ... /unique:100 spdadd 10.1.0.1 10.0.0.3 out -P ipsec esp ... /unique:100 3. カーネルから上がってくるポリシID(=100)で設定ファイルのレンジを 導き出し相手に送る。 4. 相手からレンジが来たら設定ファイルのレンジをチェックする。 1. ポリシーは addr ならそのまま SPD へ。 FQDN なら resolv して SPD へ。 同時に PF_KEYd で保持。 responder側は、TS受けたときに FQDNを展開して比較する。 IKEが終ったら SPDに突っ込む anyで受けると、TSに書かれたアドレスをSPDに突っ込む anyのノードが出し側の時は、現在のIPアドレスを書く。 o racoon2 I/F admin I/F で欲しいメッセージ SAD を吸い出すとか [picture 2] resolver --> PF_KEYd 1. FQDN, addr PF_KEYd --> KEd 1. acquire FQDN, addr 2. notify source addr (3. get src addr list) --> 要らない。 (4. expire) 上にあげる必要があるか? SA を子 daemon が忘れてよいのなら、 あげる必要はない。(acquire すればよい) --> 要らない。 KEd --> PF_KEYd 1. register supported host/addr policy 2. getspi 3. error 4. add SA 5. del SA 6. update SA ? PF_KEYd は 2 番めの policy は入れない。 per-socket policy は今はできない。 per-socket policy socket にポリシーがぶら下がっている場合、 したから acquire は上がってくるが、各 daemon がどういう ポリシーなのかということを知ることができない。 get policy を実装した場合でも、 上がってきたリクエストが本来自分が持っているポリシーなのか、 per-socket なポリシーなのかが判断できない。 各 daemon がポリシーを下に投げるときに kernel に pid も教えておく。kernel がポリシーをなめるときに pid がわかるので。 KM_REGISTER 各鍵交換daemonが起動時にracoon送信する。 担当する鍵交換プロトコルをracoonへ登録する。 racoonはカーネルがサポートしている暗号アルゴリズムを渡す。 o コマンド racoon2 racoon2ctl (option) racoonとのユーザI/Fコマンド option: check_config 設定ファイルをチェックする カーネルが使える暗号アルゴリズムと矛盾しないか setkey2 pfkey_dump pfpolicy_dump o racoonの設定ファイル フィルタの設定 IPsec-SAのアルゴリズムの設定 カーネルがサポートしている暗号アルゴリズムは分からないので、 check_config コマンドで事前にチェックできる。 racoon起動時もracoonはチェックする。 o racoonの動作 + 起動時 起動時にカーネルに対しSADB_REGISTERし、暗号アルゴリズムのリストを得る。 各プロトコル間の優先順位の設定はどうする。 daemon が起動した順 --> restart のときなど面倒で駄目。 設定ファイルを用意すればいいだけの話だと思う。 o 既存KMPdとの共存 + racoon1 racoon1 が自分で SPD に勝手に突っ込む。 racoon2 にとって、自分の持っている (master だと思っている) db と、 SPD が矛盾する。 すくなくとも、racoon2 が知らないポリシーが SPD に有っても 問題ない。 SPD を勝手に flush しちゃうやつがいると問題。 racoon2 without IKEv1 と racoon1 を使うと、 racoon1 は落ちる時に flush しに行くので、SPD 消えちゃう。 ただ、racoon2 は flush されたことは分かるので、再設定することはできる。 racoon/racoon2 を同時に動かした時 racoon: PFKEYv2, IKEv1 racoon2: PFKEYv3, KINKモード なら動くはず + pluto FreeS/WAN はポリシーの番号を持っていない。 pluto を動かすと、最初に discard な filter を設定して、 sa を交換すると、それを update する。 メッセージの番号さえあっていれば、racoon2 が来ても 動くはず。でも全体としては動かないかも。 pluto の設計思想は、外につくヘッダ 1 つにつき 1 つの sa として扱う。 ESP, AH, 外側の IP ヘッダ それぞれ sa として扱う。 + isakmpd