Ballot for draft-ietf-ipsecme-ddos-protection
Yes
No Objection
Note: This ballot was opened for revision 09 and is now closed.
This is a nicely written document... thanks! - I vaguely recalled that puzzles and IPR rang a bell. Did the WG consider [1]? If not, and if it helps, I'm fine with making a 3rd party declaration on that and last call could be done again. Or maybe there's a better way to handle it. Or maybe the WG considered it and are happy enough already that it's not relevant or about to expire or abandoned or something. ("Not relevant" would puzzle me:-) [1] https://datatracker.ietf.org/ipr/417/ - section 3: "if certificates are involved" - you could note here that involving certificates can introduce a network based delay (OCSP, CRLs etc) that's a little different from CPU consumption. (But it's a nit, and you do note a similar issue in 4.7.) - 4.2: "ratelimits should be done based on either the /48 or /64" - would it be better to say "something between a /48 and a /64" maybe? Don't some ISPs assign things in-between? - 4.4: Did you consider making the "4 keys" requirement tied to the PRF algorithm identifier? That would allow for a future where e.g. 6 keys are needed for the same PRF, if that were ever useful. (Without changing current implementations.) I guess you'd need a separate IANA registry that'd initially duplicate stuff in that case so maybe not worth doing. (And could be done later.) - 7.1.1 - you don't clearly say if the cookie value here can be a new one or should be the same as one previously used (if one was previously used). That may just be my ignorance of IPsec cookies though, but I wondered if there are any cases where the initiator gets to work away on the puzzle ahead of time if the same cookie is used for multiple interactions. There's not much (or zero) of an improvement to the attack here, though maybe the attacker could more easily offload puzzle solving to someone else in that case?
I tempted to ballot Yes on on the document. I hope it will get widespread deployment. Please excuse my ignorance: Puzzle Solution Payload format - I don't see the new payload type specified in the diagram. Where is it included?
"A typical Initiator or bot-net member in 2014 can perform slightly less than a million hashes per second per core" Is this supposed to say 2014? Struck me as a little weird.
Some questions: 1) sec 7.1.2: If there is a puzzle but no cookie, maybe the initiator should ignore it and try to send reply without the puzzle solution, as there might be still a change to get served…? If it then received another packet with puzzle it can still solve it and reply. 2) sec 7.1.4: Does „the Responder MUST verify the puzzle solution“? Maybe there are cases where the burden for the initiator is high enough by requesting the solution that there is already an effect even if the responder decides to not verify it…? 3) also sec 7.1.4: Does the following sentence really makes sense? How doe the responser know? Maybe just remove it? „The more time the Initiator spent solving the puzzles, the higher priority it should receive.“ 4) sec 7.2.1.1 says „the Responder would be able to estimate the computational power of the Initiator and select the difficulty level accordingly.“ How would it estimate the computational power? Based on the reply time? Wouldn’t it also need to know the RTT and current congestion level then? 5) sec 7.2.2 says „If the IKE_SA_INIT response message contains the PUZZLE notification and the Initiator supports puzzles, it MUST solve the puzzle.“ Should this be „IKE_SA_AUTH“ here instead of „IKE_SA_INIT“? Otherwise it contradicts sec 7.1.2 („The Initiator MAY ignore the PUZZLE notification…“) Two general comments/questions: 1) What’s about the additional cpu load of the responder to calculate the puzzle. Can that be a problem? Are there any strategies to keep that low (recalculation/caching/reuse)? How long should things be cached/used? Maybe add a few sentences in the Operational Considerations section! 2) Would it make sense to also give a field to change the number of requested keys to scale load? Or why was it decided to use a fixed number of 4 here?