$Id: memo-kame-ipsec-memo.txt,v 1.1.1.1 1999/10/26 17:19:17 sakane Exp $ %Hd: KAME IPsec MEMO ======================================== SPD o draft では… in/out 毎に SPD/SAD が１つづつ必要とある。 interface 毎に IPsec の on/off が必要とかと書いてあるが。 o setsockopt でIPsec使う！と宣言されている時に、 受け取ったパケットが、どうだったか知りたい場合がある。 パケット(mbuf)単位で {AH,ESP} されてい{る,た}か知りたい。 mbuf に履歴フラグを立てる？。 o source port が 0 のパケットが存在するので、 現状の無指定を別の値にしないとダメかもしれない。 ======================================== SAD dir を決めるときに key_checkdir は使わない。 なぜならば、bi-direction を除くと殆んど方向が決まっているから。 -> なんのことだっけ？ sa->seq って何物？ see. PF_KEY あれ？なんで key_ismysubnet を使ってんだっけ？ SAを設定する時、SAのdst,srcがnetmask付きで指定されているので。 SA <=> so の木があっても良いかもしれない。(NRL式) SADB と SPDB 併せて、SA なので要らない！ o source port が 0 のパケットが存在するので、 現状の無指定を別の値にしないとダメかもしれない。 ======================================== IPsec net.inet{,6}.ipsec{,6}.inbound_call_ike: inbound パケットについて IPsec なことが条件だが、 IPsec されていない場合、key_acquire() するフラグ。 loopback の SA を free すると 2回引かれるので、refcnt < 0 になる。 -> うそ！fixed ping -P "ipsec esp/require" 127.0.0.1 tcpdump: listening on lo0 127.0.0.1 > 127.0.0.1: ESP(spi=65537,seq=0x9) 127.0.0.1 > 127.0.0.1: icmp: echo reply とでも reply を受けてしまう。 -> mbuf が一緒だから。 -> ping -P "ipsec esp/require" 127.0.0.2 はOK SA無くても IP で queue しない。上位の再送にまかせる。 Transport mode a destination address に対する transport adjacency は [IP][AH][ESP][upper] のみ -> だけど KAME はなんでもあり。 replay の window size の単位 bit simple IPsec APIでは、行き ESPのみ、帰りAHのみ、というような ケースはカバーできない。 PF_KEY もサポートしてない。 -> マニュアルなら出来る。 こういうことをやりたいか？ -> IKE でもしないから、必要ない。 -> と言うのは全部嘘で SPD の設定で可能。 hdrsiz のコード SP を見て決める。 SA が無くても頑張る。 tunnel mode :+= sizeof(ip header) ESP: newesp + 8 + 9 + 16 AH: newah + 16 IPSEC_LEVEL_USE の時はカウントするか？ する。 計算のタイミング mss の計算(tcp*) MTU の計算(ip*_forward) ip_forward の MTUサイズ計算 心は IPsec で使う可能性のあるサイズ分を計算したい。 REQUIRE,USE に関係なくあれば足す。 iv は 8 固定。 SA の割り当て パケット出す時 SADB_SASTATE_MATURE -> SADB_SASTATE_DYING かつ新しい SA パケット受ける時 SPI で拾う。 かつ SADB_SASTATE_MATURE または SADB_SASTATE_DYING ======================================== PF_KEY 3DES は key-extension が 3 発ある？ -> 違う。24octet に 64bit鍵が3個入る。 delete の識別子。 proxy を指定するところが無い。 -> SPI でユニークになるからOK. RFC2367 には sadb_comb_flags の使い方が書いてない。 -> 列挙してないだけで、書いてある。 -> でも sadb_sa_flags(32bit), sadb_comb_flags(16bit) だぞ。 acquire で prop もらえるけど、responder 側の prop は？ expire の処理! CURRENT sadb_lifetime_allocations って refcnt の合計のことか？ -> {esp,ah}_{in,out}put で呼ばれた回数に決めた。 The sadb_msg_seq MUST be set to the value set in a kernel-generated SADB_ACQUIRE so that both associations in a pair are bound to the same ACQUIRE request. ======================================== [A->B] packet をトリガにしたPF_KEYv2 の動作 ACQUIRE A->B:000: ----------> GETSPI <---------- B->A B->A:200: ----------> [B->A:200:PA] ----------> GETSPI A->B:0 ----------> <---------- A->B:999 UPDATE ----------> A->B:999:PA ADD ----------> B->A:200:PA [A->B:999:PA] <---------- UPDATE A->B:999:PA <---------- UPDATE B->A:200:PA <----------