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.
We disagree. >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. 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. I still feel strongly that the wording as it stands imposes a new requirement in IKEv2bis, and that is inappropriate to do so. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
