Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2)
draft-ietf-ipsecme-ikev2-intermediate-10

Thanks for this. I have just a couple minor questions/suggestions.

1. Section 3.2, “these exchanges MUST follow each other”. I suppose what is meant is, “these exchanges MUST be sequential” (this hardly seems to need to be mandated, but OK). Or is something else intended, in which case, what is it?

2. In Section 3.4, there is:

   not all error notifications may ever appear in the IKE_INTERMEDIATE
   exchange (for example, errors concerning authentication are generally
   only applicable to the IKE_AUTH exchange).

I can’t make sense of what the word “ever” is doing there. It makes sense to me if I remove “ever” to make it “not all error notifications may appear”. It’s OK if I change “ever” to “even”. But I don’t get it, as written. Am I missing something, or would one of my edits be appropriate?

In Section 5, it's peculiar to use normative keywords ("RECOMMENDED", in this case) against future documents.  I suggest lower-casing that word.

In Section 6, the full name of the second registry being updated is "IKEv2 Notify Message Types - Status Types".

A few editorial items:

** Section 1.  Editorial.  s/If size of/If the size of/

** Section 1.  Editorial.  Per “… that may interfere badly with some network devices”, can something more precise than “interfere badly” be used? Perhaps:

OLD:
That may interfere badly with some network devices

NEW
Which has been shown to cause operational challenge in certain network configurations and devices.

** Section 3.3.2.  Editorial.  Per “… because peers generally are unaware in which form other side has received them”, there is a missing word here.

** Section 3.3.2. Editorial. s/After n-th exchange/After the n-th exchange/

**Section 3.3.2. Editorial.  
OLD 
The IntAuth_[i/r]*A chunk lasts from ...

NEW 
The IntAuth [i/r]*A chunk consists of the sequence of octets from ...

** Section 8.  Typo. s/regadless/regardless/

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Yoav Nir for the shepherd's write-up including the section about the WG consensus. 

I hope that this helps to improve the document,

Regards,

-éric

## Abstract

The abstract would benefit by adding a few use cases / applicability statement (per the shepherd's write-up and introduction, i.e., a hint for PQ crypto).

## Section 1

s/If size of a message is large enough, IP fragmentation takes place/If size of a message is larger than the MTU, IP fragmentation takes place/

RFC 7383 is dated 2014, is it still applicable in 2022 ?

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

(3.2) "Implementations MUST verify that Message IDs in the IKE_INTERMEDIATE messages [increment by 1]". Or what? In any case, isn't this fully enforced by the WINDOW_SIZE parameter in Sec 2.3 of RFC 7296? That is, if WINDOW_SIZE == 1, any message that doesn't increment by 1 will simply be ignored. If WINDOW_SIZE > 1, receiving an increment > 1 is in fact legal (due to packet loss) but the window will not advance until all IDs are received?

(5) The security considerations hint at it with all the DoS talk, but it would be valuable to place some limits on the kind of information that can be contained in IKE_INTERMEDIATE and how it is processed. The document doesn't appear to explicitly restrict these messages to overflow from IKE_SA_INIT messages, so if an extension sends e.g. user data in these what are the implications? I'd suggest that applications not process such data until AUTH exchange is complete.

While I am not particularly happy with solely using the WINDOW_SIZE mechanism to regulate the amount of data in flight, IMO that is an issue with RFC 7296 and not this document.