[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 01 02 03 04 05 06 rfc3882                                     
Network Working Group
Internet Draft                                                 D.  Turk
Document: draft-turk-bgp-dos-01.txt                         Bell Canada
Expires: February 2003                                      August 2002


           Configuring BGP to Block Denial-of-Service Attacks

Status of this Memo

   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.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.   Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.   It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT","SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in [RFC-2119].

Abstract

   This document describes a technique that uses BGP communities to
   remotely trigger black holing of a particular destination network.
   Black holing can be applied on a selection of routers rather than all
   BGP speaking routers in the network.   The document also describes a
   sinkhole tunnel technique using BGP communities and tunnels to pull
   traffic into a sinkhole router for analysis.








Turk                   Expires - February 2002                [Page 1]


                 Configuring BGP to Block DoS Attacks      August 2002


Table of Contents

   1. Existing BGP-Triggered Black holing Techniques                 2
   2. Enhanced BGP-Triggered Black holing Technique                  3
   3. Sinkhole tunnels                                               4
   Security Considerations                                           6
   Disclaimer                                                        6
   References                                                        7
   Acknowledgments                                                   7
   Author's Addresses                                                7

1.   Existing BGP-Triggered Black holing Techniques

   Current BGP-triggered black holing techniques rely on altering the
   next hop address of a particular network experiencing an attack by
   the use of BGP.  The BGP announcement propagates from a router
   participating in the BGP domain where the next hop address is
   modified to point to an RFC1918 address.  Most routers on the
   Internet, especially edge routers, have static routes pointing
   RFC1918 addresses to the null interface.

   When a BGP speaking router receives the update, it will install the
   announced prefix into the routing table with a next hop of one of the
   networks listed in RFC1918.  The router will then attempt to resolve
   the RFC1918 based BGP next-hop in order to qualify the route and
   derive a forwarding next-hop. This process will return a valid next
   hop of the null interface assuming the router is properly configured
   to direct RFC1918 destined traffic to a null interface.  Thus,
   traffic destined to the announced network gets dropped making the
   announced network unreachable to the attacker.

   While this technique shields the internal infrastructure from the
   attack thereby protecting a large number of devices, it has the
   undesirable side effect or rendering the targeted network unreachable
   throughout the entire AS.  Even if a static route pointing RFC1918 to
   a null interface does not exist on a particular router participating
   in the BGP domain, the modified next hop makes the traffic un-
   routable to its legitimate destination.

   Network operators usually use the BGP-triggered black holes for a
   short period of time. The technique causes traffic drops on all
   ingress points of the network for traffic destined toward the target
   network.  By default, routers dropping traffic into a null interface
   should send "ICMP unreachable" to the source address of packet being
   dropped.  Once the procedure reaches this point, one of the source
   addresses is hijacked by introducing a device with the same source IP
   address into the network.


Turk                   Expires - February 2002                [Page 2]


                 Configuring BGP to Block DoS Attacks      August 2002


   The device with the hijacked address collects the ICMP unreachable
   packets and source addresses reveal which edge routers the attack is
   coming from.  A network operator may then opt to manually stop the
   traffic on the routers from which attack traffic is entering.

2.   Enhanced BGP-Triggered Black holing Technique

   This paper describes a technique developed to remotely trigger a
   selective set of routers to alter the next hop address of a
   particular prefix. The next hop can either be a null interface or as
   discussed later to in this draft it could be a sinkhole tunnel.  This
   technique does not invoke an access list or rate limiting statement
   to treat attack traffic nor does it involve a BGP domain wide change
   of the victims next hop address to an RFC1918 address.  The next hop
   will only be changed on selection of routers with the aid of BGP
   communities.

   To prepare the network for this technique, the network operator needs
   to define a unique community value for each edge router that could
   potentially drive attack traffic to the victim.  For examples, a
   network with a BGP autonomous system number 65001 has two edge
   routers (R1 and R2).  Community value 65001:1 is assigned to identify
   R1, community value 65001:2 is assigned to identify R2 and community
   value 65001:666 is assigned to identify both R1 and R2.

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

   1.   Static route pointing an RFC1918 network to a null interface.
   2.   AS-Path access list that matches local BGP prefix announcements.
   3.   BGP community access list to match the community value assigned by
        the network operator for the particular router (i.e. 65001:1 for R1).
   4.   BGP community access list to match the community value assigned by
        the network operator for all router (i.e. 65001:666 for R1 and R2)
   5.   Under the BGP process, an iBGP import route policy should be
        applied on received BGP announcements to do the following logic.
        (Statements are in a logical AND order)
        a.   A policy statement to permit routes that match the following
             criteria and apply the following changes.
              i.   Match for community specific to that router (i.e. 65001:1,
                   for R1).
             ii.  Match AS-Path to locally generated BGP announcements.
            iii.  Set BGP next hop to an RFC1918 network.
             iv.  Overwrite BGP community with the well-known community (no-
                  advertise).


Turk                   Expires - February 2002                [Page 3]


                 Configuring BGP to Block DoS Attacks      August 2002


        b.   A policy statement to permit routes that match the following
             criteria and apply the following changes.
              i.  Match for community that covers all routers (i.e. 65001:666).
             ii.  Match AS-Path to locally generated BGP announcements.
            iii.  Set BGP next hop to an RFC1918 network.
             iv.  Overwrite BGP community with the well-known community (no-
                  advertise).

   After the policies have been configured on R1 and R2, the network
   operator can, in the case of an attack, announce the targeted network
   in its BGP domain with a community value associated with the
   router(s) where the attack is arriving. Using BGP communities
   preserves the original next hop address of the targeted network on
   all routers where the special route policy configuration is not
   configured.  iBGP will then carry the prefix announcement to all
   router in the AS.  All routers except the ones that match the
   community stamped on the prefix will be oblivious to the community
   value and will install the network route with the legitimate next hop
   address.  Routers that match the community will also install the
   network route into their routing table but will alter the next hop to
   an RFC1918 network and then a null interface as per the route
   policies configuration.  The reason for matching locally announced
   networks is to make sure that no eBGP customer can misuse this
   community to drive any network to a null interface.

   This technique stops traffic from getting forwarded to the legitimate
   destination on routers identified as transit routers for attack
   traffic.  All other traffic on the network will still get forwarded
   to the legitimate destination thus minimizing the impact on the
   targeted network.

3.   Sinkhole tunnels

   Further to the "Enhanced BGP-Triggered Black holing Technique", it
   may become a requirement to take a look at the attack traffic for
   further analysis.  This requirement adds to the complexity of the
   exercise.  Usually with broadcast interfaces, network operators
   install network sniffers on a spanned port for analysis of traffic.
   Another method would be to announce a network prefix that covers the
   attack host address(s) into BGP, altering the next hop to a sinkhole
   device that can log traffic for analysis.  Those techniques result in
   taking down the services offered on the targeted IP addresses.  Inter-
   AS traffic will be sucked into the sinkhole along with Intra-AS
   traffic.




Turk                   Expires - February 2002                [Page 4]


                 Configuring BGP to Block DoS Attacks      August 2002



   The concept of sinkhole tunnels becomes viable when the solutions
   usually involve taking the targeted IP address down when the need for
   packet level analysis arises.  The idea of a sinkhole tunnel is like
   a garden hose or a short cut path.  When traffic is pushed to enter
   one end of the tunnel, it will end up exiting from the other end.
   This concept is useful to forward traffic on a network where there
   was no tampering with the targeted address next hop address.

   First, a sinkhole router with an optional sniffer attached to is
   installed. A tunnel is then set up using for instance, MPLS Traffic
   Engineering tunnel, from all border routers a packet can potentially
   enter from (Inter-AS traffic) to the sinkhole router.  This allows
   the use of the community technique of altering the next hop of the
   targeted prefix to a series of /30 subnets assigned to the tunnels
   with the tail end terminating at the sinkhole router.  In other
   words, the border router alters the next hop of the targeted IP
   address to the address of the sinkhole router within the subnet of
   the tunnel that starts at the border router.  All other routers
   within the AS are oblivious to the change made by announcing a prefix
   with the preset community described in section 2.  If legitimate
   traffic is coming from a different part of the network, the next hop
   would not be altered because of the community since next hop altering
   route maps do not exist anywhere else.

   Attack traffic is then treated at the sinkhole device.  If the
   requirement was not to kill the traffic but rather to analyze it and
   then send it back towards the router it was originally destined to.
   Then on the sinkhole device, a default network statement is
   configured pointing to any interface attached to the network
   including the same physical interface the traffic came from.  Traffic
   entering the sinkhole device from the tunnel will be pushed out of an
   interface back to the network because of the default route.  Routing
   protocols will then take care of properly routing the traffic to its
   original destination as if nothing had happened.  This is possible
   because no router other than the border router that has a match for
   the community will take action based on that community.  It becomes
   apparent that this technique can be used for purposes other than
   analyzing attack traffic.  Legitimate traffic could be pulled out of
   normal routing into a tunnel and then reinserted onto the backbone
   without altering the next hop addressing scheme.

   MPLS Traffic Engineering is a good way of sliding traffic to the
   sinkhole simply because of the many features it is associated with.
   Features like QoS policies on the attack traffic can be applied so
   that it will not compete with legitimate traffic. Hiding the extra
   hops caused by diverting the traffic by altering its TTL, and so on.


Turk                   Expires - February 2002                [Page 5]


                 Configuring BGP to Block DoS Attacks      August 2002



   To be able to alter the next hop on the border router, a subnet of an
   RFC1918 network is statically routed to the tunnel interface.  Take
   for example 192.0.2.33/32

   ip route 192.0.2.1 255.255.255.255 Tunnel0

   Setting next hop of the target IP address to 192.0.2.1/32 will force
   the traffic to go through the tunnel.

   After the traffic is received on the sinkhole interface via TE
   tunnel, rate-limiting policies, QoS policies or access lists could be
   installed to rate limit or drop traffic classified as attack traffic.
   This could be done on the interface of the sinkhole.

   Another useful application for a sinkhole router is to pull in
   traffic via tunnels to an inbound interface and have a default route
   statement forwarding the traffic out to an Ethernet interface. The
   Ethernet interface is connected to the network and guarantees proper
   delivery of traffic but allows the use of a packet sniffer to further
   analyze the attack traffic.  This becomes very useful when it is not
   feasible to apply an Access list or a rate limiting statement on the
   border router or last hop router because of hardware or software
   limitations.  Instead of upgrading interfaces where attack traffic
   will potentially enter from, traffic could be pulled into the
   sinkhole and treated on that box.  Reduction in cost can be exercised
   if the sinkhole router is a powerful device.

Security Considerations

   It is very important to practice tight control over BGP peering
   points before implementing this technique.  BGP customers might be
   able to compromise a particular piece of the network using the Black
   holing communities.  Making sure that a match for locally generated
   BGP announcement exist helps in limiting the ability to drive a
   network to a null interface to the local AS.  Some other security
   considerations MUST be looked at based on the status of the AS those
   techniques are being implemented at.

Disclaimer

  The views and specification here are those of the authors and are not
  necessarily those of their employers.  The authors and their employers
  specifically disclaim responsibility for any problems arising from
  correct or incorrect implementation or use of this specification.




Turk                   Expires - February 2002                [Page 6]


                 Configuring BGP to Block DoS Attacks      August 2002


References

   [1] B.  Greene "ISP Security Essentials - Best Practice Cisco IOS and
       other Techniques to Help an ISP Survive in today's Internet,
       version 2.0", May, 2001

Acknowledgments

   The author of this document would like to acknowledge the developers
   of the remotely triggered black holing technique and the developers
   of the backscatter technique for collecting backscatter traffic.  The
   author would also like to thank all members of the IP Engineering
   department for their help in verifying the functionality of this
   technique.

Author's Addresses

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




























Turk                   Expires - February 2002                [Page 7]