Subject: [IPsec] Traffic Selectors - CHILD_SAs that do not allow TSi[1] & TSr[1]

From: Jeff Sun <[email-masked]>
Date: Wed, 28 Jan 2009 00:27:41 -0800

Hi,
  According to RFC 4306 Section 2.9, an implementation SHOULD include
specific traffic selectors for the first traffic selectors in the TSi and
TSr Payloads.  The reason that this specification is a SHOULD and not a MUST
is because (as stated in Section 2.9), upon start-up, some implementations
may try recover previous CHILD_SA state in response to an unexpected device
crash.  However, RFC 4718 goes on to clarify traffic selector negotiation by
defining the narrowing process more clearly.

  Specifically, it states that if the union of all subsets is not acceptable
by policy, then the subset that contains the first traffic selectors
(TSi[1], TSr[1]) take precedence over the subsets that do not contain these
first traffic selectors.  Furthermore, the section also details a case where
no subsets contain TSi[1] and TSr[1] - in this case the responder
arbitrarily chooses a subset.  I assume that TSi[1] and TSr[1] in context of
RFC 4718-Section 2.9 speaks of the specific traffic selectors (the traffic
selectors of the packet that triggered the Initial Exchange/CREATE_CHILD_SA
Exchange).  Note, RFC 4718-Section 2.9 never speaks of the start-up case,
thus it seems that the TSi[1] and TSr[1] (the specific traffic selectors)
cases are only scoped now.

  If this indeed is the case, perhaps the last case (where TSi[1] and TSr[1]
are not encompassed) should be re-considered.  Specifically, what is the
benefit of establishing a CHILD_SA such that the specific traffic selectors
are not encompassed?  The CHILD_SA establishment exchange was triggered by
that packet and generally speaking, it seems that subsequent traffic flow
would be of the same specific traffic selectors, not the other traffic
selectors associated with the specific SPD Rule Entry hit.

  In nutshell, it's probably better suited that the responder simply send
back a Notify Payload - Error Message (i.e,
FIRST_TRAFFIC_SELECTORS_PROHIBITED), thus refusing to establish the
CHILD_SA.  If by chance, different traffic flow (with different specific
traffic selector) hits the same SPD Rule entry, a new CHILD_SA
establishement exchange would simply initiate and establish a new CHILD_SA.

Thanks,
  Jeff Sun
-- 
For relaxing times, make it Suntory time. - Bob Harris, Lost in Translation
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 28 Jan 2009 15:17:34 +0200

> cases are only scoped now.

The rule saying that you select arbitrary subset if first traffic
selectors cannot be fit to the policy, is just there to work with the
startup case.

As there is no indication from the initiator whether this is startup
case or not, the responder cannot know whether the first traffic
selector is from the packet or whether it is from the policy. The
rules in rfc 4718 are written as they are so that they will work in
both cases.

I.e if the first traffic selector is from the packet (i.e. the 3rd
bullet point in the 4.10 of RFC4718) then narrowing is done so that
first traffic selector is included to the returned range. Note, that
usually in this case one of the remaining traffic selectors is
superset of the first traffic selector (i.e. the actual policy entry).

If the first traffic selector is not from the packet but from policy
then is possible that it is not completely allowed by local policy. In
that case there is nothing responder can do better than guess what
initiator meant, i.e. it will narrow down to any acceptable subset
(4th bullet point).

Note, that the last paragraph of 4.10 which says that responder
arbitrarily chooses one of them cannot apply for the 3rd bullet in
case the first traffic selector is really from packet. If the first
traffic selector has exact values taken from the packet, then there
cannot be multiple subsets which include that (as the SPD is ordered).

The last paragraph only include 3rd bullet because it might happen
that the first traffic selector is not from packet but from policy but
the whole range is still acceptable by local policy. 

> selectors associated with the specific SPD Rule Entry hit.

That case is really meant for cases where the first traffic selectors
do not come from the packet. I agree that in case the first traffic
selector happens to be from packet and it cannot be fitted in, then
creating some other SA which do not include first traffic selector
does not really help for transmitting that packet. On the other hand
if that packet is not allowed at all by the remote ends policy that
packet will never be transmitted anyways.

One of the problems is that there is still lots of broken IKEv2
implementations who do not send first traffic selector with data from
the packet at all.

In the last IKEv2 interoperability event there were few
implementations who didn't work at all if other end decided to send
traffic selector containing triggering packet data (i.e. we had to add
flag that allowed us to disable sending that data). Most of the
implementations accepted such traffic selectors, but only half of the
implementations actually sent such traffic selectors.

Because of this implementations wanting to work properly with other
vendors, need to do some compatibility code to work with those broken
implementations. 

-- 
[email-masked]