Subject: Re: [IPsec] Reopening issue #12

From: Jeff Sun <[email-masked]>
Date: Sun, 26 Apr 2009 12:03:27 -0700

All,
I'm not sure my opinion counts since Paul called for WG input.  In any
event, it seems to me that rekeying a CHILD_SA the way its currently done
seems more like creating a new CHILD_SA, especially since the SA, TSi, TSr,
and the optional N(TRANSPORT_MODE) Payloads are included.

Rekeying a CHILD_SA shouldn't require all these payloads - it should only
include some form of notification, the Nonce Payload, and the optional KE
Payload.  Any new traffic flow that is not covered by existing CHILD_SAs
would trigger a new CREATE_CHILD_SA exchange - this seems more straight
forward than mandating rekeying proceessing to create wider scoped CHILD_SAs
that may never utilize  these wider selectors and may not even be changed
due to responder narrowing and responder policy changes.

In any event, I do not think the new responder MUST hurts anything.  And
unless I'm missing something, any new negotiated transform types changes
incurred ought to be fine since they were both acceptable by both polcies.

- Jeff Sun

On Apr 24, 2009 8:20 AM, "Paul Hoffman" <[email-masked]> wrote:

Greetings again. During discussion with the other authors of IKEv2bis, we
discovered some problems with the proposed resolution to issue #12 about
traffic selectors when rekeying. The text I proposed to put in the document
was this:
-----
2.9.2 Traffic Selectors in Rekeying

Rekeying is used to replace an existing Child SA with another. If the new SA
were allowed to have a narrower set of selectors than the original, traffic
that was allowed on the old SA would be dropped in the new SA, thus
violating the idea of "replacing". Thus, the new SA MUST NOT have narrower
selectors than the original. If the rekeyed SA would ever need to have
narrower scope than currently used SA, that would mean that the policy was
changed in a way that the currently used SAs are against the policy. In that
case, the SA should have been already deleted after the policy change took
effect.

When the initiator attemepts to rekey the Child SA, the proposed traffic
selectors SHOULD be either the same as, or a superset of, the traffic
selectors used in the old Child SA. That is, they would be the same as, or a
superset of, the currently active (decorrelated) policy. The responder MUST
NOT narrow down the traffic selectors narrower than the scope currently in
use.

Because a rekeyed SA can never have narrower scope than the one currently in
use, there is no need for the selectors from the packet, so those selectors
SHOULD NOT be sent.
-----

It was pointed out that (a) this is a new MUST and (b) this also assumes
that the encryption algorithm and so on will be the same.

So, how does the WG want to proceed here?

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec