Subject: [OPSEC] ISP BGP filtering draft.

From: Warren Kumari <[email-masked]>
Date: Wed, 25 May 2011 09:19:10 -0400

Hi all,

Many many moon ago (in Anaheim) I started writing a draft on "some recommendations and suggestions regarding filtering BGP announcements from customers." -- I started this with great intentions, but as with many things, quickly got distracted....

 Anyway, as chair I feel it would probably be inappropriate for me to continue writing it -- so, I have a partially completed draft that is looking for a good home.
Is there anyone here that would be willing to take it over? If so, let me know and I'll throw the XML at you…

I never polished it enough to post it, so here it is in all it's glory^w horror.
W

----------------------------------------------------------------------------------------------

TBD                                                            W. Kumari
Internet-Draft                                                    Google
Intended status: Informational                              June 1, 2010
Expires: December 3, 2010

                        Filtering BGP Customers.
                  draft-wkumari-isp-protocol-filtering

Abstract

   This document provides some recommendations and suggestions regarding
   filtering BGP announcements from customers.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on December 3, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Kumari                  Expires December 3, 2010                [Page 1]
Internet-Draft           Filtering BGP Customers.               June 2010

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements notation  . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Recommendations  . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Other recommendations, probably in a different doc . . . . . .  7
   6.  Deny versus Warning  . . . . . . . . . . . . . . . . . . . . .  8
   7.  AS Path filtering  . . . . . . . . . . . . . . . . . . . . . .  9
     7.1.  AS Path Uniformity . . . . . . . . . . . . . . . . . . . .  9
     7.2.  AS Path Length . . . . . . . . . . . . . . . . . . . . . .  9
     7.3.  Filter your own AS number  . . . . . . . . . . . . . . . .  9
     7.4.  Max-prefixes . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  Address space filtering  . . . . . . . . . . . . . . . . . . . 11
     8.1.  Deny own IP Space  . . . . . . . . . . . . . . . . . . . . 11
     8.2.  Deny Bogons  . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 13
     10.1. Privacy  . . . . . . . . . . . . . . . . . . . . . . . . . 13
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   12. Normative References . . . . . . . . . . . . . . . . . . . . . 15
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16

Kumari                  Expires December 3, 2010                [Page 2]
Internet-Draft           Filtering BGP Customers.               June 2010

1.  Introduction

   There have been numerous outages and security incidents caused by
   poor filtering of customers by their providers.  This lack of good
   filtering allows customers to (accidentally or maliciously) announce
   address space that they are not authorized to, to announce routes
   from one provider to another (and so transit traffic from one
   provider to another), to announce a large numbers of prefixes, as
   well as many other things that could cause issues.  While in most
   instances it appears that the incident was accidental it is worth
   keeping in mind that anything that can be done accidentally can also
   be done maliciously, and so it prudent assume a malicious party and
   act accordingly.

   While this document contains many suggestions that apply to
   connections between providers, it is primarily aimed at provider to
   customer connections.  The provider and customer terms are very
   loosely defined, and mean different things to different people, so we
   will try to describe how we are using them in this document.  A
   "provider" is entity that is provides access to the Internet.  It
   usually carries "full routes", has multiple customers, is multihomed
   and is often referred to as an ISP (Internet Service Provider).  A
   customer is an entity that gets access to the Internet through a
   provider.  Its primary business purpose is usually something other
   than Internet Access, it may or may not be multihomed and usually
   only announces a few prefixes -- "customers" are often a stub AS.

   In order to aid with deployment of the described techniques, examples
   (and the language used by two vendors) are provided in the
   Appendices.  These should be viewed as examples only, and customized
   before being used.

1.1.  Requirements notation

   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 [RFC2119].

Kumari                  Expires December 3, 2010                [Page 3]
Internet-Draft           Filtering BGP Customers.               June 2010

2.  Terminology

   WK: TODO:  Figure out what terminology I am using.  Maybe: Provider,
      Customer, Bogon?!.

   Bogon:  A prefix that is known to not be used on the Internet, either
      because it is not allocated, or is a special use address such as
      described in [RFC5735]

   Provider:  A provider is an entity that provides access to the
      Internet (often called an ISP).  In this document we are assuming
      that the provider communicates with its customers over BGP.

   Customer:  An entity that gets connectivity from a provider.
      [TODO(WK): Fix / tighten up this definition.  Definitions are
      hard, lets go shopping.]

   Hijack:  A hijack is when an entity (accidentally or maliciously)
      announces a resource that they are not authorized to.  Examples of
      this would be a prefix (a prefix hijack) or an autonomous system
      number (and AS hijack).

   Warning Community:  A community (chosen by that provider) that it
      will use to mark suspicious announcements.

Kumari                  Expires December 3, 2010                [Page 4]
Internet-Draft           Filtering BGP Customers.               June 2010

