On Fri, 12 Oct 2012, Dan Harkins wrote:
Subject: [IPsec] New I-D on IKEv3
Some remarks - stateless IKE I like not dealing with lingering IKE SA's, but how to tell if a connection is dead? idletime on the IPsec SA? How to do DPD? When a roadwarrior pops up at IP A, and then at IP B, etc, how do we get rid of IPsec SA A, B etc. Or do we ignore the outer IP completely and don't care about SRC/DST of the ESP packets and just send answers the the latest IP-port we saw? - "Only one instance of the IKEv3 protocol SHALL be run at time between any two peers." What about NAT, I guess you do mean "peers" and not "IPs" but can we always tell? - algorithm selection The responder can look at the initiator SPI and match up its SPI lower bits to give its own proposal a slight edge. Could that be problematic? - ID_BLOB_ID I like this! And already have a use for it - "and two Traffic Selector payloads (TS)" In IKEv2 and here I always found it very confusing to talk about "Traffic Selector payload" payload and the "Traffic Selector" payload. There should really be better terms for that. - I'm still not a fan of narrowing, see my earlier comments on ipsecme. It destroys the concept of a tunnel being "up" or "down". If you insist on narrowing, clearly state what should happen for traffic selectors outside the narrowed set, DROPed or ACCEPTed plaintext? Related: all the IKEv2 text about meaning of the first and second TS payload is missing (eg the src/dst of the trigger and the src/dst of the negiating SA). Was that intentional? - Why still support AH? - What happened to NAT Traversal negotiation? back to vendorids? - Should compression be disallowed? Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
