One document matched: draft-ietf-karp-routing-tcp-analysis-07.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<rfc category="info" docName="draft-ietf-karp-routing-tcp-analysis-07.txt"
ipr="trust200902">
<front>
<title abbrev="BGP, LDP, PCEP and MSDP Analysis">Analysis of BGP, LDP,
PCEP and MSDP Issues According to KARP Design Guide</title>
<author fullname="Mahesh Jethanandani" initials="M."
surname="Jethanandani">
<organization>Ciena Corporation</organization>
<address>
<postal>
<street>1741 Technology Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95110</code>
<country>USA</country>
</postal>
<phone>+ (408) 436-3313</phone>
<email>mjethanandani@gmail.com</email>
</address>
</author>
<author fullname="Keyur Patel" initials="K." surname="Patel">
<organization>Cisco Systems, Inc</organization>
<address>
<postal>
<street>170 Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 (408) 526-7183</phone>
<email>keyupate@cisco.com</email>
</address>
</author>
<author fullname="Lianshu Zheng" initials="L." surname="Zheng">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>China</country>
</postal>
<phone>+86 (10) 82882008</phone>
<facsimile></facsimile>
<email>vero.zheng@huawei.com</email>
<uri></uri>
</address>
</author>
<date day="8" month="April" year="2013" />
<area>Network</area>
<workgroup>Routing Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document analyzes TCP based routing protocols, Border Gateway
Protocol (BGP), Label Distribution Protocol (LDP), Path Computation
Element Communication Protocol (PCEP), and Multicast Source Distribution
Protocol (MSDP) according to guidelines set forth in section 4.2 of
Keying and Authentication for Routing Protocols Design Guidelines
(RFC6518).</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>In March 2006, the Internet Architecture Board (IAB) described an
attack on core routing infrastructure as an ideal attack that would
inflict the greatest amount of damage, in their <xref
target="RFC4948">Report from the IAB workshop on Unwanted Traffic March
9-10, 2006</xref>, and suggests steps to tighten the infrastructure
against the attack. Four main steps were identified for that
tightening:</t>
<t><list style="numbers">
<t>Create secure mechanisms and practices for operating routers.</t>
<t>Clean up the Internet Routing Registry (IRR) repository, and
securing both the database and the access, so that it can be used
for routing verifications.</t>
<t>Create specifications for cryptographic validation of routing
message content.</t>
<t>Secure the routing protocols' packets on the wire.</t>
</list></t>
<t>In order to secure the routing protocols this document performs an
initial analysis of the current state of the following TCP based
protocols: BGP, LDP, PCEP, and MSDP according to the requirements of
<xref target="RFC6518">KARP Design Guidelines </xref>. Section 4.2 of
the document uses the term "state" which will be referred to as the
"state of the security method". Thus a term like "Define Optimal State"
would be referred to as "Define Optimal State of the Security Method".
This document builds on several previous analysis efforts into routing
security.</t>
<t>This document builds on several previous efforts into routing
security:</t>
<t><list style="symbols">
<t><xref target="RFC6039">Issues with existing Cryptographic
Protection Methods for Routing Protocols</xref>, describes issues
with existing cryptographic protection methods for routing
protocols.</t>
<t><xref target="RFC6863">Analysis of OSPF Security According to
KARP Design Guide</xref> analyzes Open Shortest Path First (OSPF)
security according to KARP Design Guide.</t>
</list></t>
<t>Section 2 of this document looks at the current state of the security
method for the four routing protocols, BGP, LDP, PCEP and MSDP. Section
3 examines what the optimal state of the security method would be for
the four routing protocols, according to <xref target="RFC6518">KARP
Design Guidelines </xref> and Section 4 does an analysis of the gap
between 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.</t>
<section title="Abbreviations">
<t>AES - Advanced Encryption Standard</t>
<t>AO - Authentication Option</t>
<t>AS - Autonomous Systems</t>
<t>BGP - Border Gateway Protocol</t>
<t>CMAC - Ciper Based MAC</t>
<t>DoS - Denial of Service</t>
<t>GTSM - Generalized TTL Security Mechanism</t>
<t>HMAC - Hash Based MAC</t>
<t>KARP - Key and Authentication for Routing Protocols</t>
<t>KDF - Key Derivation Function</t>
<t>KEK - Key Encrypting Key</t>
<t>KMP - Key Management Protocol</t>
<t>LDP - Label Distribution Protocol</t>
<t>LSR - Label Switching Routers</t>
<t>MAC - Message Authentication Code</t>
<t>MKT - Master Key Tuple</t>
<t>MSDP - Multicast Source Distribution Protocol</t>
<t>MD5 - Message Digest algorithm 5</t>
<t>OSPF - Open Shortest Path First</t>
<t>PCEP - Path Computation Element Communication Protocol</t>
<t>PCC - Path Computation Client</t>
<t>PCE - Path Computation Element</t>
<t>SHA - Security Hash Algorithm</t>
<t>TCP - Transmission Control Protocol</t>
<t>TTL - Time To Live</t>
<t>UDP - User Datagram Protocol</t>
<t>WG - Working Group</t>
</section>
</section>
<section title="Current Assessment of BGP, LDP, PCEP and MSDP">
<t>This section assesses the transport protocols for any authentication
or integrity mechanisms used by the protocol. It describes the current
security mechanisms if any used by BGP, LDP, PCEP and MSDP.</t>
<section title="Transport layer">
<t>At a transport layer, routing protocols are subject to a variety of
DoS attacks, as outlined in <xref target="RFC4732">Internet
Denial-of-Service Considerations</xref>. Such attacks can cause the
routing protocol to become congested with the result that routing
updates are supplied too slowly to be useful. In extreme cases, these
attacks prevent routers from converging after a change.</t>
<t>Routing protocols use several methods to protect themselves. Those
that use TCP as a transport protocol use access lists to accept
packets only from known sources. These access lists also help protect
edge routers from attacks originating outside the protected domain. In
addition, for edge routers running eBGP, TCP LISTEN is run only on
interfaces on which its peers have been discovered or via which
routing sessions are expected (as specified in router configuration
databases).</t>
<t><xref target="RFC5082">Generalized TTL Security Mechanism (GTSM)
</xref> describes a generalized Time to Live (TTL) security mechanism
to protect a protocol stack from CPU-utilization based attacks.<xref
target="RFC5961"> TCP Robustness</xref> recommends some TCP level
mitigations against spoofing attacks targeted towards long-lived
routing protocol sessions.</t>
<t>Even when BGP, LDP, PCEP and MSDP sessions use access lists, they
are vulnerable to spoofing and man in the middle attacks.
Authentication and integrity checks allow the receiver of a routing
protocol update to know that the message genuinely comes from the node
that claims to have sent it, and to know whether the message has been
modified. Sometimes routers can be subjected to a large number of
authentication and integrity requests, exhausting connection resources
on the router in a way that could lead to deny genuine requests.</t>
<t><xref target="RFC2385">TCP MD5</xref> has been obsoleted by <xref
target="RFC5925">TCP-AO</xref>. However, 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 segment. This digest is
computed using information known only to the end points and this
ensures authenticity and integrity of messages. The MD5 key used to
compute the digest is stored locally on the router. This option is
used by routing protocols to provide for session level protection
against the introduction of spoofed TCP segments into any existing TCP
streams, in particular TCP Reset segments. TCP MD5 does not provide a
generic mechanism to support key roll-over. It also does not support
algorithm agility.</t>
<t>The Message Authentication Codes (MACs) used by TCP MD5 option, is
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.
Furthermore, TCP MD5 does not support any algorithm agility. <xref
target="RFC5925">TCP-AO </xref>, and its companion document <xref
target="RFC5926">Crypto Algorithms for TCP-AO</xref>, describe steps
towards correcting both the MAC weakness and the management of secret
keys. For MAC it requires that two MAC algorithms be supported. They
are HMAC-SHA-1-96 as specified in <xref target="RFC2104">HMAC</xref>,
and AES-128-CMAC-96 as specified in <xref
target="NIST-SP800-38B">NIST-SP800-38B</xref>. Cryptographic research
suggests that both these MAC algorithms defined are fairly secure. By
supporting multiple MAC algorithms, TCP-AO supports algorithm agility.
TCP-AO also allows additional MACs to be added in the future.</t>
</section>
<section title="Keying mechanisms">
<t>For <xref target="RFC5925">TCP-AO</xref> there is no Key Management
Protocol (KMP) used to manage the keys that are employed to generate
the Message Authentication Code (MAC). TCP-AO talks about coordinating
keys derived from Master Key Table (MKT) between endpoints and allows
for a master key to be configured manually or for it to be managed via
a out of band mechanism.</t>
<t>It should be noted that most routers configured with static keys
have not seen the key changed ever. The common reason given for not
changing the key is the difficulty in coordinating the change between
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 guessed or
exposed e.g. when an administrator with knowledge of the keys leaves
the company.</t>
<t>For point-to-point key management <xref
target="RFC5996">IKEv2</xref> protocol provides for automated key
exchange under a SA, and can be used for a comprehensive Key
Management Protocol (KMP) solution for routers. IKEv2 can be used for
both <xref target="RFC4301">IPsec SAs</xref> and other types of SAs.
For example, <xref target="RFC4595">Fibre Channel SAs</xref> are
currently negotiated with IKEv2. Using IKEv2 to negotiate TCP-AO is a
possible option.</t>
</section>
<section title="BGP">
<t>All BGP communications take place over TCP. Therefore, all security
vulnerabilities for BGP can be categorised as relating to the security
of the transport protocol itself, or to the compromising of individual
routers and the data they handle. This document examines 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 described in
<xref target="RFC6480">An Infrastructure to Support Secure Internet
Protocol</xref>.</t>
</section>
<section title="LDP">
<t><xref target="RFC5920">Security Framework for MPLS and GMPLS
Networks</xref> outlines security aspects that are relevant in the
context of MPLS and GMPLS. It describes the security threats, the
related defensive techniques, and the mechanism for detection and
reporting.</t>
<t>Section 5 of <xref target="RFC5036">LDP</xref> states that LDP is
subject to two different types of attacks: spoofing, and denial of
service attacks.</t>
<section title="Spoofing attacks">
<t>A spoofing attack against LDP can occur both during the discovery
phase and during the session communication phase.</t>
<section title="Discovery exchanges using UDP">
<t>Label Switching Routers (LSRs) indicate their willingness to
establish and maintain LDP sessions by periodically sending 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 one.</t>
<t>There are two variants of the discovery mechanism. A Basic
Discovery mechanism that is used to discover LSR neighbors that
are directly connected at the link level and a Extended Discovery
mechanism that is used by LSRs that are more than one hop
away.</t>
<t>Unlike all other LDP messages, the Hello messages are sent
using UDP. This means that they cannot benefit from the security
mechanisms available with TCP. <xref target="RFC5036">LDP</xref>
does not provide any security mechanisms for use with Hello
messages except for some configuration which may help protect
against bogus discovery events. These configurations include
directly connected links and interfaces. Routers that do not use
directly connected links have to use Extended Discovery mechanism,
and will not be able to use configuration to protect against bogus
discovery events.</t>
<t>Spoofing a Hello packet for an existing adjacency can cause the
adjacency to time out and result in termination of the associated
session. This can occur when the spoofed Hello message specifies a
small Hold Time, causing the receiver to expect Hello messages
within this interval, while the true neighbor continues sending
Hello messages at the lower, previously agreed to frequency.</t>
<t>Spoofing a Hello packet can also cause the LDP session to be
terminated. This can occur when the spoofed Hello specifies a
different Transport Address from the previously agreed one between
neighbors. Spoofed Hello messages are observed and reported as
real problem in production networks.</t>
</section>
<section title="Session communication using TCP">
<t>LDP like other TCP based routing protocols specifies use of the
TCP MD5 Signature Option to provide for the authenticity and
integrity of session messages. As stated in section 2.1 of this
document and in section 2.9 of <xref target="RFC5036">LDP </xref>,
MD5 authentication is considered too weak for this application as
outlined in <xref target="RFC6151">MD5 and HMAC-MD5 Security
Considerations</xref>. It also does not support algorithm agility.
A stronger hashing algorithm e.g SHA1, which is supported by <xref
target="RFC5925">TCP-AO</xref> could be deployed to take care of
the weakness.</t>
<t>Alternatively, one could move to using TCP-AO which provides
for stronger MAC algorithms, makes it easier to setup manual keys
and protects against replay attacks.</t>
</section>
</section>
<section title="Denial of Service Attacks">
<t>LDP is subject to Denial of Service (DoS) attacks both in its
discovery mode and in session mode. These are documented in Section
5.3 of <xref target="RFC5036">LDP</xref>.</t>
</section>
</section>
<section title="PCEP">
<t>For effective selection by PCCs, a PCC needs to know the location
of PCEs in its domain along with some information relevant for PCE
selection. Such PCE information could be learned through manual
configuration, on each PCC, along with their capabilities or
automatically through a PCE discovery mechanism as outlined in <xref
target="RFC4674">Requirements for PCE Discovery</xref>.</t>
<t>Attacks on <xref target="RFC5440">PCEP</xref> may result in damage
to active networks. These include computation responses, which if
changed can cause protocols like <xref target="RFC3209">RSVP-TE</xref>
to setup sub-optimal or inappropriate LSPs. In addition, PCE itself
can attacked by a variety of DoS attacks. Such attacks can cause path
computations to be supplied too slowly to be of any value particularly
as it relates to recovery or establishment of LSPs.</t>
<t>Finally, PCE discovery as outlined in <xref target="RFC5088">OSPF
Protocol Extensions for PCE Discovery </xref> and <xref
target="RFC5089">IS-IS Protocol Extensions for PCE Discovery</xref> is
a significant feature for the successful deployment of PCEP in large
networks. These mechanisms allow PCC to discover the existence of PCEs
within the network. If the discovery mechanism is compromised, it will
impair the ability of the nodes to function as described below.</t>
<t>As RFC 5440 states, PCEP which makes use of TCP as a transport,
could be the target of the following attacks:</t>
<t><list style="symbols">
<t>Spoofing (PCC or PCE implementation)</t>
<t>Snooping (message interception)</t>
<t>Falsification</t>
<t>Denial of Service</t>
</list></t>
<t>In inter-Autonomous Systems (AS) scenarios where PCE-to-PCE
communication is required, attacks may be particularly significant
with commercial as well as service-level agreement implications.</t>
<t>Additionally, snooping of PCEP requests and responses may give an
attacker information about the operation of the network. By viewing
the PCEP messages an attacker can determine the pattern of service
establishment in the network, and can know where traffic is being
routed, thereby making the network susceptible to targeted attacks and
the data within specific LSPs vulnerable.</t>
<t>Ensuring PCEP communication privacy is of key importance,
especially in an inter-AS context, where PCEP communication end-points
do not reside in the same AS. An attacker that intercepts a PCE
message could obtain sensitive information related to computed paths
and resources.</t>
<t>At the time PCEP was documented in <xref target="RFC5440"></xref>,
TCP-AO had not been fully specified. Therefore, <xref
target="RFC5440"></xref> mandates that PCEP implementations include
support for TCP-MD5, and that use of the function should be
configurable by the operator. <xref target="RFC5440"></xref> also
describes the vulnerabilities and weaknesses of TCP-MD5 as noted in
this document. <xref target="RFC5440"></xref> goes on to state that
PCEP implementations should include support for TCP-AO as soon as that
specification is complete. Since <xref target="RFC5925">TCP-AO</xref>
has now been published, new PCEP implementation should fully support
TCP-AO.</t>
</section>
<section title="MSDP">
<t>Similar to BGP and LDP, Multicast Source Distribution Protocol
(MSDP) uses <xref target="RFC2385">TCP MD5</xref> to protect TCP
sessions via the TCP MD5 option. But with a weak MD5 authentication,
TCP MD5 is not considered strong enough for this application. It also
does not support algorithm agility.</t>
<t>MSDP also advocates imposing a limit on number of source address
and group addresses (S,G) that can be cached within the protocol and
thereby mitigate state explosion due to any denial of service and
other attacks.</t>
</section>
</section>
<section title="Optimal State for BGP, LDP, PCEP, and MSDP">
<t>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 attacks.
The protocols also need to support algorithm agility, i.e. they must not
hardwire themselves to one algorithm.</t>
<t>Additionally, Key Management Protocol (KMP) for the routing sessions
should help negotiate unique, pair wise random keys without
administrator involvement. It should also negotiate Security Association
(SA) parameters required for the session connection, including key life
times. It should keep track of those lifetimes and negotiate new keys
and parameters before they expire and do so without administrator
involvement. In the event of a breach, including when an administrator
with knowledge of the keys leaves the company, the keys should be
changed immediately.</t>
<t>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 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 that does
not impact legitimate packets.</t>
<t>The routing protocols should provide a mechanism to authenticate the
routing information carried within the payload and administrators should
enable it.</t>
<section title="LDP">
<t>To harden LDP against its current vulnerability to spoofing
attacks, LDP needs to be upgraded such that an implementation is able
to determine the authenticity of the neighbors sending the Hello
message.</t>
<t>Labels are similar to routing information which is distributed in
the clear. However, there is currently no requirement that the labels
be encrypted. And stated before, is currently out of scope of this
document.</t>
<t>Similarly, it is important to ensure that routers exchanging labels
are mutually authenticated, and that there are no rogue peers or
unauthenticated peers that can compromise the stability of the
network.</t>
</section>
</section>
<section title="Gap Analysis for BGP, LDP, PCEP and MSDP">
<t>This section outlines the differences between the current state of
the security methods for routing protocols, and the desired state of the
security methods as outlined in section 4.2 of <xref
target="RFC6518">KARP Design Guidelines </xref>. As that document
states, these routing protocols fall into the category of one-to-one
peering messages and will use peer keying protocol. It covers issues
that are common to the four protocols in this section, leaving protocol
specific issues to sub-sections.</t>
<t>At a transport level these routing protocols are subject to some of
the same attacks that TCP applications are subject to. These include DoS
and spoofing attacks. <xref target="RFC4732">Internet Denial-of-Service
Considerations</xref> outlines some solutions. <xref
target="RFC4953">Defending TCP Against Spoofing Attacks</xref>
recommends ways to prevent spoofing attacks. In addition, the
recommendations in <xref target="RFC5961"></xref> should also be
followed and implemented to strengthen TCP.</t>
<t>Routers lack comprehensive key management and keys derived from it
that they can use to authenticate data. As an example <xref
target="RFC5925">TCP-AO</xref>, talks about coordinating keys derived
from Master Key Table (MKT) between endpoints, but the MKT itself has to
be configured manually or through an out of band mechanism. Also TCP-AO
does not address the issue of connectionless reset, as it applies to
routers that do not store MKT across reboots.</t>
<t>Authentication, integrity protection, and encryption all require the
use of keys by sender and receiver. An automated KMP therefore has to
include a way to distribute key material between two end points with
little or no administration overhead. It has to cover automatic key
rollover. 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 layer 2 header.</t>
<t>There are two methods of automatic key rollover. Implicit key
rollover can be initiated after certain volume of data gets exchanged 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 way
that the links/adjacencies are affected. On the other hand, explicit key
rollover requires an out of band key signaling mechanism. It can be
triggered by either side and can be done anytime a security parameter
changes e.g. an attack has happened, or a system administrator with
access to the keys has left the company. An example of this is <xref
target="RFC5996">IKEv2</xref>, but it could be any other new mechanisms
also.</t>
<t>As stated earlier <xref target="RFC5925">TCP-AO</xref>, and its
accompanying document <xref target="RFC5926">Crypto Algorithms for
TCP-AO </xref>, requires that two MAC algorithms be supported, and they
are HMAC-SHA-1-96 as specified in <xref target="RFC2104">HMAC</xref>,
and AES-128-CMAC-96 as specified in <xref
target="NIST-SP800-38B">NIST-SP800-38B</xref>. Therefore, TCP-AO meets
the algorithm agility requirement.</t>
<t>There is a need to protect authenticity and validity of the
routing/label information that is carried in the payload of the
sessions. However, that is outside the scope of this document and is
being addressed by SIDR WG. Similar mechanisms could be used for
intra-domain protocols.</t>
<t>Finally, replay protection is required. The replay mechanism needs to
be sufficient to prevent an attacker from creating a denial of service
or disrupting the integrity of the routing protocol by replaying
packets. It is important that an attacker not be able to disrupt service
by capturing packets and waiting for replay state to be lost.</t>
<section title="LDP">
<t>As described in <xref target="RFC5036">LDP</xref>, the threat of
spoofed Basic Hellos can be reduced by only accepting Basic Hellos on
interfaces that LSRs trust, employing <xref
target="RFC5082">GTSM</xref> and ignoring Basic Hellos not addressed
to the "all routers on this subnet" multicast group. Spoofing attacks
via Targeted Hellos are potentially a more serious threat. An LSR can
reduce the threat of spoofed Extended Hellos by filtering them and
accepting Hellos from sources permitted by an access lists. However,
performing the filtering using access lists requires LSR resource, and
the LSR is still vulnerable to the IP source address spoofing.
Spoofing attacks can be solved by being able to authenticate the Hello
messages, and an LSR can be configured to only accept Hello messages
from specific peers when authentication is in use.</t>
<t><xref target="draft-zheng-mpls-ldp-hello-crypto-auth-04">LDP Hello
Cryptographic Authentication</xref> suggest a new Cryptographic
Authentication TLV that can be used as an authentication mechanism to
secure Hello messages.</t>
</section>
<section title="PCEP">
<t>Path Computation Element (PCE) discovery according to <xref
target="RFC5440">its RFC</xref>, is a significant feature for the
successful deployment of 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 that, where PCEs are discovered and not configured,
the PCC cannot 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 and a keying mechanism, the need for which has been
discussed above.</t>
</section>
</section>
<section title="Transition and Deployment Considerations">
<t>As stated in <xref target="RFC6518">KARP Design Guidelines</xref>, it
is imperative that the new authentication, security mechanisms defined,
and key management protocol support incremental deployment, as it is not
feasible to deploy the new routing protocol authentication mechanism
overnight.</t>
<t>Typically, authentication and security in a peer-to-peer protocol
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 fail or
will be deferred. Upon failure, the routing protocols can fallback to
the mechanisms that were already in place e.g. use 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 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 a said period of time, so a manual
coordination is not required.</t>
<t>If the automatic KMP requires use of <xref target="RFC5280">Public
Key Infrastructure Certificates</xref> to exchange key material, the
required Certificate Authority (CA) root certificates may need to be
installed to verify authenticity of requests initiated by a peer. Such a
step does not require coordination with the peer except to decide what
CA authority will be used.</t>
</section>
<section title="Security Considerations">
<t>This section describes security considerations that BGP, LDP, PCEP
and MSDP should try to meet.</t>
<t>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 with
per-packet protection using a cryptographic MAC. In order to provide for
the MAC, keys are needed.</t>
<t>The routing protocols need to support algorithm agility, i.e. they
must not hardwire themselves to one algorithm.</t>
<t>Once keys are used, mechanisms are required to support key rollover.
This should cover both manual and automatic key rollover. Multiple
approaches could be used. However, since the existing mechanisms provide
a protocol field to identify the key as well as management mechanisms to
introduce and retire new keys, focusing on the existing mechanism as a
starting point is prudent.</t>
<t>Furthermore, it is strongly suggested that these routing protocols
need to support algorithm agility. It has been proven that algorithms
weaken over time. Supporting algorithm agility assists in smooth
transition from old to new algorithms.</t>
</section>
<section title="IANA Considerations">
<t>None.</t>
</section>
<section title="Acknowledgements">
<t>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
it.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.6518'?>
<?rfc include='reference.RFC.5926'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.2104'
?>
<?rfc include='reference.RFC.2119'
?>
<?rfc include='reference.RFC.2385'?>
<?rfc include='reference.RFC.3209'?>
<?rfc include='reference.RFC.3618'?>
<?rfc include="reference.RFC.4271"
?>
<?rfc include='reference.RFC.4301'?>
<?rfc include='reference.RFC.4595'?>
<?rfc include='reference.RFC.4674'?>
<?rfc include='reference.RFC.4732'?>
<?rfc include='reference.RFC.4948'?>
<?rfc include='reference.RFC.4953'?>
<?rfc include="reference.RFC.5036"
?>
<?rfc include='reference.RFC.5082'?>
<?rfc include='reference.RFC.5088'?>
<?rfc include='reference.RFC.5089'?>
<?rfc include='reference.RFC.5280'?>
<?rfc include='reference.RFC.5440'?>
<?rfc include='reference.RFC.5920'?>
<?rfc include='reference.RFC.5925'?>
<?rfc include='reference.RFC.5961'?>
<?rfc include='reference.RFC.5996'?>
<?rfc include='reference.RFC.6039'?>
<?rfc include='reference.RFC.6151'?>
<?rfc include='reference.RFC.6480'?>
<?rfc include='reference.RFC.6863'?>
<reference anchor="NIST-SP800-38B">
<front>
<title>Recommendation for Block Cipher Modes of Operation: The CMAC
Mode for Authentication</title>
<author fullname="Morris Dworking" surname="Dworking">
<organization>National Institute of Standards and
Technology</organization>
</author>
<date month="May" year="2005" />
</front>
</reference>
<reference anchor="draft-zheng-mpls-ldp-hello-crypto-auth-04">
<front>
<title>LDP Hello Cryptographic Authentication</title>
<author fullname="Lianshu Zheng" surname="Zheng">
<organization>Huawei Technologies, Ltd</organization>
</author>
<date day="10" month="May" year="2012" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 17:37:29 |