Hi Paul, On Sat, October 13, 2012 2:35 pm, Paul Wouters wrote: > 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?
That's a great question. There's alot of complexity that gets added for IKE to deal with DPD and I'd just like to punt that to something else. Idletime on the IPsec SAs is probably the way to do it. > 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? I think any stale SA would be cleaned up by the "something else" I referred to above. Figuring out where to send packets may require some linkage between outer and inner addresses when they get plumbed into the kernel that would orphan an "old" IPsec SA (and possibly facilitate it's cleanup). Which reminds me, one thing missing from IKEv3 is a "config mode". That really needs to be there. > - "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? NAT detection is another thing I left out in my rush to hit the -00 cutoff date. I mean "peers" and the way we can tell is to include a "this is what I think my address is" payload. The recipient can then tell whether the other side is behind a NAT and disambiguate multiple "peers" behind the same IP address to enforce the "only one instance" requirement. > - 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? The tie is only the case where both sides initiate simultaneously and that happens when neither side has seen the other's offer. There just needs to be some way to unambiguously converge on accepted parameters. Of course, an implementation can receive the other side's offer and respond as if it did not (make a tie that it will win) but a responder will always have a slight edge because he gets to see the initiator's offer before exposing his own. Provided that they converge on acceptable parameters, is this a problem? > - 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? It was not intentional to lose important information, it's just that that section is kind of verbose and I think can be stated more succinctly. If the IKEv3 text is missing important information, I will try to clean it up. > - Why still support AH? I have no love of AH but is it up to the key exchange protocol to kill off an IPsec protocol? > - What happened to NAT Traversal negotiation? back to vendorids? It will be in -01. > - Should compression be disallowed? I am agnostic on the subject and willing to follow the will of the group. Thanks alot for your comments; much appreciated. regards, Dan. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
