Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks
draft-ietf-ipsecme-ddos-protection-10

[Ballot comment]

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?

[Ballot comment]
"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.

[Ballot comment]
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?

[Ballot comment]
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?

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-ipsecme-ddos-protection-09.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, in the IKEv2 Payload Types subregistry of the Internet Key Exchange Version 2 (IKEv2) Parameters registry located at:

https://www.iana.org/assignments/ikev2-parameters/

a new payload type is to be registered as follows:

Value: [ TBD-at-registration ]
Next Payload Type: Puzzle Solution
Notation: PS
Reference: [ RFC-to-be ]

Second, in the IKEv2 Notify Message Types - Status Types subregistry also located in the Internet Key Exchange Version 2 (IKEv2) Parameters registry located at:

https://www.iana.org/assignments/ikev2-parameters/

a new message type is to be registered as follows:

Value: [ TBD-at-registration ]
NOTIFY MESSAGES - STATUS TYPES: PUZZLE
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

IANA understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: ipsecme-chairs@ietf.org, draft-ietf-ipsecme-ddos-protection@ietf.org, ipsec@ietf.org, Kathleen.Moriarty.ietf@gmail.com, david.waltermire@nist.gov, "David Waltermire"
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Protecting Internet Key Exchange Protocol version 2 (IKEv2) Implementations from Distributed Denial of Service Attacks) to Proposed Standard


The IESG has received a request from the IP Security Maintenance and
Extensions WG (ipsecme) to consider the following document:
- 'Protecting Internet Key Exchange Protocol version 2 (IKEv2)
  Implementations from Distributed Denial of Service Attacks'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-09-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document recommends implementation and configuration best
  practices for Internet Key Exchange Protocol version 2 (IKEv2)
  Responders, to allow them to resist Denial of Service and Distributed
  Denial of Service attacks.  Additionally, the document introduces a
  new mechanism called "Client Puzzles" that help accomplish this task.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/ballot/


No IPR declarations have been submitted directly on this I-D.

RFC Type: Proposed Standard

Technical Summary
  This document is a standards track submission that recommends implementation and configuration best practices for Internet Key Exchange Protocol version 2 (IKEv2) Responders, to allow them to resist Denial of Service and Distributed Denial of Service attacks.  Additionally, the document introduces a new mechanism called "Client Puzzles" that help accomplish this task.
     
Working Group Summary
  The document was reviewed by several regular WG participants. Changes suggested by the chairs and participants resulted in a good deal of discussion and revisions. The submitted draft represents solid WG consensus.

Document Quality
  No implementations are currently known, but multiple WG members have  expressed an interest in implementing the guidance in this document.

Personnel
  Authors are Valery Smyslov and Yoav Nir. Kathleen Moriarty is the responsible Area Director. Dave Waltermire is the document shepherd.
 
Intellectual Property
  All authors have confirmed that they are not aware of any undisclosed IPR associated with this document. There have been no IPR disclosures.
 
Other Issues
  None

The document shepherd has completely reviewed this draft to include review of idnits, the references, and IANA considerations sections. No issues have been found.