Subject: [IPsec] Issue #155: SHOULD send triggering packet and interoperability

From: Paul Hoffman <[email-masked]>
Date: Thu, 21 Jan 2010 09:11:14 -0800

In the sectioon 2.9 the "SHOULD" requirement was removed for the
very specific traffic selector as fist traffic selector.

I think that "SHOULD" requirement needs to be kept, as it affects
interoperability, as if other end does not include that triggering
packet then certain policies cannot interoperate.

Also in the interops we have seen implementations who could not
interoperate at all if sender end included triggering packet (I do not
know if the failure to create Child SA was because the traffic
selector containing port selectors, or whether it was because there
were multiple traffic selectors).

If there is "SHOULD" level requirement for that, then we can at least
point the other vendors to that and say, that as we SHOULD be sending
that triggering packet, then you also needs to be able to cope with
it...

Old text was:

   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.

new text in draft-ietf-ipsecme-ikev2bis-07.txt is:

   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.  

--Paul Hoffman, Director
--VPN Consortium