One document matched: draft-mahesh-karp-lmp-analysis-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-mahesh-karp-lmp-analysis-00.txt"
ipr="trust200902">
<front>
<title abbrev="RSVP-TE Analysis">Analysis of LMP Security 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>+1 (408) 436-3313</phone>
<email>mjethanandani@gmail.com</email>
</address>
</author>
<date day="8" month="July" year="2013" />
<area>Network</area>
<workgroup>Routing Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document analyzes Link Management Protocol (LMP) according to
guidelines set forth in section 4.2 of KARP Design Guidelines (RFC
6518).</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 suggested 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 LMP according to the
requirements of <xref target="RFC6518">KARP Design Guidelines </xref>.
This draft builds on several previous analysis efforts into routing
security:</t>
<t><list style="symbols">
<t><xref target="RFC6039">Issues with existing Cryptographic
Protection Methods for Routing Protocols</xref> an analysis of
cryptographic issues with routing protocols.</t>
<t><xref target="RFC6863">Analysis of OSPF Security According to
KARP Design Guide</xref>.</t>
<t><xref target="RFC6952">Analysis of BGP, LDP, PCEP, and MSDP
Issues According to KARP Design Guide</xref> which is a analysis of
the four routing protocols.</t>
</list></t>
<t><xref target="RFC4204">Link Management Protocol (LMP)</xref> is used
to manage Traffic Engineering (TE) links. According to the document, LMP
can be subject to a number of attacks. Some examples include:</t>
<t><list style="symbols">
<t>an adversary may spoof control packets</t>
<t>an adversary may modify the control packet in transit</t>
<t>an adversary may replay control packets</t>
<t>an adversary may study a number of control packets and try to
break the key using cryptographic tools.</t>
</list></t>
<t>Section 2 looks at the current security state of LMP. Section 3
suggest an optimal security state and section 4 does an analysis of the
gap between the existing and the optimal security state of the protocol
and suggest some areas where we need to improve.</t>
<section title="Abbreviations">
<t>LMP - Link Management Protocol</t>
<t>TE - Traffic Engineering</t>
</section>
</section>
<section title="Current Assessment of LMP">
<t>This section looks at LMP procedure, the underlying transport layer
and security assessment associated with LMP.</t>
<section title="LMP Procedure">
<t>The two core procedures of LMP procedure are control channel
management and link property correlation. Control channel management
is used to establish and maintain control channels between adjacent
nodes. This is done using a Config message exchange and a fast
keep-alive mechanism between the nodes. Link property correlation is
used to synchronize the TE link properties and verify the TE link
configuration.</t>
<t>Two additional procedures include link connectivity verification
and fault management. Link connectivity verification is used for data
plane discovery, Interface_Id exchange, and physical connectivity
verification. This is done by sending Test messages over the data
channel and the TestStatus messages coming back over the control
plane. The LMP link connectivity verification procedure is coordinated
using the BeginVerify message exchanged over the control channel.</t>
<t>The LMP fault management procedure is based on a ChannelStatus
message exchange. The ChannelStatus message is sent unsolicited and is
used to notify an LMP neighbor about the status of one or more data
channels. ChannelStatusAck is used to acknowledge receipt of the
ChannelStatus message. Similarly, a ChannelStatusResponse message is
used to acknowledge receipt of a ChannelStatusRequest message.</t>
</section>
<section title="Transport Layer">
<t>Except for Test messages, all LMP packets use UDP to communicate
with its piers over a LMP port number. Multiple "LMP adjacencies" may
be formed and be active between two nodes. LMP messages are
transmitted reliably using Message_Ids and retransmissions.</t>
<t>Unlike TCP which can use <xref target="RFC5925">TCP-AO</xref> for
message authentication, UDP does not have any of authenticating
packets.</t>
</section>
<section title="Message Integrity and Node Authentication">
<t><xref target="RFC4204">LMP</xref> recommends the use of IPSec for
authentication. That document also states that there is currently no
requirement that LMP headers or payload be encrypted. It also states
that LMP endpoint identity does not need to be protected.</t>
<t>To authenticate LMP, the document further states that manual keying
mode be supported. However, it notes that manual keying cannot
effectively support replay protection and automatic re-keying. It
therefore recommends that manual keying should only be used for
diagnostic purposes and only use automatic re-keying for replay
protection and automatic re-keying.</t>
</section>
<section title="Replay Attack">
<t>MESSAGE_ID and MESSAGE_ID_ACK objects are included in the LMP
messages to support reliable message delivery. The Message_Id field of
the MESSAGE_ID object contains a generator selected value. This value
is supposed to be monotonically increasing. A value is considered to
be used when it has been sent in an LMP message with the same CC_Id or
LMP adjacency. The Message_Id field of the MESSAGE_ID_ACK contains the
Message_Id field of the message being acknowledged.</t>
<t>Unacknowledged messages sent with the MESSAGE_ID object are to be
retransmitted until the message is acknowledged or until a retry limit
is reached. The Message_Id field is 32 bit wide and may wrap.</t>
<t>The 32-bit Message_Id number space is not large enough to guarantee
that the Message_Id number will not wrap around within a reasonable
long period. Therefore, the system is susceptible to a replay
attack.</t>
<t>In addition, LMP does not provide for a generation of a unique
monotonically increasing sequence numbers across a failure or a
restart.</t>
</section>
<section title="Out-of-order Protection">
<t>LMP states that nodes processing incoming messages are supposed to
check to see if the newly received message is out of order messages,
and if so, they are to be ignored and dropped silently.</t>
<t>Specifically, if the message is a Config message, and the
Message_Id value is less than the largest Message_Id value previously
received from the sender for the CC_Id, then the message is supposed
to be treated as being out-of-order. If the message is a LinkSummary
message and the Message_Id value is less than the largest Message_Id
value previously received from the sender of the TE link, then the
message is supposed to be treated as being out-of-order. Similarly, if
the message is a ChannelStatus message and the Message_Id value is
less than the largest Message_id value previously received from he
sender of the specific TE link, then the receiver is supposed to check
for the Message_Id value previously received from the state of each
data channel included in the ChannelStatus message. If the Message_Id
value associated with at least one of the data channels included in
the message, the message is not supposed to be treated as
out-of-order. All other messages are not supposed to be treated as
out-of-order.</t>
</section>
</section>
<section title="Security Requirements for LMP">
<t><xref target="RFC4204">LMP</xref> states that the following
requirements should be applied to secure the protocol.</t>
<t><list style="symbols">
<t>LMP security must be able to provide authentication, integrity
and replay protection.</t>
<t>Confidentiality is not needed for LMP traffic.</t>
<t>The protection of identity of the LMP end-points is not commonly
required.</t>
<t>The security mechanism should provide for a well defined key
management scheme. The key management scheme should be scalable and
should provide for automatic key rollover.</t>
<t>The algorithm used for authentication must be cryptographically
sound and it should provide for algorithm agility.</t>
</list></t>
</section>
<section title="Gap Analysis for LMP">
<t>This section outlines the differences between the current state of
LMP and the desired state as outlined in sections 4.1 and 4.2 of <xref
target="RFC6518">KARP Design Guidelines </xref>.</t>
<section title="Replay Protection">
<t>As outlined above, LMP protocol is subject to replay attacks.
Solutions to replay protection include:</t>
<t><list style="numbers">
<t>Maintaining Message_Id numbers in stable memory</t>
<t>Introducing the data from a local time clock into the
generation of Message_Id numbers after a restart</t>
<t>Introducing the timing information from a Network Recovered
Clock into the generation of Message_Id numbers after a
restart.</t>
</list>In addition, a handshake is defined for a receiver to get the
latest value of a Message_Id number. Therefore, this solution is
effective in addressing the issues caused by the rollback of
Message_Id numbers across a system restart or failure. However, when a
router uses the approach to generating Message_Id numbers with the
time information from NTP, an attacker may try to deceive the router
to generate a Message_Id number which is less than the Message_Id
numbers it used to have, by sending replayed or foiled NTP
information.</t>
</section>
</section>
<section title="IANA Requirements">
<t>This document makes no IANA requests, and the RFC Editor may consider
deleting this section on publication of this document as a RFC.</t>
</section>
<section title="Security Consideration">
<t>This document is all about security considerations for LMP.</t>
</section>
<section title="Acknowledgements">
<t></t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.4204"?>
<?rfc include='reference.RFC.6518'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.4948'?>
<?rfc include='reference.RFC.5925'?>
<?rfc include='reference.RFC.6039'?>
<?rfc include='reference.RFC.6863'?>
<?rfc include='reference.RFC.6952'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:15:00 |