Subject: [IPsec] Updated version of RFC5996bis

From: Tero Kivinen <[email-masked]>
Date: Thu, 17 Oct 2013 16:54:39 +0300

I made new version of the RFC5996bis (yes, I am more than month too
late from my original time-estimate).

This version removes the Raw RSA public keys, adds reference to the
5996, 6989 and 4945. Cleans up IANA Considerations section, and adds
note to both to the abstract and Introduction that this document
intended for Internet Standard status.

For the RFC6989 I made Informative reference to it, as all the
Diffie-Hellman groups described IN THIS document are those groups
which do not need any special checks. I added reference to that RFC in
two places, firstly in the section "2.12 Reuse of Diffie-Hellman
Exponentials", and secondly after the "Transform Type 4
(Diffie-Hellman group)" table.

For the 4945 I made Informative reference at the end of section "3.5
Identification Payloads".
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Thu, 17 Oct 2013 10:13:56 -0400 (EDT)

On Thu, 17 Oct 2013, Tero Kivinen wrote:

> This version removes the Raw RSA public keys

Is that the old version that would be obsoleted by
draft-kivinen-ipsecme-oob-pubkey that no one implemented?

While updating the retransmit timers in libreswan, I found no useful
information in 5996. Is that something we could add? I know it is
local policy but perhaps it would be good to add some guidance for
implementors. Do people use sub-second retries? exponential backoff?
How do people deal with slow wakeup stacks (eg 3G) and preventing of
firsts of duplicate first packets?

Paul

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 17 Oct 2013 17:24:00 +0300

Hi Paul,

Regarding your second point, I would like to avoid feature creep in this 
document. So unless there's a real good reason to add text (e.g. a new 
security requirement) I would suggest not to do it. More specifically, 
since this is a matter of local policy and implementations differ, we 
could debate it forever and for little gain.

Thanks,
	Yaron

On 2013-10-17 17:13, Paul Wouters wrote:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Thu, 17 Oct 2013 15:03:49 +0000

> firsts of duplicate first packets?

I agree with Yaron. The only guidance is "at least 12 retransmission over at least two minutes"

RTT varies wildly on the Internet. I've just tried pinging www.ietf.org, and got this:
--- www.ietf.org ping statistics ---
29 packets transmitted, 28 packets received, 3.4% packet loss
round-trip min/avg/max/stddev = 275.850/542.648/1665.121/321.721 ms

To be sure, I'm using a laptop connected to a smartphone hotspot, connected to a 3G cellular network from a moving train half-way around the world. But still, sub-second retries would have you send unnecessary retransmissions, and packet loss is pretty low. 

My own policy is 1 second between first and second transmissions, and the wait time is multiplied by sqrt(2) for each additional transmission, so the 12th transmission is 107 seconds after the first. Close enough, sort of.

While it's possible to add a paragraph giving such a policy as an example, I don't see why we should even imply that this is a requirement.

Yoav

---

From: Paul Wouters <[email-masked]>
Date: Thu, 17 Oct 2013 11:22:40 -0400 (EDT)

> I agree with Yaron. The only guidance is "at least 12 retransmission over at least two minutes"

I guess I was hoping for more operation experiences. I was not asking
for specific values, but for some more guidance.

> To be sure, I'm using a laptop connected to a smartphone hotspot, connected to a 3G cellular network from a moving train half-way around the world. But still, sub-second retries would have you send…

Yet some implementations do sub-second retries. Packet loss is high
within the first second when you are waking up your 3G chipset for
example. If the first packet hits the wakeup, and you wait one second,
that's plenty of opportunity for packet leaks. But sending more packets
will likely result in a burst of initial packets being sent out.

The world is now much more depending on sub-second times than it was
before.

> While it's possible to add a paragraph giving such a policy as an example, I don't see why we should even imply that this is a requirement.

I see widely different times from sub-zero to 20 seconds. It suggests
implementors have pretty different ideas on what it should be.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 18 Oct 2013 13:42:30 +0300

> draft-kivinen-ipsecme-oob-pubkey that no one implemented?

Yes. I will submit new version of draft-kivinen-ipsecme-oob-pubkey
shortly that will remove all text about that document obsoleting the
Raw RSA keys, and just refer that RFC5996bis already did that...

> firsts of duplicate first packets?

RFC5996 already has good enough text for that:

