Subject: [IPsec] Issue #173: Trigger packets should not be required

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Feb 2010 14:49:11 -0800

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...".

- "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...".

- The same change is made in the third bullet of the client list near the end of the section.

--Paul Hoffman, Director
--VPN Consortium

---

From: Dan McDonald <[email-masked]>
Date: Tue, 2 Feb 2010 17:52:50 -0500

On Tue, Feb 02, 2010 at 02:49:11PM -0800, Paul Hoffman wrote:
> 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.

BTW, this change makes a path to no-child-SA AUTH exchanges simpler.  It's
much simpler to have a no-child-SA creation of an IKE SA when you aren't
initiating in the service of a triggering packet.

> - "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 new text is fine.

> - "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...".

As is this new text.

Dan

---

From: Raj Singh <[email-masked]>
Date: Wed, 3 Feb 2010 08:55:27 +0530

I support this change.

On Wed, Feb 3, 2010 at 4:22 AM, Dan McDonald <[email-masked]> wrote:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 3 Feb 2010 09:54:51 +0200

Me too, but the draft still requires *some* selectors, so the childless draft is still needed.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Raj Singh
Sent: Wednesday, February 03, 2010 5:25 AM
To: Dan McDonald
Cc: IPsecme WG; Paul Hoffman
Subject: Re: [IPsec] Issue #173: Trigger packets should not be required

I support this change.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 8 Feb 2010 18:11:32 +0200

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. 

> 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.
-- 
[email-masked]