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

From: Pål Dammvik <[email-masked]>
Date: Wed, 20 Aug 2014 12:17:13 +0000

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?

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...

Regards Pål

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 21 Aug 2014 14:30:38 +0300

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."
> 
> "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:
> 

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...
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 21 Aug 2014 15:49:09 +0400

Hi Tero,

> as there clearly is need for clarification (as we can see from the

I think we should add this text. The text is useful and I don't see
a reason to sacrifice it in favour to speed up RFC publication.

Regards,
Valery.

---

From: Pål Dammvik <[email-masked]>
Date: Thu, 21 Aug 2014 13:53:10 +0000

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:[email-masked]] 
Sent: den 21 augusti 2014 13:31
To: Pål Dammvik
Cc: [email-masked]; [email-masked]
Subject: [IPsec] Rekeying of child sa, Question on TS handling according to RFC 5996

-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Thu, 21 Aug 2014 22:21:07 +0300

+1

On Aug 21, 2014, at 2:49 PM, Valery Smyslov <[email-masked]> wrote:

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 21 Aug 2014 17:19:31 -0400

Assuming this is agreed upon by the working group, getting the text to be added along with a diff of the draft will be helpful to share with the IESG.  They will want a quick look to make sure they agree, but it sounds like this makes sense.

Thanks,
Kathleen 

Sent from my iPhone

> On Aug 21, 2014, at 3:21 PM, Yoav Nir <[email-masked]> wrote:
> 
> +1
>

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 28 Aug 2014 18:33:38 +0400

Hi,

if new version of draft-kivinen-ipsecme-ikev2-rfc5996bis is issued,
then it is also possible fix a typo I've come across.

Section 2.8.1, second para:
   This form of rekeying may temporarily result in multiple similar SAs
   between the same pairs of nodes.  When there are two SAs eligible to
   receive packets, a node MUST accept incoming packets through either
   SA.  If redundant SAs are created though such a collision, the SA
                                                      ^^^^^^ 
s/though/through
   created with the lowest of the four nonces used in the two exchanges
   SHOULD be closed by the endpoint that created it.

Regards,
Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 29 Aug 2014 16:11:46 +0300

>    SHOULD be closed by the endpoint that created it.

This typo was already noticed and fixed during the rfc-editor process.
-- 
[email-masked]