----------------------------------------------------------------------
2.4.  State Synchronization and Connection Timeouts
...
   The number of retries and length of timeouts are not covered in this
   specification because they do not affect interoperability.  It is
   suggested that messages be retransmitted at least a dozen times over
   a period of at least several minutes before giving up on an SA, but
   different environments may require different rules.  To be a good
   network citizen, retransmission times MUST increase exponentially to
   avoid flooding the network and making an existing congestion
   situation worse.
----------------------------------------------------------------------

so exponential backoff, whether to use sub-second retries depends on
your environment. In host to host case inside the local area network
subsecond would be fine (I think we use 0.5 seconds by default). Over
the satellite link that would be too fast.

It would also be nice if people would implement the DPD properly as
defined in the RFC5996:

----------------------------------------------------------------------
            If there has only been outgoing traffic on all of
   the SAs associated with an IKE SA, it is essential to confirm
   liveness of the other endpoint to avoid black holes.  If no
   cryptographically protected messages have been received on an IKE SA
   or any of its Child SAs recently, the system needs to perform a
   liveness check in order to prevent sending messages to a dead peer.
   (This is sometimes called "dead peer detection" or "DPD", although it
   is really detecting live peers, not dead ones.)  Receipt of a fresh
   cryptographically protected message on an IKE SA or any of its Child
   SAs ensures liveness of the IKE SA and all of its Child SAs.
----------------------------------------------------------------------

Most of the implementations seem to have stupid send DPD every 10
seconds type of implementations, and some people have even complained
that we do not do DPD properly as we only send DPD messages if there
is no other traffic, not all the time... 

Anyways I do not think we want to add anything else that is already
there in the rfc5996bis.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 18 Oct 2013 17:52:42 +0400

Hi all,

as RFC5996 is revised, I suggest to make some editorial changes
to improve its clarity and to fix some small issues that I found.

1. Section 1.6 Requirements Terminology is placed far from the begining
    of the document and all the requirements words, along with terms
    from RFC4301 etc. are used before they are formally introduced.
    I don't think it is appropriate for standards track document.
    I suggest to move this section before Introduction.

2. Page 5:
   "IKEv2 was a change to the IKE protocol that was not backward
   compatible.  In contrast, the current document not only provides a
   clarification of IKEv2, but makes minimum changes to the IKE
   protocol."

For me this piece sounds strange. I think it should look like:

   "IKEv2 was a change to the IKE protocol that was not backward
   compatible.  In contrast, the current document only provides a
   clarification of IKEv2, and makes minimum changes to the IKEv2
   protocol."

3. Page 10.
   "HDR contains the Security Parameter Indexes (SPIs), version numbers,
   and flags of various sorts."

Not mentioned Message ID, Exchange Type (and Next Payload and length,
but they are not very important here). I suggest to change:

   "HDR contains the Security Parameter Indexes (SPIs), version numbers,
   Type of Exchange, Message ID and flags of various sorts."

4. Page 11.
   "At this point in the negotiation, each party can generate SKEYSEED,
   from which all keys are derived for that IKE SA."

Term SKEYSEED pops up from nowhere. No reference is gived and
even no word is explained what is it all about. First-time readers will
definitely be puzzled. I suggest to change:

   "At this point in the negotiation, each party can generate a quantity
    called SKEYSEED (see section 2.14), from which all keys are derived
    for that IKE SA."

5. Page 14, 15 and 16
   "The responder replies (using the same Message ID to respond) with the
   accepted offer in an SA payload, and a Diffie-Hellman value in the
   KEr payload if KEi was included in the request and the selected
   cryptographic suite includes that group."

   "The responder replies (using the same Message ID to respond) with the
   accepted offer in an SA payload, and a Diffie-Hellman value in the
   KEr payload if the selected cryptographic suite includes that group."

   "The responder replies (using the same Message ID to respond) with the
   accepted offer in an SA payload, and a Diffie-Hellman value in the
   KEr payload if KEi was included in the request and the selected
   cryptographic suite includes that group."

All three sentencies look like they were copy-pasted and all three
lacks mention Nonce Payload. I think it should be explicitely
mentioned here, as it was mentioned in descriptions of Initiator's message,
above each of this sentencies.

And I also think that words in parentheses here are superfluous,
as this requirement is comon for all exchanges, not only for 
CREATE_CHILD_SA,
and stated several times in the document. So, I suggest to change:

   "The responder replies with the accepted offer in an SA payload,
    nonce in the Nr payload and a Diffie-Hellman value in the
   KEr payload if KEi was included in the request and the selected
   cryptographic suite includes that group."

   "The responder replies with the accepted offer in an SA payload,
    nonce in the Nr payload and a Diffie-Hellman value in the
   KEr payload if the selected cryptographic suite includes that group."

   "The responder replies with the accepted offer in an SA payload,
    nonce in the Nr payload and a Diffie-Hellman value in the
   KEr payload if KEi was included in the request and the selected
   cryptographic suite includes that group."