3.  Background

   In recent years the Internet has become a critical resource for a
   large number of companies.  This has led a substantial increase in
   multi-homing, often by customers that have very little experience
   with BGP.  In many cases the "network engineer" for the company is
   also responsible for many other aspects of technology and so cannot
   dedicate as much time and effort to the networking side as it
   deserves.  This can lead to engineers with only very rudimentary
   knowledge of BGP performing the BGP configuration.

   Even in organizations with very knowledgeable and experienced
   engineers, mistakes can (and do) still happen - for this reason, this
   document suggests a "belt and suspenders" type design, so that
   mistakes (or intentional attacks against the routing system) can be
   mitigated / avoided altogether.

   There are numerous efforts underway to address many of these issues
   in a much more automated and secure manner, such as the work in the
   SIDR (Secure Inter-Domain Routing) Working Group.  This document
   exists to provide a solution until these efforts are deployed, and
   addresses some issues that they do not.

   (TODO(WK): Consider inserting some examples like YT/Pakistan Tele,
   AS7007 ?).

Kumari                  Expires December 3, 2010                [Page 5]
Internet-Draft           Filtering BGP Customers.               June 2010

4.  Recommendations

   [TODO(WK): This is a place holder for all recommendations.  For each
   recommendations, list: Title.  Brief description, Pros / Cons,
   Applicability.

   1.  Filter to deny your own / infrastructure space.

   2.  Filter to deny your own AS(s) -- DONE

   3.  Filter to only permit the customer space.

   4.  Filter out bogons (TODO(WK): Insert *scary* text re: not keeping
       bogons up to date.  Consider just removing any mention of this!).
       -- DONE

   5.  Filter to only allow the customer AS.

   6.  Implement something like max-prefixes (TODO(WK): Figure out
       vendor independent name) -- DONE

   7.  Route-filter to only allow ASPATH of < 10 (TODO(WK): Pick a
       number) -- Kinda

Kumari                  Expires December 3, 2010                [Page 6]
Internet-Draft           Filtering BGP Customers.               June 2010

5.  Other recommendations, probably in a different doc

   1.  GTSM / BGP TTL hack.

   2.  Juniper's "configured neighbors" prefix list thing.

   3.  MD5's?!  Point to KARP? something...

Kumari                  Expires December 3, 2010                [Page 7]
Internet-Draft           Filtering BGP Customers.               June 2010

6.  Deny versus Warning

   While providers can craft filters that only allow customers to make a
   very restricted set of announcements, it is sometimes preferable to
   craft slightly less draconian filters to allow a slightly larger set
   of announcements and then follow up with the customer to check if
   what they are announcing is what they intended to announce.
   [TODO(WK): Add something about nipping problems in the bud and making
   things tidier.]

   This can be accomplished by marking announcements that may indicate
   the existence of an issue with a chosen community (which we will
   refer to as the "Warning Community") and then monitoring for routes
   tagged with that community.  This can be done with in conjunction
   with other measures, such as tagging the suspect announcements with
   NO_ADVERTISE or NO_EXPORT, or placing them into a different routing
   instance.  In order for this technique to be effective a provider
   should monitor for routes tagged with this warning community and take
   appropriate action

   For example, if a provider has a policy that the longest prefix it
   will accept from a customer is a /24 and it receives an announcement
   for 192.0.2.0/25 it could accept the announcement and tag it with
   NO_EXPORT and its Warning Community.  A monitoring script would
   detect these routes and generate an alert so that the provider could
   contact the customer to determine if this was an error or if the
   customer intended to make this announcement.  This may be preferable
   to just denying the announcement as it allows the root issue to be
   resolved.  By addressing the root issue (as opposed to just
   mitigating symptoms) we end up with a cleaner network, which makes
   future troubleshooting easier.  Fixing the problem also decrease the
   impact if the provider "drops filters" temporarily (for example
   during troubleshooting).

Kumari                  Expires December 3, 2010                [Page 8]
Internet-Draft           Filtering BGP Customers.               June 2010

7.  AS Path filtering

   Filtering of customers announcements can be performed in many ways,
   but the two primary methods are by filtering based upon
   characteristics of the AS_PATH [TODO(WK): Check capitalization /
   definition of "AS_PATH"] (AS Path filtering) and on the address
   space.  This section focuses on AS Path filtering.

7.1.  AS Path Uniformity

   In many cases a provider will know that a customer is a stub network
   and should only be announcing it's own AS number.  This can be
   enforced by applying an AS Path filter that only permits the
   customer's AS number, possibly repeated multiple times.

   This provides multiple levels of protections.  It protects the
   provider against the customer competing with the provider by selling
   transit to other entities (and so violating their contract), it
   protects against accidental leaks of routes from one provider to
   another and also protects against accidental leaks of "private" AS
   numbers[RFC1930].

   An example of a filter that only allows the customer AS is provided
   in Appendix A.1.

7.2.  AS Path Length

   While AS paths that are substantially longer than what is needed to
   perform traffic engineering are not technically incorrect they may be
   symptoms of other issues.  For example, if Customer A is multihomed
   to both Provider B and Provider C (both large, well connected
   providers), then Customer A can achieve traffic engineering by
   prepending N+1 times, where N is the number of ASs between Provider B
   and Provider C. If Customer A is prepending many more times than
   this, it is likely an error, or Customer A needs a little help
   understanding how prepending works.

   This is an example of where tagging these routes with a Warning
   Community may help.

7.3.  Filter your own AS number

   Depending on the size of a customer and how many other networks they
   peer with, it may be difficult to determine what all AS numbers they
   may be announcing to you.  One thing that you can be certain of
   though is that they should never be announcing your own AS to you.
   While the standard BGP loop prevention algorithm *should* protect you
   from ever accepting an update with your own AS in it, it doesn't hurt

Kumari                  Expires December 3, 2010                [Page 9]
Internet-Draft           Filtering BGP Customers.               June 2010

   to be extra careful (some implementations allow you to relax the
   rule, and some providers use multiple AS numbers).

   This can by done by simply crafting an AS_PATH regular expression
   that macthes your Authonomous System number and denying any update
   that contains this.

7.4.  Max-prefixes

   The max-prefixes knob allows a provider to set a limit on how many
   prefixes it will accept over a peering session.  This can be a very
   useful tool and can prevent a large range of issues.  If a provider
   knows that its customer will only announce a single prefix, it can
   set max-prefix to one or two.  If the customer accidenatlly
   redistributes thier IGP into BGP, the max-prefixes limit will kick in
   and drop the peerin session.  If the customer sends a large number (a
   few hundred or thousands), it is good practice to monitor how many
   prefixes the customer sends, and set max-prefixes to be some
   percentage higher than the current number.  Some vendors allow
   setting of two limits, a lower limit at which the router will log a
   warning message, and a higher limit at which the session will be shut
   down.

Kumari                  Expires December 3, 2010               [Page 10]
Internet-Draft           Filtering BGP Customers.               June 2010

8.  Address space filtering

8.1.  Deny own IP Space

   In many cases customers are assigned address space by their provider,
   which often means that the customer is using address space that is
   "similar" to space used by the provider.  By "similar" we mean that
   the customer is using a subnet (longer prefix) of the providers
   space, or that a simple typing mistake could cause the customer to
   accidentally use the same space as the provider.  And example of this
   would be if the provider assigned 10.0.10.0/24 to the customer and
   the customer accidentally configured 10.0.10.0/20 or 10.10.0.0/24.

   It is a good practice to address network (and similar) infrastructure
   out of blocks set aside for this purpose.  This allows the
   application of access lists (or filters) to protects this
   infrastructure and only allow access from authorized locations.  By
   applying BGP prefix list filters to prevent learning external routes
   to ones own infrastructure space, one can avoid learning (and
   following) hijacked space to devices outsides one's network.

8.2.  Deny Bogons

   This section should be approached with dicipline!  Bogons are
   addresses that you know are not currently valid addresses for use on
   the Internet.  This includes addresses that have not yet been
   allocated, Special Use Addresses ([RFC5735][RFC5156]), example
   addresses and similar.  It is simple to filter out announcements with
   these address, but if this is done, one MUST ensure that you keep up
   to date with this.  There have been amlost as many issues with Bogon
   filters being deployed and not kept up to date as there have been
   from not having Bogon filters at all.

Kumari                  Expires December 3, 2010               [Page 11]
Internet-Draft           Filtering BGP Customers.               June 2010

9.  Acknowledgements

   I would like to thank the IETF community for making me feel welcome -
   some of my best friendships have been a direct result of the IETF.  I
   would like to thank Google for 20% time and allowing me to work in
   this space.  [This space for rent.]

Kumari                  Expires December 3, 2010               [Page 12]
Internet-Draft           Filtering BGP Customers.               June 2010

10.  Security Considerations

10.1.  Privacy

   TODO(WK) -- Fill this in!

Kumari                  Expires December 3, 2010               [Page 13]
Internet-Draft           Filtering BGP Customers.               June 2010

11.  IANA Considerations

   No action required.

Kumari                  Expires December 3, 2010               [Page 14]
Internet-Draft           Filtering BGP Customers.               June 2010

12.  Normative References

   [RFC1930]  Hawkinson, J. and T. Bates, "Guidelines for creation,
              selection, and registration of an Autonomous System (AS)",
              BCP 6, RFC 1930, March 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5156]  Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156,
              April 2008.

   [RFC5735]  Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
              BCP 153, RFC 5735, January 2010.

Kumari                  Expires December 3, 2010               [Page 15]
Internet-Draft           Filtering BGP Customers.               June 2010

Author's Address

   Warren Kumari
   Google
   1600 Amphitheater Parkway
   Mountain View, CA  94043
   US

   Email: [email-masked]

Kumari                  Expires December 3, 2010               [Page 16]