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? 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. Same in section 4.7, maybe "meaningless bits" or something along those lines? 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. 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. 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. Thank you! -- Best regards, Kathleen _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
