Mon Jan 10 2000 - Fri Jan 14 2000

vs microsoft
    as responder
	phase 1の最後のパケットを再送してくる。kame側のstate machineの
	null pointer checkが足りず落ちた。明日再挑戦。

	再挑戦、うまくいった
		phase 1: pre-shared/3des/sha1/dh2
		phase 2: esp/sha/des/600sec/3kb

vs bluesteel
	うまくいったらしい。

	うまくいかなかった。
	initiator: 鍵できたけど ping しても向こうが返事せず。
		再戦予定
	transport やろうとしたら敵が tunnel mode をネゴってた。
	tunnel の時は敵が内側のアドレスを間違ってた。
	と言う分けで OK.
	phase 1: pre-shared/md5/des/dh1/10min
	phase 2: esp/md5/des/10min

	やっぱりネゴったポリシを突っ込む方が楽っす…

vs racoon
	rekey問題を解決したあと
	- phase 2を5秒に1回rekey
	- phase 1を8秒に1回rekey
	などのいじめをしているが、おおむね快調。
	たまにphase 2の失敗がある(pingしてると10秒くらい穴があく)。

	chargenとかも並行して試しているが問題なし。

	kernel codeにmemory leakはほとんどない模様。
	racoon内にmemory leakがある模様。動かしてると太る。

	IPv6もIPv4同様ちゃんと動いてます(ただしglobal address)。

	phase 1がaggressive modeのとき、rekeyに失敗しやすい。
	(phase 1を待ってphase 2が再開しない)

	rekeyのときにときどきno spi云々が出る。jenkins-ipsec-rekeyを
	もっと頑張らないと駄目か?

vs ashley laurent
	phase 1 userfqdn supportいれてよんと言われた。今回間に合うのかな。

	userfqdn 入れて再戦しようとしたけど、敵が tunnel mode の client あり
	しかサポートしてないので、明日再戦予定。

	PC用意して再戦。phase1 はあっさりok.
	phase2 で pfs を使うと敵がクラッシュする。
	治りそうも無いのでテストはあきらめ。

	phase1: psk/userfadn/md5/des/dh2

	pfs group だけ事前にprotocol の外でネゴしないとダメなのって変かも

vs ericsson
	initiator: 既知のDH groupについてはDH group typeをつけてはいけない
	responder: blowfish、およびkey lengthをちゃんとサポートしないとまずい

	修正後ok(size=2000のpingまで)
		phase 1: pre-shared/des/md5/dh1/lifetime 1hour/lifebyte 1MB
		phase 2: esp/md5/blowfish 56bit/lifetime 1hour/lifebyte 1MB

	delete payloadを受けてもこっちはphase 1を保持しつづけているが、
	あっちはphase 1もきれたと思ってる。
	(jenkins-rekeyからするとphase 1/2は分離して管理するのが正しいので、
	こっちが正解)

vs ibm
	先方で試したところ、agressive modeにinterop issueがあるらしい。
	(これは追ってBull側の問題であることが確認された)

	IPv4: main/aggressive両方ok
		phase 1 3des/md5/dh1/3600sec
		phase 2 esp/transport/des/sha1/dh2/1800sec

vs radguard
	gateway: いまいち。原因不明。
		こっちinitiate: policyのあがりかたがまずい/phase 1 2とも
			いまいち
		こっちrespond: phase 1 2ともいまいち。先方gateway裏のnodeから
			pingが届かない

		phase 1: pre-shared/des/md5/dh1
		phase 2: esp tun(裏)/3des/sha1/dh2
	client: ばっちり、ただし先方にfragment問題あり(ping > 1500答えなし)
		phase 1: pre-shared/3des/sha1/dh2
		phase 2: esp tun(自分自身)/3des/sha1/dh2

	base mode やろうよって言ったら持って来てないから、
	うちのテストサイト www.ip-sec.com でテストしてみてって言われる。
	見たけど base mode のかけらもないぞ。

vs network associates
	base mode:
		initiator/responder: psk
		PSK の HASH_R の計算は RFC2409 だよと諭される…
		治して phase1 ok. 
		phase2 で向こうに no proposal choosen. と言われる。
		md5/sha1 x des/3des, esp, transport のはずなんだけど…
		チェックしてもらってる最中。

	ふつうの: ばっちり、rekey放題もばっちり
		phase 1: pre-shared/sha1/3des/dh2/10min
		phase 2: esp/md5/cast128/dh2/5min
	明日dh5をやる予定。(1/12)
	dh5成功。(1/13)
	agressive modeもやった。

	こっちがわ、byte lifetimeに虫あり。つねに設定の1024倍のproposalを
	投げる。
	さらにlifetimeに虫。

