[IPsec] Closing #25

[Tero Kivinen <[e-mail]>]

Paul Hoffman writes:
> At 9:46 AM +0200 10/21/09, Yoav Nir wrote:
> > A few lines above this section it already says "If the responder's
> > policy allows it to accept the first selector of TSi and TSr, then
> > the responder MUST narrow the traffic selectors to a subset that
> > includes the initiator's first choices." 
> >
> > So there is a MUST requirement to select the initiator's first
> > choice (if possible), so I don't think the SHOULD and MAY are
> > appropriate here. The way I read this section, it only clarifies
> > what to do if the initiator traffic selector (first or not) is too
> > broad. In that case, we shouldn't mention the initiator's choices. 
> >
> >On Oct 20, 2009, at 6:19 PM, Paul Hoffman wrote:
> >
> >>Issue #25, Choice of the right TS when narrowing
> ><snip/>
> >>Proposed change:
> >>  When narrowing is done, there may be several subsets that are
> >>  acceptable but their union is not.  In this case, the responder
> >>  SHOULD select the initiator's first choice (to be interoperable
> >>  with RFC 4306), but MAY arbitrarily select any of them,
> >>  and MAY include an
> >>  ADDITIONAL_TS_POSSIBLE notification in the response.
> 
> God call. I have closed #25 without making any change.

There is one problem with the current text for this traffic selector
negotiation.

If the initiator has policy that says (I only use one end of traffic
selectors as that is enough for this example):

  192.0.2.0 - 192.0.2.255 PROTECT

and responder has policy that says:

  192.0.2.128 - 192.0.2.255 PROTECT

Now when initiator gets packet form the network that has address of
192.0.2.5, it will match its policy and it will start creating new IKE
SA and Child SA. It sends traffic selectors having content of:

  TS(TCP:80-80, 192.0.2.5 - 192.0.2.5)
  TS(0:0-65535, 192.0.2.0 - 192.0.2.255)

The responder will see those and starts following the rules in the
section 2.9. 
----------------------------------------------------------------------
   The responder performs the narrowing as follows:

   o  If the responder's policy does not allow it to accept any part of
      the proposed traffic selectors, it responds with TS_UNACCEPTABLE.

   o  If the responder's policy allows the entire set of traffic covered
      by TSi and TSr, no narrowing is necessary, and the responder can
      return the same TSi and TSr values.

   o  If the responder's policy allows it to accept the first selector
      of TSi and TSr, then the responder MUST narrow the traffic
      selectors to a subset that includes the initiator's first choices.
      In this example above, the responder might respond with TSi being
      (192.0.1.43 - 192.0.1.43) with all ports and IP protocols.

   o  If the responder's policy does not allow it to accept the first
      selector of TSi and TSr, the responder narrows to an acceptable
      subset of TSi and TSr.
----------------------------------------------------------------------

1) The responder's policy do allow some part of the traffic selectors,
   so it does not send TS_UNACCEPTABLE.

2) Responder's policy does not allow entire set of traffic, so it
   cannot return full set.

3) Responder's policy does not allow first traffic selector, so it
   cannot narrow it down to that.

4) So it gets to this last rule and narrows traffic selectors down to
   acceptable subset of initiators set, i.e resulting traffic selector
   will be:

  TS(0:0-65535, 192.0.2.128 - 192.0.2.255)

Now when initiator gets this it installs the Child SA as normally. The
created SA is useless for triggering packet, so it cannot send the
packet over that SA, and most likely it will throw that packet away.

When the next packet coming having same address comes in, it most
likely triggers new child SA exchange with same results. After a few
hundred packets the initiator and responder have 100 overlapping Child
SAs which all are completely useless for any traffic.

Responder cannot do anything, as it is completely valid to create
multiple overlapping Child SAs, as this is required for the QoS.

Initiator might try to do something smart and for example disable the
trigger rule for next n minutes when it started creating Child SA, so
it will not trigger again, but at some point it do want to enable the
trigger again, just in case the other end has fixed its configuration.

All of this is caused because of the final rule saying:

   o  If the responder's policy does not allow it to accept the first
      selector of TSi and TSr, the responder narrows to an acceptable
      subset of TSi and TSr.

If that would not be there, then the responder would return
TS_UNACCEPTABLE to the initiators Child SA create exchange, which
would prevent creating extra Child SAs. This final rule is NOT in the
RFC4306 in triggering packet case, it was only there in case there was
no triggering packet (of course there is no text explaining how do you
know if the first traffic selector is triggering packet or not).

I suggest that we add text explaining what it means when there is
triggering packet and modify the last rule to be:

   o  If the initiator's first TSi and TSr are not from triggering
      packet (i.e. they are ranges), then if the responder's policy
      does not allow it to accept the first selector of TSi and TSr,
      the responder narrows to an acceptable subset of TSi and TSr.

And the text to explain what triggering packet is should be added
before paragraph above:

   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. This kind of
   triggering packet can be detected because it exactly match one IP
   address, protocol and port. In the example, the initiator would
   include in TSi two traffic selectors: the first containing the
   address range (192.0.1.43 - 192.0.1.43) and the source port and IP
   protocol from the packet and the second containing (192.0.1.0 -
   192.0.1.255) with all ports and IP protocols. The initiator would
   similarly include two traffic selectors in TSr. If the initiator
   creates the Child SA pair not in response to an arriving packet,
   but rather, say, upon startup, then there may be no specific
   addresses the initiator prefers for the initial tunnel over any
   other. In that case, the first values in TSi and TSr will be ranges
   rather than specific values.

(Added text "This kind of triggering packet can be detected because it
exactly match one IP address, protocol and port." in the middle, and
changed the final "can be ranges" to "will be ranges". 
-- 
[e-mail]