I guess, but it's still using one notification to announce another notification.
On Aug 25, 2013, at 1:08 PM, Yaron Sheffer <yaronf.i...@gmail.com> wrote: > And this would imply support for Childless, too? > > Thanks, > Yaron > > On 2013-08-25 13:01, Yoav Nir wrote: >> 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 >> > > Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