6. Page 19.
    "The recipient of this notification cannot tell
   whether the SPI is for AH or ESP, but this is not important because
   the SPIs are supposed to be different for the two."

Why "is supposed to be different"? RFC4301 clearly states:
    "For a unicast SA, the SPI can be used by itself to specify an SA, or it 
may be
      used in conjunction with the IPsec protocol type."

So I suggest to change as follows:

    "The recipient of this notification cannot tell
   whether the SPI is for AH or ESP, but this is not important because
    in many cases the SPIs will be different for the two."

And some words should be added for the case when SPIs are not
different for AH and ESP. I have no good suggestion here.

7. Page 31.
Phrase "(see Section 2.6)" actually references the same section. It should 
either
be removed or corrected.

8. Page 31.
    "However, if the responder sends a non-zero
   responder SPI, the initiator should not reject the response for only
   that reason."

Should here "should not" be "SHOULD NOT"?

9. Page 49.
    "There are two types of EAP authentication (described in
   Section 2.16), and each type uses different values in the AUTH
   computations shown above.  If the EAP method is key-generating,
   substitute master session key (MSK) for the shared secret in the
   computation.  For non-key-generating methods, substitute SK_pi and
   SK_pr, respectively, for the shared secret in the two AUTH
   computations."

Isn't this para superfluous here? Its content belongs to EAP authentication
and in fact it is described in more details two pages below.

10. Page 51.
    "As described in Section 2.2, when EAP is used, each pair of IKE SA
   initial setup messages will have their message numbers incremented;
   the first pair of AUTH messages will have an ID of 1, the second will
   be 2, and so on."

Should be:

    "As described in Section 2.2, when EAP is used, each pair of IKE SA
   initial setup messages will have their message numbers incremented;
   the first pair of IKE_AUTH messages will have an ID of 1, the second will
   be 2, and so on."

11. Page 52:
    "A single CHILD_SA negotiation may result in multiple Security
   Associations."

Should be:

   "A single CREATE_CHILD_SA negotiation may result in multiple Security
   Associations."

That's all for now.
Valery.

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 18 Oct 2013 17:11:44 +0300

Hi Valery,

Sorry for being the Bad Guy on this. Your #6 does not seem editorial to 
me. Similarly, #8 (adding new RFC 2119 language) is not editorial. I 
would suggest to implement #6 only if it is critical to interoperability 
or security, and to forgo #8.

By the way, your correction #2 still does not do it IMHO. The sentence 
refers to RFC 5996. So:

"IKEv2 as stated in RFC 4306 was a change to the IKE protocol that was 
not backward compatible. RFC 5996 revised RFC 4306 to provide a 
clarification of IKEv2, making minimum changes to the IKEv2 protocol. 
The current document slightly revises RFC 5996 to make it suitable for 
progression to Internet Standard."

Thanks,
	Yaron

On 2013-10-18 16:52, Valery Smyslov wrote:
>     "For a unicast SA, the SPI can be used by itself to specify an SA,
> or it may be
> Phrase "(see Section 2.6)" actually references the same section. It
> should either
> be removed or corrected.
>
> 8. Page 31.

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 18 Oct 2013 18:24:24 +0400

Hi Yaron,

> Sorry for being the Bad Guy on this. Your #6 does not seem editorial to

I think that current text is not aligned with RFC4301.
We may leave it as is or try to find other form that
would not appear so misaligned.

> me. Similarly, #8 (adding new RFC 2119 language) is not editorial. I would 
> suggest to implement #6 only if it is critical to interoperability or 
> security, and to forgo #8.

What about #8 - it's just a question from me. From my feeling it must
be uppercase, but I might be wrong. We may leave it as is.

> "IKEv2 as stated in RFC 4306 was a change to the IKE protocol that was not 
> backward compatible. RFC 5996 revised RFC 4306 to provide a clarification 
> of IKEv2, making minimum changes to the IKEv2 protocol. The current 
> document slightly revises RFC 5996 to make it suitable for progression to 
> Internet Standard."

Yes, your text is for RFC5996bis, while I made my notes a while ago
and the text was for RFC5996. Of course your variant is better.

Valery.

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 19 Oct 2013 14:56:24 +0300

> would not appear so misaligned.

