Paul Hoffman writes: > 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.
There is SHOULD requirement for trigger packet if negotiation was started because of traffic. See section 2.9 saying: To enable the responder to choose the appropriate range in this case, if the initiator has requested the SA due to a data packet, the initiator SHOULD include as the first traffic selector in each of TSi and TSr a very specific traffic selector including the addresses in the packet triggering the request. ... Hmm... it seems that SHOULD was removed in the IKEv2bis, and it is not mentioned in the section 1.7, so I am not sure if that was intentional. The current text in 2.9 says: If the initiator requests an SA because it wants to send a data packet, including the specific addresses in the packet triggering the request in the first traffic selector in both TSi and TSr enables the responder to choose the appropriate range. and I think it should be changed to keep the SHOULD: If the initiator requests an SA because it wants to send a data packet, it SHOULD include the specific addresses in the packet triggering the request in the first traffic selector in both TSi and TSr to enable the responder to choose the appropriate range. > - "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...". Note, that this is the case where client starts creating IKEv2 SA because it has traffic to send to the server, so it has the triggering packet. If it decides to create IKEv2 SA bacause of some other reason, then he does not have triggering packet, but it is bit funny to say that "When you have packet you are sending from client to server, you may have packet..." > - "The first traffic selector of TSi and TSr SHOULD have very > specific traffic selectors including protocol and port numbers from > the packet triggering the request" should be changed to "...SHOULD > have very specific traffic selectors including protocol and port > numbers, such as from the packet...". This SHOULD matches the RFC4306 SHOULD, and it should be kept here, or otherwise we need to note, that this SHOULD is no longer requirement. If the transport mode NAT-T SA is created because of autostart rule or similar, it does not have this specific first traffic selector, so saying "such as from the packet" is wrong, as those triggering packet information is always from the packet. The current text does not really explictly mention the case where triggering packet is not there as it concentrates on the cases where the trasnport mode SA is created because of the traffic client is sending to the server. On the other hand generic traffic selector processing has already been described in the 2.9 and the transport mode NAT-T case does not really modify that, except it only allows one IP address to be used in the traffic selectors. The text about the triggering packet is important here, as some implementors have misinterpreted the text in RFC4306 to mean there can be only one traffic selector, and they have failed to create SA if there was multiple traffic selectors even when they had same IP address in them and the first one of them was the triggering packet. > - The same change is made in the third bullet of the client list > near the end of the section. That third bullet might need a text saying "If SA is created because of the data packet, then the first TSi and TSr ....", but the SHOULD should be still there. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
