draft-ietf-karp-routing-tcp-analysis-04.txt   draft-ietf-karp-routing-tcp-analysis-05.txt 
Routing Working Group M. Jethanandani Routing Working Group M. Jethanandani
Internet-Draft Ciena Corporation Internet-Draft Ciena Corporation
Intended status: Informational K. Patel Intended status: Informational K. Patel
Expires: January 31, 2013 Cisco Systems, Inc Expires: April 21, 2013 Cisco Systems, Inc
L. Zheng L. Zheng
Huawei Huawei Technologies
July 30, 2012 October 18, 2012
Analysis of BGP, LDP, PCEP and MSDP Issues According to KARP Design Analysis of BGP, LDP, PCEP and MSDP Issues According to KARP Design
Guide Guide
draft-ietf-karp-routing-tcp-analysis-04.txt draft-ietf-karp-routing-tcp-analysis-05.txt
Abstract Abstract
This document analyzes BGP, LDP, PCEP and MSDP according to This document analyzes Border Gateway Protocol (BGP) [RFC4271], Label
guidelines set forth in section 4.2 of Keying and Authentication for Distribution Protocol (LDP) [RFC5036], Path Computation Element
Routing Protocols Design Guidelines [RFC6518]. Protocol (PCEP) [RFC5440] and Multicast Source Distribution Protocol
(MSDP) [RFC3618] according to guidelines set forth in section 4.2 of
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Keying and Authentication for Routing Protocols Design Guidelines
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this [RFC6518].
document are to be interpreted as described in RFC 2119 [RFC2119]..
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 31, 2013. This Internet-Draft will expire on April 21, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Contributing Authors . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
2. Current State of BGP, LDP, PCEP and MSDP . . . . . . . . . . . 5 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. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1. Spoofing attacks . . . . . . . . . . . . . . . . . . . 6 2.3.1. Spoofing attacks . . . . . . . . . . . . . . . . . . . 6
2.3.2. Privacy Issues . . . . . . . . . . . . . . . . . . . . 7 2.3.2. Privacy Issues . . . . . . . . . . . . . . . . . . . . 7
2.3.3. Denial of Service Attacks . . . . . . . . . . . . . . 8 2.3.3. Denial of Service Attacks . . . . . . . . . . . . . . 8
2.4. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.5. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Transition and Deployment Considerations . . . . . . . . . . . 13 5. Transition and Deployment Considerations . . . . . . . . . . . 13
6. Security Requirements . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
In March 2006 the Internet Architecture Board (IAB) in its "Unwanted In March 2006 the Internet Architecture Board (IAB) in its "Unwanted
Internet Traffic" workshop documented in Report from the IAB workshop Internet Traffic" workshop documented in Report from the IAB workshop
skipping to change at page 3, line 24 skipping to change at page 3, line 24
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 securing 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.
This document looking at the last bullet performs an initial analysis In order to secure the routing protocols this document performs an
of the current state of BGP, LDP, PCEP and MSDP according to the initial analysis of the current state of BGP, LDP, PCEP and MSDP
requirements of KARP Design Guidelines [RFC6518]. This draft builds according to the requirements of KARP Design Guidelines [RFC6518].
on several previous analysis efforts into routing security. The Section 4.2 of the document uses the term "state" which will be
OPSEC working group published Issues with existing Cryptographic referred to as the "state of the security method". Thus a term like
Protection Methods for Routing Protocols [RFC6039] an analysis of "Define Optimal State" would be referred to as "Define Optimal State
cryptographic issues with routing protocols and Analysis of OSPF of the Security Method". This document builds on several previous
Security According to KARP Design Guide analysis efforts into routing security. The OPSEC working group
[draft-ietf-karp-ospf-analysis-03]. published Issues with existing Cryptographic Protection Methods for
Routing Protocols [RFC6039] an analysis of cryptographic issues with
routing protocols and Analysis of OSPF Security According to KARP
Design Guide [draft-ietf-karp-ospf-analysis-03].
Section 2 of this document looks at the current state of security for Section 2 of this document looks at the current state of security
the four routing protocols. Section 3 examines what the optimal method for the four routing protocols, BGP, LDP, PCEP and MSDP.
state would be for the four routing protocols according to KARP Section 3 examines what the optimal state of the security method
Design Guidelines [RFC6518] and Section 4 does a analysis of the gap would be for the four routing protocols according to KARP Design
between the existing state and the optimal state of the protocols and Guidelines [RFC6518] and Section 4 does a analysis of the gap between
suggests some areas where improvement is needed. the existing state of the security method and the optimal state of
the security method for protocols and suggests some areas where
improvement is needed.
1.1. Contributing Authors 1.1. Conventions Used in This Document
Anantha Ramaiah, Mach Chen The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Abbreviations 1.2. Abbreviations
AS - Autonomous Systems
BGP - Border Gateway Protocol BGP - Border Gateway Protocol
DoS - Denial of Service DoS - Denial of Service
GTSM - Generalized TTL Security Mechanism
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 Switch Routers LSR - Label Switch Routers
skipping to change at page 4, line 28 skipping to change at page 4, line 41
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 Protocol PCEP - Path Computation Element Protocol
TCP - Transmission Control Protocol TCP - Transmission Control Protocol
TTL - Time To Live
UDP - User Datagram Protocol UDP - User Datagram Protocol
2. Current State of BGP, LDP, PCEP and MSDP 2. Current Assessment of BGP, LDP, PCEP and MSDP
This section looks at the current state of transport protocol and any This section assesses the transport protocols for any authentication
authentication 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 a 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 Considerations
[RFC4732]. Such attacks can cause the routing protocol to become [RFC4732]. Such attacks can cause the routing protocol to become
congested with the result that routing updates are supplied too congested with the result that routing updates are supplied too
slowly to be useful. In extreme cases, these attacks prevent routes slowly to be useful. In extreme cases, these attacks prevent routers
from converging after a change. 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 from outside the protect edge routers from attacks originating from outside the
protected domain. In addition for edge routers running eBGP, TCP protected domain. In addition for edge routers running eBGP, TCP
LISTEN is run only on interfaces on which its peers have been LISTEN is run only on interfaces on which its peers have been
discovered or via which routing sessions are expected (as specified discovered or via which routing sessions are expected (as specified
in router configuration databases). in router configuration databases).
GTSM [RFC5082] describes a generalized Time to Live (TTL) security Generalized TTL Security Mechanism (GTSM) [RFC5082] describes a
mechanism to protect a protocol stack from CPU-utilization based generalized Time to Live (TTL) security mechanism to protect a
attacks.TCP Robustness [RFC5961] recommends some TCP level protocol stack from CPU-utilization based attacks.TCP Robustness
mitigations against spoofing attacks targeted towards long-lived [RFC5961] recommends some TCP level mitigations against spoofing
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 are
subject to spoofing and man in the middle attacks. Authentication vulnerable to spoofing and man in the middle attacks. Authentication
and integrity checks allow the receiver of a routing protocol update and integrity checks allow the receiver of a routing protocol update
to know that the message genuinely comes from the node that purports to know that the message genuinely comes from the node that purports
to have sent it, and to know whether the message has been modified. to have sent it, and to know whether the message has been modified.
Sometimes routers can be subjected to a large number of Sometimes routers can be subjected to a large number of
authentication and integrity requests, exhausting connection authentication and integrity requests, exhausting connection
resources on the router in a way that deny genuine requests. resources on the router in a way that deny genuine requests.
TCP MD5 [RFC2385] deprecated, but widely used, specifies a mechanism TCP MD5 [RFC2385] has been obsoleted by TCP-AO [RFC5925]. However it
to protect BGP and other TCP based routing protocols via the TCP MD5 is still widely used to authenticate TCP based routing protocols such
option. TCP MD5 option provides a way for carrying an MD5 digest in as BGP. It provides a way for carrying a MD5 digest in a TCP
a TCP segment. This digest acts like a signature for that segment, segment. This digest acts like a signature for that segment,
computed using information known only to the connection end points. computed using information known only to the connection end points.
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. key roll-over.
The Message Authentication Codes (MACs) used by the TCP MD5 option is The Message Authentication Codes (MACs) used by the TCP MD5 option is
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
skipping to change at page 6, line 30 skipping to change at page 6, line 30
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 Message
Authentication Code (MAC). TCP-AO allows for a master key to be Authentication Code (MAC). TCP-AO allows for a master key to be
configured manually or for it to be managed via a out of band configured manually or for it to be managed via a out of band
mechanism. 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 longer pairs of routers when using TCP MD5. It is well known that the
the same key is used, higher is the chance that it can be guessed or longer the same key is used, the greater the chance that it can be
exposed e.g. when an administrator with knowledge of the keys leaves guessed or exposed e.g. when an administrator with knowledge of the
the company. keys leaves the company.
For point-to-point key management IKEv2 [RFC5996] provides for For point-to-point key management IKEv2 [RFC5996] provides for
automated key exchange under a SA and can be used for a comprehensive automated key exchange under a SA and can be used for a comprehensive
Key Management Protocol (KMP) solution. Key Management Protocol (KMP) solution.
2.3. LDP 2.3. LDP
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.
In addition, labels are distributed in the clear, enabling hackers to In addition, LDP distributes labels in the clear, enabling hackers to
see what labels are being exchanged that could then be used to launch see what labels are being distributed. The attacker can use that
an attack. information to spoof a connection and distribute a different set of
labels causing traffic to be dropped.
2.3.1. Spoofing attacks 2.3.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.3.1.1. Discovery exchanges using UDP 2.3.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
skipping to change at page 8, line 4 skipping to change at page 8, line 4
Alternatively, one could move to using TCP-AO which provides for Alternatively, one could move to using TCP-AO which provides for
stronger MACs, makes it easier to setup manual keys and protects stronger MACs, makes it easier to setup manual keys and protects
against replays. against replays.
2.3.2. Privacy Issues 2.3.2. Privacy Issues
LDP provides no mechanism for protecting the privacy of label LDP provides no mechanism for protecting the privacy of label
distribution. The security requirements of label distribution are distribution. The security requirements of label distribution are
similar to other routing protocols that need to distribute routing similar to other routing protocols that need to distribute routing
information and as such LDP is vulnerable to the same extent as other information.
routing protocols that distribute their routing information in the
clear.
2.3.3. Denial of Service Attacks 2.3.3. 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 its
discovery mode and in session mode. discovery mode and in session mode. These are documented in Section
5.3 of LDP [RFC5036].
The discovery mode attack is similar to the spoofing attack except
that when the spoofed Hello messages are sent with a high enough
frequency, it can cause the adjacency to time out.
2.4. PCEP 2.4. PCEP
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 LDP to setup sub-optimal or inappropriate LSPs. In protocols like LDP to setup sub-optimal or inappropriate LSPs. In
addition, PCE itself can be attacked by a variety of DoS attacks. addition, PCE itself can be attacked by a variety of DoS attacks.
Such attacks can cause path computations to be supplied too slowly to Such attacks can cause path computations to be supplied too slowly to
be of any value particularly as it relates to recovery or be of any value particularly as it relates to recovery or
establishment of LSPs. establishment of LSPs.
As the RFC states, PCEP could be the target of the following attacks. As RFC 5440 states, PCEP 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
According to the RFC, inter-AS scenarios when PCE-to-PCE In inter-Autonomous Systems (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 implications. with commercial 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 end-points 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.
2.5. MSDP 2.5. MSDP
Similar to BGP and LDP, MSDP uses TCP MD5 [RFC2385] to protect TCP Similar to BGP and LDP, Multicast Source Distribution Protocol (MSDP)
sessions via the TCP MD5 option. But with a weak MD5 authentication, uses TCP MD5 [RFC2385] to protect TCP sessions via the TCP MD5
TCP MD5 is not considered strong enough for this application. option. But with a weak MD5 authentication, TCP MD5 is not
considered strong enough for this application.
MSDP also advocates imposing a limit on number of source address and MSDP also advocates imposing a limit on number of source address and
group addresses (S,G) that can be stored within the protocol and group addresses (S,G) that can be cached within the protocol and
thereby mitigate state explosion due to any denial of service and thereby mitigate state explosion due to any denial of service and
other attacks. other attacks.
3. Optimal State for BGP, LDP, PCEP, and MSDP 3. Optimal State for BGP, LDP, PCEP, and MSDP
The ideal state for BGP, LDP, PCEP and MSDP protocols are when they The ideal state of the security method for BGP, LDP, PCEP and MSDP
can withstand any of the known types of attacks. protocols are when they can withstand any of the known types of
attacks.
Additionally, Key Management Protocol (KMP) for the routing sessions Additionally, Key Management Protocol (KMP) for the routing sessions
should help negotiate unique, pair wise random keys without should help negotiate unique, pair wise random keys without
administrator involvement. It should also negotiate Security administrator involvement. It should also negotiate Security
Association (SA) parameter required for the session connection, Association (SA) parameter required for the session connection,
including key life times. It should keep track of those lifetimes including key life times. It should keep track of those lifetimes
and negotiate new keys and parameters before they expire and do so and negotiate new keys and parameters before they expire and do so
without administrator involvement. In the event of a breach, without administrator involvement. In the event of a breach,
including when an administrator with knowledge of the keys leaves the including when an administrator with knowledge of the keys leaves the
company, the keys should be changed immediately. company, the keys should be changed immediately.
skipping to change at page 10, line 31 skipping to change at page 10, line 32
transport protocol, TCP for the most part and UDP in case of transport protocol, TCP for the most part and UDP in case of
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 DoS scenarios by dropping packets that are attack packets in a way
that does not impact legitimate packets. 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. routing information carried within the payload.
3.1. LDP 3.1. LDP
For spoofing attacks that LDP is vulnerable to during the discovery To harden LDP against its current vulnerability to spoofing attacks,
phase, LDP should be able to determine the authenticity of the LDP needs to be upgraded such that an implementation is able to
neighbors sending the Hello message. determine the authenticity of the neighbors sending the Hello
message.
There is currently no requirement to protect the privacy of label There is currently no requirement to protect the privacy of label
distribution as labels are carried in the clear like other routing distribution as labels are carried in the clear like other routing
information. information.
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 routing protocol and the desired state as outlined in section 4.2 the security methods for routing protocols and the desired state of
of KARP Design Guidelines [RFC6518]. As that document states, these the security methods as outlined in section 4.2 of KARP Design
routing protocols fall into the category of one-to-one peering Guidelines [RFC6518]. As that document states, these routing
messages and will use peer keying protocol. It covers issues that protocols fall into the category of one-to-one peering messages and
are common to the four protocols in this section, leaving protocol will use peer keying protocol. It covers issues that are common to
specific issues to sub-sections. the four protocols in this section, leaving protocol specific issues
to sub-sections.
At a transport level the routing protocols are subject to some of the At a transport level these routing protocols are subject to some of
same attacks that TCP applications are subject to. These include DoS the same attacks that TCP applications are subject to. These include
and spoofing attacks. Internet Denial-of-Service Considerations DoS and spoofing attacks. Internet Denial-of-Service Considerations
[RFC4732] outlines some solutions. Defending TCP Against Spoofing [RFC4732] outlines some solutions. Defending TCP Against Spoofing
Attacks [RFC4953] recommends ways to prevent spoofing attacks. In Attacks [RFC4953] recommends ways to prevent spoofing attacks. In
addition Improving TCP's Robustness to Blind In-Window Attacks. addition Improving TCP's Robustness to Blind In-Window Attacks.
[RFC5961] should also be followed and implemented to strengthen TCP. [RFC5961] should also be followed and implemented to strengthen TCP.
From a security perspective there is lack of comprehensive KMP. As Routers lack comprehensive key management and keys derived from it
an example TCP-AO [RFC5925], talks about coordinating keys derived that they can use to authenticate data. As an example TCP-AO
from MKT between endpoints, but the MKT itself has to be configured [RFC5925], talks about coordinating keys derived from Master Key
manually or through a out of band mechanism. Also TCP-AO does not Table (MKT) between endpoints, but the MKT itself has to be
address the issue of connectionless reset, as it applies to routers configured manually or through an out of band mechanism. Also TCP-AO
that do not store MKT across reboots. does not address the issue of connectionless reset, as it applies to
routers that do not store MKT across reboots.
Authentication, tamper protection, and encryption all require the use Authentication, tamper protection, and encryption all require the use
of keys by sender and receiver. An automated KMP therefore has to of keys by sender and receiver. An automated KMP therefore has to
include a way to distribute MKT between two end points with little or include a way to distribute MKT between two end points with little or
no administration overhead. It has to cover automatic key rollover. no administration overhead. It has to cover automatic key rollover.
It is expected that authentication will cover the packet, i.e. the It is expected that authentication will cover the packet, i.e. the
payload and the TCP header and will not cover the frame i.e. the link payload and the TCP header and will not cover the frame i.e. the link
layer 2 header. 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 certain volume of data gets exchanged
or when a certain time has elapsed. This does not require explicit or when a certain time has elapsed. This does not require explicit
signaling nor should it result in a reset of the TCP connection in a signaling nor should it result in a reset of the TCP connection in a
way that the links/adjacencies are affected. On the other hand, way that the links/adjacencies are affected. On the other hand,
explicit key rollover requires a out of band key signaling mechanism. explicit key rollover requires an out of band key signaling
It can be triggered by either side and can be done anytime a security mechanism. It can be triggered by either side and can be done
parameter changes e.g. an attack has happened, or a system anytime a security parameter changes e.g. an attack has happened, or
administrator with access to the keys has left the company. An a system administrator with access to the keys has left the company.
example of this is IKEv2 [RFC5996] but it could be any other new An example of this is IKEv2 [RFC5996] but it could be any other new
mechanisms also. 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] suggest that two MAC Crypto Algorithms for TCP-AO [RFC5926] suggest that two MAC
algorithms that MUST be supported are HMAC-SHA-1-96 as specified in algorithms that MUST be supported 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]. [NIST-SP800-38B].
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 at this time and However, that is outside the scope of this document and is being
is being addressed by SIDR WG. Similar mechanisms could be used for addressed by SIDR WG. Similar mechanisms could be used for intra-
intra-domain protocols. domain protocols.
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 accepting Basic Hellos on interfaces that LSRs trust, be reduced by only accepting Basic Hellos on interfaces that LSRs
employing GTSM [RFC5082] and ignoring Basic Hellos not addressed to trust, employing GTSM [RFC5082] and ignoring Basic Hellos not
the "all routers on this subnet" multicast group. Spoofing attacks addressed to the "all routers on this subnet" multicast group.
via Extended Hellos are potentially a more serious threat. An LSR Spoofing attacks via Targeted Hellos are potentially a more serious
can reduce the threat of spoofed Extended Hellos by filtering them threat. An LSR can reduce the threat of spoofed Extended Hellos by
and accepting Hellos from sources permitted by an access lists. filtering them and accepting Hellos from sources permitted by an
However, performing the filtering using access lists requires LSR access lists. However, performing the filtering using access lists
resource, and the LSR is still vulnerable to the IP source address requires LSR resource, and the LSR is still vulnerable to the IP
spoofing. Spoofing attacks can be solved by being able to source address spoofing. Spoofing attacks can be solved by being
authenticate the Hello messages, and an LSR can be configured to only able to authenticate the Hello messages, and an LSR can be configured
accept Hello messages from specific peers when authentication is in to only accept Hello messages from specific peers when authentication
use. is in use.
LDP Hello Cryptographic Authentication LDP Hello Cryptographic Authentication
[draft-zheng-mpls-ldp-hello-crypto-auth-04] 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
PCE discovery according to its RFC is a significant feature for the Path Computation Element (PCE) discovery according to its RFC
successful deployment of PCEP in large networks. This mechanism [RFC5440] is a significant feature for the successful deployment of
allows a PCC to discover the existence of suitable PCEs within the PCEP in large networks. This mechanism allows a Path Computation
Client (PCC) to discover the existence of suitable PCEs within the
network without the necessity of configuration. It should be obvious network without the necessity of configuration. It should be obvious
that, where PCEs are discovered and not configured, the PCC cannot that, where PCEs are discovered and not configured, the PCC cannot
know the correct key to use. There are different approaches to know the correct key to use. There are different approaches to
retain some aspect of security, but all of them require use of a keys retain some aspect of security, but all of them require use of a keys
and a keying mechanism, the need for which has been discussed above. and a 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 KARP Design Guidelines [RFC6518] it is imperative that
the new authentication and security mechanisms defined support the new authentication and security mechanisms defined support
skipping to change at page 14, line 5 skipping to change at page 14, line 5
for one end to use the new mechanism while the other end uses the 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 a said old. Policies can be put in place to retry upgrading after a said
period of time, so a manual coordination is not required. period of time, so a manual coordination is not required.
If the automatic KMP requires use of public/private keys to exchange If the automatic KMP requires use of public/private keys to exchange
key material, the required CA root certificates may need to be key material, the required CA root certificates may need to be
installed to verify authenticity of requests initiated by a peer. installed to verify authenticity of requests initiated by a peer.
Such a step does not require coordination with the peer except to Such a step does not require coordination with the peer except to
decide what CA authority will be used. decide what CA authority will be used.
6. Security Requirements 6. Security Considerations
This section describes requirements for BGP, LDP, PCEP and MSDP This section describes security considerations that BGP, LDP, PCEP
security that should be met within the routing protocol. 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.
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 This 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
skipping to change at page 15, line 8 skipping to change at page 15, line 8
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.
7. 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 providing comments on it. draft and to Anantha Ramaiah and Mach Chen for providing comments on
it.
8. References 8. References
8.1. Normative References 8.1. Normative References
[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.
[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,
skipping to change at page 16, line 43 skipping to change at page 16, line 43
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003. Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery
Protocol (MSDP)", RFC 3618, October 2003.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
Service Considerations", RFC 4732, December 2006. Service Considerations", RFC 4732, December 2006.
[RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the
IAB workshop on Unwanted Traffic March 9-10, 2006", IAB workshop on Unwanted Traffic March 9-10, 2006",
RFC 4948, August 2007. RFC 4948, August 2007.
skipping to change at page 18, line 26 skipping to change at page 18, line 26
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 Huawei Technologies
No. 3 Xinxi Road, Hai-Dian District
Beijing, 100085
China China
Phone: +86 (10) 82882008 Phone: +86 (10) 82882008
Fax: Fax:
Email: verozheng@huawei.com Email: vero.zheng@huawei.com
URI: URI:
 End of changes. 45 change blocks. 
120 lines changed or deleted 138 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/