Subject: [IPsec] Bis issue #11: Clarify which traffic selectors to use in rekeying

From: Yaron Sheffer <[email-masked]>
Date: Wed, 28 Jan 2009 00:49:46 +0200

Existing text (sec. 1.3.1)

The CREATE_CHILD_SA response for creating a new Child SA is:

                                <--  HDR, SK {SA, Nr, [KEr],

                                         TSi, TSr}

The responder replies (using the same Message ID to respond) with the accepted offer in an SA payload, and a Diffie-Hellman value in the KEr payload if KEi was included in the request and the selected cryptographic suite includes that group.

The traffic selectors for traffic to be sent on that SA are specified in the TS payloads in the response, which may be a subset of what the initiator of the Child SA proposed.

Tero:

Add comment about which traffic selectors to use in the rekeying:

When doing rekeying the traffic selectors SHOULD come from the original decorrelated policy, i.e. not the same traffic selectors which the old SA had in case the responder narrowed them, but from the policy which initiator used originally to create the IPsec SA. This allows the SA to expand to full traffic selector set allowed by latest (perhaps changed) policy.

Paul:

Not done. This is interesting, but should be discussed on the list.

Email secured by Check Point

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Wed, 28 Jan 2009 10:17:55 +0200

Yaron Sheffer wrote:

> The responder replies (using the same Message ID to respond) with the accepted offer in an SA
> payload, and a Diffie-Hellman value in the KEr payload if KEi was included in the request and the
> selected cryptographic suite includes that group.
>
>   The traffic selectors for traffic to be sent on that SA are specified
>   in the TS payloads in the response, which may be a subset of what the
>   initiator of the Child SA proposed.
>
> Tero:
> When doing rekeying the traffic selectors SHOULD come from the original decorrelated policy, i.e.
> not the same traffic selectors which the old SA had in case the responder narrowed them, but from
> the policy which initiator used originally to create the IPsec SA. This allows the SA to expand to
> full traffic selector set allowed by latest (perhaps changed) policy.
>
> Paul:

It can be done as Tero suggests, as long as the policy hasn't changed, and as long as the new initiator is the same as the old initiator. But what if the original decorrelated policy is no longer valid, but the current SPD cache entry still is?  What if the new initiator (formerly the responder) does not have the same decorrelated policy?

I suggest that the (new) initiator be able to rekey with any traffic selectors, as long as they are a superset of the old SA selectors. IOW as long as the (new) responder can narrow the selectors down to the selectors from the old SA, it should be fine. Here's some proposed text for the end of section 1.3.3.

   The traffic selectors for traffic to be sent on that SA are specified
   in the TS payloads in the response, which may be a subset of what the
   initiator of the Child SA proposed. When rekeying a Child SA, the
   proposal of the initiator MUST be a superset of the selectors of the
   old SA.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 28 Jan 2009 14:36:13 +0200

Yoav Nir writes:
> It can be done as Tero suggests, as long as the policy hasn't
> changed, and as long as the new initiator is the same as the old
> initiator. But what if the original decorrelated policy is no longer
> valid, but the current SPD cache entry still is?

If the policy has changed so that old SA is no longer valid (and
cannot be rekeyed because of that), then that is even more reason to
use the new policy and create new SA which is allowed by policy and
delete the old SA which after the reconfigruation would be against the
current policy.

If policy is not changed then they should get same narrowing happening
again, meaning they will get new SA with same traffic selectors. If
policy has been changed so it affects the resulting SA, then the new
SA MUST follow new policy and reusing old traffic selectors (which are
against current policy) would be violation of policy. 

> What if the new initiator (formerly the responder) does not have the
> same decorrelated policy?

If the policies re different in both ends, then it is possible the
traffic selectors will be different depending which end created the
SA. I do not think that really matters.

> I suggest that the (new) initiator be able to rekey with any traffic
> selectors, as long as they are a superset of the old SA selectors.
> IOW as long as the (new) responder can narrow the selectors down to
> the selectors from the old SA, it should be fine. Here's some
> proposed text for the end of section 1.3.3.

So you propose that is not necessarely to take traffic selectors
directly from policy, but initiator starting rekey can take any
superset of current traffic selectors, even when it would not be
subset of its own policy?

That would mean initiator of the rekey could be violating his own
policy, and I do not think we want to allow that. 

>    proposal of the initiator MUST be a superset of the selectors of the

This would mean that if initiators policy has changed so that some
addresses are no longer acceptable by policy he cannot use rekey to
create new SA with that set of traffic selectors, but he must delete
the old IPsec SA and create new.

I.e. lets take example:

Host A has policy of

local = 192.168.11.0-192.168.11.64
remote = any

Host B has policy of

remote = 192.168.11.1-192.168.11.99
local = 10.0.0.0 - 10.255.255.255

Host A initiates first and proposes traffic selectors:

TSi = 192.168.11.0-192.168.11.64
TSr = 0.0.0.0-255.255.255.255

Host B narrows them down to:

reply TSi = 192.168.11.1-192.168.11.64
reply TSr = 10.0.0.0 - 10.255.255.255

Now if host A would start rekey the TSi, TSr, and reply TSi, and TSr
would be exactly same. If Host B starts rekey the traffic selectors
would be:

