>Unfortunately, I don't think we arranged for anyone >to take the minutes of the meeting (if anyone did >take notes, please post!). However, at least the >following was discussed: mostly this is the copy of the slides, but anyway, better than nothing. itojun
-- BEGIN included message
- To: ikebone@kame.net, core@kame.net
- Subject: summary of bakeoff
- From: Jun-ichiro itojun Hagino <itojun@iijlab.net>
- Date: Fri, 17 Aug 2001 20:58:26 +0900
- Delivered-To: itojun@coconut.itojun.org
- Sender: itojun@itojun.org
what people have tested what went well, what went not going so well if not, spec problem or implementation problem bakeoff organization what's new? what's tested? N x NAT traversal N x AES N x IPv6 cert management: SCEP OCSP CMP? new DH groups new implementations (cellphones, new vendors) hybrid auth, xauth hub-and-spoke VPNs multiple trusted roots, cert chains, subordinate certs, PKCS#7 oppotunitistic encryption? two vendors what works well? ipsec sha1, 3des ike with preshared keys ike with rsa sig certs aes - some issues in phase 1, still rekey with established vendors, no problems in testing v4 fragmentation basic ipv6 cases problem areas ipsec ipcomp - some problems? minor fragmentation issues diff between ike spec and ipcomp spec - encapsulation mode rekey - a couple of problems ike aes key length attributes - phase 1 optional, phase 2 mandatory slow new dh group calc cause timeouts delete messages some vendors do not send them - spec unclear? if xauth phase 1.5 falls, torn down phase 1? should not tear down ??. - in the draft. if don't support all xauth attrs, turn down the whole thing? retransmission and long rtt problems in some people's ike state mechanisms cert many smaller problems cr warss: when to send and what to inlcude also, is the whole chain sent or not problems in certain fields, eg identity fqdn vs ip-addrs cr with null cert authority - send multiple certs, some implementations can't cope with this enrollment:scep ra/ca certificate chain - use of all cert; ca certificates might not have the key encipherment bit set correct ordering of relative distinguished name encodings - x509 vs ldap not much testing of revokation certificate hierarchy and multiple ca troubles scep - quite many (10+?). nat traversal packet fragmentation problems with esp-udp - implementation issue? early phase of test. ipv6 certs with ipv6 identities neighbor discovery to work with ipsec missing combinations (v6 inside v4) many types of ipv6 addrs source addr selection link local adddresses fragmentation - implementation? some ipv6 connectivity setup problems configuration problems from "no" to "lots", opinion varies specification problems keepalives, how to solve? - no spec. what kind of problem you are trying to solve? if you don't have failover, you just need to have a way to recover from loss of traffic (old draft by sommerfeld) failover solves routing problem.. ??? some interpretations on nat traversal aes key length proposals - send or not use of default lifetimes, if other type provided lifetime should never been a part of the protocol - hugh sending lifetime helps rekey sometimes if initiate/response relationship is not bidir, need lifetime? lifetime helps. rekey without lifetime... you don't always want to rekey. if you don't have lifetime, keys will stay forever and is not secure. you don't know how long sas will be alive, and you don't know how to kill it. if the peer ignores the lifetime value, you lose. discussion, discussion... implementation problems some: lifetimes, ike, proposal numbers, too many unnecessary hcecks, CRL content formats disjoint opitons problem not many people have AES not many people have large DH groups somebody wan't able to turn PFS off different st of id types (DN vs email) clean vs abrupt tunnel close not many support IPv6 address-only SPD some people require certs certificate encodings 3des, sha1, v4 are well supported let us remove 1des from spec. any objections? restrictive countries. i have no choice. deprecate it in the spec, keep the codepoint, try to discourage 1des new implementation. some lowend devices still need des. still sometimes need to implement. may make sense to keep it registration generally good feedback additional information had to be requested by some (how much power available etc) map to the site would have been useful general good feedback uphill walk from the hotel in the morning some didn't bring all equipment, used over network - maybe good thing less people than last time - economic, location? where are the ca vendors? busy people, not much time to test good food some time zone problems with crews back home security guards? network generally good feedback wanted to see net/vendor/implementation info before event web site was a bit slow network problems at start too many steps for adding machines, interfaces, etc we need a NAT more realistic test environments - delay drop capacity ipv6 worked great ipv6 has other apps than ping6? wlan was great firewall would have been nice regular phones or more mobile phones dns setup very useful routable address to behind the gw NTP would be (was?) good we keep intranet webpage for a while. furture bakeoffs? yes maybe more participants if in the US system for testing over the network? VPNC did something like this. test what? whatever gets implemented advanced cert things: enrollment, ocsp nat traversal dhcp aes opportunistic encryption maybe "ipsec and pki" bakeoff to attract more CA vendors new DH groups son-of-ike outside of the US to host? if outside of US, no anita, too bad. finding host is hard. face-to-face is good. no L2TP/...
-- END included message