Internet DRAFT - draft-mahesh-karp-lmp-analysis
draft-mahesh-karp-lmp-analysis
Routing Working Group M. Jethanandani
Internet-Draft Ciena Corporation
Intended status: Informational February 11, 2014
Expires: August 15, 2014
Analysis of LMP Security According to KARP Design Guide
draft-mahesh-karp-lmp-analysis-01.txt
Abstract
This document analyzes Link Management Protocol (LMP) according to
guidelines set forth in section 4.2 of KARP Design Guidelines (RFC
6518).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 15, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Jethanandani Expires August 15, 2014 [Page 1]
Internet-Draft RSVP-TE Analysis February 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
2. Current Assessment of LMP . . . . . . . . . . . . . . . . . . 3
2.1. LMP Procedure . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Transport Layer . . . . . . . . . . . . . . . . . . . . . 4
2.3. Message Integrity and Node Authentication . . . . . . . . 4
2.4. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Out-of-order Protection . . . . . . . . . . . . . . . . . 5
3. Security Requirements for LMP . . . . . . . . . . . . . . . . 6
4. Gap Analysis for LMP . . . . . . . . . . . . . . . . . . . . 6
4.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 6
5. IANA Requirements . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Consideration . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
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 Report from the IAB
workshop on Unwanted Traffic March 9-10, 2006 [RFC4948], and
suggested steps to tighten the infrastructure against the attack.
Four main steps were identified for that tightening:
1. Create secure mechanisms and practices for operating routers.
2. 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.
3. Create specifications for cryptographic validation of routing
message content.
4. Secure the routing protocols' packets on the wire.
In order to secure the routing protocols this document performs an
initial analysis of the current state of LMP according to the
requirements of KARP Design Guidelines [RFC6518]. This draft builds
on several previous analysis efforts into routing security:
Jethanandani Expires August 15, 2014 [Page 2]
Internet-Draft RSVP-TE Analysis February 2014
o Issues with existing Cryptographic Protection Methods for Routing
Protocols [RFC6039] an analysis of cryptographic issues with
routing protocols.
o Analysis of OSPF Security According to KARP Design Guide
[RFC6863].
o Analysis of BGP, LDP, PCEP, and MSDP Issues According to KARP
Design Guide [RFC6952] which is a analysis of the four routing
protocols.
Link Management Protocol (LMP) [RFC4204] is used to manage Traffic
Engineering (TE) links. According to the document, LMP can be
subject to a number of attacks. Some examples include:
o an adversary may spoof control packets
o an adversary may modify the control packet in transit
o an adversary may replay control packets
o an adversary may study a number of control packets and try to
break the key using cryptographic tools.
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.
1.1. Abbreviations
LMP - Link Management Protocol
TE - Traffic Engineering
2. Current Assessment of LMP
This section looks at LMP procedure, the underlying transport layer
and security assessment associated with LMP.
2.1. LMP Procedure
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
Jethanandani Expires August 15, 2014 [Page 3]
Internet-Draft RSVP-TE Analysis February 2014
to synchronize the TE link properties and verify the TE link
configuration.
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.
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.
2.2. Transport Layer
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.
Unlike TCP which can use TCP-AO [RFC5925] for message authentication,
UDP does not have any of authenticating packets.
2.3. Message Integrity and Node Authentication
LMP [RFC4204] 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.
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.
Jethanandani Expires August 15, 2014 [Page 4]
Internet-Draft RSVP-TE Analysis February 2014
2.4. Replay Attack
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.
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.
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.
In addition, LMP does not provide for a generation of a unique
monotonically increasing sequence numbers across a failure or a
restart.
2.5. Out-of-order Protection
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.
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.
Jethanandani Expires August 15, 2014 [Page 5]
Internet-Draft RSVP-TE Analysis February 2014
3. Security Requirements for LMP
LMP [RFC4204] states that the following requirements should be
applied to secure the protocol.
o LMP security must be able to provide authentication, integrity and
replay protection.
o Confidentiality is not needed for LMP traffic.
o The protection of identity of the LMP end-points is not commonly
required.
o 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.
o The algorithm used for authentication must be cryptographically
sound and it should provide for algorithm agility.
4. Gap Analysis for LMP
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 KARP
Design Guidelines [RFC6518].
4.1. Replay Protection
As outlined above, LMP protocol is subject to replay attacks.
Solutions to replay protection include:
1. Maintaining Message_Id numbers in stable memory
2. Introducing the data from a local time clock into the generation
of Message_Id numbers after a restart
3. Introducing the timing information from a Network Recovered Clock
into the generation of Message_Id numbers after a restart.
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.
Jethanandani Expires August 15, 2014 [Page 6]
Internet-Draft RSVP-TE Analysis February 2014
5. IANA Requirements
This document makes no IANA requests, and the RFC Editor may consider
deleting this section on publication of this document as a RFC.
6. Security Consideration
This document is all about security considerations for LMP.
7. Acknowledgements
8. References
8.1. Normative References
[RFC4204] Lang, J., "Link Management Protocol (LMP)", RFC 4204,
October 2005.
[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for
Routing Protocols (KARP) Design Guidelines", RFC 6518,
February 2012.
8.2. Informative References
[RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the
IAB workshop on Unwanted Traffic March 9-10, 2006", RFC
4948, August 2007.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues
with Existing Cryptographic Protection Methods for Routing
Protocols", RFC 6039, October 2010.
[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.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, May 2013.
Jethanandani Expires August 15, 2014 [Page 7]
Internet-Draft RSVP-TE Analysis February 2014
Author's Address
Mahesh Jethanandani
Ciena Corporation
3939 North 1st Street
San Jose, CA 95134
USA
Phone: +1 (408) 904-2160
Email: mjethanandani@gmail.com
Jethanandani Expires August 15, 2014 [Page 8]