Your new text is fine, if we leave it at that. If we try to add text to 
deal with the exceptional cases (same SPI shared between protocols), 
this will quickly become normative. I don't want to do it in "bis" and 
frankly, I think this situation is too rare to matter.

>> would suggest to implement #6 only if it is critical to
>> interoperability or security, and to forgo #8.
>

IETF process is very serious about the difference between lowercase and 
uppercase (see RFC 6919). Maybe it should have been a SHOULD to start 
with. But we SHOULD NOT change it for a "bis" document.

---

From: Yoav Nir <[email-masked]>
Date: Sat, 19 Oct 2013 12:27:14 +0000

Hi, Yaron

Suppose that instead of sending the message to the list yesterday, Valery had submitted his comments as errata a few months ago, before Sean asked us to do the revision. Would those errata not have been verified?

If so (and I think it's true for at least #3, #4, #7, and #11, and #6 would also merit some new text), the corrections would now be in the draft. So why not now?

Yoav

On Oct 19, 2013, at 2:56 PM, Yaron Sheffer <[email-masked]> wrote:

> Your new text is fine, if we leave it at that. If we try to add text to deal with the exceptional cases (same SPI shared between protocols), this will quickly become normative. I don't want to do it in "bis" and frankly, I think this situation is too rare to matter.
> 
>> 
> IETF process is very serious about the difference between lowercase and uppercase (see RFC 6919). Maybe it should have been a SHOULD to start with. But we SHOULD NOT change it for a "bis" document.
> 
>>

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 19 Oct 2013 18:47:12 +0300

Hi Yoav,

You're probably right in your speculation. But my point was that 
Valery's subject line said "editorial changes", and two of these changes 
were arguably non-editorial. Technical changes would be treated 
differently in an errata review and should be treated differently in a 
"bis" document, whose main purpose in life is to progress (i.e., 
stabilize) the protocol.

Thanks,
	Yaron

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 21 Oct 2013 08:53:52 +0400

HI Yaron,

> Hi Yoav,
>
> You're probably right in your speculation. But my point was that Valery's 
> subject line said "editorial changes", and two of these changes were 
> arguably non-editorial. Technical changes would be treated

Actually, I don't think #6 is technical, as It doesn't change protocol's 
behaviour.
Current text doesn't specify what to do if SPIs are the same for AH and ESP,
and we can leave the behaviour unspecified either. The only difference
is that current text is written as if this situation cannot happen, which
contradicts RFC4301. We can rewrite is so, that admit that it may
happen, but leave to implementers to decide what to do in this case.
I think that it is important that RFC4301 and IKEv2 be aligned.

What about #8 - it is a minor issue and we can forgo it.

Valery.

>> Suppose that instead of sending the message to the list yesterday, Valery 
>> had submitted his comments as errata a few months ago, before Sean asked 
>> us to do the revision. Would those errata not have been verified?
>>
>> If so (and I think it's true for at least #3, #4, #7, and #11, and #6 
>> would also merit some new text), the corrections would now be in the 
>> draft. So why not now?
>>
>> Yoav
>>

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 21 Oct 2013 09:35:09 +0300

Hi Valery,

I'm OK with this resolution.

Thanks,
	Yaron

On 2013-10-21 07:53, Valery Smyslov wrote:
>> Valery's subject line said "editorial changes", and two of these
>> changes were arguably non-editorial. Technical changes would be treated
>
>>> Suppose that instead of sending the message to the list yesterday,
>>> Valery had submitted his comments as errata a few months ago, before
>>> Sean asked us to do the revision. Would those errata not have been
>>> verified?
>>>
>>>> Your new text is fine, if we leave it at that. If we try to add text
>>>> to deal with the exceptional cases (same SPI shared between
>>>> protocols), this will quickly become normative. I don't want to do
>>>> it in "bis" and frankly, I think this situation is too rare to matter.
>>>>
>>>>>
>>>> IETF process is very serious about the difference between lowercase
>>>> and uppercase (see RFC 6919). Maybe it should have been a SHOULD to
>>>> start with. But we SHOULD NOT change it for a "bis" document.
>>>>
>>>>>

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 22 Oct 2013 09:50:24 +0400

Hi, 

Just came across one more small editorial issue in RFC5996.
Page 73, description of "Next Payload" field, sentence

      In the header of an Encrypted payload, the Next Payload field is set
      to the payload type of the first contained payload (instead of 0);
      conversely, the Next Payload field of the last contained payload
      is set to zero).  

has extra round bracket at the end.

Regards,
Valery.