This is an early review of Group Key Management using IKEv2 concerns transport issues. It does not comment on the maturity of security aspects, which are the primary concerns of the specification.

Transport issues that may be relevant: 

1. PMTUD and PLPMTUD are transport mechanisms. In 2.4.1.2. mention is made of PMTUD, bit it was not clear to what was intended and what needs to be done:
/PMTU probing cannot be performed due to lack of GSA_REKEY response
message./
Some additional text, and a cross reference to a section in another RFC would seem helpful here: What is /probing/ in this context? Maybe it would help to explain a little and cite an RFC for PMTUD, if that is what is intended? 

2. The document discuses protection from replay, but it seems the mechanism will also impacted by the effect of path reordering, and that interaction should be described to explain that packet re-ordering can occur on some Internet paths and how this will impact Replay/Reflection Attack Protection, presumably it will simply result in some packet loss? Could it trigger retransmission? 

3. RFC8055 describes BCP guidance for congestion control: Retransmission is described in 2.4.1.3. Are the retransmitted messages subject to congestion control? or some form of rate limit? There is a maximum interval for retransmission discussed, but there is not a mention of a minimum interval, or what happens when a retransmission fails? Specifically, is the retransmission time period backed-off, or is there a limit on the of retries?

4. What is required by:  /If the GM and the GCKS used UDP port 848 for the
 IKE_SA_INIT exchange, they MUST behave as if they used UDP port 500./ This reads as if there normative requirements, but I am unsure what they are, and specifically what is intended by /behave as if/. Perhaps though, it only means the same method needs to be followed when port 848 is used instead of using port 500?


Editorial issues:
/that allows to perform a group key management./
which allows this to perform a group key management./

/describes how IKEv2 deals with NATs/
- sound a little judgmental, could this be:
- /describes how IKEv2 supports paths with NATs/
- or
- /describes how IKEv2 interacts with paths with NATs/