Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes measures to counter (distributed) denial of service attacks on an IKE listener/responder. Some of the measures involve adjusting settings for the numbers of half-open SAs at any one time, for rate-limiting, or for using the stateless cookie approach of RFC7296 (to test return routability). The document also introduces an additional mechanism of challenging the initiator to conduct a proof-of-work (i.e. solve a puzzle), and includes discussion of appropriate settings for when to use such puzzles and their level of difficulty. The document suggests that as the level of perceived DDoS grows (e.g. by monitoring the number of half open SAs), the responder can introduce cookies as a first line of defence, and then use puzzles when its available resources become more critical (as described in section 7.1). The puzzle extends the cookie method; the proof-of-work uses the cookie. Overall the document is Ready with Nits. General comments: I like the chatty, informal style of the document; it is very easy and enjoyable to read. But there are perhaps a few overly casual phrases and terms used, which it may be appropriate to tidy up for a standards track document, e.g. phrases like “attacks of such sort”. There are a few other typos such as “principals” instead of “principles”, but these are relatively minor. Overall, it’s very well written, both in style and substance. There will, in the early stages of adoption of this approach, be a majority of “legacy” initiators that do not recognise the puzzle being requested of them (and thus discard such puzzles, as described in 7.1.2). An initiator might also choose not to solve a puzzle for power consumption reasons (as stated in section 10). And of course attackers would (at least at first) not attempt to solve any puzzle presented. The issue of how and whether puzzle rejection by certain clients is allowed is discussed in sections 7.1.1 and 7.1.5, with the bottom line being that how the responder ultimately makes a decision whether to serve the request is “implementation dependent”. I think this text is OK, but some words in Section 9 about puzzle rejection in early stage deployments, where most initiators won’t have puzzle support, might be useful. I would guess that if puzzles are used as a last line of defence, and only a fraction of initiators understand the option, that there’s little benefit to the mechanism until adoption is more widespread. The IPv6-specific text talks about using prefixes to make decisions rather than single IP addresses; the text should probably say this could be applied on any prefix between /48 and /64, rather than an either/or, as different ISPs have different policies (not that the filtering entity would know those), so using a /48 is “safer” but may have more collateral damage than say a /56 or just a /64. Finally, with hindsight it might have been interesting to see if the proof-of-work mechanism could be abstracted to a standards track document that could be used by other protocols that are vulnerable to a similar type of attack, with the main document then being published as an informational/BCP document. But equally I’m fine seeing the document as it is; it may still inspire similar approaches elsewhere. Tim