Subject: [IPsec] Issue #12: Traffic selectors when rekeying vs. the packet that trigerred the rekeying

From: Yaron Sheffer <[email-masked]>
Date: Wed, 1 Apr 2009 23:37:54 +0300

Tero:

I think we should mention that the traffic selectors for the rekying should
have those selectors from the packet (see section 2.9):

    To allow responder to do intelligent narrowing of the traffic selector
the responder should know which packet triggered the rekeying, so it will
not narrow the traffic selectors to set which is not usable for the packet
triggering the rekeying. This means that even the traffic selectors for the
rekeying needs to have those selectors from the packet (see section 2.9).
Note, that if the responders policy has changed, it is possible that
originally traffic that fit to one SA cannot fit to one SA anymore, which
means the responder will narrow the traffic selectors so that not all
original traffic fits to SA anymore. In that case the initiator getting
packet that only fits the old SA (which is waiting to be deleted) but not
new, should create new SA for this traffic too (but it is not rekeying
anymore, so no REKEY_SA notify is included in the exchange). Same thing
happens when the original SA expires, and one ends gets packet which not fit
the current traffic selectors, but instead triggers new SA creation.

No SF discussion.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 2 Apr 2009 16:27:44 +0300

I agree with Tero.

How about replacing this:
   The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
   payload, optionally a Diffie-Hellman value in the KEi payload, and
   the proposed traffic selectors for the proposed Child SA in the TSi
   and TSr payloads.

With this:
   The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
   payload, optionally a Diffie-Hellman value in the KEi payload, and
   the proposed traffic selectors for the proposed Child SA in the TSi
   and TSr payloads. The TSi and TSr payloads SHOULD include the
   very specifig traffic selectors including the addresses in the packet
   triggering the request, as described in section 2.9.

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaron Sheffer
Sent: Wednesday, April 01, 2009 11:38 PM
To: IPsecme WG
Subject: [IPsec] Issue #12: Traffic selectors when rekeying vs. the packet that trigerred the rekeying

Tero:

I think we should mention that the traffic selectors for the rekying should have those selectors from the packet (see section 2.9):

    To allow responder to do intelligent narrowing of the traffic selector the responder should know which packet triggered the rekeying, so it will not narrow the traffic selectors to set which is not usable for the packet triggering the rekeying. This means that even the traffic selectors for the rekeying needs to have those selectors from the packet (see section 2.9). Note, that if the responders policy has changed, it is possible that originally traffic that fit to one SA cannot fit to one SA anymore, which means the responder will narrow the traffic selectors so that not all original traffic fits to SA anymore. In that case the initiator getting packet that only fits the old SA (which is waiting to be deleted) but not new, should create new SA for this traffic too (but it is not rekeying anymore, so no REKEY_SA notify is included in the exchange). Same thing happens when the original SA expires, and one ends gets packet which not fit the current traffic selectors, but instead triggers new SA creation.

No SF discussion.

Email secured by Check Point

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 7 Apr 2009 13:45:54 +0300

>    triggering the request, as described in section 2.9.

That is one change that is needed, but in addition I think we need to
say that the TSi and TSr should be the original traffic selectors from
the policy, not the already narrowed down ones that the current child
SA is using.

I.e. if initiator originally offered TSi as 10.0.0.0-10.0.255.255 and
included specific packet of 10.0.0.5 TCP port 25 by sending following
TSi entries:

TSi = (TCP, 25 - 25, 10.0.0.5 - 10.0.0.5)
      (0, 0 - 65535, 10.0.0.0 - 10.0.255.255)

and then the responder narrowed it down to per host basic, i.e.
returned TSi as:

TSi = (0, 0 - 65535, 10.0.0.5 - 10.0.0.5)

now when the initiator starts to rekey that SA after receiving TCP
packet going to that SA (otherwise he would not be rekeying this SA),
and lets say the packet is 10.0.0.5 TCP port 80, so he should send TSi
when rekeying as follows:

TSi = (TCP, 80 - 80, 10.0.0.5 - 10.0.0.5)
      (0, 0 - 65535, 10.0.0.0 - 10.0.255.255)

Note, that the second entry is still the whole 10.0.0.0 - 10.0.255.255
range as specified by the policy, not the already narrowed down range
of 10.0.0.5 - 10.0.0.5 which the current child SA is using.

If the responders policy is still same it will still return same TSi:

TSi = (0, 0 - 65535, 10.0.0.5 - 10.0.0.5)

If the responders policy has been changed so that port host SAs are no
longer required it can instead rekey the old SA to have TSi which
would cover the new range, i.e. widen up the traffic selectors from
what they used to be.

If this is not done, then this kind of widening is not possible,
meaning that even if the policy is fixed the original more narrow
policy is still used.

I have seen implementations where the traffic selectors are sent out
(and narrowed to) based on the traffic selectors used in the child SA
now, not what is specified in the policy. The traffic selectors used
in the child SA can always be only more narrow than what is in the
policy (if child SA would have more wider traffic selectors than what
is allowed by policy it would be violating the policy, and it would be
deleted).

