Early Review of draft-ietf-ipsecme-g-ikev2-08
review-ietf-ipsecme-g-ikev2-08-tsvart-early-fairhurst-2023-04-10-00
Request | Review of | draft-ietf-ipsecme-g-ikev2 |
---|---|---|
Requested revision | No specific revision (document currently at 14) | |
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) |
|
Comments |
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 | https://mailarchive.ietf.org/arch/msg/tsv-art/HyB6JnJV9OV02VnsZxR2NjY-rl0 | |
Reviewed revision | 08 (document currently at 14) | |
Result | Ready w/issues | |
Completed | 2023-04-10 |
review-ietf-ipsecme-g-ikev2-08-tsvart-early-fairhurst-2023-04-10-00
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/