Network Working Group                                        S. Bellovin
Internet-Draft                                       Columbia University
Intended status: Standards Track                                 R. Bush
Expires: September 8, 2011               Internet Initiative Japan, Inc.
                                                                 D. Ward
                                                        Juniper Networks
                                                           March 7, 2011

             Security Requirements for BGP Path Validation


   This document describes requirements for a future BGP security
   protocol design to provide cryptographic assurance that the origin AS
   had the right to announce the prefix and to provide assurance of the
   AS Path of the announcement.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may not be modified,
   and derivative works of it may not be created, and it may not be
   published except as an Internet-Draft.

   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

   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 September 8, 2011.

Copyright Notice

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

Bellovin, et al.        Expires September 8, 2011               [Page 1]

Internet-Draft    Requirements for BGP Path Validation        March 2011

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Recommended Reading . . . . . . . . . . . . . . . . . . . . . . 3
   3.  General Requirements  . . . . . . . . . . . . . . . . . . . . . 3
   4.  BGP UPDATE Security Requirements  . . . . . . . . . . . . . . . 5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8

Bellovin, et al.        Expires September 8, 2011               [Page 2]

Internet-Draft    Requirements for BGP Path Validation        March 2011

1.  Introduction

   RPKI-based Origin Validation ([I-D.ietf-sidr-pfx-validate]) provides
   a measure of resilience to accidental mis-origination of prefixes.
   But it provides neither cryptographic assurance (announcements are
   not signed), nor assurance of the AS Path of the announcement.

   This document describes requirements to be placed on a BGP security
   protocol, herein termed BGPsec, intended to rectify these gaps.

   The threat model assumed here is documented in [RFC4593] and

2.  Recommended Reading

   This document assumes knowledge of the RPKI see [I-D.ietf-sidr-arch]
   and the RPKI Repository Structure, see [I-D.ietf-sidr-repos-struct].

   This document assumes ongoing incremental deployment of ROAs, see
   [I-D.ietf-sidr-roa-format], the RPKI to Router Protocol, see
   [I-D.ietf-sidr-rpki-rtr], and RPKI-based Prefix Validation, see

   And, of course, a knowledge of BGP [RFC4271] is required.

3.  General Requirements

   The following are general requirements for a BGPsec protocol:

   3.1   A BGPsec design must allow the receiver of a BGP announcement
         to determine, to a strong level of certainty, that the received
         PATH attribute accurately represents the sequence of eBGP
         exchanges that propagated the prefix from the origin AS to the

   3.2   A BGPsec design MUST be amenable to incremental deployment.
         Any incompatible protocol capabilities MUST be negotiated.

   3.3   A BGPsec design MUST provide analysis of the operational
         considerations for deployment and particularly of incremental
         deployment, e.g, contiguous islands, non-contiguous islands,
         universal deployment, etc..

Bellovin, et al.        Expires September 8, 2011               [Page 3]

Internet-Draft    Requirements for BGP Path Validation        March 2011

   3.4   As cryptographic payloads and memory requirements on routers
         are likely to increase, a BGPsec design MAY require use of new
         hardware.  I.e. compatibility with current hardware abilities
         is not a requirement that this document imposes on a solution.
         As BGPsec will likely not be rolled out for some years, this
         should not be a major problem.

   3.5   A BGPsec design need not prevent attacks on data plane traffic.
         It need not provide assurance that the data plane even follows
         the control plane.

   3.6   A BGPsec design MUST resist attacks by an enemy who has access
         to the link layer, per Section of [RFC4593].  In
         particular, such a design must provide mechanisms for
         authentication of all data, including protecting against
         message insertion, deletion, modification, or replay.
         Mechanisms that suffice include TCP sessions authenticated with
         IPsec [RFC4301] or TLS [RFC5246].

   3.7   A BGPsec design MAY make use of a security infrastructure
         (e.g., a PKI) to distribute authenticated data used as input to
         routing decisions.  Such data include information about
         holdings of address space and ASNs, and assertions about
         binding of address space to ASNs.

   3.8   If message signing increases message size, the 4096 byte limit
         on BGP PDU size MAY be removed.

   3.9   It is entirely OPTIONAL to secure AS SETs and prefix
         aggregation.  The long range solution to this is the
         deprecation of AS-SETs, see [I-D.wkumari-deprecate-as-sets].

   3.10  If a BGPsec design uses signed prefixes, given the difficulty
         of splitting a signed message while preserving the signature,
         it need NOT handle multiple prefixes in a single UPDATE PDU.

   3.11  A BGPsec design MUST enable each BGPsec speaker to configure
         use of the security mechanism on a per-peer basis.

   3.12  A BGPsec design MUST provide backward compatibility in the
         message formatting, transmission, and processing of routing
         information carried through a mixed security environment.
         Message formatting in a fully secured environment MAY be
         handled in a non-backward compatible manner.

Bellovin, et al.        Expires September 8, 2011               [Page 4]

