draft-ietf-karp-routing-tcp-analysis-07.txt   rfc6952.txt 
Routing Working Group M. Jethanandani Internet Engineering Task Force (IETF) M. Jethanandani
Internet-Draft Ciena Corporation Request for Comments: 6952 Ciena Corporation
Intended status: Informational K. Patel Category: Informational K. Patel
Expires: October 10, 2013 Cisco Systems, Inc ISSN: 2070-1721 Cisco Systems, Inc
L. Zheng L. Zheng
Huawei Technologies Huawei Technologies
April 08, 2013 May 2013
Analysis of BGP, LDP, PCEP and MSDP Issues According to KARP Design Analysis of BGP, LDP, PCEP, and MSDP Issues According to the
Guide Keying and Authentication for Routing Protocols (KARP) Design Guide
draft-ietf-karp-routing-tcp-analysis-07.txt
Abstract Abstract
This document analyzes TCP based routing protocols, Border Gateway This document analyzes TCP-based routing protocols, the Border
Protocol (BGP), Label Distribution Protocol (LDP), Path Computation Gateway Protocol (BGP), the Label Distribution Protocol (LDP), the
Element Communication Protocol (PCEP), and Multicast Source Path Computation Element Communication Protocol (PCEP), and the
Distribution Protocol (MSDP) according to guidelines set forth in Multicast Source Distribution Protocol (MSDP), according to
section 4.2 of Keying and Authentication for Routing Protocols Design guidelines set forth in Section 4.2 of "Keying and Authentication for
Guidelines (RFC6518). Routing Protocols Design Guidelines", RFC 6518.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on October 10, 2013. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6952.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
2. Current Assessment of BGP, LDP, PCEP and MSDP . . . . . . . . 4 2. Current Assessment of BGP, LDP, PCEP, and MSDP . . . . . . . 5
2.1. Transport layer . . . . . . . . . . . . . . . . . . . . . 5 2.1. Transport Layer . . . . . . . . . . . . . . . . . . . . . 5
2.2. Keying mechanisms . . . . . . . . . . . . . . . . . . . . 6 2.2. Keying Mechanisms . . . . . . . . . . . . . . . . . . . . 6
2.3. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.1. Spoofing attacks . . . . . . . . . . . . . . . . . . 7 2.4.1. Spoofing Attacks . . . . . . . . . . . . . . . . . . 7
2.4.2. Denial of Service Attacks . . . . . . . . . . . . . . 8 2.4.2. Denial-of-Service Attacks . . . . . . . . . . . . . . 8
2.5. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.5. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.6. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. Optimal State for BGP, LDP, PCEP, and MSDP . . . . . . . . . 10 3. Optimal State for BGP, LDP, PCEP, and MSDP . . . . . . . . . 10
3.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Gap Analysis for BGP, LDP, PCEP and MSDP . . . . . . . . . . 11 4. Gap Analysis for BGP, LDP, PCEP, and MSDP . . . . . . . . . . 11
4.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Transition and Deployment Considerations . . . . . . . . . . 13 5. Transition and Deployment Considerations . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
In March 2006, the Internet Architecture Board (IAB) described an In their "Report from the IAB Workshop on Unwanted Traffic March
attack on core routing infrastructure as an ideal attack that would 9-10, 2006" [RFC4948], the Internet Architecture Board (IAB)
inflict the greatest amount of damage, in their Report from the IAB described an attack on core routing infrastructure as an ideal attack
workshop on Unwanted Traffic March 9-10, 2006 [RFC4948], and suggests that would inflict the greatest amount of damage and suggested steps
steps to tighten the infrastructure against the attack. Four main to tighten the infrastructure against the attack. Four main steps
steps were identified for that tightening: were identified for that tightening:
1. Create secure mechanisms and practices for operating routers. 1. Create secure mechanisms and practices for operating routers.
2. Clean up the Internet Routing Registry (IRR) repository, and 2. Clean up the Internet Routing Registry (IRR) repository, and
securing both the database and the access, so that it can be used secure both the database and the access, so that it can be used
for routing verifications. for routing verifications.
3. Create specifications for cryptographic validation of routing 3. Create specifications for cryptographic validation of routing
message content. message content.
4. Secure the routing protocols' packets on the wire. 4. Secure the routing protocols' packets on the wire.
In order to secure the routing protocols this document performs an In order to secure the routing protocols, this document performs an
initial analysis of the current state of the following TCP based initial analysis of the current state of four TCP-based protocols --
protocols: BGP, LDP, PCEP, and MSDP according to the requirements of BGP [RFC4271], LDP [RFC5036], PCEP [RFC5440], and MSDP [RFC3618] --
KARP Design Guidelines [RFC6518]. Section 4.2 of the document uses according to the requirements of the KARP Design Guidelines
the term "state" which will be referred to as the "state of the [RFC6518]. Section 4.2 of that document uses the term "state", which
security method". Thus a term like "Define Optimal State" would be will be referred to as the "state of the security method". Thus, a
referred to as "Define Optimal State of the Security Method". This term like "Define Optimal State" would be referred to as "Define
document builds on several previous analysis efforts into routing Optimal State of the Security Method".
security.
This document builds on several previous efforts into routing This document builds on several previous efforts into routing
security: security:
o Issues with existing Cryptographic Protection Methods for Routing o "Issues with Existing Cryptographic Protection Methods for Routing
Protocols [RFC6039], describes issues with existing cryptographic Protocols" [RFC6039], describes issues with existing cryptographic
protection methods for routing protocols. protection methods for routing protocols.
o Analysis of OSPF Security According to KARP Design Guide [RFC6863] o Analysis of OSPF Security According to the KARP Design Guide
analyzes Open Shortest Path First (OSPF) security according to [RFC6863] analyzes Open Shortest Path First (OSPF) security
KARP Design Guide. according to the KARP Design Guide.
Section 2 of this document looks at the current state of the security Section 2 of this document looks at the current state of the security
method for the four routing protocols, BGP, LDP, PCEP and MSDP. method for the four routing protocols: BGP, LDP, PCEP, and MSDP.
Section 3 examines what the optimal state of the security method Section 3 examines what the optimal state of the security method
would be for the four routing protocols, according to KARP Design would be for the four routing protocols according to the KARP Design
Guidelines [RFC6518] and Section 4 does an analysis of the gap Guidelines [RFC6518], and Section 4 does an analysis of the gap
between the existing state of the security method and the optimal between the existing state of the security method and the optimal
state of the security method for protocols and suggests some areas state of the security method for the protocols and suggests some
where improvement is needed. areas where improvement is needed.
1.1. Abbreviations 1.1. Abbreviations
AES - Advanced Encryption Standard AES - Advanced Encryption Standard
AO - Authentication Option AO - Authentication Option
AS - Autonomous Systems AS - Autonomous System
BGP - Border Gateway Protocol BGP - Border Gateway Protocol
CMAC - Ciper Based MAC CMAC - Cipher-Based Message Authentication Code
DoS - Denial of Service DoS - Denial of Service
GTSM - Generalized TTL Security Mechanism
HMAC - Hash Based MAC GTSM - Generalized Time-to-Live (TTL) Security Mechanism
HMAC - Hash-Based MAC
KARP - Key and Authentication for Routing Protocols KARP - Key and Authentication for Routing Protocols
KDF - Key Derivation Function KDF - Key Derivation Function
KEK - Key Encrypting Key KEK - Key Encrypting Key
KMP - Key Management Protocol KMP - Key Management Protocol
LDP - Label Distribution Protocol LDP - Label Distribution Protocol
LSR - Label Switching Routers LSR - Label Switching Routers
MAC - Message Authentication Code MAC - Message Authentication Code
MKT - Master Key Tuple MKT - Master Key Table
MSDP - Multicast Source Distribution Protocol MSDP - Multicast Source Distribution Protocol
MD5 - Message Digest algorithm 5 MD5 - Message Digest Algorithm 5
OSPF - Open Shortest Path First OSPF - Open Shortest Path First
PCEP - Path Computation Element Communication Protocol PCEP - Path Computation Element Communication Protocol
PCC - Path Computation Client PCC - Path Computation Client
PCE - Path Computation Element PCE - Path Computation Element
SHA - Security Hash Algorithm SHA - Secure Hash Algorithm
TCP - Transmission Control Protocol TCP - Transmission Control Protocol
TTL - Time To Live TTL - Time-to-Live
UDP - User Datagram Protocol UDP - User Datagram Protocol
WG - Working Group WG - Working Group
2. Current Assessment of BGP, LDP, PCEP and MSDP 2. Current Assessment of BGP, LDP, PCEP, and MSDP
This section assesses the transport protocols for any authentication This section assesses the transport protocols for any authentication
or integrity mechanisms used by the protocol. It describes the or integrity mechanisms used by the protocol. It describes the
current security mechanisms if any used by BGP, LDP, PCEP and MSDP. current security mechanisms, if any, used by BGP, LDP, PCEP, and
MSDP.
2.1. Transport layer 2.1. Transport Layer
At a transport layer, routing protocols are subject to a variety of At the transport layer, routing protocols are subject to a variety of
DoS attacks, as outlined in Internet Denial-of-Service Considerations DoS attacks, as outlined in "Internet Denial-of-Service
[RFC4732]. Such attacks can cause the routing protocol to become Considerations" [RFC4732]. Such attacks can cause the routing
congested with the result that routing updates are supplied too protocol to become congested, resulting in the routing updates being
slowly to be useful. In extreme cases, these attacks prevent routers supplied too slowly to be useful. In extreme cases, these attacks
from converging after a change. prevent routers from converging after a change.
Routing protocols use several methods to protect themselves. Those Routing protocols use several methods to protect themselves. Those
that use TCP as a transport protocol use access lists to accept that use TCP as a transport protocol use access lists to accept
packets only from known sources. These access lists also help packets only from known sources. These access lists also help
protect edge routers from attacks originating outside the protected protect edge routers from attacks originating outside the protected
domain. In addition, for edge routers running eBGP, TCP LISTEN is domain. In addition, for edge routers running the External Border
run only on interfaces on which its peers have been discovered or via Gateway Protocol (eBGP), TCP LISTEN is run only on interfaces on
which routing sessions are expected (as specified in router which its peers have been discovered or via which routing sessions
configuration databases). are expected (as specified in router configuration databases).
Generalized TTL Security Mechanism (GTSM) [RFC5082] describes a "Generalized TTL Security Mechanism (GTSM)" [RFC5082] describes a
generalized Time to Live (TTL) security mechanism to protect a generalized Time-to-Live (TTL) security mechanism to protect a
protocol stack from CPU-utilization based attacks.TCP Robustness protocol stack from CPU-utilization-based attacks. TCP Robustness
[RFC5961] recommends some TCP level mitigations against spoofing [RFC5961] recommends some TCP-level mitigations against spoofing
attacks targeted towards long-lived routing protocol sessions. attacks targeted towards long-lived routing protocol sessions.
Even when BGP, LDP, PCEP and MSDP sessions use access lists, they are Even when BGP, LDP, PCEP, and MSDP sessions use access lists, they
vulnerable to spoofing and man in the middle attacks. Authentication are vulnerable to spoofing and man-in-the-middle attacks.
and integrity checks allow the receiver of a routing protocol update Authentication and integrity checks allow the receiver of a routing
to know that the message genuinely comes from the node that claims to protocol update to know that the message genuinely comes from the
have sent it, and to know whether the message has been modified. node that claims to have sent it and to know whether the message has
Sometimes routers can be subjected to a large number of been modified. Sometimes routers can be subjected to a large number
authentication and integrity requests, exhausting connection of authentication and integrity requests, exhausting connection
resources on the router in a way that could lead to deny genuine resources on the router in a way that could lead to the denial of
requests. genuine requests.
TCP MD5 [RFC2385] has been obsoleted by TCP-AO [RFC5925]. However, TCP MD5 [RFC2385] has been obsoleted by TCP-AO [RFC5925]. However,
it is still widely used to authenticate TCP based routing protocols it is still widely used to authenticate TCP-based routing protocols
such as BGP. It provides a way for carrying a MD5 digest in a TCP such as BGP. It provides a way for carrying a MD5 digest in a TCP
segment. This digest is computed using information known only to the segment. This digest is computed using information known only to the
end points and this ensures authenticity and integrity of messages. endpoints, and this ensures authenticity and integrity of messages.
The MD5 key used to compute the digest is stored locally on the The MD5 key used to compute the digest is stored locally on the
router. This option is used by routing protocols to provide for router. This option is used by routing protocols to provide for
session level protection against the introduction of spoofed TCP session-level protection against the introduction of spoofed TCP
segments into any existing TCP streams, in particular TCP Reset segments into any existing TCP streams, in particular, TCP Reset
segments. TCP MD5 does not provide a generic mechanism to support segments. TCP MD5 does not provide a generic mechanism to support
key roll-over. It also does not support algorithm agility. key rollover. It also does not support algorithm agility.
The Message Authentication Codes (MACs) used by TCP MD5 option, is The Message Authentication Codes (MACs) used by TCP MD5 are
considered too weak both because of the use of the hash function and considered too weak both because of the use of the hash function and
because of the way the secret key used by TCP MD5 is managed. because of the way the secret key used by TCP MD5 is managed.
Furthermore, TCP MD5 does not support any algorithm agility. TCP-AO Furthermore, TCP MD5 does not support any algorithm agility. TCP-AO
[RFC5925], and its companion document Crypto Algorithms for TCP-AO [RFC5925] and its companion document Cryptographic Algorithms for
[RFC5926], describe steps towards correcting both the MAC weakness TCP-AO [RFC5926], describe steps towards correcting both the MAC
and the management of secret keys. For MAC it requires that two MAC weakness and the management of secret keys. Those steps require that
algorithms be supported. They are HMAC-SHA-1-96 as specified in HMAC two MAC algorithms be supported. They are HMAC-SHA-1-96, as
[RFC2104], and AES-128-CMAC-96 as specified in NIST-SP800-38B specified in HMAC [RFC2104], and AES-128-CMAC-96, as specified in
[NIST-SP800-38B]. Cryptographic research suggests that both these NIST-SP800-38B [NIST-SP800-38B]. Cryptographic research suggests
MAC algorithms defined are fairly secure. By supporting multiple MAC that both these MAC algorithms are fairly secure. By supporting
algorithms, TCP-AO supports algorithm agility. TCP-AO also allows multiple MAC algorithms, TCP-AO supports algorithm agility. TCP-AO
additional MACs to be added in the future. also allows additional MACs to be added in the future.
2.2. Keying mechanisms 2.2. Keying Mechanisms
For TCP-AO [RFC5925] there is no Key Management Protocol (KMP) used For TCP-AO [RFC5925], there is no Key Management Protocol (KMP) used
to manage the keys that are employed to generate the Message to manage the keys that are employed to generate the MAC. TCP-AO
Authentication Code (MAC). TCP-AO talks about coordinating keys talks about coordinating keys derived from the Master Key Table (MKT)
derived from Master Key Table (MKT) between endpoints and allows for between endpoints and allows for a master key to be configured
a master key to be configured manually or for it to be managed via a manually or for it to be managed via an out-of-band mechanism.
out of band mechanism.
It should be noted that most routers configured with static keys have It should be noted that most routers configured with static keys have
not seen the key changed ever. The common reason given for not not seen the key changed ever. The common reason given for not
changing the key is the difficulty in coordinating the change between changing the key is the difficulty in coordinating the change between
pairs of routers when using TCP MD5. It is well known that the pairs of routers when using TCP MD5. It is well known that the
longer the same key is used, the greater the chance that it can be longer the same key is used, the greater the chance that it can be
guessed or exposed e.g. when an administrator with knowledge of the guessed or exposed, e.g., when an administrator with knowledge of the
keys leaves the company. keys leaves the company.
For point-to-point key management IKEv2 [RFC5996] protocol provides For point-to-point key management, the IKEv2 protocol [RFC5996]
for automated key exchange under a SA, and can be used for a provides for automated key exchange under a Security Association (SA)
comprehensive Key Management Protocol (KMP) solution for routers. and can be used for a comprehensive KMP solution for routers. IKEv2
IKEv2 can be used for both IPsec SAs [RFC4301] and other types of can be used for both IPsec SAs [RFC4301] and other types of SAs. For
SAs. For example, Fibre Channel SAs [RFC4595] are currently example, Fibre Channel SAs [RFC4595] are currently negotiated with
negotiated with IKEv2. Using IKEv2 to negotiate TCP-AO is a possible IKEv2. Using IKEv2 to negotiate TCP-AO is a possible option.
option.
2.3. BGP 2.3. BGP
All BGP communications take place over TCP. Therefore, all security All BGP communications take place over TCP. Therefore, all security
vulnerabilities for BGP can be categorised as relating to the vulnerabilities for BGP can be categorized as relating to the
security of the transport protocol itself, or to the compromising of security of the transport protocol itself, or to the compromising of
individual routers and the data they handle. This document examines individual routers and the data they handle. This document examines
the issues for the transport protocol, while the SIDR Working Group the issues for the transport protocol, while the SIDR Working Group
(WG) looks at ways to sign and secure the data exchanged in BGP as (WG) looks at ways to sign and secure the data exchanged in BGP as
described in An Infrastructure to Support Secure Internet Protocol described in "An Infrastructure to Support Secure Internet Protocol"
[RFC6480]. [RFC6480].
2.4. LDP 2.4. LDP
Security Framework for MPLS and GMPLS Networks [RFC5920] outlines "Security Framework for MPLS and GMPLS Networks" [RFC5920] outlines
security aspects that are relevant in the context of MPLS and GMPLS. security aspects that are relevant in the context of MPLS and GMPLS.
It describes the security threats, the related defensive techniques, It describes the security threats, the related defensive techniques,
and the mechanism for detection and reporting. and the mechanism for detection and reporting.
Section 5 of LDP [RFC5036] states that LDP is subject to two Section 5 of LDP [RFC5036] states that LDP is subject to two
different types of attacks: spoofing, and denial of service attacks. different types of attacks: spoofing and denial-of-service attacks.
2.4.1. Spoofing attacks 2.4.1. Spoofing Attacks
A spoofing attack against LDP can occur both during the discovery A spoofing attack against LDP can occur both during the discovery
phase and during the session communication phase. phase and during the session communication phase.
2.4.1.1. Discovery exchanges using UDP 2.4.1.1. Discovery Exchanges using UDP
Label Switching Routers (LSRs) indicate their willingness to Label Switching Routers (LSRs) indicate their willingness to
establish and maintain LDP sessions by periodically sending Hello establish and maintain LDP sessions by periodically sending Hello
messages. Reception of a Hello message serves to create a new "Hello messages. Reception of a Hello message serves to create a new "Hello
adjacency", if one does not already exist, or to refresh an existing adjacency", if one does not already exist, or to refresh an existing
one. one.
There are two variants of the discovery mechanism. A Basic Discovery There are two variants of the discovery mechanism. A Basic Discovery
mechanism that is used to discover LSR neighbors that are directly mechanism is used to discover LSR neighbors that are directly
connected at the link level and a Extended Discovery mechanism that connected at the link level, and an Extended Discovery mechanism is
is used by LSRs that are more than one hop away. used by LSRs that are more than one hop away.
Unlike all other LDP messages, the Hello messages are sent using UDP. Unlike all other LDP messages, the Hello messages are sent using UDP.
This means that they cannot benefit from the security mechanisms This means that they cannot benefit from the security mechanisms
available with TCP. LDP [RFC5036] does not provide any security available with TCP. LDP [RFC5036] does not provide any security
mechanisms for use with Hello messages except for some configuration mechanisms for use with Hello messages except for some configuration
which may help protect against bogus discovery events. These that may help protect against bogus discovery events. These
configurations include directly connected links and interfaces. configurations include directly connected links and interfaces.
Routers that do not use directly connected links have to use Extended Routers that do not use directly connected links have to use the
Discovery mechanism, and will not be able to use configuration to Extended Discovery mechanism and will not be able to use
protect against bogus discovery events. configuration to protect against bogus discovery events.
Spoofing a Hello packet for an existing adjacency can cause the Spoofing a Hello packet for an existing adjacency can cause the
adjacency to time out and result in termination of the associated adjacency to time out and result in termination of the associated
session. This can occur when the spoofed Hello message specifies a session. This can occur when the spoofed Hello message specifies a
small Hold Time, causing the receiver to expect Hello messages within small Hold Time, causing the receiver to expect Hello messages within
this interval, while the true neighbor continues sending Hello this interval, while the true neighbor continues sending Hello
messages at the lower, previously agreed to frequency. messages at the lower, previously agreed to frequency.
Spoofing a Hello packet can also cause the LDP session to be Spoofing a Hello packet can also cause the LDP session to be
terminated. This can occur when the spoofed Hello specifies a terminated. This can occur when the spoofed Hello specifies a
different Transport Address from the previously agreed one between different Transport Address from the previously agreed one between
neighbors. Spoofed Hello messages are observed and reported as real neighbors. Spoofed Hello messages are observed and reported as a
problem in production networks. real problem in production networks.
2.4.1.2. Session communication using TCP 2.4.1.2. Session Communication using TCP
LDP like other TCP based routing protocols specifies use of the TCP LDP, like other TCP-based routing protocols, specifies use of the TCP
MD5 Signature Option to provide for the authenticity and integrity of MD5 Signature Option to provide for the authenticity and integrity of
session messages. As stated in section 2.1 of this document and in session messages. As stated in Section 2.1 of this document and in
section 2.9 of LDP [RFC5036], MD5 authentication is considered too Section 2.9 of LDP [RFC5036], MD5 authentication is considered too
weak for this application as outlined in MD5 and HMAC-MD5 Security weak for this application as outlined in MD5 and HMAC-MD5 Security
Considerations [RFC6151]. It also does not support algorithm Considerations [RFC6151]. It also does not support algorithm
agility. A stronger hashing algorithm e.g SHA1, which is supported agility. A stronger hashing algorithm, e.g., SHA1, which is
by TCP-AO [RFC5925] could be deployed to take care of the weakness. supported by TCP-AO [RFC5925], could be deployed to take care of the
weakness.
Alternatively, one could move to using TCP-AO which provides for Alternatively, one could move to using TCP-AO, which provides for
stronger MAC algorithms, makes it easier to setup manual keys and stronger MAC algorithms, makes it easier to set up manual keys, and
protects against replay attacks. protects against replay attacks.
2.4.2. Denial of Service Attacks 2.4.2. Denial-of-Service Attacks
LDP is subject to Denial of Service (DoS) attacks both in its LDP is subject to Denial-of-Service (DoS) attacks both in discovery
discovery mode and in session mode. These are documented in mode and session mode. The potential targets are documented in
Section 5.3 of LDP [RFC5036]. Section 5.3 of LDP [RFC5036].
2.5. PCEP 2.5. PCEP
For effective selection by PCCs, a PCC needs to know the location of For effective selection by Path Computation Clients (PCCs), a PCC
PCEs in its domain along with some information relevant for PCE needs to know the location of Path Computation Elements (PCEs) in its
selection. Such PCE information could be learned through manual domain along with some information relevant for PCE selection. Such
configuration, on each PCC, along with their capabilities or PCE information could be learned through manual configuration, on
automatically through a PCE discovery mechanism as outlined in each PCC, along with the capabilities of the PCE or automatically
Requirements for PCE Discovery [RFC4674]. through a PCE discovery mechanism as outlined in Requirements for PCE
Discovery [RFC4674].
Attacks on PCEP [RFC5440] may result in damage to active networks. Attacks on PCEP [RFC5440] may result in damage to active networks.
These include computation responses, which if changed can cause These include computation responses, which if changed can cause
protocols like RSVP-TE [RFC3209] to setup sub-optimal or protocols like RSVP-TE [RFC3209] to set up suboptimal or
inappropriate LSPs. In addition, PCE itself can attacked by a inappropriate LSPs. In addition, PCE itself can be a target for a
variety of DoS attacks. Such attacks can cause path computations to variety of DoS attacks. Such attacks can cause path computations to
be supplied too slowly to be of any value particularly as it relates be supplied too slowly to be of any value, particularly as it relates
to recovery or establishment of LSPs. to recovery or establishment of LSPs.
Finally, PCE discovery as outlined in OSPF Protocol Extensions for Finally, PCE discovery, as outlined in OSPF Protocol Extensions for
PCE Discovery [RFC5088] and IS-IS Protocol Extensions for PCE PCE Discovery [RFC5088] and IS-IS Protocol Extensions for PCE
Discovery [RFC5089] is a significant feature for the successful Discovery [RFC5089], is a significant feature for the successful
deployment of PCEP in large networks. These mechanisms allow PCC to deployment of PCEP in large networks. These mechanisms allow PCC to
discover the existence of PCEs within the network. If the discovery discover the existence of PCEs within the network. If the discovery
mechanism is compromised, it will impair the ability of the nodes to mechanism is compromised, it will impair the ability of the nodes to
function as described below. function as described below.
As RFC 5440 states, PCEP which makes use of TCP as a transport, could As RFC 5440 states, PCEP (which makes use of TCP as a transport)
be the target of the following attacks: could be the target of the following attacks:
o Spoofing (PCC or PCE implementation) o Spoofing (PCC or PCE implementation)
o Snooping (message interception) o Snooping (message interception)
o Falsification o Falsification
o Denial of Service o Denial of Service
In inter-Autonomous Systems (AS) scenarios where PCE-to-PCE In inter-Autonomous System (inter-AS) scenarios where PCE-to-PCE
communication is required, attacks may be particularly significant communication is required, attacks may be particularly significant
with commercial as well as service-level agreement implications. with commercial implications as well as service-level agreement
implications.
Additionally, snooping of PCEP requests and responses may give an Additionally, snooping of PCEP requests and responses may give an
attacker information about the operation of the network. By viewing attacker information about the operation of the network. By viewing
the PCEP messages an attacker can determine the pattern of service the PCEP messages, an attacker can determine the pattern of service
establishment in the network, and can know where traffic is being establishment in the network and can know where traffic is being
routed, thereby making the network susceptible to targeted attacks routed, thereby making the network susceptible to targeted attacks
and the data within specific LSPs vulnerable. and the data within specific LSPs vulnerable.
Ensuring PCEP communication privacy is of key importance, especially Ensuring PCEP communication privacy is of key importance, especially
in an inter-AS context, where PCEP communication end-points do not in an inter-AS context, where PCEP communication endpoints do not
reside in the same AS. An attacker that intercepts a PCE message reside in the same AS. An attacker that intercepts a PCE message
could obtain sensitive information related to computed paths and could obtain sensitive information related to computed paths and
resources. resources.
At the time PCEP was documented in [RFC5440], TCP-AO had not been At the time PCEP was documented in [RFC5440], TCP-AO had not been
fully specified. Therefore, [RFC5440] mandates that PCEP fully specified. Therefore, [RFC5440] mandates that PCEP
implementations include support for TCP-MD5, and that use of the implementations include support for TCP MD5 and that use of the
function should be configurable by the operator. [RFC5440] also function should be configurable by the operator. [RFC5440] also
describes the vulnerabilities and weaknesses of TCP-MD5 as noted in describes the vulnerabilities and weaknesses of TCP MD5 as noted in
this document. [RFC5440] goes on to state that PCEP implementations this document. [RFC5440] goes on to state that PCEP implementations
should include support for TCP-AO as soon as that specification is should include support for TCP-AO as soon as that specification is
complete. Since TCP-AO [RFC5925] has now been published, new PCEP complete. Since TCP-AO [RFC5925] has now been published, new PCEP
implementation should fully support TCP-AO. implementations should fully support TCP-AO.
2.6. MSDP 2.6. MSDP
Similar to BGP and LDP, Multicast Source Distribution Protocol (MSDP) Similar to BGP and LDP, the Multicast Source Distribution Protocol
uses TCP MD5 [RFC2385] to protect TCP sessions via the TCP MD5 (MSDP) uses TCP MD5 [RFC2385] to protect TCP sessions via the TCP MD5
option. But with a weak MD5 authentication, TCP MD5 is not option. But with a weak MD5 authentication, TCP MD5 is not
considered strong enough for this application. It also does not considered strong enough for this application. It also does not
support algorithm agility. support algorithm agility.
MSDP also advocates imposing a limit on number of source address and MSDP advocates imposing a limit on the number of source address and
group addresses (S,G) that can be cached within the protocol and group addresses (S,G) that can be cached within the protocol in order
thereby mitigate state explosion due to any denial of service and to mitigate state explosion due to any denial of service and other
other attacks. attacks.
3. Optimal State for BGP, LDP, PCEP, and MSDP 3. Optimal State for BGP, LDP, PCEP, and MSDP
The ideal state of the security method for BGP, LDP, PCEP and MSDP The ideal state of the security method for BGP, LDP, PCEP, and MSDP
protocols are when they can withstand any of the known types of protocols is when they can withstand any of the known types of
attacks. The protocols also need to support algorithm agility, i.e. attacks. The protocols also need to support algorithm agility, i.e.,
they must not hardwire themselves to one algorithm. they must not hardwire themselves to one algorithm.
Additionally, Key Management Protocol (KMP) for the routing sessions Additionally, the KMP for the routing sessions should help negotiate
should help negotiate unique, pair wise random keys without unique, pair-wise random keys without administrator involvement. It
administrator involvement. It should also negotiate Security should also negotiate Security Association (SA) parameters required
Association (SA) parameters required for the session connection, for the session connection, including key lifetimes. It should keep
including key life times. It should keep track of those lifetimes track of those lifetimes and negotiate new keys and parameters before
and negotiate new keys and parameters before they expire and do so they expire and do so without administrator involvement. In the
without administrator involvement. In the event of a breach, event of a breach, including when an administrator with knowledge of
including when an administrator with knowledge of the keys leaves the the keys leaves the company, the keys should be changed immediately.
company, the keys should be changed immediately.
The DoS attacks for BGP, LDP, PCEP and MSDP are attacks to the The DoS attacks for BGP, LDP, PCEP, and MSDP are attacks to the
transport protocol, TCP for the most part and UDP in case of transport protocol -- TCP for the most part, and UDP in case of the
discovery phase of LDP. TCP and UDP should be able to withstand any discovery phase of LDP. TCP and UDP should be able to withstand any
of DoS scenarios by dropping packets that are attack packets in a way of the DoS scenarios by dropping packets that are attack packets in a
that does not impact legitimate packets. way that does not impact legitimate packets.
The routing protocols should provide a mechanism to authenticate the The routing protocols should provide a mechanism to authenticate the
routing information carried within the payload and administrators routing information carried within the payload, and administrators
should enable it. should enable it.
3.1. LDP 3.1. LDP
To harden LDP against its current vulnerability to spoofing attacks, To mitigate LDP's current vulnerability to spoofing attacks, LDP
LDP needs to be upgraded such that an implementation is able to needs to be upgraded such that an implementation is able to determine
determine the authenticity of the neighbors sending the Hello the authenticity of the neighbors sending the Hello message.
message.
Labels are similar to routing information which is distributed in the Labels are similar to routing information, which is distributed in
clear. However, there is currently no requirement that the labels be the clear. However, there is currently no requirement that the
encrypted. And stated before, is currently out of scope of this labels be encrypted. Such a requirement is out of scope for this
document. document.
Similarly, it is important to ensure that routers exchanging labels Similarly, it is important to ensure that routers exchanging labels
are mutually authenticated, and that there are no rogue peers or are mutually authenticated, and that there are no rogue peers or
unauthenticated peers that can compromise the stability of the unauthenticated peers that can compromise the stability of the
network. network.
4. Gap Analysis for BGP, LDP, PCEP and MSDP 4. Gap Analysis for BGP, LDP, PCEP, and MSDP
This section outlines the differences between the current state of This section outlines the differences between the current state of
the security methods for routing protocols, and the desired state of the security methods for routing protocols and the desired state of
the security methods as outlined in section 4.2 of KARP Design the security methods as outlined in Section 4.2 of the KARP Design
Guidelines [RFC6518]. As that document states, these routing Guidelines [RFC6518]. As that document states, these routing
protocols fall into the category of one-to-one peering messages and protocols fall into the category of one-to-one peering messages and
will use peer keying protocol. It covers issues that are common to will use peer keying protocols. This section covers issues that are
the four protocols in this section, leaving protocol specific issues common to the four protocols, leaving protocol-specific issues to
to sub-sections. sub-sections.
At a transport level these routing protocols are subject to some of At a transport level, these routing protocols are subject to some of
the same attacks that TCP applications are subject to. These include the same attacks that TCP applications are subject to. These include
DoS and spoofing attacks. Internet Denial-of-Service Considerations DoS and spoofing attacks. "Internet Denial-of-Service
[RFC4732] outlines some solutions. Defending TCP Against Spoofing Considerations" [RFC4732] outlines some solutions. "Defending TCP
Attacks [RFC4953] recommends ways to prevent spoofing attacks. In Against Spoofing Attacks" [RFC4953] recommends ways to prevent
addition, the recommendations in [RFC5961] should also be followed spoofing attacks. In addition, the recommendations in [RFC5961]
and implemented to strengthen TCP. should also be followed and implemented to strengthen TCP.
Routers lack comprehensive key management and keys derived from it Routers lack comprehensive key management and keys derived that they
that they can use to authenticate data. As an example TCP-AO can use to authenticate data. As an example, TCP-AO [RFC5925], talks
[RFC5925], talks about coordinating keys derived from Master Key about coordinating keys derived from the Master Key Table (MKT)
Table (MKT) between endpoints, but the MKT itself has to be between endpoints, but the MKT itself has to be configured manually
configured manually or through an out of band mechanism. Also TCP-AO or through an out-of-band mechanism. Also, TCP-AO does not address
does not address the issue of connectionless reset, as it applies to the issue of connectionless reset, as it applies to routers that do
routers that do not store MKT across reboots. not store MKT across reboots.
Authentication, integrity protection, and encryption all require the Authentication, integrity protection, and encryption all require the
use of keys by sender and receiver. An automated KMP therefore has use of keys by sender and receiver. An automated KMP, therefore has
to include a way to distribute key material between two end points to include a way to distribute key material between two endpoints
with little or no administration overhead. It has to cover automatic with little or no administrative overhead. It has to cover automatic
key rollover. It is expected that authentication will cover the key rollover. It is expected that authentication will cover the
packet, i.e. the payload and the TCP header and will not cover the packet, i.e., the payload and the TCP header, and will not cover the
frame i.e. the link layer 2 header. frame, i.e., the layer 2 header.
There are two methods of automatic key rollover. Implicit key There are two methods of automatic key rollover. Implicit key
rollover can be initiated after certain volume of data gets exchanged rollover can be initiated after a certain volume of data gets
or when a certain time has elapsed. This does not require explicit exchanged or when a certain time has elapsed. This does not require
signaling nor should it result in a reset of the TCP connection in a explicit signaling nor should it result in a reset of the TCP
way that the links/adjacencies are affected. On the other hand, connection in a way that the links/adjacencies are affected. On the
explicit key rollover requires an out of band key signaling other hand, explicit key rollover requires an out-of-band key
mechanism. It can be triggered by either side and can be done signaling mechanism. It can be triggered by either side and can be
anytime a security parameter changes e.g. an attack has happened, or done anytime a security parameter changes, e.g., an attack has
a system administrator with access to the keys has left the company. happened, or a system administrator with access to the keys has left
An example of this is IKEv2 [RFC5996], but it could be any other new the company. An example of this is IKEv2 [RFC5996], but it could be
mechanisms also. any other new mechanisms also.
As stated earlier TCP-AO [RFC5925], and its accompanying document As stated earlier, TCP-AO [RFC5925] and its accompanying document,
Crypto Algorithms for TCP-AO [RFC5926], requires that two MAC Cryptographic Algorithms for TCP-AO [RFC5926], require that two MAC
algorithms be supported, and they are HMAC-SHA-1-96 as specified in algorithms be supported, and they are HMAC-SHA-1-96, as specified in
HMAC [RFC2104], and AES-128-CMAC-96 as specified in NIST-SP800-38B HMAC [RFC2104], and AES-128-CMAC-96, as specified in NIST-SP800-38B
[NIST-SP800-38B]. Therefore, TCP-AO meets the algorithm agility [NIST-SP800-38B]. Therefore, TCP-AO meets the algorithm agility
requirement. requirement.
There is a need to protect authenticity and validity of the routing/ There is a need to protect authenticity and validity of the routing/
label information that is carried in the payload of the sessions. label information that is carried in the payload of the sessions.
However, that is outside the scope of this document and is being However, that is outside the scope of this document and is being
addressed by SIDR WG. Similar mechanisms could be used for intra- addressed by the SIDR WG. Similar mechanisms could be used for
domain protocols. intra-domain protocols.
Finally, replay protection is required. The replay mechanism needs Finally, replay protection is required. The replay mechanism needs
to be sufficient to prevent an attacker from creating a denial of to be sufficient to prevent an attacker from creating a denial of
service or disrupting the integrity of the routing protocol by service or disrupting the integrity of the routing protocol by
replaying packets. It is important that an attacker not be able to replaying packets. It is important that an attacker not be able to
disrupt service by capturing packets and waiting for replay state to disrupt service by capturing packets and waiting for replay state to
be lost. be lost.
4.1. LDP 4.1. LDP
As described in LDP [RFC5036], the threat of spoofed Basic Hellos can As described in LDP [RFC5036], the threat of spoofed Basic Hellos can
be reduced by only accepting Basic Hellos on interfaces that LSRs be reduced by only accepting Basic Hellos on interfaces that LSRs
trust, employing GTSM [RFC5082] and ignoring Basic Hellos not trust, employing GTSM [RFC5082], and ignoring Basic Hellos not
addressed to the "all routers on this subnet" multicast group. addressed to the "all routers on this subnet" multicast group.
Spoofing attacks via Targeted Hellos are potentially a more serious Spoofing attacks via Targeted Hellos are potentially a more serious
threat. An LSR can reduce the threat of spoofed Extended Hellos by threat. An LSR can reduce the threat of spoofed Extended Hellos by
filtering them and accepting Hellos from sources permitted by an filtering them and accepting Hellos from sources permitted by access
access lists. However, performing the filtering using access lists lists. However, performing the filtering using access lists requires
requires LSR resource, and the LSR is still vulnerable to the IP LSR resources, and the LSR is still vulnerable to the IP source
source address spoofing. Spoofing attacks can be solved by being address spoofing. Spoofing attacks can be solved by being able to
able to authenticate the Hello messages, and an LSR can be configured authenticate the Hello messages, and an LSR can be configured to only
to only accept Hello messages from specific peers when authentication accept Hello messages from specific peers when authentication is in
is in use. use.
LDP Hello Cryptographic Authentication LDP Hello Cryptographic Authentication [HELLO-CRYPTO] suggest a new
[draft-zheng-mpls-ldp-hello-crypto-auth-04] suggest a new
Cryptographic Authentication TLV that can be used as an Cryptographic Authentication TLV that can be used as an
authentication mechanism to secure Hello messages. authentication mechanism to secure Hello messages.
4.2. PCEP 4.2. PCEP
Path Computation Element (PCE) discovery according to its RFC Path Computation Element (PCE) discovery, according to [RFC5440], is
[RFC5440], is a significant feature for the successful deployment of a significant feature for the successful deployment of PCEP in large
PCEP in large networks. This mechanism allows a Path Computation networks. This mechanism allows a Path Computation Client (PCC) to
Client (PCC) to discover the existence of suitable PCEs within the discover the existence of suitable PCEs within the network without
network without the necessity of configuration. It should be obvious the necessity of configuration. It should be obvious that, where
that, where PCEs are discovered and not configured, the PCC cannot PCEs are discovered and not configured, the PCC cannot know the
know the correct key to use. There are different approaches to correct key to use. There are different approaches to retain some
retain some aspect of security, but all of them require use of a keys aspect of security, but all of them require use of a keys and a
and a keying mechanism, the need for which has been discussed above. keying mechanism, the need for which has been discussed above.
5. Transition and Deployment Considerations 5. Transition and Deployment Considerations
As stated in KARP Design Guidelines [RFC6518], it is imperative that As stated in the KARP Design Guidelines [RFC6518], it is imperative
the new authentication, security mechanisms defined, and key that the new authentication, security mechanisms, and key management
management protocol support incremental deployment, as it is not protocol support incremental deployment, as it is not feasible to
feasible to deploy the new routing protocol authentication mechanism deploy the new routing protocol authentication mechanism overnight.
overnight.
Typically, authentication and security in a peer-to-peer protocol Typically, authentication and security in a peer-to-peer protocol
requires that both parties agree to the mechanisms that will be used. requires that both parties agree to the mechanisms that will be used.
If an agreement is not reached the setup of the new mechanism will If an agreement is not reached, the setup of the new mechanism will
fail or will be deferred. Upon failure, the routing protocols can fail or will be deferred. Upon failure, the routing protocols can
fallback to the mechanisms that were already in place e.g. use fall back to the mechanisms that were already in place, e.g., use
static keys if that was the mechanism in place. The fallback should static keys if that was the mechanism in place. The fallback should
be configurable on a per-node or per-interface. It is usually not be configurable on a per-node or per-interface basis. It is usually
possible for one end to use the new mechanism while the other end not possible for one end to use the new mechanism while the other end
uses the old. Policies can be put in place to retry upgrading after uses the old. Policies can be put in place to retry upgrading after
a said period of time, so a manual coordination is not required. a said period of time, so that manual coordination is not required.
If the automatic KMP requires use of Public Key Infrastructure If the automatic KMP requires use of Public Key Infrastructure
Certificates [RFC5280] to exchange key material, the required Certificates [RFC5280] to exchange key material, the required
Certificate Authority (CA) root certificates may need to be installed Certificate Authority (CA) root certificates may need to be installed
to verify authenticity of requests initiated by a peer. Such a step to verify the authenticity of requests initiated by a peer. Such a
does not require coordination with the peer except to decide what CA step does not require coordination with the peer, except to decide
authority will be used. which CA authority will be used.
6. Security Considerations 6. Security Considerations
This section describes security considerations that BGP, LDP, PCEP This section describes security considerations that BGP, LDP, PCEP,
and MSDP should try to meet. and MSDP should try to meet.
As with all routing protocols, they need protection from both on-path As with all routing protocols, they need protection from both on-path
and off-path blind attacks. A better way to protect them would be and off-path blind attacks. A better way to protect them would be
with per-packet protection using a cryptographic MAC. In order to with per-packet protection using a cryptographic MAC. In order to
provide for the MAC, keys are needed. provide for the MAC, keys are needed.
The routing protocols need to support algorithm agility, i.e. they The routing protocols need to support algorithm agility, i.e., they
must not hardwire themselves to one algorithm. must not hardwire themselves to one algorithm.
Once keys are used, mechanisms are required to support key rollover. Once keys are used, mechanisms are required to support key rollover.
This should cover both manual and automatic key rollover. Multiple They should cover both manual and automatic key rollover. Multiple
approaches could be used. However, since the existing mechanisms approaches could be used. However, since the existing mechanisms
provide a protocol field to identify the key as well as management provide a protocol field to identify the key as well as management
mechanisms to introduce and retire new keys, focusing on the existing mechanisms to introduce and retire new keys, focusing on the existing
mechanism as a starting point is prudent. mechanism as a starting point is prudent.
Furthermore, it is strongly suggested that these routing protocols Furthermore, it is strongly suggested that these routing protocols
need to support algorithm agility. It has been proven that support algorithm agility. It has been proven that algorithms weaken
algorithms weaken over time. Supporting algorithm agility assists in over time. Supporting algorithm agility assists in smooth
smooth transition from old to new algorithms. transitions from old to new algorithms.
7. IANA Considerations
None.
8. Acknowledgements 7. Acknowledgements
We would like to thank Brian Weis for encouraging us to write this We would like to thank Brian Weis for encouraging us to write this
draft, and to Anantha Ramaiah and Mach Chen for providing comments on document, and thanks to Anantha Ramaiah and Mach Chen for providing
it. comments on it.
9. References 8. References
9.1. Normative References 8.1. Normative References
[RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms
for the TCP Authentication Option (TCP-AO)", RFC 5926, for the TCP Authentication Option (TCP-AO)", RFC 5926,
June 2010. June 2010.
[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for
Routing Protocols (KARP) Design Guidelines", RFC 6518, Routing Protocols (KARP) Design Guidelines", RFC 6518,
February 2012. February 2012.
9.2. Informative References [RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security
According to the Keying and Authentication for Routing
Protocols (KARP) Design Guide", RFC 6863, March 2013.
8.2. Informative References
[HELLO-CRYPTO]
Zheng, L., Chen, M., and M. Bhatia, "LDP Hello
Cryptographic Authentication", Work in Progress, January
2013.
[NIST-SP800-38B] [NIST-SP800-38B]
Dworking, , "Recommendation for Block Cipher Modes of Dworking, , "Recommendation for Block Cipher Modes of
Operation: The CMAC Mode for Authentication", May 2005. Operation: The CMAC Mode for Authentication", May 2005.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February Hashing for Message Authentication", RFC 2104, February
1997. 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998. Signature Option", RFC 2385, August 1998.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery
Protocol (MSDP)", RFC 3618, October 2003. Protocol (MSDP)", RFC 3618, October 2003.
skipping to change at page 16, line 39 skipping to change at page 17, line 5
with Existing Cryptographic Protection Methods for Routing with Existing Cryptographic Protection Methods for Routing
Protocols", RFC 6039, October 2010. Protocols", RFC 6039, October 2010.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms", for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, March 2011. RFC 6151, March 2011.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, February 2012. Secure Internet Routing", RFC 6480, February 2012.
[RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security
According to the Keying and Authentication for Routing
Protocols (KARP) Design Guide", RFC 6863, March 2013.
[draft-zheng-mpls-ldp-hello-crypto-auth-04]
Zheng, , "LDP Hello Cryptographic Authentication", May
2012.
Authors' Addresses Authors' Addresses
Mahesh Jethanandani Mahesh Jethanandani
Ciena Corporation Ciena Corporation
1741 Technology Drive 1741 Technology Drive
San Jose, CA 95110 San Jose, CA 95110
USA USA
Phone: + (408) 436-3313 Phone: +1 (408) 436-3313
Email: mjethanandani@gmail.com EMail: mjethanandani@gmail.com
Keyur Patel Keyur Patel
Cisco Systems, Inc Cisco Systems, Inc
170 Tasman Drive 170 Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 (408) 526-7183 Phone: +1 (408) 526-7183
Email: keyupate@cisco.com EMail: keyupate@cisco.com
Lianshu Zheng Lianshu Zheng
Huawei Technologies Huawei Technologies
China China
Phone: +86 (10) 82882008 Phone: +86 (10) 82882008
Email: vero.zheng@huawei.com EMail: vero.zheng@huawei.com
 End of changes. 121 change blocks. 
313 lines changed or deleted 301 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/