Hi Kathleen,
thank you for the review. I'll try to answer.
Hello,
Thank you for you work on draft-ietf-ipsecme-ddos-protection. This is
a good read that lays out the problem well and describes the solution
well. Thanks for that!
I have some nits and questions before we put this into IETF last call.
Section 4.2 -
This level of detail is great. Hopefully developers make sure logs
and other ways to help with troubleshooting to determine the number of
half open SA and failed IKE-Auth exchanges. Are these maintained with
counters (SNMP/YANG) or log entries or some other way? Does this
matter and does it need to be indicated here for developers so
implementors have the tools needed to determine next steps?
I think that it is a local matter how implementations measure the number
of half-open SAs. It is possible to maintain some counters or
parse local log files. Or, for example, just call size() method
for some kind of container (list, map) in case all half-open SAs are placed
there.
The only requirement is that implementations must do this measuring
periodically to get a picture of what is happening. Again, it is a local
matter how often implementations should learn the number of half-open SAs,
the draft doesn't impose any restrictions.
Do you think some clarification is needed here?
Section 4.6: Suggest using some descriptive language instead of
saying 'garbage' in the following sentence for non-native English
speakers:
The
attacker can just send garbage in the IKE_AUTH message forcing the
Responder to perform costly CPU operations to compute SK_* keys.
How about:
Instead of sending properly formed and encrypted IKE_AUTH message the
attacker can just send arbitrary data, forcing the Responder
to perform costly CPU operations to compute SK_* keys.
(by the way, I'm a non-native English speaker, and the word "garbage"
doesn't shock me here, but I agree that more formal language is probably better)
Same in section 4.7, maybe "meaningless bits" or something along those lines?
Great! Definitely better from my point of view, thank you.
Malicious
initiators can use this feature to mount a DoS attack on the
responder by providing an URL pointing to a large file possibly
containing garbage.
Section 7.1.1.2: The following sentence could be cleaned up a bit
(last paragraph):
The
initial request message sent by the Initiator contains an SA payload
with the list of transforms the Initiator supports and is willing to
use in the IKE SA being established.
I'm not sure what's wrong with this sentence, but I'll try. Is the followng
better?
The
initial request message sent by the Initiator, contains an SA payload,
containing a list of transforms. The Initiator supports all transforms
from this list and can use any of them in the IKE SA being established.
Section 7.2.1.1
The first sentence of course fits in this section, but has already
been said in the draft. This whole section seems repetitious. There
are a few places where text is repeated, is it possible to reduce
repetition? It might not be for clarity as the sections vary, but an
effort to reduce it might make the latter part of the draft as easy to
read as the start.
Yes, this sentence almost duplicates the sentence from the second para
of previous Section (7.2). But I'd rather to keep it in 7.2.1.1 and just
remove from 7.2, because 7.2.1.1 gives more detailed instructions
to implementers while 7.2 is just an overview.
Are you OK with this?
Section 7.2.4: 4th paragraph, 1st sentence doesn't read well. Can you
break it up and phase the "non-first" differently? I don't think that
is a term of art, is it?
If the Initiator uses IKE Fragmentation, then it is possible, that
due to packet loss and/or reordering the Responder could receive non-
first IKE Fragment messages before receiving the first one containing
the PS payload.
How about:
If the Initiator uses IKE Fragmentation, then it sends all IKE Fragment
messages simultaneously.
Due to packets loss and/or reordering the Responder could receive
subsequent IKE Fragment messages before receiving the first one, that contains
the PS payload.
Thank you,
Valery.
Thank you!
--
Best regards,
Kathleen
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
