Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks
draft-ietf-ipsecme-ddos-protection-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2016-11-15
|
10 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2016-11-12
|
10 | Jean Mahoney | Closed request for Last Call review by GENART with state 'No Response' |
2016-11-10
|
10 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2016-10-17
|
10 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2016-10-10
|
10 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2016-10-07
|
10 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2016-10-06
|
10 | (System) | RFC Editor state changed to EDIT |
2016-10-06
|
10 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2016-10-06
|
10 | (System) | Announcement was received by RFC Editor |
2016-10-06
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2016-10-06
|
10 | (System) | IANA Action state changed to In Progress |
2016-10-06
|
10 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2016-10-06
|
10 | Cindy Morgan | IESG has approved the document |
2016-10-06
|
10 | Cindy Morgan | Closed "Approve" ballot |
2016-10-06
|
10 | Cindy Morgan | Ballot approval text was generated |
2016-10-06
|
10 | Cindy Morgan | IESG state changed to Approved-announcement to be sent from Approved-announcement sent |
2016-10-06
|
10 | Cindy Morgan | Ballot writeup was changed |
2016-10-06
|
10 | Kathleen Moriarty | IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup |
2016-10-06
|
10 | Kathleen Moriarty | Ballot comment text updated for Kathleen Moriarty |
2016-10-06
|
10 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2016-10-05
|
10 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Tim Chown. |
2016-10-01
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2016-10-01
|
10 | Yoav Nir | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2016-10-01
|
10 | Yoav Nir | New version approved |
2016-10-01
|
10 | Yoav Nir | New version available: draft-ietf-ipsecme-ddos-protection-10.txt |
2016-10-01
|
10 | Yoav Nir | Request for posting confirmation emailed to previous authors: "Valery Smyslov" , "Yoav Nir" |
2016-10-01
|
10 | (System) | Uploaded new revision |
2016-09-29
|
09 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Waiting for AD Go-Ahead |
2016-09-29
|
09 | Kathleen Moriarty | [Ballot comment] Pending on IANA expert review |
2016-09-29
|
09 | Kathleen Moriarty | Ballot comment text updated for Kathleen Moriarty |
2016-09-28
|
09 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2016-09-28
|
09 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2016-09-28
|
09 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2016-09-28
|
09 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2016-09-28
|
09 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2016-09-27
|
09 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2016-09-27
|
09 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2016-09-27
|
09 | Stephen Farrell | [Ballot comment] This is a nicely written document... thanks! - I vaguely recalled that puzzles and IPR rang a bell. Did the WG consider [1]? … [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? |
2016-09-27
|
09 | Stephen Farrell | [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell |
2016-09-27
|
09 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2016-09-27
|
09 | Alissa Cooper | [Ballot comment] "A typical Initiator or bot-net member in 2014 can perform slightly less than a million hashes per second per core" Is … [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. |
2016-09-27
|
09 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2016-09-27
|
09 | Alexey Melnikov | [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 … [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? |
2016-09-27
|
09 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from No Record |
2016-09-27
|
09 | Alexey Melnikov | [Ballot comment] Puzzle Solution Payload format - I don't see the new payload type specified in the diagram. |
2016-09-27
|
09 | Alexey Melnikov | Ballot comment text updated for Alexey Melnikov |
2016-09-26
|
09 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2016-09-23
|
09 | Mirja Kühlewind | [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 … [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? |
2016-09-23
|
09 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2016-09-23
|
09 | Kathleen Moriarty | Ballot has been issued |
2016-09-23
|
09 | Kathleen Moriarty | [Ballot Position Update] New position, Yes, has been recorded for Kathleen Moriarty |
2016-09-23
|
09 | Kathleen Moriarty | Created "Approve" ballot |
2016-09-21
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Chown |
2016-09-21
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Chown |
2016-09-21
|
09 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2016-09-21
|
09 | Sabrina Tanamal | (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 … (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 |
2016-09-21
|
09 | Kathleen Moriarty | Ballot writeup was changed |
2016-09-21
|
09 | Kathleen Moriarty | Ballot writeup was changed |
2016-09-15
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Lucy Yong |
2016-09-15
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Lucy Yong |
2016-09-15
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Warren Kumari |
2016-09-15
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Warren Kumari |
2016-09-14
|
09 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2016-09-14
|
09 | Amy Vezza | 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 … 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. |
2016-09-14
|
09 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2016-09-14
|
09 | Kathleen Moriarty | Placed on agenda for telechat - 2016-09-29 |
2016-09-14
|
09 | Kathleen Moriarty | Last call was requested |
2016-09-14
|
09 | Kathleen Moriarty | Ballot approval text was generated |
2016-09-14
|
09 | Kathleen Moriarty | Ballot writeup was generated |
2016-09-14
|
09 | Kathleen Moriarty | IESG state changed to Last Call Requested from AD Evaluation |
2016-09-14
|
09 | Kathleen Moriarty | Last call announcement was generated |
2016-09-12
|
09 | Yoav Nir | New version available: draft-ietf-ipsecme-ddos-protection-09.txt |
2016-09-09
|
08 | Kathleen Moriarty | IESG state changed to AD Evaluation from Publication Requested |
2016-08-18
|
08 | David Waltermire | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2016-08-18
|
08 | David Waltermire | RFC Type: Proposed Standard Technical Summary This document is a standards track submission that recommends implementation and configuration best practices for Internet Key Exchange … 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. |
2016-08-18
|
08 | David Waltermire | Responsible AD changed to Kathleen Moriarty |
2016-08-18
|
08 | David Waltermire | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2016-08-18
|
08 | David Waltermire | IESG state changed to Publication Requested |
2016-08-18
|
08 | David Waltermire | IESG process started in state Publication Requested |
2016-08-18
|
08 | David Waltermire | Changed document writeup |
2016-08-18
|
08 | David Waltermire | Changed consensus to Yes from Unknown |
2016-08-18
|
08 | David Waltermire | Intended Status changed to Proposed Standard from None |
2016-08-18
|
08 | David Waltermire | Notification list changed to "David Waltermire" <david.waltermire@nist.gov> |
2016-08-18
|
08 | David Waltermire | Document shepherd changed to David Waltermire |
2016-08-17
|
08 | David Waltermire | New version available: draft-ietf-ipsecme-ddos-protection-08.txt |
2016-07-01
|
07 | Yoav Nir | New version available: draft-ietf-ipsecme-ddos-protection-07.txt |
2016-06-06
|
06 | David Waltermire | Tag Revised I-D Needed - Issue raised by WGLC set. |
2016-06-06
|
06 | David Waltermire | IETF WG state changed to In WG Last Call from WG Document |
2016-04-15
|
06 | Yoav Nir | New version available: draft-ietf-ipsecme-ddos-protection-06.txt |
2016-03-21
|
05 | Yoav Nir | New version available: draft-ietf-ipsecme-ddos-protection-05.txt |
2016-03-01
|
04 | Yoav Nir | New version available: draft-ietf-ipsecme-ddos-protection-04.txt |
2015-12-16
|
03 | Yoav Nir | New version available: draft-ietf-ipsecme-ddos-protection-03.txt |
2015-07-04
|
02 | Yoav Nir | New version available: draft-ietf-ipsecme-ddos-protection-02.txt |
2015-03-09
|
01 | Yoav Nir | New version available: draft-ietf-ipsecme-ddos-protection-01.txt |
2014-10-27
|
00 | Yoav Nir | New version available: draft-ietf-ipsecme-ddos-protection-00.txt |