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

[Valery Smyslov <[e-mail]>]

Hi Lars,

thank you for your comments.

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

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?

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

Typo, fixed.

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

Added missing comma.

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

Ditto.

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

Ditto.

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

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

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

Fixed.

> 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"?

Typo, fixed.

Thank you!

Regards,
Valery.