Hi Gorry,
thank you for your review. Please see inline.
> 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.
> 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).
> 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).
> 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?
> 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?
> /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".
Regards,
Valery.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