I would like to have text saying that the original traffic selectors
from the policy SHOULD be used. 
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Tue, 7 Apr 2009 16:18:23 +0300

The traffic selectors in the REKEY exchange are not currently specified. If were designing IKEv2 from scratch, I would be in favor of removing traffic selectors altogether from REKEY exchanges - I don't think it should be called a "rekey" if you get a totally different SA.  This does raise the question (that has been asked before) of why do we really need REKEY_SA exchanges as opposed to regular exchanges.

As it is, I think the initiator of the rekey (not necessarily the same as the initiator of the old SA) should keep the selectors in the old SA, and the responder should either accept of reject, but I don't think we need to capitalize the SHOULD.

In some implementations, the REKEY is generated because of traffic passing the IPsec stack when little time remains before the child SA expiration. It may be much more convenient to rekey with the narrowed selectors rather than locating an SPD entry which is a superset of the SPD cache entry that matches this SA.

I think the rekey initiator SHOULD propose any superset of the current selectors, which can be the current selectors, or anything that matches its policy. I don't think we should recommend doing one or the other.  We can and should, however, require the responder to not expect the traffic selectors in a rekey-SA to exactly match those of the current SA.

Tero Kivinen wrote:
> That is one change that is needed, but in addition I think we 
> need to say that the TSi and TSr should be the original 
> traffic selectors from the policy, not the already narrowed 
> down ones that the current child SA is using.
> 
> I.e. if initiator originally offered TSi as 
> 10.0.0.0-10.0.255.255 and included specific packet of 
> 10.0.0.5 TCP port 25 by sending following TSi entries:
> 
> now when the initiator starts to rekey that SA after 
> receiving TCP packet going to that SA (otherwise he would not 
> be rekeying this SA), and lets say the packet is 10.0.0.5 TCP 
> port 80, so he should send TSi when rekeying as follows:
> 
> Note, that the second entry is still the whole 10.0.0.0 - 
> 10.0.255.255 range as specified by the policy, not the 
> already narrowed down range of 10.0.0.5 - 10.0.0.5 which the 
> current child SA is using.
> 
> If the responders policy has been changed so that port host 
> SAs are no longer required it can instead rekey the old SA to 
> have TSi which would cover the new range, i.e. widen up the 
> traffic selectors from what they used to be.
> 
> If this is not done, then this kind of widening is not 
> possible, meaning that even if the policy is fixed the 
> original more narrow policy is still used.
> 
> I have seen implementations where the traffic selectors are 
> sent out (and narrowed to) based on the traffic selectors 
> used in the child SA now, not what is specified in the 
> policy. The traffic selectors used in the child SA can always 
> be only more narrow than what is in the policy (if child SA 
> would have more wider traffic selectors than what is allowed 
> by policy it would be violating the policy, and it would be deleted).
> 
> I would like to have text saying that the original traffic 
> selectors from the policy SHOULD be used. 
> --
> [email-masked]

---

From: Scott C Moonen <[email-masked]>
Date: Tue, 7 Apr 2009 11:13:30 -0400

I agree with Yoav, for two reasons.  First, as Yoav suggests, the idea of 
doing a rekey seems to correspond in principle more closely with holding 
everything else about the SA constant.  Second, by the time you want to 
rekey a child SA, the notion of referring to the original selectors seems 
strange and arbitrary.  By that time, the original connection that 
triggered the SA might be gone, and a dozen other connections might be 
using the SA.  In that case, to reuse the original packet selectors when 
refreshing the SA would obviously be incorrect.

I think it is better to recommend that you exactly reuse the existing SA 
selectors on rekey.  True, in case the responder policy has changed, the 
rekey may fail.  (However, one wonders why the policy change didn't cause 
the existing SA to be deleted.)  Nevertheless, if the rekey fails, once 
the original SA expires, new SA(s) can be negotiated on-demand as needed 
to serve existing connections.  I think this is better than having the 
illusion of doing a rekey that accommodates policy changes but which might 
actually not benefit any existing connection at all.

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
1-919-254-1388 (T/L: 444-1388)
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen

From:
Yoav Nir <[email-masked]>
To:
Tero Kivinen <[email-masked]>
Cc:
IPsecme WG <[email-masked]>
Date:
04/07/2009 09:18 AM
Subject:
Re: [IPsec] Issue #12: Traffic selectors when rekeying vs. the packet that 
trigerred the rekeying

The traffic selectors in the REKEY exchange are not currently specified. 
If were designing IKEv2 from scratch, I would be in favor of removing 
traffic selectors altogether from REKEY exchanges - I don't think it 
should be called a "rekey" if you get a totally different SA.  This does 
raise the question (that has been asked before) of why do we really need 
REKEY_SA exchanges as opposed to regular exchanges.

As it is, I think the initiator of the rekey (not necessarily the same as 
the initiator of the old SA) should keep the selectors in the old SA, and 
the responder should either accept of reject, but I don't think we need to 
capitalize the SHOULD.

In some implementations, the REKEY is generated because of traffic passing 
the IPsec stack when little time remains before the child SA expiration. 
It may be much more convenient to rekey with the narrowed selectors rather 
than locating an SPD entry which is a superset of the SPD cache entry that 
matches this SA.

