[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 draft-ietf-sidr-pfx-validate

Network Working Group                                  P. Mohapatra, Ed.
Internet-Draft                                             Cisco Systems
Intended status: Standards Track                         J. Scudder, Ed.
Expires: April 30, 2009                                 Juniper Networks
                                                        October 27, 2008


                      BGP Prefix Origin Validation
                  draft-pmohapat-sidr-pfx-validate-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   This Internet-Draft will expire on April 30, 2009.

Abstract

   A BGP route associates an address prefix with a set of autonomous
   systems (AS) that identify the interdomain path the prefix has
   traversed in the form of BGP announcements.  This set is represented
   as the AS_PATH attribute in BGP and starts with the AS that
   originated the prefix.  To help reduce well-known threats against BGP
   including prefix hijacking and monkey-in-the-middle attacks, one of
   the security requirements is the ability to validate the origination
   AS of BGP routes.  More specifically, one needs to validate that the
   AS number claiming to originate an address prefix (as derived from
   the AS_PATH attribute of the BGP route) is in fact authorized.  This
   document describes a simple validation mechanism to partially satisfy



Mohapatra & Scudder      Expires April 30, 2009                 [Page 1]


Internet-Draft        BGP Prefix Origin Validation          October 2008


   this requirement.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 4
   2.  Prefix-to-AS Mapping Database . . . . . . . . . . . . . . . . . 4
   3.  Changes to the BGP Decision Process . . . . . . . . . . . . . . 5
     3.1.  Policy Control  . . . . . . . . . . . . . . . . . . . . . . 6
   4.  Route Aggregation . . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Deployment Considerations . . . . . . . . . . . . . . . . . . . 6
   6.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   9.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   10. Normative References  . . . . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9
































Mohapatra & Scudder      Expires April 30, 2009                 [Page 2]


Internet-Draft        BGP Prefix Origin Validation          October 2008


1.  Introduction

   A BGP route associates an address prefix with a set of autonomous
   systems (AS) that identify the interdomain path the prefix has
   traversed in the form of BGP announcements.  This set is represented
   as the AS_PATH attribute in BGP and starts with the AS that
   originated the prefix.  To help reduce well-known threats against BGP
   including prefix hijacking and monkey-in-the-middle attacks, one of
   the security requirements is the ability to validate the origination
   AS of BGP routes.  More specifically, one needs to validate that the
   AS number claiming to originate an address prefix (as derived from
   the AS_PATH attribute of the BGP route) is in fact authorized.  This
   document describes a simple validation mechanism to partially satisfy
   this requirement.

   The Resource Public Key Infrastructure (RPKI) describes an approach
   to build a formally verifyable database of IP addresses and AS
   numbers as resources.  The overall architecture of RPKI as defined in
   [I-D.ietf-sidr-arch] consists of three main components:

   o  A public key infrastructure (PKI) with the necessary certificate
      objects,

   o  Digitally signed routing objects,

   o  A distributed repository system to hold the objects that would
      also support periodic retrieval

   The RPKI system is based on resource certificates that define
   extensions to X.509 to represent IP addresses and AS identifiers
   [RFC3779], thus the name RPKI.  Route Origin Authorizations (ROA)
   [I-D.ietf-sidr-roa-format] and possibly Bogon Origin Attestations
   (BOA) [I-D.ietf-sidr-bogons] are separate digitally signed objects
   that define positive and negative associations between ASes and IP
   address blocks.  Finally the repository system is operated in a
   distributed fashion through the IANA, RIR hierarchy, and ISPs.

   In order to benefit from the RPKI system, it is envisioned that
   relying parties either at AS or organization level obtain a local
   copy of the signed object collection, verify the signatures, and
   process them.  The cache must also be refreshed periodically.  The
   exact access mechanism used to retrieve the local cache is beyond the
   scope of this document.

   Once the cache is made local, individual BGP speakers can utilize the
   processed data to validate BGP announcements.  Again, the
   mechanism(s) to have the data available at the BGP routers is not
   defined in this document.  This document proposes a simple



Mohapatra & Scudder      Expires April 30, 2009                 [Page 3]


Internet-Draft        BGP Prefix Origin Validation          October 2008


   modification to the BGP decision process that makes use of the
   processed data from signed objects and validates prefix origination
   of received BGP UPDATE messages.

   Note that the complete path attestation against the AS_PATH attribute
   of a route is outside the scope of this document.

   Although RPKI provides the context for this draft, it is equally
   possible to use any other database which is able to map prefixes to
   their authorized origin ASes.  Each distinct database will have its
   own particular operational and security characteristics; such
   characteristics are beyond the scope of this document.

1.1.  Requirements Language

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


2.  Prefix-to-AS Mapping Database

   The resource certificates and other signed objects (e.g.  ROAs) as
   received from the RPKI repository and stored in the local cache are
   not in a suitable format to be matched against the prefixes received.
   Moreover, further processing of the objects is necessary -- e.g.  ROA
   validation is required, which involves checking against the
   corresponding EE certificate and so on up to configured trust
   anchors, presumably for the IANA and/or other registries.  But a
   validated and normalized database can be created on the router for
   efficient lookup purposes.  The primary key for this database is a
   prefix set represented as (IP prefix)/[min. length, max. length].
   The value stored against each prefix set is the set of AS numbers
   that is assigned or sub-allocated the corresponding IP address block.
   This database can be implemented as a prefix trie structure.

   Whenever UPDATEs are received from peers, a BGP speaker is expected
   to perform a lookup in this database for each of the prefixes in the
   UPDATE message.  To aid with better description, we define terms
   "UPDATE prefix" and "UPDATE origin AS number" to mean the values
   derived from the received UPDATE message, and "database prefix set"
   and "database origin AS number" to mean the values derived from the
   database lookup.  The following are the different types of results
   expected from such a lookup operation:

   o  If the prefix length of the "UPDATE prefix" is within the range of
      the most specific "database prefix set" found during the lookup,
      an exact match is declared and the "UPDATE origin AS number" is



Mohapatra & Scudder      Expires April 30, 2009                 [Page 4]


Internet-Draft        BGP Prefix Origin Validation          October 2008


      compared against the "database origin AS number set".  Depending
      on whether the UPDATE AS number is a member of the database AS set
      for that prefix, the lookup result should be returned as "valid"
      or "invalid".

   o  Due to the incremental deployment model of the RPKI repository,
      the implementation should not expect that a complete registry of
      all IP address blocks and their AS associations is available at a
      given point of time.  Thus, it is possible that a prefix set match
      is not found in the database.  In this case, the lookup result
      should simply be "not found".

   o  It is also possible that the prefix length of the "UPDATE prefix"
      is greater than the range of the most specific "database prefix
      set" found during the lookup.  According to
      [I-D.ietf-sidr-roa-format], an AS is required to originate
      prefixes only in the range specified in the corresponding ROA
      object.  Thus, if such a prefix match occurs and the "UPDATE
      origin AS number" is the same as the "database origin AS number",
      the lookup result is declared as "invalid".  However, if the AS
      numbers are not the same, the lookup result is declared as "not
      found" since it may mean that the more specific address block has
      been sub-allocated to another party and the corresponding ROA
      object is not yet present in the database.

   Depending on the lookup result, we define a property for each "UPDATE
   prefix", called as the "validity state" of the prefix.  It can assume
   the following values:

                  +-------+-----------------------------+
                  | Value | Meaning                     |
                  +-------+-----------------------------+
                  |   0   | Lookup result = "valid"     |
                  |   1   | Lookup result = "not found" |
                  |   2   | Lookup result = "invalid"   |
                  +-------+-----------------------------+

   Note that all the routes, regardless of their "validity state" will
   be stored in the local BGP speaker's Adj-RIB-In.


3.  Changes to the BGP Decision Process

   If a BGP router supports prefix validation and is configured to do
   so, the validation check MUST be performed prior to any of the steps
   defined in the decision process of [RFC4271].  The validation step is
   stated as follows:




Mohapatra & Scudder      Expires April 30, 2009                 [Page 5]


Internet-Draft        BGP Prefix Origin Validation          October 2008


      When comparing routes for a BGP destination, if both routes have
      had their "validity state" computed, the route with the lowest
      "validity state" value is preferred.

   In all other respects, the decision process remains unchanged.

3.1.  Policy Control

   It MUST be possible to enable or disable the validation step as
   defined in Section 3 through configuration.  The default SHOULD be
   for the validation step to be enabled.

   It MUST be possible to exclude routes from the BGP decision process
   based on their validation state.  In particular it is anticipated
   that it will be desirable to exclude routes from consideration when
   their validation state is "invalid"; however it may also be desirable
   to exclude routes whose validation state is "not found" as well.


4.  Route Aggregation

   When an UPDATE message carries AGGREGATOR attribute, the "UPDATE
   origin AS number" is set to the value encoded in the AGGREGATOR
   instead of being derived from the AS_PATH attribute.


5.  Deployment Considerations

   It is critical that IBGP speakers within an AS have a consistent
   routing view of the BGP destinations and do not make conflicting
   decisions regarding the BGP best path selection that might cause
   forwarding loops.  Thus, the best practice in BGP deployment does not
   run any policy on IBGP sessions which could potentially create an
   inconsistent view.  Going by the same rules, the prefix validation
   procedures SHOULD not be performed on IBGP learnt routes in an AS.
   As a general principle, prefix validation SHOULD be executed on EBGP
   boundaries.  In some cases, it may be desirable to run the validation
   on centralized route servers within an AS to offload the computation.
   Care should be taken to ensure routing consistency in such cases.


6.  Contributors

      David Ward dward@cisco.com
      Cisco Systems






Mohapatra & Scudder      Expires April 30, 2009                 [Page 6]


Internet-Draft        BGP Prefix Origin Validation          October 2008


      Rex Fernando rex@juniper.net
      Robert Raszuk raszuk@juniper.net
      Miya Kohno mkohno@juniper.net
      Juniper Networks

      Shin Miyakawa miyakawa@nttv6.jp
      Taka Mizuguchi taka@nttv6.jp
      Tomoya Yoshida yoshida@nttv6.jp
      NTT Communications

      Randy Bush randy@psg.com
      Internet Initiative Japan

      Rob Austein sra@isc.org
      ISC

      Russ Housley housley@vigilsec.com
      Vigil Security


7.  Acknowledgements


8.  IANA Considerations


9.  Security Considerations

   Although this specification discusses one portion of a system to
   validate BGP routes, it should be noted that it relies on a database
   (RPKI or other) to provide validation information.  As such, the
   security properties of that database must be considered in order to
   determine the security provided by the overall solution.  If
   "invalid" routes are blocked as this specification suggests, the
   overall system provides a possible denial-of-service vector, for
   example if an attacker is able to inject one or more spoofed records
   into the validation database which lead a good route to be declared
   invalid.  In addition, this system is only able to provide limited
   protection against a determined attacker -- the attacker need only
   prepend the "valid" source AS to a forged BGP route announcement in
   order to defeat the protection provided by this system.  This
   mechanism does not protect against "AS in the middle attacks" or
   provide any path validation.  It only attempts to verify the origin.
   In general, this system should be thought of more as a protection
   against misconfiguration than as true "security" in the strong sense.






Mohapatra & Scudder      Expires April 30, 2009                 [Page 7]


Internet-Draft        BGP Prefix Origin Validation          October 2008


10.  Normative References

   [I-D.ietf-sidr-arch]
              Lepinski, M., Kent, S., and R. Barnes, "An Infrastructure
              to Support Secure Internet Routing",
              draft-ietf-sidr-arch-03 (work in progress), February 2008.

   [I-D.ietf-sidr-bogons]
              Huston, G., Manderson, T., and G. Michaelson, "A Profile
              for Bogon Origin Attestations (BOAs)",
              draft-ietf-sidr-bogons-00 (work in progress), August 2008.

   [I-D.ietf-sidr-roa-format]
              Kent, S., "A Profile for Route Origin Authorizations
              (ROAs)", draft-ietf-sidr-roa-format-03 (work in progress),
              July 2008.

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

   [RFC3779]  Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
              Addresses and AS Identifiers", RFC 3779, June 2004.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.


Authors' Addresses

   Pradosh Mohapatra (editor)
   Cisco Systems
   170 W. Tasman Drive
   San Jose, CA  95134
   USA

   Email: pmohapat@cisco.com


   John Scudder (editor)
   Juniper Networks
   1194 N. Mathilda Ave
   Sunnyvale, CA  94089
   USA

   Email: jgs@juniper.net






Mohapatra & Scudder      Expires April 30, 2009                 [Page 8]


Internet-Draft        BGP Prefix Origin Validation          October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Mohapatra & Scudder      Expires April 30, 2009                 [Page 9]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/