Hi Tero,
Thank's a lot for this clarification. I really think that the proposed text
for section 2.9.2 clarifies this in a good way and would appreciate if that
was inserted into the next revision.
Regards Pål
-Original Message-
From: Tero Kivinen [mailto:kivi...@iki.fi]
Sent: den 21 augusti 2014 13:31
To: Pål Dammvik
Cc: ipsec@ietf.org; sec-...@tools.ietf.org
Subject: [IPsec] Rekeying of child sa, Question on TS handling according to RFC
5996
Pål Dammvik writes:
> One of the differences between RFC 5996 and 4306 is in the rekeying
> where it's stated in RFC 5996 section 2.8:
>
> "Note that, when rekeying, the new Child SA SHOULD NOT have
> different Traffic Selectors and algorithms than the old one."
>
> Additionally in section 1.3.3 (that also addresses rekeying) of the
> same RFC, it's stated:
>
> "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."
>
> I think these sentences leaves some room for interpretation what the
> create child sa request message can contain in the rekeying
> scenario.
>
> When a node initiates rekeying of a child sa using the create child
> sa message exchange, which traffic selectors is it allowed to
> include in the create child sa request? Does it have to be identical
> to the negotiated traffic selector from the old child sa (i.e. the
> traffic selector received in the original create child sa response
> for the sa) or can it for example be the same traffic selectors as
> originally proposed in the create child sa request for the old child
> sa..?
>
> There is a strange sentence related to this topic in section 1.7 "
> Significant Differences between RFC 4306 and This document" related
> to this topic:
>
> "The new Section 2.9.2 covers Traffic Selectors in rekeying."
>
> but there does not seem to be a chapter 2.9.2 in the document ?!
>
> Is this an editorial mistake or something missing?
Yes. This is editorial mistake done in 2009...
There was original ticket #12 (2008-09-22).
http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/12?version=1#L1
which said that we should mention traffic selectors in rekeying.
Then we had discussion on the mailing list between 2009-04-01 and
2009-04-08.
http://www.ietf.org/mail-archive/web/ipsec/current/msg04112.html
http://www.ietf.org/mail-archive/web/ipsec/current/msg04117.html
http://www.ietf.org/mail-archive/web/ipsec/current/msg04129.html
http://www.ietf.org/mail-archive/web/ipsec/current/msg04133.html
http://www.ietf.org/mail-archive/web/ipsec/current/msg04134.html
http://www.ietf.org/mail-archive/web/ipsec/current/msg04138.html
Then the ticket was closed at 2009-04-20 with status of fixed and
with status saying:
Added section 2.9.2 on traffic selectors in rekeying. Also added a
reference to the new section in 2.8.
Then the ticket was reopened at 2009-04-24 and ticket was updated to
include new text for the section 2.9.2:
http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/12
--
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.
--
Then 2009-08-10 the ticket was again closed with comment:
Fixed in -05: In 2.8, changed "Note that, when rekeying, the new
Child SA MAY have different traffic selectors and algorithms than
the old one." to "Note that, when rekeying, the new Child SA
SHOULD NOT have different traffic selectors and algorithms than
the old one.".
In -05 version of the draft this changes was really done, but the
section 2.9.2 was not added. In the -07 version the change log was
modified to say that the sectio
