Subject: [IPsec] Lars Eggert's No Objection on draft-ietf-ipsecme-ikev2-intermediate-09: (with COMMENT)

From: Lars Eggert via Datatracker <[email-masked]>
Date: Tue, 01 Mar 2022 01:53:13 -0800

Lars Eggert has entered the following ballot position for
draft-ietf-ipsecme-ikev2-intermediate-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-intermediate/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1. , paragraph 5, comment:
>    This specification describes a way to transfer a large amount of data
>    in IKEv2 using UDP transport.  For this purpose the document defines

To a transport person, "a large amount of data" sounds like a bulk transfer.
Surely this isn't the intention here? Could the text more precisely state for
which data sizes this is an appropriate mechanism?

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Paragraph 3, nit:
> v2-intermediate-09 Abstract This documents defines a new exchange, called Int
>                                  ^^^^^^^^^
Consider using the singular form after the singular determiner "This".

Section 1. , paragraph 3, nit:
> um Computer (QC) resistant ones. Currently most QC-resistant key exchange me
>                                  ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Currently".

Section 1. , paragraph 3, nit:
> r IKEv2, as defined in [RFC8229]. However this approach has significant draw
>                                   ^^^^^^^
A comma may be missing after the conjunctive/linking adverb "However".

Section 3.3.2. , paragraph 17, nit:
> ready to be encrypted) fragments. However care must be taken to properly rep
>                                   ^^^^^^^
A comma may be missing after the conjunctive/linking adverb "However".

Section 3.3.2. , paragraph 18, nit:
> e[i/r] and SK_a[i/r] used for its messages protection (see Section 3.3.1) an
>                                   ^^^^^^^^
An apostrophe may be missing.

Section 3.4. , paragraph 2, nit:
> he peers can be certain that they receives messages from the party they perf
>                                   ^^^^^^^^
The pronoun "they" must be used with a non-third-person form of a verb.

Section 5. , paragraph 4, nit:
> nt interoperable implementations of this specifications from the following v
>                                     ^^^^
The demonstrative "this" may not agree with the plural noun "specifications".
Did you mean "these"?

---

From: Valery Smyslov <[email-masked]>
Date: Tue, 1 Mar 2022 16:53:09 +0300

Hi Lars,

thank you for your comments.

> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-intermediate/

By no means it was intended to use this exchange for a bulk transfer.
If we talk about PQ public keys, then "large amount" will be in most cases
less than few tens Kbytes. A notable exception is classic McEliece,
which has public key size of few hundred Kbytes, but transferring 
this amount of data in IKE requires some changes in the protocol 
anyway (see draft-tjhai-ikev2-beyond-64k-limit-02 as an example)
and will most probably require TCP transport (although
we successfully used UDP for this purpose in test lab).

I can add the following text at the end of Section 1 (as new paragraph):

  Note, that the IKE_INTERMEDIATE exchange is not intended for 
  bulk transfer. This specification doesn't set a hard cap on
  the amount of data that can be safely transferred using this mechanism, 
  as it depends on its application. But it is anticipated that in most cases 
  the amount of data will be limited to tens of Kbytes (few hundred Kbytes 
  in extreme cases). 
  
 Is it OK?

Typo, fixed.

> A comma may be missing after the conjunctive/linking adverb "Currently".

Added missing comma.

> A comma may be missing after the conjunctive/linking adverb "However".

Ditto.

> A comma may be missing after the conjunctive/linking adverb "However".

Ditto.

> An apostrophe may be missing.

Changed to "for protection of its messages" to eliminate confusion.

> The pronoun "they" must be used with a non-third-person form of a verb.

Fixed.

> The demonstrative "this" may not agree with the plural noun "specifications".

Typo, fixed.

Thank you!

Regards,
Valery.

---

From: Lars Eggert <[email-masked]>
Date: Tue, 1 Mar 2022 15:45:06 +0100

Hi,

>  the amount of data will be limited to tens of Kbytes (few hundred Kbytes

thanks, that looks very reasonable.

(If you wanted to, you could point at RFC6928 as an illustration that the IETF thought it OK for TCP to send up to ~15K in the first flight. There were also measurements done at the time that showed that at least some CDNs used even larger initial flight sizes.)

Thanks,
Lars

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 1 Mar 2022 18:24:44 +0300

Hi Lars,

> (If you wanted to, you could point at RFC6928 as an illustration that the IETF thought it OK for TCP to send up
> to ~15K in the first flight. There were also measurements done at the time that showed that at least some
> CDNs used even larger initial flight sizes.)

Thanks for the pointer. I updated the text as follows:

   Note, that the IKE_INTERMEDIATE exchange is not intended for bulk
   transfer.  This specification doesn't set a hard cap on the amount of
   data that can be safely transferred using this mechanism, as it
   depends on its application.  But it is anticipated that in most cases
   the amount of data will be limited to tens of Kbytes (few hundred
   Kbytes in extreme cases), which is believed to cause no network
   problems (see [RFC6928] as an example of experiments with sending
   similar amounts of data in the first flight of TCP).  See also
   Section 5 for the discussion of possible DoS attack vectors when
   amount of data sent in IKE_INTERMEDIATE is too large.

I also mentioned a possible DoS attack vectors when amount of data is too large.

Thank you,
Valery.