Internet DRAFT - draft-christian-bgpsecrec
draft-christian-bgpsecrec
Routing Protocol Security B. Christian
Requirements KMC Telecom Solutions
Internet-Draft B. Akyol
Expires: December 30, 2004 R. White
Cisco Systems
J. Haas
Next Hop Technologies
S. Murphy
Trusted Information Systems
July 2004
BGP Security Requirements
draft-christian-bgpsecrec-01
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, in accordance with Section 6 of RFC
3668.
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 December 30, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
The security of BGP is critical to the continued health and well
being of internetworking. While securing a link between two BGP
peers is a relatively easy technical matter, the manner in which to
Christian, et al. Expires December 30, 2004 [Page 1]
Internet-Draft BGP Security Requirements July 2004
do so is not standard. Additionally, a secure link does not provide
security or authentication of the routes updates themselves. In this
document, we describe a set of requirements for securing BGP, both in
the areas of peering relationships and prefix authentication.
Christian, et al. Expires December 30, 2004 [Page 2]
Internet-Draft BGP Security Requirements July 2004
1. Introduction
Threats to networking protocols generally fall under one of the three
categories as defined in RFC 2196:
o Unauthorized access to resources and/or information
o Unintended and/or unauthorized disclosure of information
o Denial of service
A number of attacks can be realized which, if exploited, can lead to
one of the above mentioned threats. These are typically classified
as passive attacks and active attacks. Passive attacks are ones
where an attacker simply reads information off the network and
obtains confidential and/or private information. Active attacks are
ones where the attacker writes data to the network and can include
replay attacks, message insertion, message deletion, message
modification and man-in-the-middle attacks. Often, these attacks are
combined as in the instance where a forged BGP packet is injected
into a BGP routing infrastructure to force a particular data path for
traffic that can then be sniffed and used for further destructive
behavior.
Some of the attacks against normal BGP protocol behavior can be
difficult to recognize or prevent and these fall outside of the scope
of this document. Protecting against an attack where an end-system
has been compromised is also extremely difficult although wherever
possible the requirements will attempt to minimize the extent of the
damage under these circumstances.
The intent of this requirements document is to prevent attacks that
originate false data or create invalid routing paths and therefore
addresses issues relating to data integrity and peer entity
authentication. As described in RFC 3552, data integrity protection
ensures that data is not modified in transit and peer entity
authentication ensures that there is a reasonable guarantee that the
sender and recipient of the data are the intended parties.
The guarantee of packet delivery is not part of the BGP protocol
security model. Just because a packet is addressed to a specific
peer does not mean it will be received, even with a "secure" route.
For example: an attacker could have compromised an intermediate
router and installed a static route for target address A.B.C.D
pointing to an inappropriate direction or an attacker might splice
into a circuit between two secure routers and install a device that
diverts A.B.C.D traffic without requiring the compromise of control
plane devices.
Christian, et al. Expires December 30, 2004 [Page 3]
Internet-Draft BGP Security Requirements July 2004
2. Definition of Verifiable
For the purposes of this document the word verifiable indicates the
ability to determine through algorithmic means whether a unit of
information is correct.
Christian, et al. Expires December 30, 2004 [Page 4]
Internet-Draft BGP Security Requirements July 2004
3. Incremental Deployments Requirements
The following attributes of BGP SHOULD be preserved with a security
mechanism in place:
o BGP's convergence speed, with a security system in operation,
SHOULD be equivalent to or faster than BGP running without the
security system in operation. This includes the preservation of
optimizations currently used to produce acceptable convergence
speeds on current hardware, including update packing, peer groups,
and others.
o Current timers, including hold timers, keepalive timers, and the
peering process, SHOULD NOT be impacted by the security system.
o BGP SHOULD support both secured and unsecured routes with the
security system in place.
o The security system MUST support a range of possible outputs for
local determination of the trust level for a specific route. Any
given route should be trustable to a locally configured degree,
based on the completeness of security information for the update
and other factors.
o The security system SHOULD allow the operator to determine whether
the speed of convergence is more important than security
operations, or security operations are more important than the
speed of convergence. This facilitates the incremental deployment
of security on systems not designed to support increased
processing requirements imposed by the security system.
Network recovery times for secured routing as well as unsecured
routing SHOULD work with similar speed and SHOULD perform with
equivalent, or greater, rapidity than legacy routing methods.
Unsecured routing of secured prefixes MUST be supported so that a mix
of secured and unsecured routing paths will provide security for the
prefixes that have security features applied, but will not penalize
or preempt "normal" prefixes.
Christian, et al. Expires December 30, 2004 [Page 5]
Internet-Draft BGP Security Requirements July 2004
4. Trust Models
4.1 Trust Model Examples
One example of a trust model is a distributed trust system.
Inter-domain routing as implemented today is based on the concept of
distributed trust. There is no central authority; each AS is free to
choose whom to trust and whom to avoid placing trust in. This model
is expressed through the filtering of routing information received
from BGP peers. Financial contracts and business arrangements play a
large role in how an AS chooses to filter their peers.
A second trust model is a hierarchical system much like how root
certificates for SSL/TLS are distributed today. In this model, a
central authority controls all information. For example, all address
allocations are authenticated and signed by ICANN, then by a regional
registry, then a large ISP, a small ISP, etc. ICANN serves as the
root of the address allocation system. This type of trust is usually
referred to as a strict hierarchical trust model or a chain of trust.
4.2 Trust Model Recommendation
While there are a number of trust models available, a distributed
trust mechanism lends itself well to the current model used
throughout the various networks and internetworks making up the
public Internet and other large scale internetworks.
In the public Internet today, larger service providers trust each
other to appropriately deploy edge based filtering mechanisms to
protect the Internet as a whole and to protect sensitive inter-
provider peering sessions. These peering relationships, with their
interprovider legal contracts and partnerships, are comparable to the
relationships established within the PGP web of trust.
The establishment of a distributed trust mechanism allows operators
to make their own decisions about the level with which they trust
their peers and their customers. Operators may choose to honor, or
create, a strict hierarchy of trust up to the level of numbering
authority within the distributed model if so desired.
A distributed trust model that allows for varying levels of trust
based on operator input and a trust hierarchy MUST be supported. The
distributed trust model SHOULD allow for a strict hierarchy to root
authorities if desired.
Christian, et al. Expires December 30, 2004 [Page 6]
Internet-Draft BGP Security Requirements July 2004
5. Path Attributes and NLRI Authentication
BGP distributes routing information across the Internet (between BGP
speakers) using the BGP UPDATE messages. The UPDATE message contains
withdrawn routes, path attributes and one or more NLRIs. For the
remainder of this section, we will focus on Path Attributes and the
NLRI.
The AS_PATH for specific prefixes must be protected in any proposed
security system in three ways:
o Authorization of Originating AS: For all prefixes announced in
BGP, the originating AS MUST be verifiable through the trust model
as the authorized announcer of the prefix. The verification
mechanism must account for existing BGP mechanisms such as
summarization.
o The AS_PATH list MUST correspond to a verifiable list of
autonomous systems based on the peering topology of the network.
o Announcing AS Check: For all BGP peers, a BGP Implementation MUST
ensure that the first element of the AS_PATH list corresponds to
the locally configured AS of that peer.
Since BGP is a stateful routing protocol, the timeliness and
freshness of reachability updates are critical for consistent routing
state within the BGP routing system. To this end, there MUST be a
mechanism to ensure that changes to reachability that result in an
explicit or implicit withdrawal of reachability (RFC1771) are
propagated within the secured BGP routing system in a timely manner.
Two types of verification MAY be offered for the NLRI and the
AS_PATH:
o Contents of the UPDATE message SHOULD be authenticated in
real-time as the UPDATE message is processed.
o The route information base MAY be authenticated periodically or in
an event driven manner by scanning the data and verifying the
originating AS and the verifiability of the AS-PATH list.
All BGP implementations that implement security MUST utilize at least
one of the above methods for validating routing information. Real
time verification is preferred in order to prevent transitive
failures based on periodic or event driven scan intervals.
The originating AS of a prefix may occasionally need to be changed
either due to a re-assignment or a network transition. Any BGP
security mechanism MUST support the change of an originating AS for a
prefix within normal convergence times of the internetwork.
Christian, et al. Expires December 30, 2004 [Page 7]
Internet-Draft BGP Security Requirements July 2004
5.1 Address Allocation
As part of the regular operation of the Internet, addresses that are
allocated to an organization may be advertised by a different
organization. Common reasons for this practice include multi-homing
and route reduction for the purposes of resource conservation. There
are two modes of delegation:
o Mode 1 Delegation: In this mode, a BGP speaker and listener have
chosen to restrict the amount of received prefixes for the
listener. The listener has chosen to honor route announcements
sent in a summary fashion by the speaker.
o Mode 2 Delegation: In this mode, the address space that is being
delegated is part of a larger allocation that is owned by an
autonomous system. The owner then delegates the smaller block to
another AS for purposes of advertisement. This mode is commonly
observed in multi-homing.
These two modes lead to a single common requirement: Any BGP Security
solution MUST support delegation of an address block of any size
regardless of its relationship to other address blocks to another
entity via verifiable means.
An associated delegation criteria is the requirement to allow for
non-BGP IP end user implementations. As a result, all secured BGP
implementations MUST allow for the propagation of a prefix by more
than one originator AS.
Christian, et al. Expires December 30, 2004 [Page 8]
Internet-Draft BGP Security Requirements July 2004
6. NLRI and Path Attribute Tracking
Non-repudiation of a routing update, the ability for a receiver to
know exactly who originated and forwarded a routing update, is a
desirable trait. This document doesn't make any claims about the
technical ability to actually deploy non-reputable security in
various networks, including the public Internet, but we do believe
non-repudiation to be an important goal.
Any security system SHOULD provide some method to allow the receiver
of an UPDATE to verify that the originator actually originated the
UPDATE, and the AS's listed in the AS_PATH actually forwarded it.
The data generated by logging may be very large depending on the
number of peers, the number of prefixes received, the authentication
model used and routing policies.
Path and NLRI attributes MUST be logged using a standard format. The
format must be scalable with the amount of data logged and the
frequency of log generation. The frequency of log generation should
be controllable by the operator. The logging mechanisms for the
tracked information MUST be standardized across all platforms.
Logging ability both on and off line is considered highly desirable.
Christian, et al. Expires December 30, 2004 [Page 9]
Internet-Draft BGP Security Requirements July 2004
7. Transport Protection
Transport protection is an aspect of BGP routing protocol security
and provides the potential for a linked transport/prefix
authentication mechanism. This section discusses transport security
requirements for BGP and covers peering and authentication of
peering.
Any proposed security mechanism MUST include provisions for
authenticating both iBGP and eBGP peering sessions. Examples of
session security mechanisms include TCP-MD5 and IPSec, though
possible security alternatives are not limited to those two.
Transport protection systems SHOULD function as a component of the
BGP routing protocol security mechanism. This includes the use of
the same key generation/management systems as the rest of the
security system.
Authors' Addresses
Blaine Christian
KMC Telecom Solutions
305 Church Street Suite 715
Huntsville, AL 35801
US
Bora Akyol
Cisco Systems
170 Tasman Drive
San Jose, CA 95134
US
Russ White
Cisco Systems
7025 Kit Creek Road
Research Triangle Park, NC 95134
US
Jeffrey Haas
Next Hop Technologies
825 Victors Way Suite 100
Ann Arbor, MI 48108
US
Christian, et al. Expires December 30, 2004 [Page 10]
Internet-Draft BGP Security Requirements July 2004
Sandy Murphy
Trusted Information Systems
3060 Washington Road
Glenwood, MD 21378
US
Christian, et al. Expires December 30, 2004 [Page 11]
Internet-Draft BGP Security Requirements July 2004
Appendix A. Acknowledgements
The following individuals contributed to the development and review
of this draft. Mike Tibodeau, Thomas Renzy, Kaarthik Sivakumar, Tao
Wan, Radia Perlman, and Merike Kaeo.
This draft was developed based on conversations with various network
operators including Chris Morrow, Jared Mauch, Tim Battles, and Ryan
McDowell.
Christian, et al. Expires December 30, 2004 [Page 12]
Internet-Draft BGP Security Requirements July 2004
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Christian, et al. Expires December 30, 2004 [Page 13]
