Skip to main content

Early Review of draft-ietf-ipsecme-g-ikev2-08

Request Review of draft-ietf-ipsecme-g-ikev2
Requested revision No specific revision (document currently at 10)
Type Early Review
Team Transport Area Review Team (tsvart)
Deadline 2023-04-30
Requested 2023-03-27
Requested by Tero Kivinen
Authors Valery Smyslov , Brian Weis
I-D last updated 2023-04-10
Completed reviews Secdir Early review of -08 by Russ Housley (diff)
Tsvart Early review of -08 by Gorry Fairhurst (diff)
This is old document implementing the G-DOI for IKEv2, to allow secure multicast communications. We would like to get bit more reviews for this before we ship it out. It is past WG last call but we got quite little comments during WGLC so want to get more people looking at it.
Assignment Reviewer Gorry Fairhurst
State Completed
Request Early review on draft-ietf-ipsecme-g-ikev2 by Transport Area Review Team Assigned
Posted at
Reviewed revision 08 (document currently at 10)
Result Ready w/issues
Completed 2023-04-10
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 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

3. RFC8055 describes BCP guidance for congestion control: Retransmission is
described in 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/