Or do my other favorite thing with a "support_cafr" notification in the Initial exchange, so that support indicates that you understand protocol=1 and SPI size=16.
If we ever do an IKEv3, we need a "Features" payload, where optional capabilities be listed in compact form. That and replacing "Next Payload" with "This Payload" Yoav On Aug 25, 2013, at 12:07 PM, Yaron Sheffer <yaronf.i...@gmail.com> wrote: > Thanks for pointing me to the registry! > > I'm not worried about creative interpretations. More about existing > implementations doing the wrong thing. So yes, maybe we should register a new > value. > > Thanks, > Yaron > > On 2013-08-25 11:47, Yoav Nir wrote: >> I read section 3.10 in RFC 4306, and it says this: >> >> o Protocol ID (1 octet) - If this notification concerns an existing >> SA, this field indicates the type of that SA. For IKE_SA >> notifications, this field MUST be one (1). For notifications >> concerning IPsec SAs this field MUST contain either (2) to >> indicate AH or (3) to indicate ESP. For notifications that do not >> relate to an existing SA, this field MUST be sent as zero and MUST >> be ignored on receipt. All other values for this field are >> reserved to IANA for future assignment. >> >> o SPI Size (1 octet) - Length in octets of the SPI as defined by the >> IPsec protocol ID or zero if no SPI is applicable. For a >> notification concerning the IKE SA, the SPI Size MUST be zero and >> the field must be empty. >> >> Sure there is a registry: >> http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-18 >> . There are even values #4 and #5. But I see that bit about SPI size having >> to be zero, because it is assumed that notification about IKE SA only relate >> to *this* IKE SA. >> >> So we can creatively interpret "the IKE SA" to be different from "an IKE >> SA", or we can ask IANA to add a new value with meaning "other IKE SA". >> Agree it's a corner case. >> >> -----Original Message----- >> From: Yaron Sheffer [mailto:yaronf.i...@gmail.com] >> Sent: Sunday, August 25, 2013 11:12 AM >> To: Yoav Nir >> Cc: IPsecme WG >> Subject: Re: [IPsec] CAFR -01 comments >> >> Hi Yoav, >> >> Regarding the notification syntax, it is actually a bit worse than that. >> This is a corner case in the RFC, but if you read Sec. 3.10 literally, there >> are exactly 2 allowed values for the Protocol ID field (or 3 values, if you >> read RFC 4306). There is no extensibility defined, and no IANA registry >> either. So a responder would be correct if it replied with an INVALID_SYNTAX >> rather than ignoring your notification, if it doesn't recognize it. >> >> And the value you are using (1) comes from RFC 2407 and has never existed in >> IKEv2. Ugh. >> >> Thanks, >> Yaron >> >> On 2013-08-25 10:53, Yoav Nir wrote: >>> >>> On Aug 25, 2013, at 9:45 AM, Yaron Sheffer <yaronf.i...@gmail.com> wrote: >>> >>>> Hi Yoav, >>>> >>>> I started by reading -01, then went back to -00. And I think the two can >>>> be merged to create a better solution. >>>> >>>> Including the notification as soon as the peers know they want a handover >>>> is cleaner. So IKE_AUTH (of the new SA) is better than DELETE, and in fact >>>> IKE_SA_INIT would be even more useful because then you can define that all >>>> such IKE SAs are implicitly childless, and avoid the need for the RFC 6023 >>>> notification. >>>> >>>> CAFR -01 says a peer is allowed to hand over the Child SAs if it >>>> successfully authenticates to the other peer and has the same >>>> authenticated identity. Seems to me this is symmetric, i.e. it doesn't >>>> matter if the exchange is run over the "old" or the "new" IKE SA. And so >>>> this could apply just as well to -00, and the POP stuff is not needed. >>>> >>>> I'm not sure about the race discussion in -00, because it only applies in >>>> failure cases. Can't an attacker "swallow" a few DELETE messages or their >>>> responses and cause a similar database mismatch? >>> >>> I hope they can't. Informationals with DELETEs are just like any other >>> IKEv2 exchange. If at active attacker swallows DELETEs or their responses, >>> eventually at least one side loses the IKE SA. >>> >>> But with regular initial IKE, there is an asymmetry. The Responder verifies >>> the IKE_AUTH request, generates the Response, sends it, and believes that >>> everything is just fine. Then the Initiator gets the IKE_AUTH response, and >>> decides that something is wrong. Maybe the certificate has just expired, or >>> the OCSP server is unreachable, or the new certificate does not have the >>> proper extended key usage. So we have an asymmetry, where the Responder >>> believes that IKE_AUTH succeeded, while the Initiator believes that it >>> failed. The Initiator quickly rectifies this with a DELETE, but that takes >>> some time (milliseconds, but still - time). >>> >>> So if we tie some action on the part of both parties to the IKE_AUTH >>> success, we get cases where the Responder performs the action, while the >>> Initiator does not. In this case, the Responder transfers the child SAs to >>> the new IKE SA, and the Initiator doesn't. The subsequent DELETE for the >>> new IKE SA sent by the Initiator deletes all those Child SAs on the >>> Responder, while they remain alive and active on the Initiator. You could >>> use some heuristic, like if the DELETE comes within x seconds of the >>> IKE_AUTH, you transfer the child SAs back. But that is some weird code that >>> we should not require people to make. >>> >>> Making the transfer follow the IKE_AUTH makes it all cleaner. Whether it's >>> done with the old or new IKE SA depends on whether you are worried about >>> childless IKE SAs kidnapping the children of other IKE SAs (sorry, couldn't >>> resist). We are not likely to require sameness of IP address, and I am >>> worried about the reliability of code comparing to IKE SAs for sameness of >>> authenticated identity. All L2TP over IPsec clients tend to have the same >>> identity (with user authentication being done at the PPP layer). Do we >>> allow them to claim each other's child SAs? I think not, and then if we >>> take the "pull" approach - using the new IKE SA - we need some PoP. With a >>> "push" approach - using the old IKE SA - we don't. >>> >>>> Also note that the notification syntax is in conflict with both RFC 5996 >>>> and RFC 4306. RFC 5996 removes the option of Protocol ID=1, while RFC 4306 >>>> assumes that we are talking about the *current* IKE SA, and so mandates >>>> that the SPI field should be empty in this case. Practically speaking, we >>>> will have to fix 5996 before this can document move forward. Luckily we're >>>> doing just that with Tero's bis draft. >>> >>> Good timing! >>> >>> Yoav >>> >> >> Email secured by Check Point >> > > Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
