Re: [IPsec] Rekeying of child sa, Question on TS handling according to RFC 5996

[Pål Dammvik <[e-mail]>]

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:[e-mail]] 
Sent: den 21 augusti 2014 13:31
To: Pål Dammvik
Cc: [e-mail]; [e-mail]
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 section 2.9.2 was added, but it still wasn't
added.

And nobody noticed this until now... The RFC editor just asked this
when going through the rfc5996bis document, i.e. they asked what this
2.9.2 should be as it is referenced, but not included in the document.

Does the missing section 2.9.2 quoted above answer your question?

This is also question what should we do for the rfc5996bis.

We have two options, we removed the text saying section 2.9.2 was
added in the RFC5996, or we add the section 2.9.2 from the ticket #12,
and add note that saying that this time we really added it...

What does the working group feel we should do? Note, that if we add
the 2.9.2 that might cause delays, as I am not sure if we can do that
kind of change after IESG has already approved the rfc5996bis (it is
now in the AUTH48), meaning it might need IESG to recheck that part.

On the other hand I think adding the text which we already have
approved in 2009 to the specification would be the right thing to do,
as there clearly is need for clarification (as we can see from the
Dammvik's question). 

> As the RFC has similar statement for the negotiated algorithms (i.e.
> encryption, integrity), the same question pops up there.. I.e.
> should it in the create child sa request only include the algorithms
> used by the old child sa or can it include all algorithms originally
> proposed...
-- 
[e-mail]