Network Working Group S. Bellovin
Internet-Draft Columbia University
Intended status: Standards Track R. Bush
Expires: August 2, 2011 Internet Initiative Japan, Inc.
D. Ward
Juniper Networks
January 29, 2011
Security Requirements for BGP Path Validation
draft-ymbk-bgpsec-reqs-00
Abstract
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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 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 August 2, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Bellovin, et al. Expires August 2, 2011 [Page 1]
Internet-Draft Requirements for BGP Path Validation January 2011
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Recommended Reading . . . . . . . . . . . . . . . . . . . . . . 3
3. General Requirements . . . . . . . . . . . . . . . . . . . . . 3
4. BGP UPDATE Security Requirements . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Bellovin, et al. Expires August 2, 2011 [Page 2]
Internet-Draft Requirements for BGP Path Validation January 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 future BGP
security protocol, herein termed BGPsec, intended to satisfy these
gaps.
The threat model assumed here is documented in [RFC4593] and
[I-D.kent-bgpsec-threats].
The output of a router applying BGPsec to a received signed
announcement is either Valid or Unverified. There are no shades of
grey.
2. Recommended Reading
This document assumes knowledge of the RPKI see [I-D.ietf-sidr-arch],
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
[I-D.ietf-sidr-pfx-validate].
3. General Requirements
The following are general requirements for a BGPsec protocol:
3.1 A BGPsec design MUST be able to be incrementally deployed on
today's Internet.
3.2 A BGPsec design proposal MUST provide analysis of the
operational considerations for deployment and particularly of
incremental deployment, e.g, contiguous islands, non-contiguous
islands, universal deployment, etc..
3.3 As cryptographic payloads and loading on routers are likely to
seriously increase, a BGPsec design may require use of new
hardware. It must be possible to build routers that do BGPsec
with within acceptable (to operators) bounds of cost and
performance.
Bellovin, et al. Expires August 2, 2011 [Page 3]
Internet-Draft Requirements for BGP Path Validation January 2011
3.4 A BGPsec design need not prevent attacks on data plane traffic.
It need not assure that the data plane even follows the control
plane.
3.5 A BGPsec design MUST resist attacks by an enemy who has access
to the link layer, per Section 3.1.1.2 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.6 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.7 If message signing increases message size, the 4096 byte limit
on BGP PDU size MAY be removed.
3.8 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.9 If a BGPsec design uses signed NLRIs, it need NOT handle
multiple NLRIs in a single UPDATE, given the impossibility of
splitting a signed message while preserving the signature.
3.10 A BGPsec design MUST enable each BGPsec speaker to configure
use of the security mechanism on a per-peer basis.
3.11 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.
3.12 A BGPsec design MUST allow local policy to determine the trust
level for a specific route so that routing preference and
policy can be applied to its inclusion in the RIB. Such
mechanisms MUST conform with [I-D.ietf-sidr-ltamgmt].
3.13 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,
[I-D.ietf-sidr-ltamgmt].
Bellovin, et al. Expires August 2, 2011 [Page 4]
Internet-Draft Requirements for BGP Path Validation January 2011
3.14 A BGPsec design MUST NOT require operators to reveal
proprietary data. This includes peering, customer, and
provider relationships, an ISP's internal infrastructure, etc.
Though it is understood that some data are revealed to the
savvy seeker by BGP, traceroute, etc. today.
3.15 A BGPsec design document SHOULD note security events that are
significant enough that they should be logged. The specific
data to be logged are an implementation matter.
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 UPDATE.
4.2 A BGPsec design MUST enable the recipient of an UPDATE to
formally determine that the UPDATE has traversed the AS path
indicated in the UPADTE. 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 Contents of the UPDATE message SHOULD be able to be
authenticated in real-time as the message is processed.
4.5 The routing information base MAY also be re-authenticated
periodically or in an event-driven manner, especially in
response to events such as, for example. PKI updates.
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
an UPDATE was received.
5. IANA Considerations
This document asks nothing of the IANA.
Bellovin, et al. Expires August 2, 2011 [Page 5]
Internet-Draft Requirements for BGP Path Validation January 2011
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, Steve Kent, Sandy Murphy,
John Scudder, and a number of others.
8. References
8.1. Normative References
[I-D.kent-bgpsec-threats]
Kent, S., "Threat Model for BGP Path Security",
draft-kent-bgpsec-threats-00 (work in progress),
January 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
[I-D.ietf-rpsec-bgpsecrec]
Christian, B. and T. Tauber, "BGP Security Requirements",
draft-ietf-rpsec-bgpsecrec-10 (work in progress),
November 2008.
[I-D.ietf-sidr-arch]
Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", draft-ietf-sidr-arch-11 (work in
progress), September 2010.
[I-D.ietf-sidr-ltamgmt]
Kent, S. and M. Reynolds, "Local Trust Anchor Management
for the Resource Public Key Infrastructure",
Bellovin, et al. Expires August 2, 2011 [Page 6]
Internet-Draft Requirements for BGP Path Validation January 2011
draft-ietf-sidr-ltamgmt-00 (work in progress),
November 2010.
[I-D.ietf-sidr-pfx-validate]
Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation",
draft-ietf-sidr-pfx-validate-00 (work in progress),
July 2010.
[I-D.ietf-sidr-repos-struct]
Huston, G., Loomans, R., and G. Michaelson, "A Profile for
Resource Certificate Repository Structure",
draft-ietf-sidr-repos-struct-06 (work in progress),
November 2010.
[I-D.ietf-sidr-roa-format]
Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)",
draft-ietf-sidr-roa-format-09 (work in progress),
November 2010.
[I-D.ietf-sidr-rpki-rtr]
Bush, R. and R. Austein, "The RPKI/Router Protocol",
draft-ietf-sidr-rpki-rtr-07 (work in progress),
January 2011.
[I-D.wkumari-deprecate-as-sets]
Kumari, W., "Deprecation of BGP AS_SET, AS_CONFED_SET.",
draft-wkumari-deprecate-as-sets-01 (work in progress),
September 2010.
[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.
Bellovin, et al. Expires August 2, 2011 [Page 7]
Internet-Draft Requirements for BGP Path Validation January 2011
Authors' Addresses
Steven M. Bellovin
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, New York 10027
US
Phone: +1 212 939 7149
Email: bellovin@acm.org
Randy Bush
Internet Initiative Japan, Inc.
5147 Crystal Springs
Bainbridge Island, Washington 98110
US
Phone: +1 206 780 0431 x1
Email: randy@psg.com
Dave Ward
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, California 94089-1206
US
Phone: +1-408-745-2000
Email: dward@juniper.net
Bellovin, et al. Expires August 2, 2011 [Page 8]