Am reading this right? On Fri, Feb 19, 2010 at 08:22:51AM -0800, Paul Hoffman wrote: > At 1:10 PM +0200 2/19/10, Tero Kivinen wrote: > >Yoav Nir writes: > >> Hi all. > >> > >> There are only three issues this time, because this is the last batch. > >> > > > Issue #173 - Trigger packets should not be required > >> =================================================== > >> In a few places in the new section 2.23.1 in IKEv2bis, it says that one > >> must have a trigger packet when starting negotiation. This assumption > >> should be removed so as not to cause new requirements in IKEv2bis: > >> there is no requirement for trigger packets in RFC 4306 or in the rest > >> of IKEv2bis. > >> > >> - "When the client starts creating the IKEv2 SA and Child SA for sending > >> traffic to the server, it has a triggering packet with source IP address > >> of IP1, and a destination IP address of IPN2" should be changed to > >> "...it may have a triggering packet...". > > > >This change is wrong.
Tero -- why precisely is "may have a triggering packet" wrong? The change is to say, "may have a triggering packet," right? If I understand that, then what Tero says: > >If client starts creating IKEv2 SA for sending traffic, it will have > >trigger packet. If it creates IKEv2 SA for some other reason (i.e not > >because of trigger packet, but because of autostart rule or similar), > >then it does not have triggering packet. AND what Paul says: > We disagree. If a client starts creating an IKEv2SA for sending traffic, it > may do that because it knows it will have packets in the future, but does > not have them when it sets up the SA. An autostart rule that is based on > *knowing* that something will come in the future is still creating IKEv2 SA > for sending traffic. are both true. If there's disagreement, it's only because you two are tassling over what constitutes "creating an IKEv2 SA for sending traffic." Sure an IKEv2 SA can be used for sending traffic, but creating one doesn't have to be the result of an outbound packet that needs AH or ESP protection. Both of you acknowledge, I believe, that creating an IKEv2 SA can occur without a triggering packet (whether it's by some autostart rule, or some explicit administrator action). Am I missing something else? Ahh, I think I am. After reviewing Tero's note: > All of that paragraph is for the case where you do have packet. It > does not cover other cases. > > > - The same change is made in the third bullet of the client list near > > the end of the section. > > This is the one that needs to be changed, as that third bullet is not > only specific to triggering packet case, it is in the generic > processing section, i.e. that bullet should be changed to: > > - If SA is created because of the data packet, then the first TSi > and TSr traffic selectors SHOULD have very specific traffic > selectors including protocol and port numbers from the packet > triggering the request. So Tero --> you agree that an IKEv2 SA can be created w/o a triggering packet, but the changes need to be localized to only certain portions of 4301bis, while the other portions of text only apply when we KNOW a triggering packet would be present? Just checking, Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
