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 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 |