Configuring BGP to Block Denial-of-Service Attacks
draft-turk-bgp-dos-06

I don't have objections if the document gets published in it's current state,
however, the author might want to consider the comments that I received
from the ops directorate and address them:

I received the following comments from Pekka Savola (ops dir):

This proposed approach makes the unstated assumption that in general,
DoS attacks only come from one or specific directions or border
routers.  This is not necessarily the case, and I'd argue that for
e.g., larger operators in the U.S., this is never the case.

This approach might help if you only have one or two designated
upstream routers that don't do much else, and when someone attacks
your customer, you block the traffic at upstream, but still allow
traffic from other customers and possibly peers.  But again, here
peers would possibly still flood the customer, and due to the nature
of Internet, the user might not actually be much better off if he's
capable of only communicating with your network.

So, I think the applicability of the whole approach in
operational scenarios might warrant some criticism.  If this goes
forward, my suggestion would be teasing out the assumptions and the
applicable scenarios better, for example by adding an introduction
section and discussing the motivations etc. of current approaches
there, as well as the justifications for this approach as well.

FWIW, one concrete way how to make this operationally slightly more
feasible would be also designating classes of border routers with some
community values, e.g., 'upstream', 'peer', 'customer'.

So, I think this doc suffers from the severe failure to consider what
the actual problem being solved is, and what are the scenarios for
that problem .. and spelling that out right out.  Some hints are
available here and there throughout the memo, one should concentrate
more on this.

nits:
 - ToC could be very well omitted, the doc is so short.
 - there are too long lines in the draft.
 - missing boilerplates at the end
 - there are hyphens at the end of lines, which is forbidden.

editorial comments:

- editorially, the document would be better split to a bit more
smalled (sub)sections and shorter paragraphs, but is readable as is.

- in general, I think the document is confusing with regard to how
this would work out if the attack is directed through your network but
toward a different AS, not your AS.  It seems as if the assumption is
that it's always your AS that's being attacked.

           By default, routers dropping traffic into a null interface
   should send "ICMP unreachable" message to the source address
   belonging to the origin/attacking AS.

==> is this something which you think should be done, or what *is*
being done?  My experience is that most people will just discard
traffic w/o ICMPs when blackholing them through null interfaces.  But
as you describe a requirement for this operation to function, for
tracing, maybe this should reworded to something like:

           To be able to easily trace which routers were dropping
   the traffic, "ICMP unreachable" messages must be sent by the
   routers for the dropped traffic.

   After the BGP community assignment, R1 and R2 must be configured with
   the following:

   1.   Static route pointing an RFC 1918 network to a null interface.
2.   AS-Path access list that matches local BGP prefix advertisement.
[...]

==> the lists have been screwed up here, and in the following
sections, as well as going over 72 chars/line.  This should probably
be fixed if the doc requires revision in any case.

..

the network operator for all router (i.e. 65001:666 for R1 and R2)

==> s/router/routers/

        b.   A policy statement to permit routes that match the following
          criteria and apply the following changes.

==> this appears to be identical except that in i.) you check a
different community.  If this is the case, summarize the rules by
rewriting a-i.) to something like:

i.   Match for community specific to that router (e.g., 65001:1 for R1)
    OR the community that covers all the routers (i.e., 65001:666).

...

Security Considerations

   It is very important to practice tight control over eBGP peering
   points before implementing the techniques described in this paper.
   eBGP customers might be able to blackhole a particular subnet using
   the Blackhole communities.  To eliminate the risk, the match for
   locally generated BGP advertisements in the special route policy
   should not be neglected.

==> uhh, isn't the first sentence totally irrelevant?  You don't need
to police anything on eBGP sessions (they can still send you the
blackhole community), all it takes is that you'll always and
everywhere remember to require that the router is locally generated.

Acknowledgments

   The author of this document would like to acknowledge the developers
   of the remotely triggered black-holing technique

==> who are these?

   and the developers
   of the backscatter technique for collecting backscatter traffic.

==> who are these?

   The
   author would also like to thank all members of the IP Engineering
   department for their help in verifying the functionality of this
   technique.

==> I guess you refer to Bell Canada?

==> did nobody in the IETF provide anything useful to your document
because you haven't acknowledged anyone for providing feeedback on
your work?  In that case, I guess nobody is interested in it and this
could be dropped?

Author's Addresses

   Doughan Turk
   Bell Canada
   100 Wynford Drive
   Email: doughan.turk@bell.ca

==> snailmail and email don't count as two addresses so
s/Addresses/Address/ :)

The usual boilerplate text needed at the end of the document is missing.