Hi Gorry,
> -----Original Message-----
> From: Gorry Fairhurst [mailto:go...@erg.abdn.ac.uk]
> Sent: Tuesday, April 11, 2023 7:22 PM
> To: Valery Smyslov; tsv-...@ietf.org
> Cc: draft-ietf-ipsecme-g-ikev2....@ietf.org; ipsec@ietf.org
> Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-ipsecme-g-ikev2-08
>
> On 11/04/2023 14:09, Valery Smyslov wrote:
> > Hi Gorry,
> >
> > thank you for your review. Please see inline.
> See below, marked [GF]
> >> Reviewer: Gorry Fairhurst
> >> Review result: Ready with Issues
> >>
> >> 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?
> > This piece of text is not related to classic PMTUD/PLMTUD mechanisms.
> > Instead, it is related to the PMTUD process described in Section 2.5.2 of
> > RFC 7383,
> > which is a bit specific (sender starts from larger packets and retransmits
> > smaller packets if it receives no reply).
> >
> > We can clarify this. How about the following?
> >
> > * PMTU mechanism, defined in Section 2.5.2 of [RFC7383], cannot be
> > used due to lack of
> GSA_REKEY response
> > messages.
> [GF] Aha - that text would indeed be clearer.
OK.
> >> 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?
> > If we are talking about GSA_REKEY messages, then the replay protection
> > mechanism (incrementing counter) will cause packets loss in case of
> > reordering.
> > In other words, if GM receives message with MessageID equal to N,
> > it will then ignore any messages with MessageID <= N.
> >
> > However, in real life this should not cause problems, because
> > GSA_REKEY messages are infrequent (usually one per few hours,
> > in extreme cases one per several minutes).
> >
> > The packet loss cannot trigger retransmissions, because there is no
> > back channel from GMs to GCKS. However, there are mechanisms
> > that allow receiving GMs that miss the next GSA_REKEY message to recover
> > (see Sections 2.4.1.3 and 4.4.2.2.3).
> [GF] I uinderstand now, could the ID say something?
We can add the following clarification into 2.4.1.4:
Since GSA_REKEY messages are infrequent (typically one per several
hours or,
in extreme cases, several minutes), packet reordering is not a
problem.
Is it OK or more text is needed?
> >> 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?
> > No, there is no congestion control, because there is no back channel from
> > GMs to GCKS.
> > It is assumed that the GSA_REKEY messages are infrequent to not cause
> > any congestion. If several GSA_REKEY messages are sent to mitigate possible
> > packet loss,
> > then the draft suggests that they are not sent at once, but instead be sent
> > with some delay (few seconds) to avoid any possible congestion.
> >
> > The concrete delay and number of sent packets are not defined in the draft,
> > since they don't affect interoperability (following long practice of IPsec
> > WG documents).
> >
> A few seconds, seems to align with what I hoped. You will know best
> whether that needs any text or not.
I believe no new text is needed.
> >> 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?
> > The intended meaning of this text was that the behavior of GMs and GCKS must
> > not depend on the port they created initial IKE SA over. How can we state
> > this more clearly?
>
> That proposed text works fine with the example you have... e.g.
> something like this:
>
> The behavior of GMs and GCKS MUST NOT depend on the port used to create the
> initial IKE SA.
> For exmaple, if the GM and the GCKS used UDP port 848 for the IKE_SA_INIT
> exchange, they
> will operate the same as if they had used UDP port 500.
OK, will use this text. Thank you.
Regards,
Valery.
> >> Editorial issues:
> >> /that allows to perform a group key management./
> >> which allows this to perform a group key management./
> > Changed to "which allows performing a group key management". Is it better?
> [GF] yes.
> >
> >> /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/
> > Changed to "describes how IKEv2 supports paths with NATs".
>
> [GF] :-)
>
>
> >
> > Regards,
> > Valery.
> >
> > _______________________________________________
> > Tsv-art mailing list
> > tsv-...@ietf.org
> > https://www.ietf.org/mailman/listinfo/tsv-art
>
> Bets wishes,
>
> Gorry
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
