Telechat Review of draft-ietf-opsec-blackhole-urpf-
review-ietf-opsec-blackhole-urpf-secdir-telechat-austein-2009-06-16-00

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This document describes a BGP-based mitigation technique for
denial-of-service attacks, combining two previously known techniques
(BGP-triggered black holes and unicast reverse path forwarding -- see
RFCs 3704 & 3882) in a clever way to allow configuration of relatively
precise rules to discard offending packets with minimal collateral
damage (at least by comparision to other known techniques).

This is not a protocol draft; it is an explanation of how to use
existing tools to handle a real problem.

The techniques described require careful attention to detail, there
are some tricky router configuration issues setting this stuff up, and
the BGP announcements involved really need to be prevented from
leaking out of their intended scope.  The draft spells out a number of
precautions, including use of the BGP NO_EXPORT community and several
"belt and suspenders" checks in case all the other precautions fail.
Nothing in this space is risk-free, but I am satisfied that the
authors have done a reasonable job of identifying the risks and
explaining how to manage them.  The authors have also included a brief
discussion of a variation of uRPF which, if implemented by router
vendors, would allow operators to turn on just the part of uRPF that
is needed for this mitigation technique, thus reducing one of the
associated risks.

I do not have any security concerns per se with this draft.  Most of
the issues above are operational; the only security issue per se is in
step 2.3 of section 3.2 ("Customer Triggered" RTBH filtering), and the
authors have already specified the obvious restriction.

Caveats:

- While I am reasonably familiar with how BGP works, I am not a BGP
  protocol wizard.

- I am not a router operator.

- I am not competent to debug the configuration examples in the
  appendices of this draft.