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.
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?
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.
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.
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
[email protected]
https://www.ietf.org/mailman/listinfo/tsv-art
Bets wishes,
Gorry
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