TSi = 10.0.0.0 - 10.255.255.255
TSr = 192.168.11.1-192.168.11.99
reply TSi = 10.0.0.0 - 10.255.255.255
reply TSr = 192.168.11.1-192.168.11.64

i.e. resulting exactly same traffic selectors..

Now if host B is reconfigured with new policy:

remote = 192.168.11.1-192.168.11.99
local = 10.10.0.0 - 10.10.255.255

With your proposal host B cannot anymore rekey the old SA at all as it
cannot propose the new local IP address range 10.10.0.0 -
10.10.255.255 as it is not superset of the negotiated traffic
selector 10.0.0.0 - 10.255.255.255. Host A could still rekey as he
could offer remote = any, and host B could then narrow it down to new
smaller range.

In my proposal both ends could still rekey the old SA with new traffic
selectors.

Hmm... perhaps the "original policy" word in my text was misleading. I
do not mean the exact policy values the node had when the SA was
created, but that the same policy entry that caused the SA to be
created is looked up and the current policy values are then fetched.

I.e. get the same SPD entry (or its successor if it has been changed)
and derive traffic selectors from there again. In essence this means
doing policy lookup based on the any packet going to the IPsec SA and
finding the SPD entry that should be used for that packet. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Wed, 28 Jan 2009 16:43:44 +0200

> delete the old SA which after the reconfigruation would be against the

I was referring to the case where the old SA is still valid (it is a subset of some (new) SPD entry) but that SPD entry is no longer the same as the old SPD entry that was the basis for the proposal form the original initiator.

> subset of its own policy?

The (new) initiator should, of course, make a proposal based on its (new) policy, but it can only count as a rekey if it is a superset of the existing SA selectors.

> the old IPsec SA and create new.

Yes.

> finding the SPD entry that should be used for that packet.

I think that SA should have been deleted the moment host B was reconfigured, as it violates host B's policy.  In any case it requires a new SA, not a rekey of the old SA.

---

From: Dan McDonald <[email-masked]>
Date: Wed, 28 Jan 2009 10:11:43 -0500

On Wed, Jan 28, 2009 at 04:43:44PM +0200, Yoav Nir wrote:
<SNIP!>
> I think that SA should have been deleted the moment host B was
> reconfigured, as it violates host B's policy.  In any case it requires a
> new SA, not a rekey of the old SA.

What if the triggering packet is from a connection-latched TCP session?  If
the SPD gets reconfigured, the connected session still inherits the policy
from its creation.  I suspect I would, upon rekey, send the specific 5-tuple.

Dan

---

From: Yoav Nir <[email-masked]>
Date: Thu, 29 Jan 2009 10:08:21 +0200

> from its creation.  I suspect I would, upon rekey, send the specific 5-tuple.

I don't understand this scenario. If the policy changed for this connection from PROTECT to DROP, do you keep the connection?  If it remained PROTECT for this connection, but the SA covers 5-tuples that should now be DROPped, it's a tougher question.

IMO the SA should be deleted, not rekeyed, and a new SA created. If for a particular implementation this causes a TCP connection to break rather than just get a minor delay while the next packet triggers a new Child SA creation, then that is a limitation of that particular implementation.

---

From: Dan McDonald <[email-masked]>
Date: Thu, 29 Jan 2009 08:52:14 -0500

On Thu, Jan 29, 2009 at 10:08:21AM +0200, Yoav Nir wrote:
> I don't understand this scenario. If the policy changed for this connection
> from PROTECT to DROP, do you keep the connection?

That's why it's called connection latching.  Once a socket is connect()ed,
the specific policy actions stay latched for the connection.

> IMO the SA should be deleted, not rekeyed, and a new SA created. If for a
> particular implementation this causes a TCP connection to break rather than
> just get a minor delay while the next packet triggers a new Child SA
> creation, then that is a limitation of that particular implementation.

Disallowing a rekey is fine, actually, because a latched connection can
narrow any previous SPD entry's selector set to the precise 5-tuple if the
SPD no longer covers the latched connection's 5-tuple.

Dan

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 29 Jan 2009 16:23:54 +0200

Yoav Nir writes:
> reconfigured, as it violates host B's policy.  In any case it
> requires a new SA, not a rekey of the old SA. 

True, but I think B should also be allowed to rekey it and make it
narrower for the old SA, and then delete the old SA. Rekeying allows
traffic counters and so on to keep running, and also does not cause
packets to be dropped. If the B immediately deletes the old SA and
then starts creating new SA when the next triggering packet comes,
that will cause cause packets to be dropped. If the B will start
creating new SA and only deletes old SA when new one is created, there
is no difference in the rekeying case for the policy point of view
(the old policy is still allowed during that transition period), but
that will reset traffic counters.

What is the benefit for disallowing rekeys with narrower traffic
selectors?
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Thu, 29 Jan 2009 16:27:02 +0200

> the specific policy actions stay latched for the connection.

So I guess in that case, you won't want to rekey, because the old SA is no longer acceptable, but you can get a new SA for the that covers only this connection (or all latched connections)

> SPD no longer covers the latched connection's 5-tuple.

I agree