Subject: [IPsec] Reopening issue #12

From: Paul Hoffman <[email-masked]>
Date: Fri, 24 Apr 2009 08:18:01 -0700

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

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 27 Apr 2009 15:20:00 +0300

Paul Hoffman writes:
> It was pointed out that (a) this is a new MUST and

Yes, but it can mostly be already deducted from the requirement that
end node cannot violate its own policy, meaning it needs to delete
Child SA which are not following his policy. If that is already done,
there is no point for the new SA having narrower scope than old SA
had, and making this MUST makes it simplier for implementations (i.e.
they do not need to think what to do for the traffic which do not fit
the rekeyed SA, and we do not need to add the traffic selectors from
the packet parts). 

> (b) this also
> assumes that the encryption algorithm and so on will be the same. 

No it does not. I do not see any text there saying anything about
encryption algorithms. Those are negotiated as normally and again if
policy has been changed so that the original algorithms are not valid
anymore, then the child SA should have been deleted already.

There are cases where intiator can only propose subset of algorithms
it itself finds acceptable, but that will simply result in
NO_PROPOSAL_CHOSEN failure, if other end does not accept any of the
algorithms initiator offered. 

> So, how does the WG want to proceed here?

I do not think we need to do anything more than what is already done
here. 
-- 
[email-masked]

---

From: <[email-masked]>
Date: Tue, 28 Apr 2009 11:33:36 +0200

> anymore, then the child SA should have been deleted already.

Hmm... narrowing and algorithm negotiation can interact. Consider
the following situation:

Alice's SPD:
traffic on UDP ports 1000-1999 MUST use ESP w/3DES or AES (AES preferred)

Bob's SPD:
traffic on UDP ports 1000-1499 MUST use ESP w/3DES or AES (3DES preferred)
traffic on UDP ports 1500-1999 MUST use ESP w/AES

The old SA (OK to both Alice and Bob):  
UDP ports 1000-1999, AES

Now, suppose Alice sends a CREATE_CHILD_SA exchange for rekeying this
SA, proposing algorithms AES and 3DES, and traffic selectors for UDP
ports 1000-1999. Bob prefers 3DES, and picks that. But now Bob cannot
meet the requirement "new SA MUST NOT be narrower than the old one",
because it would violate his policy.

So, I think the current text in 2.9.2 *does* assume that encryption 
algorithm negotiation behaves differently when rekeying (and IMHO
this requirement is not in RFC 4306).

Best regards,
Pasi

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 29 Apr 2009 14:18:21 +0300

[email-masked] writes:
> ports 1000-1999. Bob prefers 3DES, and picks that.

Bob cannot pick that one, as it would be against his own policy for
the port 1500-1999 range, thus he MUST select AES, which is acceptable
for the whole range. 

> But now Bob cannot meet the requirement "new SA MUST NOT be narrower
> than the old one", because it would violate his policy.

This depends which happens first, algorithm selection or narrowing. In
most cases the first thing happens that traffic selectors are used to
find suitable policy entry from SPD and then algorithms and traffic
selectors are selected based on that.

In most case I would not expect Bob to create the old SA that way at
all, as it would require it to combine two SPD rules together when
accepting such entry. As the SPD entries are ordered list that would
mean it was combining two entries which had different locations in the
list, and I am not sure if combining two SPD entries when creating SA
is actually allowed by the RFC4301.

In general I do not expect implementations ever to do that, and if
they happen to do that then they should also have code that
understands the rekeying requirements, meaning they must select those
same SPD entries for the rekeying and also use the policy restrictions
from them to select algorithms for the rekey.

Meaning that, in your example the Bob can still pick same SA traffic
selectors (UDP ports 1000-1999) and select algorithm which is
acceptable for him (AES). He cannot select 3DES even when that is his
preferred algorithm for one part of the range. 

> this requirement is not in RFC 4306).

I do not find anything from 2.9.2 which would indicate that it assumes
algorithms to stay same (which was the actual question of b).

It does require algorithm selection to work so it does result in
algorithm that is acceptable for the whole old SA.

Note, that when the Bob initially created the SA he had exactly same
algorithm selection problem, and that algorithm selection problem is
because he allowed SA to use multiple SPD entries. If Bob makes sure
that SA is derived from exactly one SPD entry, then this problem
cannot arise. In that case Bob would also delete the SA when it was
reconfigured to have that new policy which splitted old SPD entry to 2
new SPD entries, as the SA would then refer to two SPD entries.
-- 
[email-masked]