sandiego0009-result.en

来自「Linux 2.6 内核上配置IPSec VPN 的工具」· EN 代码 · 共 358 行

$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).