Network Working Group M. Behringer
Internet-Draft Cisco
Intended status: Informational April 24, 2007
Expires: October 26, 2007
BGP Session Security Requirements
draft-behringer-bgp-session-sec-req-01.txt
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 October 26, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The document "BGP security requirements"
(draft-ietf-rpsec-bgpsecrec-07) specifies general security
requirements for BGP. However, specific security requirements for
single BGP sessions, i.e., the connection between two BGP peers, are
only touched on briefly in the section "transport layer protection".
This document expands on this particular aspect of BGP security,
defining the security requirements between two BGP peers.
Behringer Expires October 26, 2007 [Page 1]
Internet-Draft BGP Session Security Requirements April 2007
Context of this document: RPSEC WG; Charter item: "Document security
requirements for routing systems".
Table of Contents
1. Introduction and Problem Statement . . . . . . . . . . . . . . 3
2. The Threat Model . . . . . . . . . . . . . . . . . . . . . . . 4
3. BGP Session Security Requirements . . . . . . . . . . . . . . . 5
3.1. BGP Speaker Identity . . . . . . . . . . . . . . . . . . . 5
3.2. Peer Authentication . . . . . . . . . . . . . . . . . . . . 5
3.3. Integrity . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Confidentiality . . . . . . . . . . . . . . . . . . . . . . 6
3.5. Anti-Replay . . . . . . . . . . . . . . . . . . . . . . . . 6
3.6. Availability and Restricting IP Reachability . . . . . . . 6
3.7. Key Management and Operational Considerations . . . . . . . 7
3.8. Logging and Alerting . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Behringer Expires October 26, 2007 [Page 2]
Internet-Draft BGP Session Security Requirements April 2007
1. Introduction and Problem Statement
The document "BGP security requirements"
(draft-ietf-rpsec-bgpsecrec-07) specifies general security
requirements for BGP. However, specific security requirements for
single BGP sessions, i.e., the connection between two BGP peers, are
only touched on briefly in the section "transport layer protection".
This document expands on this particular aspect of BGP security,
defining the security requirements between two BGP peers.
It is important to note that security requirements between BGP peers
are not limited to the BGP protocol itself or a particular layer of
the OSI stack. Crafted ICMP messages for example may have an impact
on an established BGP session: An ICMP port unreachable, referring to
the BGP port on the peer router, would tear down the BGP session, if
no additional security meassures are taken to prevent this. A
similar effect can be achieved with ICMP source quench messages.
Some of the mechanims to secure a BGP peering are on the TCP layer
(MD5), some on the IP layer (GTSM). This document provides an
overall, practical view on the security requirements for BGP
sessions, not limited to the BGP protocol.
Previous work in this area includes most notably the following
documents:
o "Protection of BGP Sessions via the TCP MD5 Signature Option" (RFC
2385)
o "The Generalized TTL Security Mechanism (GTSM)" (RFC 3682)
o "Key Management Considerations for the TCP MD5 Signature Option"
(RFC 3562)
o "Key Change Strategies for TCP-MD5"
(draft-bellovin-keyroll2385-04)
o "Authentication for TCP-based Routing and Management Protocols"
(draft-bonica-tcp-auth-06)
o "" - draft-ietf-rpsec-bgpsecrec-06
o "" - draft-ietf-rpsec-generic-requirements-01
o "" - draft-ietf-rpsec-bgpattack-00
o "GTSM bis" - draft-ietf-rtgwg-rfc3682bis-09
o "" - draft-weis-tcp-auth-auto-ks-01.txt
Current implementations of BGP include a combination of some of these
mechanisms. However, while the security level achieved with these is
probably currently acceptable for most providers, they pose some
operational challenges which limit the effectiveness of BGP point to
point security. Current problems with BGP session security (between
BGP peers) include:
o The use of static keys, which tend to be changed infrequently, and
often not at all. RFC 3562 [insert ref] states that keys SHOULD
be changed at least every 90 days. However, the relative
Behringer Expires October 26, 2007 [Page 3]
Internet-Draft BGP Session Security Requirements April 2007
complexity of chaining MD5 keys on all BGP peerings, specifically
where third parties are involved, means that keys are often not
changed at all. This makes long term brute force attacks
feasible.
o The key change process needs to be coordinated between both sides
of the BGP peering, making this an operationally expensive
exercise.
o The keys are typically chosen by humans, and in ASCII code;
therefore, the entropy is typically small, making the keys easier
to guess. [ref: RFC 3562]
o Dependence on the MD5 algorithm, which brings two problems: MD5 is
not considered strong enough for the future [insert ref]. And,
security architectures should also allow a choice of algorithms
[insert ref].
o Where confidentiality of BGP routing information is required, this
can only be achieved today by securing the BGP session with IPsec.
Other ways to provide confidentiality may be desirable.
This document lists the requirements for BGP session security, with
the goal to provide a guideline for flexible, operationally
manageable, and secure algorithms for BGP session protection.
2. The Threat Model
The threat model presented here is based on RFC4593 [insert ref],
which explains generic threats to routing protocols. This document
provides a categorization and classification of threat sources,
threat actions, threat consequences, threat consequence zones, and
threat consequence periods.
Security threats to point to point BGP sessions can be classified
with the following parameters:
o Threat source: Any host in the Internet which can reach one of the
BGP peers. By using RFC3682 [insert ref] the threat source must
be within the configured IP hop count, in the ideal case directly
connected.
o Threat action: Sending of forged BGP packets.
o Threat consequence: Denial of service, for example by sending fake
RST packets, intrusion by sending fake BGP update messages, or
session hijacking.
o Threat consequence zones: The BGP peering session itself, the BGP
tables on the affected peers, or potentially larger areas of the
BGP routing system.
o Threat consequence period: Depending on the attack and the
implemented counter measures, a threat might be preliminarily
mitigated by changing the MD5 key, unless it is a threat against
MD5 itself, in which case the threat period is indefinite.
Behringer Expires October 26, 2007 [Page 4]
Internet-Draft BGP Session Security Requirements April 2007
Threats not considered in this document include:
o Attacks from legitimate BGP speakers, in other words, attacks from
other BGP speakers, which are trusted (implicitly or explicitly).
The source of the attack in this case could be either a
misconfiguration, or an attacker gaining illegitimate access to a
router, for example through SSH brute force attacks.
o Other forms of attack against routers, such as denial of service
attacks against other services of the router, or against the
ingress interface.
3. BGP Session Security Requirements
3.1. BGP Speaker Identity
A BGP speaker MUST have a unique identity to present to its peer.
This serves as a base for subsequent security mechanisms, such as
peer authentication. At this moment this identity is tied to the IP
address used for the BGP peering session, presenting a globally
unique ID. This address can be either the IP address of a loopback
interface, or a physical interface. Any point to point security
mechanism for BGP MUST refer to and use a specific BGP ID. This ID
MUST be unique for the BGP peers, it SHOULD be unique within an
autonomous system, and it MAY be globally unique.
Note that a router based identity may not be sufficient for this
purpose, since different identities may be used, for example an
internal ID for iBGP sessions, and an external one for eBGP sessions.
Therefore, it might be necessary to assign different identities to
different BGP sessions.
Although currently the IP address used for the BGP peering is used as
an identifier, it is entirely possible to use an alternative BGP ID,
for example based on public/private key pairs, or the HIP
architecture (RFC 4423). draft-ietf-idr-bgp-identifier-08 [insert
ref] for example proposes a 4-byte unsigned, non-zero integer as an
identity, which should be unique in the autonomous system.
3.2. Peer Authentication
A BGP speaker MUST have a way to authenticate messages from its peer.
Currently this is achieved by RFC 2385 derived mechanisms, however,
several alternatives are conceivable and partly under discussion, for
example draft-bonica-tcp-auth-06. Also IPsec [insert ref] provides
peer authentication, as does TLS [insert ref] or SSH [insert ref].
To avoid overloading system resources, the method used SHOULD be
light weight. (Note: Key management is discussed below.)
Behringer Expires October 26, 2007 [Page 5]
Internet-Draft BGP Session Security Requirements April 2007
3.3. Integrity
A BGP speaker MUST have methods to ensure integrity of messages in
transit, to avoid insertion of fake messages in the transport layer.
This requirement is currently addressed by RFC 2385 derived
mechanisms. However, new methods should avoid the operational issues
mentioned in the introduction. It SHOULD be possible to use various
algorithms, either statically by specifying the algorithms used for
integrity services, or by dynamic negotiation. (Note: Key management
is discussed below.)
3.4. Confidentiality
A BGP speaker MAY have mechanisms to encrypt BGP messages in transit,
thus providing confidentiality. This service is rarely used today,
but since BGP is used increasingly for more applications, amongst
which for example signalling security measures, it is conceivable
that the need for confidentiality for BGP sessions will increase. If
confidentiality services are provided, they SHOULD allow for
different crypto algorithms, and negotiation of which algorithm to
use. (Note: Key management is discussed below.)
3.5. Anti-Replay
A BGP speaker MUST have methods to detect and prevent replay of
messages, to avoid for example an attacker saving a session reset
message, and replaying that later, to produce a denial of service
attack.
3.6. Availability and Restricting IP Reachability
A BGP speaker SHOULD have mechanisms to protect the BGP session
against denial of service attacks, targeting the availability of the
BGP session. More specifically, a BGP speaker SHOULD have mechanisms
to drop packets efficiently (with minimum CPU impact) which are not
originating from the legitimate peer. This includes access control
lists (ACL) on layer 3/4 and possibly layer 2, providing easy
protection against some forms of attack. It also includes TTL based
mechanisms such as proposed in RFC 3682 [insert ref].
Fragmentation attacks can bypass layer 4 ACLs, by fragmenting packets
in a way that neither fragment is recognized by the ACL.
Fragmentation should never occur on a BGP session, therefore
fragments on a BGP session SHOULD be dropped. Also on other,
related, protocols fragmentation needs to be specially considered,
since it can bypass some forms of ACLs.
Behringer Expires October 26, 2007 [Page 6]
Internet-Draft BGP Session Security Requirements April 2007
3.7. Key Management and Operational Considerations
Some of the requirements above may in turn require shared keys
between the BGP peers. Currently statically defined and manually
configured keys are used for this purpose. RFC 3562 explains
possible shortcomings of such keys, and gives recommendations to
improve security. Key selection is also discussed in
draft-weis-tcp-auth-auto-ks-01, as an extension to
draft-bonica-tcp-auth-06.
For any new mechanism aimed at securing BGP sessions it is highly
desirable to use automated key negotiation mechanisms, based on the
BGP speaker identity.
Mechanisms based on key lists with defined life times for keys, for
example as defined by draft-viswanathan-keyrollover-00.txt may be
acceptable if there are good reasons to avoid automated key
negotiation.
Any security mechanism proposed to secure point to point BGP sessions
should be easy to configure, and not require regular changes.
3.8. Logging and Alerting
To be able to detect attempts of security breaks, BGP speakers MUST
have be able to produce related alerts or logging messages. General
considerations to logging apply here: There should be summarization
of events, to avoid for example a message to be sent for each packet
that is not authenticated. When available, secure syslog should be
used to guarantee delivery of those messages to the management
center.
4. Security Considerations
This document is entirely about security requirements for BGP point-
to-point connections. No new security exposures are created by this
document.
5. Acknowledgements
The author would like to thank Russ White, Alvaro Retana, Brian Weis
and Carlos Pignataro for their feedback and support.
6. References
Behringer Expires October 26, 2007 [Page 7]
Internet-Draft BGP Session Security Requirements April 2007
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
6.2. Informative References
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL
Security Mechanism (GTSM)", RFC 3682, February 2004.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006.
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
Routing Protocols", RFC 4593, October 2006.
Author's Address
Michael H. Behringer
Cisco
Behringer Expires October 26, 2007 [Page 8]
Internet-Draft BGP Session Security Requirements April 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Behringer Expires October 26, 2007 [Page 9]