Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2004-06-02
06 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2004-06-01
06 Amy Vezza IESG state changed to Approved-announcement sent
2004-06-01
06 Amy Vezza IESG has approved the document
2004-06-01
06 Amy Vezza Closed "Approve" ballot
2004-05-28
06 (System) Removed from agenda for telechat - 2004-05-27
2004-05-27
06 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation by Amy Vezza
2004-05-27
06 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2004-05-27
06 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman
2004-05-27
06 Margaret Cullen Created "Approve" ballot
2004-05-27
06 (System) IESG has approved the document
2004-05-26
06 (System) Closed "Approve" ballot
2004-05-26
06 David Kessens
[Ballot comment]
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 …
[Ballot comment]
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/ :)
2004-05-26
06 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2004-05-25
06 Ted Hardie [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie
2004-05-25
06 Scott Hollenbeck [Ballot Position Update] Position for Scott Hollenbeck has been changed to No Objection from Undefined by Scott Hollenbeck
2004-05-25
06 Scott Hollenbeck [Ballot comment]
The usual boilerplate text needed at the end of the document is missing.
2004-05-25
06 Scott Hollenbeck [Ballot Position Update] New position, Undefined, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2004-05-19
06 Alex Zinin Placed on agenda for telechat - 2004-05-27 by Alex Zinin
2004-05-19
06 Alex Zinin State Changes to IESG Evaluation from Approved-announcement to be sent::Point Raised - writeup needed by Alex Zinin
2004-05-19
06 Alex Zinin [Note]: 'Information for the write-up requested by the IESG has been missing for a few weeks.' added by Alex Zinin
2004-04-15
06 Amy Vezza State Changes to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation by Amy Vezza
2004-04-15
06 Alex Zinin [Ballot Position Update] New position, Yes, has been recorded for Alex Zinin
2004-04-15
06 Alex Zinin Ballot has been issued by Alex Zinin
2004-04-15
06 Alex Zinin Created "Approve" ballot
2004-04-15
06 (System) Ballot writeup text was added
2004-04-15
06 (System) Last call text was added
2004-04-15
06 (System) Ballot approval text was added
2004-04-08
06 Alex Zinin Placed on agenda for telechat - 2004-04-15 by Alex Zinin
2004-04-08
06 Alex Zinin State Changes to IESG Evaluation from AD Evaluation::Revised ID Needed by Alex Zinin
2004-03-25
06 (System) New version available: draft-turk-bgp-dos-06.txt
2004-03-23
05 (System) New version available: draft-turk-bgp-dos-05.txt
2004-03-19
06 Alex Zinin State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::External Party by Alex Zinin
2004-03-15
06 Alex Zinin State Changes to AD Evaluation::External Party from AD Evaluation by Alex Zinin
2004-03-15
06 Alex Zinin
Some points:

  1. You are not using the 2119 language, but you have the "Conventions"
    section. I could attach an RFC-Editor note …
Some points:

  1. You are not using the 2119 language, but you have the "Conventions"
    section. I could attach an RFC-Editor note to the draft asking to
    remove this section.

  2. Ref [1] in your doc is neither complete nor used in the text.
    You need to decide whether you should use it somewhere and complete
    the biblio for it, or simply drop it.

  3. Your doc says:

>    This document is an Internet-Draft and is in full conformance with
>    all provisions of Section 10 of RFC2026 except that the right to
>    produce derivative works is not granted.

    Did you mean to remove this limitation before submitting the doc
    to the IESG?
2004-03-12
06 Alex Zinin State Changes to AD Evaluation from AD Evaluation::Revised ID Needed by Alex Zinin
2003-10-23
06 Alex Zinin
ops-dir comments from Kurt:

A VERY quick read-through gave me the follwing :

- - For the "current" attack scenario assumes acces to a iBGP …
ops-dir comments from Kurt:

A VERY quick read-through gave me the follwing :

- - For the "current" attack scenario assumes acces to a iBGP speaking
  router within the AS. This is most certainly possible, but I would
  like to see some elaboration on this in the draft.

- - It requires you to be able to introduce the the source address to
  gather the ICMP packets

- - Something that requires 13 conditions to be met (in this case
  activly configured) is not really that common or standard. Then I
  agree that some of the requirements really should be in operators
  networks but that is another issue.

- - The security consideration section does not (IMHO) deal with
  security considerations. Rather it's recommendations on how to
  prevent this type of attack. Something that should be elaborated in
  the draft itself.

In general, the scenario is absolutly possible, but how likely? I
would argue not enough to warrant a RFC in itself. While I was an
operator, we discussed a variation of this attack and deemed it
simply so unlikely that we didn't care. Anyone else here with other
views? This might have become more of an issue in the year and a half
  I have been gone from the carrier world.
2003-10-14
06 Alex Zinin State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Alex Zinin
2003-10-14
06 Alex Zinin Comments received during the call for review on the routing area mailing list. New version needed.
2003-09-05
06 Alex Zinin State Changes to AD Evaluation from Publication Requested::External Party by Alex Zinin
2003-09-05
06 Alex Zinin Reviewing
2003-08-26
06 Randy Bush State Changes to Publication Requested::External Party from AD is watching by Randy Bush
2003-08-26
06 Randy Bush
From: Randy Bush
Date: Wed, 27 Aug 2003 08:35:51 +0900
To: doughan.turk@bell.ca
Cc: Natalia Syracuse ,
    Dave Meyer ,
    Bert Wijnen …
From: Randy Bush
Date: Wed, 27 Aug 2003 08:35:51 +0900
To: doughan.turk@bell.ca
Cc: Natalia Syracuse ,
    Dave Meyer ,
    Bert Wijnen ,
    Bill Fenner ,
    Alex Zinin 
Subject: RE: FW: draft???

> We took the draft out of GROW and into independent submissions,

so send it to the rfc-ed as an individual submission and i will remove
it from my plate.

randy
2003-08-26
06 Randy Bush Shepherding AD has been changed to Alex Zinin from Randy Bush
2003-08-26
06 Randy Bush Area acronymn has been changed to rtg from ops
2003-06-18
06 Bill Fenner
Author requested move to GROW WG

From: "Turk, Doughan A."
Subject: RE: Informational RFC to be: draft-turk-bgp-dos-04.txt
Date: Wed, 18 Jun 2003 14:48:43 -0400
To: …
Author requested move to GROW WG

From: "Turk, Doughan A."
Subject: RE: Informational RFC to be: draft-turk-bgp-dos-04.txt
Date: Wed, 18 Jun 2003 14:48:43 -0400
To: "RFC Editor" , iesg@ISI.EDU
Cc: "Turk, Doughan A."

Dear Sir or Madam,

I would like to request that you move my internet-draft
"draft-turk-bgp-dos-04.txt" from the general WG to the GROW WG.
2003-06-18
06 Bill Fenner Shepherding AD has been changed to Bush, Randy from Fenner, Bill
2003-06-18
06 Bill Fenner Area acronymn has been changed to ops from rtg
2003-06-18
06 Bill Fenner State Changes to AD is watching from Publication Requested by Fenner, Bill
2003-02-05
06 Bill Fenner From: RFC Editor
Subject: Informational RFC to be: draft-turk-bgp-dos-04.txt
Date: Mon, 3 Feb 2003 11:09:56 -0800
To: iesg@ISI.EDU
2003-02-05
06 Bill Fenner Draft Added by Fenner, Bill
2003-01-20
04 (System) New version available: draft-turk-bgp-dos-04.txt
2003-01-07
03 (System) New version available: draft-turk-bgp-dos-03.txt
2002-11-06
02 (System) New version available: draft-turk-bgp-dos-02.txt
2002-08-29
01 (System) New version available: draft-turk-bgp-dos-01.txt