Network Working Group
Internet Draft                                                 D.  Turk
Document: draft-turk-bgp-dos-02.txt                         Bell Canada
Expires: May 2003                                         November 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 an operational technique that uses BGP
   communities to remotely trigger black-holing of a particular
   destination network to block denial-of-service attacks.   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 - March 2003                 [Page 1]


                 Configuring BGP to Block DoS Attacks    November 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 RFC 1918 (private internet) address.  Most
   routers on the Internet, especially edge routers, have static routes
   pointing RFC 1918 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 RFC 1918.  The router will then attempt to resolve
   the RFC 1918 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 RFC 1918 destined traffic to a null interface.  Thus,
   traffic destined to the announced network gets dropped, making the
   announced network unreachable to the attacker and everyone else.

   While this technique shields the internal infrastructure from the
   attack, thereby protecting a large number of devices, it has the
   undesirable side effect of rendering the targeted network unreachable
   throughout the entire AS.  Even if a static route pointing an RFC
   1918 address 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 - March 2003                 [Page 2]


                 Configuring BGP to Block DoS Attacks    November 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 on in this draft it could be a sinkhole tunnel
   interface.  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 RFC 1918
   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 RFC 1918 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 RFC 1918 network.
              iv.  Overwrite BGP community with the well-known community (no-
                   advertise).


Turk                     Expires - March 2003                 [Page 3]


                 Configuring BGP to Block DoS Attacks    November 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 RFC 1918 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 RFC 1918 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 - March 2003                 [Page 4]


                 Configuring BGP to Block DoS Attacks    November 2002



   Packet level analysis involves redirecting traffic away from the
   destination host to a sniffer or a router.  As a result, if the
   traffic being examined includes legitimate traffic, that legitimate
   traffic will never make it to the destination host.  This will result
   in denial of service for the legitimate traffic.  A better
   alternative would be to use a sinkhole tunnel.  A sinkhole tunnel is
   implemented only at the entry point to the network, where the all
   traffic destined to the target host will be re-routed to a special
   path (tunnel) where the sniffer will be able to analyze the traffic.
   After being analyzed, the traffic will exit the tunnel and get routed
   normally to the destination host.  In other words, the traffic will
   be passed through the network to a sniffer without altering the next
   hop information of the destination network in all routers in the BGP
   domain.  Only the entry point router will have the altered next hop
   information.

   First, a sinkhole router with an optional sniffer attached to it 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



Turk                     Expires - March 2003                 [Page 5]


                 Configuring BGP to Block DoS Attacks    November 2002


   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.

   To be able to alter the next hop on the border router, a subnet of an
   RFC 1918 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.  Some other security considerations MUST
   be looked at based on the status of the AS those techniques are being
   implemented at.


Turk                     Expires - March 2003                 [Page 6]


                 Configuring BGP to Block DoS Attacks    November 2002


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.

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 - March 2003                 [Page 7]