From: Valery Smyslov [mailto:[email protected]] Sent: Tuesday, December 01, 2015 7:45 AM To: Waltermire, David A. <[email protected]>; [email protected] Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-02
Hi David, thank you for the careful review. I hope we'll manage to address your comments and issue an updated version shortly. Please find more inline. Regards, Valery. ----- Original Message ----- From: Waltermire, David A.<mailto:[email protected]> To: [email protected]<mailto:[email protected]> Sent: Tuesday, December 01, 2015 6:15 AM Subject: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-02 Please find my comments on draft-ietf-ipsecme-ddos-protection-02 below. Overall I found the content of the draft to be very good. Here is a quick summary of my comments: - There are still some placeholder sections in the draft that need to be written (i.e. sections 3.1, 3.2, 11). That's true. However sections 3.1 and 3.2 are left due to miscommunication between the authors while preparing the draft for publication. The Keyed-Cookie Notification and the Puzzle-Required Notification are left from the earlier version of the draft, they are now replaced with the PUZZLE Notification and the Puzzle Solution Notification, which are covered in Sections 10.1 and 10.2. The Security Considerations section need to be filled and I think we need more input from the WG, since the topic is both important and subtle. Agreed. - I don't recall seeing many comments on the list, if any, on sections 6 through 10. In general I'd like to see more review and comments on these sections in the draft before the draft goes to WGLC. - Also related to sections 6 - 10, there appear to be a number of requirements that are not capitalized according to RFC 2119 in these sections. Anyone willing to volunteer to review the draft and make recommendations for RCF2119 wording changes? - I also found quite a few NITS relating to spelling, grammar, and punctuation. Given the number of nits, it would be good to produce a clean draft for additional review, so we don't duplicate review effort. Yoav and Valery, do you have a sense of when you can turn around an update to this draft with these comments addressed? Regards, Dave Comments/Questions: ---------------------------- General: There seem to be places in the draft where RFC2119 wording should be used (i.e. sections 6 - 10). It would be good to see more review and comments on this section to make sure we are 1) providing appropriate guidance and 2) using the appropriate normative language. For example in section 6: s/DDoS attack, it is suggested that no Cookie or puzzles be used/DDoS attack, it is RECOMMENDED that no Cookie or puzzles be used/ I agree that it is good idea if the draft is reviewed for the proper use of RFC2119 keywords. Section 3: Is it possible if "the same value is sent to all Initiators", that the attacker could coordinate solving the puzzle across a number of attack hosts to achieve some efficiency? If so, it might be good to recommend that a new challenge be sent to each host for each SA. Here "the same value" means "the same number of zero bits", i.e. the same puzzle difficulty. The puzzles themselves must be different for each initiator. Should we rephrase the para to make it more clear? I believe rephrasing would be helpful in making this more clear. Sections 3.1 and 3.2 need to be completed or removed. Some of this looks like it may be included in Section 8. It also looks to be fully described in sections 10.1 and 10.2. Some work is needed to sort this out. They should be removed. As I've said they were left due to miscommunication in a rush conditions. Section 5: I am not a fan of using the phrase "but the current thinking", since this may be read many years from now. This paragraph should be reworked to make it more temporally relevant. Perhaps you can tie the thinking directly to the degree of IPv6 NAT usage directly and avoid the temporal qualifier? I tend to agree with you, however I'd let Yoav comment on this. Section 6: The phrase "the amount of failed IKE_AUTH exchanges to never exceed the threshold of attack detection" doesn't make sense and needs to be reworded. In the phrase "only defensive measure is the monitoring", it is not clear what is being monitored. I am assuming this is about monitoring half-open SAs. This should be clarified. OK. Section 8.2.1: Shouldn't the puzzle used in the IKE_SA_INIT be different than the puzzle used in the IKE_AUTH exchange to prevent the initiator from sending back a cached response or am I misunderstanding something? Same comment for section 8.2.1.2. They will be different due to the differences in construction of the string S. Ininitial exchange the S is the content of the cookie, while in the IKE_AUTH puzzles the S is the concatenation of the Responder's nonce (Nr) and Responder's SPI (SPIr). It is very unlikely thatthese two S are the same. Should we add some clarificationon this? Looking back the values for S are defined in 8.1.2.1 and 8.2.2.1. The text in the first paragraph of section 8.2.2 makes the construction distinction clear. This did not jump out right away for me. It might be more clear to make this distinction up front at the beginning of section 8 by adding an introductory paragraph? This text could also describe the layout of section 8 as well. Section 11: The security consideration section needs to be completed. Perhaps this could be made a summary of the threats and related countermeasures described in the document? Certainly. However this summary might not be enough, since the topic is subtle and it's easy to miss some important details. I think we need more reviews and more comments. Agreed. Nits: ------ I agree with all of the nits even before I read them. Thank you, we'll incorporate the suggested changes into the next version of the draft.
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
