Last Call Review of draft-ietf-ipsecme-ddos-protection-09
review-ietf-ipsecme-ddos-protection-09-opsdir-lc-chown-2016-10-05-00

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