$KAME: sandiego0009-result.en,v 1.35 2000/09/23 15:37:37 itojun Exp $ Mon Sep 18 2000 - Fri Sep 22 2000 Paradise Point Hotel, San Diego, CA Goals: - kernel IPsec: rijndael-cbc, twofish-cbc, blowfish-cbc - racoon: RSA signature, verify cert chain Things to look at during tests: IPsec: - behavior against large packet (> MTU) - TCP behavior (fragmentation) IKE: - interpretation of phase 2 proposal. if we want "IP AH ESP IP payload", is it "AH tunnel + ESP tunnel", or "AH transport + ESP tunnel"? - attribute formatting. TV/TLV mistakes? - mandatory/optional attributes mistakes (like key length attributes). - negotiation mode of key length attributes. Result template: -->8 vs XXX phase 1: initiate/responder, main/aggressive preshared, 3des-cbc, md5, DH group 2, lifetime 600 preshared, des-cbc, sha1, DH group 2, lifetime 1000 rsasig, 3des-cbc, sha1, DH group 2, lifetime 600 phase 2: PFS group 2 ESP blowfish-cbc, transport mode, lifetime 600 ESP 3des-cbc, transport mode, lifetime 600 IPsec: (flood) ping with small packet (flood) ping with large packet (>1500) tcp session (look at fragmentation issue) Notes: -->8 Result: * No body has base mode with RSA signature. vs Cryptek phase 1: responder, main preshared, 3des-cbc, md5, DH group 1, lifetime 600 <== choiced preshared, des-cbc, sha1, DH group 1, lifetime 1000 phase 2: ESP 3des-cbc, hmac-sha1, transport mode, lifetime 600, PFS group 2 Notes: - racoon crashed because of linker problem, header size had changed. - ph1 proposal mismatched because cryptek sent DH group 1, but I expected 2. - cryptek sent the length of 4 as ph1 spi size. racoon warned and ignore it. phase 1: initiator, main preshared, 3des-cbc, md5, DH group 1, lifetime 600 <== choiced preshared, des-cbc, sha1, DH group 1, lifetime 1000 phase 2: no PFS ESP des-cbc, hmac-sha1, transport mode, lifetime 300 ESP des-cbc, hmac-md5, transport mode, lifetime 300 ESP 3des-cbc, hmac-sha1, transport mode, lifetime 300 <== choiced ESP 3des-cbc, hmac-md5, transport mode, lifetime 300 Notes: - cryptek might send me the broken ID payload. - IPsec-SA was installed, but cryptek still sent me the notify of invalid-payload. vs SSH (IPv6) phase 1: aggressive either of the following: preshared, blowfish, md5, DH group 2 preshared, 3des, sha1, DH group 2 phase 2: either of the following (not sure if algorithm names are right): PFS group 2 ESP blowfish-cbc+md5, transport mode ESP 3des-cbc+sha1, transport mode AH md5, transport mode ESP blowfish-cbc + AH sha1, transport mode ESP blowfish-cbc+md5 + AH sha1, transport mode IPCOMP deflate + ESP blowfish-cbc+md5 + AH sha1, transport mode IPCOMP deflate + AH sha1, transport mode ESP twofish-cbc+sha1, transport mode ESP rijndael-cbc+sha1, transport mode IPCOMP deflate + ESP rijndael-cbc+sha1, transport mode IPCOMP deflate + ESP twofish-cbc+sha1, transport mode Notes: - both end had issues with ND, if we configure "encrypt all" policy. both end changed policy to use ipsec on tcp6 only (not on icmp6). - racoon crashed if SSH attaches more than 10 phase 1 proposals. (fixed) - in phase 2 first packet, racoon crashed in cmpspidx_wild(). (seems to be fixed, not 100% sure) - in phase 2 negotiation, racoon assumes that the order of proposal payloads is the same as the order of protocols in kernel policy. ssh does not assume it (fixed/racoon can do both behavior, not sure if which side is more common) - no SADB_ACQUIRE on ipcomp SPD (fixed by making SADB_ACQUIRE processing violate RFC2367 a little) - SADB_UPDATE when wellknown CPI is negotiated - rekey is working fine. - SSH uses different algorithm number for twofish than the AES draft. - deflate does not look stable enough (memory leak in SSH side). - twofish/rijndael are variable length cipher, need key length attribute (fixed) vs RapidStream phase 1: responder, main rsasig, 3des-cbc, md5, DH group 1, lifetime 600 phase 2: 3des, hmac-sha1, tunnel mode, lifetime 300, PFS group 2 Notes: - racoon crashed due to unkown problem. I may be incorrect to use openssl functions. - rapidstream sent multiple subjectAltName and ID was matched 2nd one. But racoon can not process multiple one. (fixed) - fragmented packet was failed due to no response from rapidstream. vs HITACHI phase 1: responder, main rsasig, 3des-cbc, sha1, DH group 2, lifetime 600 both subjectAltName and DN are OK. multiple subjectAltName is OK. subjectAltName = email subjectAltName = dns phase 2: des, hmac-sha1, tunnel mode, lifetime 300 <== choiced des, hmac-md5, tunnel mode, lifetime 300 3des, hmac-sha1, tunnel mode, lifetime 300 3des, hmac-md5, tunnel mode, lifetime 300 Notes: - rekeying is fine. vs Ericsson manual key ESP blowfish-cbc, transport mode, key = mekmitasdigoat (112bit) Notes: - works just fine after blowfish-cbc logic fix. - no fragment tests as Ericsson side would panic. vs Linux FreeSWAN phase 1: main preshared, 3des-cbc, md5, DH group 2, lifetime 1h phase 2: ESP 3des-cbc, hmac-md5, tunnel mode, lifetime 1h, PFS 2 rekey test: phase 1: main preshared, 3des-cbc, md5, DH group 2, lifetime 1m phase 2: ESP 3des-cbc, hmac-md5, tunnel mode, lifetime 20s, PFS 2 IPv6 test: phase 1: main preshared, 3des-cbc, md5, DH group 2, lifetime 1h phase 2: ESP 3des-cbc, hmac-md5, transport mode, lifetime 1h, PFS 2 AH (the IPsec SA did not get installed into linux kernel) Notes: - ping with short, long (2k, 32k, 64k) - chargen - FreeSWAN did not consider ESP header size on MSS computation - rekey - some packet losses on flood ping. this was because of difference in rekey. KAME: jenkins draft, uses oldest key possible linux: uses latest key possible, and assumes that phase 2 responder will install inbound SA on reception of 1st packet - IPv6 test: linux side cannot install IPsec SA into the kernel (negotiation was successful) - linux side chokes if they gets proposal with algorithm # which linux side does not know about. - racoon chokes if (1) racoon is phase 2 responder, (2) there's no id payload from initiator, and (3) kame side has tcp policy (not "any" policy). - racoon choked if the peer (responder) reorders phase 2 proposals. vs HiFn phase 1: initiator, main rsasig, 3des-cbc, md5, DH group 2, lifetime 180 <== choiced rsasig, 3des-cbc, sha1, DH group 2, lifetime 600 subjectAltName = email phase 2: ESP 3des-cbc, hmac-sha1, tunnel mode, lifetime 600, PFS group 2 Notes: - defined "verify_cert off;" rekey test: phase 1: initiator, main rsasig, 3des-cbc, sha1, DH group 2, lifetime 60 phase 2: ESP 3des-cbc, hmac-sha1, tunnel mode, lifetime 30, PFS group 2 Notes: - large ping (8k) test. - when rekeying started, sometime ok but sometime HiFn did not response last phase 2 packet. vs NxNetworks phase 1: main preshared, 3des-cbc, sha1, DH group 2 phase 2: ESP 3des-cbc, hmac-sha1, tunnel mode, PFS 2 phase 1: main preshared, 3des-cbc, md5, DH group 2 phase 2: ESP blowfish, hmac-md5, tunnel mode, no PFS Notes: - fragmented packets did not get through NxNet gw. - phase 2 ID: (KAME) the gw itself (NxNet) net10 addr behind NxNet phase 1: aggressive rsasig, 3des, sha1, DH group 2 rsasig, 3des, md5, DH group 2 subjectAltName = email phase 2: 3des, sha1, tunnel, pfs 2 - parsing the type of subjectaltname fault in racoon. (fixed) - even if using old SA, when old SA expire, packet may drop when both sides clock are different. vs Intel Canada phase 1: main rsasig, 3des, sha1, DH group 2 entrust, subjectaltname = ipaddress phase 2: 3des, sha1, transport, pfs 2 - when kame did not send CR, then intel did not reply CERT. It makes sense. vs Intel (Packet Protect Pro/100S) phase 1: main preshared, 3des-cbc, sha1, DH group 2 phase 2: ESP 3des-cbc, hmac-md5, transport mode, no PFS Notes: - fragmented ping works fine, large ftp transfer went well too phase 1: main rsasig, 3des, sha1, DH group 2 subjectaltname = ipaddress phase 2: 3des, md5, transport, no pfs - a lot of SA were installed, because kame doesn't delete old SA until it expires. vs Intel phase 1: main rsasig, 3des-cbc, sha1, DH group 2 entrust, subjectaltname = ipaddress phase 2: ESP 3des-cbc, hmac-sha1, transport mode, PFS 2 Notes: - 64k ping does not work. freebsd problem ? it's not relative ipsec. vs NetLock phase 1: main preshared, des-cbc, md5, DH group 1 phase 2: ESP des-cbc, hmac-md5, tunnel mode, no PFS phase 1: main preshared, 3des-cbc, sha1, DH group 1 phase 2: ESP 3des-cbc, hmac-md5, tunnel mode, no PFS phase 1: main preshared, 3des-cbc, sha1, DH group 1 phase 2: ESP 3des-cbc, hmac-md5, transport mode, no PFS phase 1: main preshared, 3des-cbc, sha1, DH group 1 phase 2: IPComp deflate + ESP 3des-cbc, hmac-md5, transport mode, no PFS (failed due to IPComp SPI size) Notes: - fragmented ping works fine, large ftp transfer went well too - BSD userland (or socket layer?) limits UDP echo size to 4k vs Pivotal manual key fragmented packet (8k) is ok. 1: esp tunnel des-cbc, hmac-md5 vpn test. 2: esp tunnel 3des-cbc, hmac-sha1 internal address is same to pivotal's network (10.33.134.0/24). ifconfig lo0 inet 10.33.134.4 netmask 255.255.255.0 alias route add -inet -net 10.33.134.0/24 206.175.32.1 vs Cisco phase 1: main, initiator rsasig, 3des-cbc, sha1, DH group 2 entrust, subjectaltname = ipaddress Notes: - I had not sent CR, then cisco did not CERT even though rsasig was negotiated. In this caes, I SHOULD send CR. - negotiation failed because ID and subjectaltname in Cisco's CERT mismatched. phase 1: main, responder rsasig, 3des-cbc, sha1, DH group 2 entrust, subjectaltname = ipaddress phase 2: ESP 3des-cbc, hmac-sha1, transport mode, PFS 2 Notes: vs RSA phase 1: aggressive, initiator rsasig, 3des-cbc, sha1, DH group 5 rsa, subjectaltname = ipaddress phase 2: ESP 3des-cbc, hmac-sha1, transport mode, PFS 5 Notes: - pfs group mismatched. it's racoon's bug. (fixed) phase 1: aggressive, responder rsasig, 3des-cbc, sha1, DH group 2 rsa, subjectaltname = ipaddress phase 2: ESP 3des-cbc, hmac-sha1, transport mode, PFS 2 Notes: vs III manual key 1: esp tunnel des-cbc, hmac-md5 kame sent 1492 bytes packet. but no response. 2: ah transport hmac-sha1 1474 bytes packet was replyed from iii. in addition broken 46 bytes. vs IBM AIX phase 1: responder main rsasig, 3des-cbc, sha1, DH group 2, lifetime 600 use subjectname as ID payload. phase 2: PFS group 2 ESP 3des-cbc, transport mode, lifetime 300 Notes: negotiation success on IPv6. we promise to test for IPv6 subjectaltname over 6bone. common problem: - KAME/FreeBSD3 presents strange behavior with outgoing fragmented packet. (1) it cannot ping with some specific sizes, on loopback interface (around 16300 or so). (2) first fragmented packet is never get replied by the peer. this depends on operating system type. - need more checks about kernel ACQUIRE rate-limiting policy. (1) is the behavior sane when a DELETE/FLUSH is issued? i have seen no ACQUIRE is passed right after DELETE payload is sent. (2) should we use ppsratecheck (per-SA) or whatever? shouldn't it be integrated into SPD/SAD entries? - IPv6 ND and policy lookup (chicken-and-egg).