NetBSD/crypto/dist/kame/racoon/doc/sandiego0009-result.en

358 lines
12 KiB
Plaintext

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