Internet-Draft    Requirements for BGP Path Validation        March 2011

   3.13  While the trust level of an NLRI should be determined by the
         BGPsec protocol, local routing preference and policy MUST then
         be applied to best path and other decisions.  Such mechanisms
         MUST conform with [I-D.ietf-sidr-ltamgmt].

   3.14  If a BGPsec design makes use of a security infrastructure, that
         infrastructure SHOULD enable each network operator to select
         the entities it will trust when authenticating data in the
         security infrastructure.  See, for example,

   3.15  A BGPsec design MUST NOT require operators to reveal more than
         is currently revealed in the operational inter-domain routing
         environment, other than the inclusion of necessary security
         credentials to allow others to ascertain for themselves the
         necessary degree of assurance regarding the validity of NLRI
         received via BGPsec.  This includes peering, customer, and
         provider relationships, an ISP's internal infrastructure, etc.
         It is understood that some data are revealed to the savvy
         seeker by BGP, traceroute, etc. today.

   3.16  A BGPsec design SHOULD flag security exceptions which are
         significant enough to be logged.  The specific data to be
         logged are an implementation matter.

   3.17  Any routing information database MAY be re-authenticated
         periodically or in an event-driven manner, especially in
         response to events such as, for example, PKI updates.

   3.18  Should a BGPsec design use hashes or signatures, it should
         provide mechanisms for algorithm agility.

   3.19  A BGPsec design SHOULD NOT presume to know the intent of the
         originator of a NLRI, nor that of any AS on the AS Path.

   3.20  A BGP listener SHOULD NOT trust non-BGPsec markings, such as
         communities, across trust boundaries.

4.  BGP UPDATE Security Requirements

   The following requirements MUST be met in the processing of BGP
   UPDATE messages:

   4.1  A BGPsec design MUST enable each recipient of an UPDATE to
        formally validate that the origin AS in the message is
        authorized to originate a route to the prefix(es) in the

Bellovin, et al.        Expires September 8, 2011               [Page 5]

Internet-Draft    Requirements for BGP Path Validation        March 2011

   4.2  A BGPsec design MUST enable the recipient of an UPDATE to
        formally determine that the NLRI has traversed the AS path
        indicated in the UPDATE.  Note that this is more stringent than
        showing that the path is merely not impossible.

   4.3  Replay of BGP UPDATE messages need not be completely prevented,
        but a BGPsec design MUST provide a mechanism to control the
        window of exposure to replay attacks.

   4.4  A BGPsec design SHOULD provide some level of assurance that the
        origin of a prefix is still 'alive', i.e. that a monkey in the
        middle has not withheld a WITHDRAW message or the effects

   4.5  NLRI of the UPDATE message SHOULD be able to be authenticated in
        real-time as the message is processed.

   4.6  Normal sanity checks of received announcements MUST be done,
        e.g. verification that the first element of the AS_PATH list
        corresponds to the locally configured AS of the peer from which
        the UPDATE was received.

   4.7  The output of a router applying BGPsec to a received signed
        UPDATE MUST be either Valid or Unverified.  There should be no
        shades of grey.

5.  IANA Considerations

   This document asks nothing of the IANA.

6.  Security Considerations

   The data plane may not follow the control plane.

   Security for subscriber traffic is outside the scope of this
   document, and of BGP security in general.  IETF standards for payload
   data security should be employed.  While adoption of BGP security
   measures may ameliorate some classes of attacks on traffic, these
   measures are not a substitute for use of subscriber-based security.

7.  Acknowledgments

   The author wishes to thank the authors of [I-D.ietf-rpsec-bgpsecrec]
   from whom we liberally stole, Russ Housley, Geoff Huston, Steve Kent,
   Sandy Murphy, John Scudder, Sam Weiler, and a number of others.

Bellovin, et al.        Expires September 8, 2011               [Page 6]

Internet-Draft    Requirements for BGP Path Validation        March 2011

8.  References

8.1.  Normative References

              Kent, S., "Threat Model for BGP Path Security",
              draft-kent-bgpsec-threats-01 (work in progress),
              February 2011.

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

   [RFC4593]  Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
              Routing Protocols", RFC 4593, October 2006.

8.2.  Informative References

              Christian, B. and T. Tauber, "BGP Security Requirements",
              draft-ietf-rpsec-bgpsecrec-10 (work in progress),
              November 2008.

              Lepinski, M. and S. Kent, "An Infrastructure to Support
              Secure Internet Routing", draft-ietf-sidr-arch-12 (work in
              progress), February 2011.

              Kent, S. and M. Reynolds, "Local Trust Anchor Management
              for the Resource Public Key Infrastructure",
              draft-ietf-sidr-ltamgmt-00 (work in progress),
              November 2010.

              Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
              Austein, "BGP Prefix Origin Validation",
              draft-ietf-sidr-pfx-validate-01 (work in progress),
              February 2011.

              Huston, G., Loomans, R., and G. Michaelson, "A Profile for
              Resource Certificate Repository Structure",
              draft-ietf-sidr-repos-struct-07 (work in progress),
              February 2011.

              Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
              Origin Authorizations (ROAs)",

Bellovin, et al.        Expires September 8, 2011               [Page 7]

Internet-Draft    Requirements for BGP Path Validation        March 2011

              draft-ietf-sidr-roa-format-10 (work in progress),
              February 2011.

              Bush, R. and R. Austein, "The RPKI/Router Protocol",
              draft-ietf-sidr-rpki-rtr-10 (work in progress),
              March 2011.

              Kumari, W., "Deprecation of BGP AS_SET, AS_CONFED_SET.",
              draft-wkumari-deprecate-as-sets-01 (work in progress),
              September 2010.

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

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

Authors' Addresses

   Steven M. Bellovin
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, New York  10027

   Phone: +1 212 939 7149

   Randy Bush
   Internet Initiative Japan, Inc.
   5147 Crystal Springs
   Bainbridge Island, Washington  98110

   Phone: +1 206 780 0431 x1

Bellovin, et al.        Expires September 8, 2011               [Page 8]

Internet-Draft    Requirements for BGP Path Validation        March 2011

   Dave Ward
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, California  94089-1206

   Phone: +1-408-745-2000

Bellovin, et al.        Expires September 8, 2011               [Page 9]