vs intel
	base mode: initiator/responder共に敵がHASHの計算間違っているらしい。
		再戦予定。

vs freeswan
	group 5: phase1 ok.
	phase2 で PFS してるのに KE が出ない時がある。
	大量にracoon.conf書いて起動すると落ちずにパースに失敗する時がある。
	結果、変な値が入る時がある。KEが出ないのはこのせい。

	racoon.conf を少なめにして再挑戦。
	今度は KE 出したのに失敗。
	freeswan は informational exchange しないので、何が起きたかわからない。

	phase2 のproposalを6個書いたら SPI=0 で出していた。
	とりあえず少なめに書いて再挑戦。

	phase2 でPFSを使った時は SA の group description を
	書かないとエラーになる。

	治してok. thanx hugh!
	phase1: psk/sha1/3des/dh5/10min
	phase2: esp/3des/md5/dh1/10min

vs ire
	ipcomp over ikeのテスト
	spiまわりなどたくさん直した。2byte spiが来たときの対処等。
	現状のcodeはwell-known cpiをつっこまれると困る。
	phase 1: 3des/sha1/dh1/600s
	phase 2: esp/transport/3des/sha1/300s, ipcomp/deflate/300s

	とりあえずipcompはok。やってみた組合せ:
	ip esp ipcomp payload
	ip ah ipcomp payload
	ip esp ipcomp ip payload
	ip ah ipcomp ip payload

	- kame側のwindow sizeがちいさすて伸長できない。
	  sys/netinet6/ipcomp_core.c 1.3 -> 1.4が悪影響しているので戻す。
	- ire側はtransport modeのとき、圧縮前サイズ > MTUを解釈しない。
	  のでテストでping -s 2000とかやると返ってこない。これ困んないか?
	- ireは「ip esp ipcomp ip payload」のとき、IKE的にesp ipcompとも
	  tunnelとproposeしてくる。kame側はそうではない。
	  kame側で無理矢理あわせようとしてIKE的にtunnel+tunnel、kernel的に
	  tunnel+transportとすると、無限にacquireがあがる。

vs fitel
	あっさり。tunnel/transport ok.  rekey にちょっと問題あり。
	phase1: pks/userfqdn/md5/des/20s
	phase2: pfs1/md5/des/10s

	nonce の長さ 320 叩き付けたら malformed payload で返される。
	encode の padding を 0-100までrandom にしても平気。
	padding の中身が 0 だったので治す。
	たまに向こうからのパケットに1(s)位の遅延がある。rekeyとは関係ないっぽい

		A --- fitel === KAME --- B
	B から A へ ping して SA を作る。
	B は ping し続ける。
	A から ping する。
	rekey すると A からのパケットを fitel が捻れなくなる。
	rekey すると fitel は
		出し側: 古いSAはすぐ消す
		入り側: 古いSAはlifetimeまで残す。
	rekey した後に使う SA の問題は無さそう。原因不明。

vs cisco
	IKEはほぼ問題なし。
	phase 1: pre-shared/3des/sha1/dh2/180sec
	phase 2: esp transport/3des/sha1/dh2/120sec

	phase 1: pre-shared/3des/sha1/dh2/180sec
	phase 2: esp tunnel/3des/sha1/dh2/120sec

	ipsec SAをカーネルにいれた後、packet出力時のSA検索に
	失敗してしまう症状続発。delete payloadをくらったときに消したSAが
	deadのまま残ってしまい、検索をあきらめる。これは二度と消せない?
	-> 直した。reference count問題。

>206.175.160.20 206.175.161.114 
>	esp mode=tunnel spi=372644951(0x16361c57) reqid=0(0x00000000)
>	E: 3des-cbc  83dfc523 b3b66e28 06222ccf f33d1d4b c039aeef 07b0e7f0
>	A: hmac-sha1  e30c8e8a d3a8fa30 1985ed93 bdf1ad35 9cd46861
>	replay=4 flags=0x00000000 state=dead seq=1 pid=495
>	created: Jan 13 22:24:40 2000	current: Jan 13 22:39:54 2000
>	diff: 914(s)	hard: 120(s)	soft: 96(s)
>	last:                     	hard: 0(s)	soft: 0(s)
>	current: 0(bytes)	hard: 0(bytes)	soft: 515395584(bytes)
>	allocated: 0	hard: 0	soft: 0
>	refcnt=1
>206.175.160.20 206.175.161.114 
>	esp mode=tunnel spi=205659402(0x0c421d0a) reqid=0(0x00000000)
>	E: 3des-cbc  b2bec5f2 9a9d7d7c 92a5aea3 0ce5310c 7cedd2bb efdd62b2
>	A: hmac-sha1  8fff7c61 990fbb3e 6730e2ed c26c06cf 3c75a2c4
>	replay=4 flags=0x00000000 state=dead seq=0 pid=495
>	created: Jan 13 22:24:47 2000	current: Jan 13 22:39:54 2000
>	diff: 907(s)	hard: 120(s)	soft: 96(s)
>	last:                     	hard: 0(s)	soft: 0(s)
>	current: 0(bytes)	hard: 0(bytes)	soft: 0(bytes)
>	allocated: 0	hard: 0	soft: 0
>	refcnt=1