I think the rekey initiator SHOULD propose any superset of the current 
selectors, which can be the current selectors, or anything that matches 
its policy. I don't think we should recommend doing one or the other.  We 
can and should, however, require the responder to not expect the traffic 
selectors in a rekey-SA to exactly match those of the current SA.

Email secured by Check Point
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 8 Apr 2009 14:50:02 +0300

Yoav Nir writes:
> The traffic selectors in the REKEY exchange are not currently
> specified. If were designing IKEv2 from scratch, I would be in favor
> of removing traffic selectors altogether from REKEY exchanges - I
> don't think it should be called a "rekey" if you get a totally
> different SA.  This does raise the question (that has been asked
> before) of why do we really need REKEY_SA exchanges as opposed to
> regular exchanges.

I think the reason for REKEY_SA is to know which SA is being replaced
with the one we are creating now. I.e. from where we can move
statistics to, and from which SA we should move traffic to this new SA
(even before the old SA expires, but after we know other end has also
installed the SAs, i.e. after responder sees traffic in the new
incoming SA).

For example in our implementation rekeyed SA shares same internal SA
slot in the engine, i.e. we have one SA slot having two associated
crypto contextes and SPIs, and only one of them are in active use.
I.e. old one is in use until traffic moves to new one and then later
the old ones are removed (but might still be used to decrypt traffic
as there might be out of order packets coming in) etc. I.e. it makes
implementations easier and more efficient when you know which SA is
going to be replaced with the rekey.

In IKEv1 you usually tried to do same by inspecting the selectors and
tried to guess which one was the old SA being replaced. This is not
possible in IKEv2, as it is normal to have multiple overlapping Child
SAs with same selectors for different QoS classes.

> As it is, I think the initiator of the rekey (not necessarily the
> same as the initiator of the old SA) should keep the selectors in
> the old SA, and the responder should either accept of reject, but I
> don't think we need to capitalize the SHOULD.

Responder should do normal narrowing of the selectors, it should not
ever reject the selectors. I mean if the selectors initiator offered
is superset of the old selectors of the SA, they cannot be against the
policy of the responder, thus the responder should either accept wider
ones or narrow it down to subset of the offered selectors as normally. 

> In some implementations, the REKEY is generated because of traffic
> passing the IPsec stack when little time remains before the child SA
> expiration. It may be much more convenient to rekey with the
> narrowed selectors rather than locating an SPD entry which is a
> superset of the SPD cache entry that matches this SA.

I agree that should be allowed, but in most cases the implementations
do have pointers back to the original SPD entry anyways, and in that
case they SHOULD use the original selectors from the SPD entry if they
are readily available.

> I think the rekey initiator SHOULD propose any superset of the
> current selectors, which can be the current selectors, or anything
> that matches its policy.

Yes. 

> I don't think we should recommend doing one or the other.

I would prefer to say "SHOULD" for the selectors from the original SPD
entry, but I can accept also the wording saying that either one can be
used. 

> We can and should, however, require the responder to not expect the
> traffic selectors in a rekey-SA to exactly match those of the
> current SA.

Yes, this is something we should at least require (even as MUST).

Now that I think more of this I think the initiators proposed
selectors MUST always be same or superset of the old SAs selectors.
They cannot be narrower than what was used before, as that would
normally mean that the policy of the inititor was changed so that old
SA is no longer valid with the new policy, which means it should be
deleted and new SA created (and this is so rare case, that we do not
need to optimize performance for this). Earlier I though we could use
rekey in that case too, but I think it is better to say it MUST be
same or superset of the currently used selectors.

The responder should narrow the offered proposal down to either
superset of the current used selectors, or same as currently used
selectors. Again it really cannot narrow it down to anything smaller
than currently used, as in that it case the current SA is against its
policy, and should be deleted.

If we go with those rules (i.e. SA can be rekeyed only to superset of
the current SA, never to subset), then we actually do NOT need the
specific selectors from the packet, as we always know that the subset
where we need to narrow it down to, is the one containing the old SAs
selectors. 

So perhaps we should change the resolution to issue #12 (and #11):
----------------------------------------------------------------------
  - When initiator proposes traffic selectors when rekeying Child SA,
    the proposed traffic selectors SHOULD be either superset of the
    traffic selectors used in the Child SA (i.e. come from the
    currently active (decorrelated) policy), or same as the traffic
    selectors currently used.

  - When responder narrows traffic selectors down when rekeying Child
    SA, the narrowed traffic selectors SHOULD be either superset of
    the traffic selectors used in the Child SA, or same as the traffic
    selectors currently used.

  - As rekeyed SA can never have narrower scope than currently in use,
    there is no need for selectors from the packet (section 2.9), so
    those selectors SHOULD NOT be sent.

If the rekeyed SA would ever have narrower scope than currently used
SA, that would mean that the policy was changed so that the currently
used SAs is against the policy, which means it should have been
already deleted after the policy change took effect.
----------------------------------------------------------------------

(Yes, I know, I changed my mind during the process :-)
-- 
[email-masked]