Subject: Re: [OPSEC] ISP BGP filtering draft.

From: David Barak <[email-masked]>
Date: Wed, 25 May 2011 13:50:46 -0700 (PDT)

I&#39;ll take a swing at it.

-David Barak

---

From: Warren Kumari <[email-masked]>
Date: Thu, 26 May 2011 13:20:40 -0400

On May 25, 2011, at 4:50 PM, David Barak wrote:

> I'll take a swing at it.

Yay! Thank you....

It's currently living on an SVN server -- the repository is: 

SVN: https://svn.kumari.net/svn/opsec
Username: davidbarak
Password: raiL4oP0

Please note: The https:// in the repository URL is important. If you just do http:// apache will try send you a redirect and SVN will get grumpy.
This repository is configured for anonymous read, but requires a PW for making changes.

I wasn't sure what username you use, so I randomly picked davidbarak, and pwgen chose the password for you. 
Feel free to tell me a different username and / or provide a htdigest style password and I'll update it...

W

> 
> -David Barak
> 
> From: Warren Kumari <[email-masked]>; 
> To: <[email-masked]>; 
> Subject: [OPSEC] ISP BGP filtering draft. 
> Sent: Wed, May 25, 2011 1:19:10 PM 
> 
> 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]
> 
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec

---

From: Warren Kumari <[email-masked]>
Date: Thu, 26 May 2011 13:32:02 -0400

And, obviously enough I didn't mean to send the credentials to the list :-) I have some folk doing construction at home today, and was horribly distracted -- that'll teach me to send mail while not paying attention....

I have just changed them and will *unicast* them to David....

W