テストするには
	psk.txtにエントリ追加。
	samples/Makefileに相手のentryを追加、生成。
	生成されたconfig fileを適宜いじる。

	tunnel modeの場合はけっこいろいろいじらないと駄目かも。

kame
	kernelのmbuf/key management memoryのleakはほとんど皆無。いくらでも
	続けられます。racoonは太ったりふんづけたり? とにぎやか。

	bundleについて:
	- proposalいっこについてtransformいっこになるようなconfig fileでないと
	  動かない。つまり、
		proposal { protocol ah; protocol esp; }
	  はいいが
		proposal { protocol esp; protocol esp; }
	  や、strengthの使用は不可。

	ときどきacquireまわりのtroubleでrekeyしなくなることがある。
	bundle使っていないときも似た症状が出るが、bundleを使うとさらに
	起きやすい気がする。
	(socket policyにrequireと書いた場合に、acquireが上がらないことが多い)

	acquireをuserland側でフィルタするところで、フィルタしすぎに
	なることがある。(ネゴるべきなのにネゴらない)
	-> reference count問題とのからみか?
	-> acquireのフィルタリングはよいことかわるいことか?
	   kernel側はまあいいとして、userland側はkernel側情報とuserland側情報の
	   ずれについてもうちょっと頑張らないといけないかもしれない。
	   例えば、racoon動かしながらsetkey -Fした場合、
	   現状: phase 2 handleは残っているが鍵はないので、一定時間フィルタする
	   実は: 鍵がないんだからネゴった方がよい。
	   acquireが上がったらそのSAがほんとにカーネルにあるのか検証する?
	   acquireに「kernelのなかにはSAがある/ない」情報のextensionをつける?

	kernelでah use/esp useと書いてあるのにracoon側でespしかネゴしなかった
	場合、永遠にahのacquireが上がり続ける。
	で、ahのacquireがあがったにも係わらず、racoonはespのネゴをするので
	永久にネゴが続く。
	- kernel policyとracoon policyの整合性 - racoonがkernelに
	  ポリシをつっこめばよい
	- acquireの細かいチェック - ahが要求されているのにespをネゴらないように
	が必要。

	byte lifetime問題。
	- 片方向だけたくさんtrafficがあると、片方向だけexpireする。
	  で、ネゴすると逆側はちっともexpireしないので鍵がたくさん溜っていく。
	- パケットロスがあると、出し側はexpireするのに受け側はexpireしない
	  場合がある。(問題にはならないと思うが)

	どっちの挙動が望ましいのか?
	racoon: lifetime、こっち側のconfig fileに関係なくネゴした結果を
		kernelにいれる。
	nai pgp client: lifetimeのネゴは普通に通すが、kernelにいれるのは
		min(自分のポリシ, ネゴ結果)

	initiate するパラメータと acceptable check に使うパラメータを
	分けた方が良いかもしれない。
	少なくとも lifetime や PFS group には範囲が必要。

	DOS対策
	- 同じ src から、phase 1 の一発目を
	  n秒間に m発受け取ったらDOSと思うとか？
	- src は偽造できるから n秒間に m発受け取ったらで十分かも？
	  itojunはこっちでいいと思う。ただしnとmは調整可能にしておきたい
	  (n = 1固定でmだけ可変でもいいけど)

	INITIAL CONTACT やんないと。

	phase 1 の最後に CONNECTED 受け取ったら、結局どうするのが正しいの？

	COMMIT BIT の必要性がよくわからん。
		jenkins rekey 読めばわかるかも。

	IPcomp と ESP を併用する時のlifetimeって？
		bundle なら一緒にするはず。
		通常 ESP の lifetime は 28800(s)
		けど、 ipcomp の lifetime って∞でも良いくらいなのに。
		IPcomp のネゴって必要なんだろうか？ (i.e.  相手がipcomp capable
		かわかればよい。それ以上のネゴの必要性は疑問)
	-> IPComp capable nodeかどうかの情報を蓄えるにはSAを使う。
	   SAはメモリを食う。メモリいつまでも食ってるのは嫌。
	   よってipcomp lifetimeも必要。
