Hi Valery, Thanks for the quick response, inline.
Please excuse typos, sent from handheld device > On Sep 9, 2016, at 4:01 PM, Valery Smyslov <sva...@gmail.com> wrote: > > 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? > No, it's fine to leave it out. I appreciate the explanation. >> 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. 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. Yes, thank you! > >> 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? Yes, thank you! > >> 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. Better, thanks! Let me know when you have the updated draft & I'll initiate IETF last call. Thanks, Kathleen > > Thank you, > Valery. > >> Thank you! >> -- >> Best regards, >> Kathleen > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
