Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks
draft-ietf-ipsecme-ddos-protection-10
Yes
(Kathleen Moriarty)
(Spencer Dawkins)
No Objection
(Alia Atlas)
(Alvaro Retana)
(Ben Campbell)
(Deborah Brungard)
(Jari Arkko)
(Suresh Krishnan)
(Terry Manderson)
Note: This ballot was opened for revision 09 and is now closed.
Kathleen Moriarty Former IESG member
Yes
Yes
(2016-10-06)
Unknown
Spencer Dawkins Former IESG member
Yes
Yes
(for -09)
Unknown
Stephen Farrell Former IESG member
Yes
Yes
(2016-09-27 for -09)
Unknown
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?
Alexey Melnikov Former IESG member
No Objection
No Objection
(2016-09-27 for -09)
Unknown
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?
Alia Atlas Former IESG member
No Objection
No Objection
(for -09)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(2016-09-27 for -09)
Unknown
"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.
Alvaro Retana Former IESG member
No Objection
No Objection
(for -09)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(for -09)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -09)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -09)
Unknown
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2016-09-23 for -09)
Unknown
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?
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -09)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -09)
Unknown