RFC 4204
Link Management Protocol (LMP)
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005. [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001. [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC3471] Berger, L., Ed., "Generalized MPLS - Signaling Functional Description", RFC 3471, January 2003.14.2. Informative References
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
15. Security Considerations
There are number of attacks that an LMP protocol session can potentially experience. Some examples include: o an adversary may spoof control packets; o an adversary may modify the control packets 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. If the hash/encryption algorithm used has known weaknesses, then it becomes easy for the adversary to discover the key using simple tools. This section specifies an IPsec-based security mechanism for LMP.15.1. Security Requirements
The following requirements are applied to the mechanism described in this section. o LMP security MUST be able to provide authentication, integrity, and replay protection. o For LMP traffic, confidentiality is not needed. Only authentication is needed to ensure that the control packets (packets sent along the LMP Control Channel) are originating from the right place and have not been modified in transit. LMP Test packets exchanged through the data links do not need to be protected. o For LMP traffic, protecting the identity of LMP end-points is not commonly required. o The security mechanism should provide for well defined key management schemes. The key management schemes should be well analyzed to be cryptographically secure. The key management schemes should be scalable. In addition, the key management system should be automatic. o The algorithms used for authentication MUST be cryptographically sound. Also, the security protocol MUST allow for negotiating and using different authentication algorithms.
15.2. Security Mechanisms
IPsec is a protocol suite that is used to secure communication at the network layer between two peers. This protocol is comprised of IP Security architecture document [RFC2401], IKE [RFC2409], IPsec AH [RFC2402], and IPsec ESP [RFC2406]. IKE is the key management protocol for IP networks, while AH and ESP are used to protect IP traffic. IKE is defined specific to IP domain of interpretation. Considering the requirements described in Section 15.1, it is recommended that, where security is needed for LMP, implementations use IPsec as described below: 1. Implementations of LMP over IPsec protocol SHOULD support manual keying mode. Manual keying mode provides an easy way to set up and diagnose IPsec functionality. However, note that manual keying mode cannot effectively support features such as replay protection and automatic re-keying. An implementer using manual keys must be aware of these limits. It is recommended that an implementer use manual keying only for diagnostic purposes and use dynamic keying protocol to make use of features such as replay protection and automatic re-keying. 2. IPsec ESP with trailer authentication in tunnel mode MUST be supported. 3. Implementations MUST support authenticated key exchange protocols. IKE [RFC2409] MUST be used as the key exchange protocol if keys are dynamically negotiated between peers. 4. Implementation MUST use the IPsec DOI [RFC2407]. 5. For IKE protocol, the identities of the SAs negotiated in Quick Mode represent the traffic that the peers agree to protect and are comprised of address space, protocol, and port information. For LMP over IPsec, it is recommended that the identity payload for Quick mode contain the following information: The identities MUST be of type IP addresses and the value of the identities SHOULD be the IP addresses of the communicating peers.
The protocol field MUST be UDP. The port field SHOULD be set to
zero to indicate port fields should be ignored. This implies all
UDP traffic between the peers must be sent through the IPsec
tunnel. If an implementation supports port-based selectors, it
can opt for a more finely grained selector by specifying the port
field to the LMP port. If, however, the peer does not use port-
based selectors, the implementation MUST fall back to using a port
selector value of 0.
6. Aggressive mode of IKE negotiation MUST be supported.
When IPsec is configured to be used with a peer, all LMP messages
are expected to be sent over the IPsec tunnel (crypto channel).
Similarly, an LMP receiver configured to use Ipsec with a peer
should reject any LMP traffic that does not come through the
crypto channel.
The crypto channel can be pre-setup with the LMP neighbor, or the
first LMP message sent to the peer can trigger the creation of the
IPsec tunnel.
A set of control channels can share the same crypto channel. When
LMP Hellos are used to monitor the status of the control channel,
it is important to keep in mind that the keep-alive failure in a
control channel may also be due to a failure in the crypto
channel. The following method is recommended to ensure that an
LMP communication path between two peers is working properly.
o If LMP Hellos detect a failure on a control channel, switch to
an alternate control channel and/or try to establish a new
control channel.
o Ensure the health of the control channels using LMP Hellos. If
all control channels indicate a failure and it is not possible
to bring up a new control channel, tear down all existing
control channels. Also, tear down the crypto channel (both the
IKE SA and IPsec SAs).
o Reestablish the crypto channel. Failure to establish a crypto
channel indicates a fatal failure for LMP communication.
o Bring up the control channel. Failure to bring up the control
channel indicates a fatal failure for LMP communication.
When LMP peers are dynamically discovered (particularly the
initiator), the following points should be noted:
When using pre-shared key authentication in identity protection
mode (main mode), the pre-shared key is required to compute the
value of SKEYID (used for deriving keys to encrypt messages
during key exchange). In main mode of IKE, the pre-shared key
to be used has to be identified before receiving the peer's
identity payload. The pre-shared key is required for
calculating SKEYID. The only information available about the
peer at this point is its IP address from which the negotiation
came from. Keying off the IP address of a peer to get the
pre-shared key is not possible since the addresses are dynamic
and not known beforehand.
Aggressive mode key exchange can be used since identification
payloads are sent in the first message.
Note, however, that aggressive mode is prone to passive denial
of service attacks. Using a shared secret (group shared
secret) among a number of peers is strongly discouraged because
this opens up the solution to man-in-the-middle attacks.
Digital-signature-based authentication is not prone to such
problems. It is RECOMMENDED that a digital-signature-based
authentication mechanism be used where possible.
If pre-shared-key-based authentication is required, then
aggressive mode SHOULD be used. IKE pre-shared authentication
key values SHOULD be protected in a manner similar to the
user's account password.
16. IANA Considerations
The IANA has assigned port number 701 to LMP.
In the following, guidelines are given for IANA assignment for each
LMP name space. Ranges are specified for Private Use, to be assigned
by Expert Review, and to be assigned by Standards Action (as defined
in [RFC2434].
Assignments made from LMP number spaces set aside for Private Use
(i.e., for proprietary extensions) need not be documented.
Independent LMP implementations using the same Private Use code
points will in general not interoperate, so care should be exercised
in using these code points in a multi-vendor network.
Assignments made from LMP number spaces to be assigned by Expert Review are to be reviewed by an Expert designated by the IESG. The intent in this document is that code points from these ranges are used for Experimental extensions; as such, assignments MUST be accompanied by Experimental RFCs. If deployment suggests that these extensions are useful, then they should be described in Standards Track RFCs, and new code points from the Standards Action ranges MUST be assigned. Assignments from LMP number spaces to be assigned by Standards Action MUST be documented by a Standards Track RFC, typically submitted to an IETF Working Group, but in any case following the usual IETF procedures for Proposed Standards. The Reserved bits of the LMP Common Header should be allocated by Standards Action, pursuant to the policies outlined in [RFC2434]. LMP defines the following name spaces that require management: - LMP Message Type. - LMP Object Class. - LMP Object Class type (C-Type). These are unique within the Object Class. - LMP Sub-object Class type (Type). These are unique within the Object Class. The LMP Message Type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-127 are allocated by Standards Action, 128-240 are allocated through an Expert Review, and 241-255 are reserved for Private Use. The LMP Object Class name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range of 0-127 are allocated by Standards Action, 128-247 are allocated through an Expert Review, and 248-255 are reserved for Private Use. The policy for allocating values out of the LMP Object Class name space is part of the definition of the specific Class instance. When a Class is defined, its definition must also include a description of the policy under which the Object Class names are allocated. The policy for allocating values out of the LMP Sub-object Class name space is part of the definition of the specific Class instance. When a Class is defined, its definition must also include a description of the policy under which sub-objects are allocated.
The following name spaces have been assigned by IANA: ------------------------------------------------------------------ LMP Message Type name space o Config message (Message type = 1) o ConfigAck message (Message type = 2) o ConfigNack message (Message type = 3) o Hello message (Message type = 4) o BeginVerify message (Message type = 5) o BeginVerifyAck message (Message type = 6) o BeginVerifyNack message (Message type = 7) o EndVerify message (Message type = 8) o EndVerifyAck message (Message type = 9) o Test message (Message type = 10) o TestStatusSuccess message (Message type = 11) o TestStatusFailure message (Message type = 12) o TestStatusAck message (Message type = 13) o LinkSummary message (Message type = 14) o LinkSummaryAck message (Message type = 15) o LinkSummaryNack message (Message type = 16) o ChannelStatus message (Message type = 17) o ChannelStatusAck message (Message type = 18) o ChannelStatusRequest message (Message type = 19) o ChannelStatusResponse message (Message type = 20) ------------------------------------------------------------------
LMP Object Class name space and Class type (C-Type) o CCID Class name (1) The CCID Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use. - LOCAL_CCID (C-Type = 1) - REMOTE_CCID (C-Type = 2) o NODE_ID Class name (2) The NODE ID Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use. - LOCAL_NODE_ID (C-Type = 1) - REMOTE_NODE_ID (C-Type = 2) o LINK_ID Class name (3) The LINK_ID Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use. - IPv4 LOCAL_LINK_ID (C-Type = 1) - IPv4 REMOTE_LINK_ID (C-Type = 2) - IPv6 LOCAL_LINK_ID (C-Type = 3) - IPv6 REMOTE_LINK_ID (C-Type = 4) - Unnumbered LOCAL_LINK_ID (C-Type = 5) - Unnumbered REMOTE_LINK_ID (C-Type = 6) o INTERFACE_ID Class name (4) The INTERFACE_ID Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use.
- IPv4 LOCAL_INTERFACE_ID (C-Type = 1)
- IPv4 REMOTE_INTERFACE_ID (C-Type = 2)
- IPv6 LOCAL_INTERFACE_ID (C-Type = 3)
- IPv6 REMOTE_INTERFACE_ID (C-Type = 4)
- Unnumbered LOCAL_INTERFACE_ID (C-Type = 5)
- Unnumbered REMOTE_INTERFACE_ID (C-Type = 6)
o MESSAGE_ID Class name (5)
The MESSAGE_ID Object Class type name space should be allocated as
follows: pursuant to the policies outlined in [RFC2434], the numbers
in the range 0-111 are allocated by Standards Action, 112-119 are
allocated through an Expert Review, and 120-127 are reserved for
Private Use.
- MESSAGE_ID (C-Type = 1)
- MESSAGE_ID_ACK (C-Type = 2)
o CONFIG Class name (6)
The CONFIG Object Class type name space should be allocated as
follows: pursuant to the policies outlined in [RFC2434], the numbers
in the range 0-111 are allocated by Standards Action, 112-119 are
allocated through an Expert Review, and 120-127 are reserved for
Private Use.
- HELLO_CONFIG (C-Type = 1)
o HELLO Class name (7)
The HELLO Object Class type name space should be allocated as
follows: pursuant to the policies outlined in [RFC2434], the numbers
in the range 0-111 are allocated by Standards Action, 112-119 are
allocated through an Expert Review, and 120-127 are reserved for
Private Use.
- HELLO (C-Type = 1)
o BEGIN_VERIFY Class name (8)
The BEGIN_VERIFY Object Class type name space should be allocated as
follows: pursuant to the policies outlined in [RFC2434], the numbers
in the range 0-111 are allocated by Standards Action, 112-119 are
allocated through an Expert Review, and 120-127 are reserved for
Private Use.
- Type 1 (C-Type = 1)
o BEGIN_VERIFY_ACK Class name (9) The BEGIN_VERIFY_ACK Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use. - Type 1 (C-Type = 1) o VERIFY_ID Class name (10) The VERIFY_ID Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use. - Type 1 (C-Type = 1) o TE_LINK Class name (11) The TE_LINK Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use. - IPv4 TE_LINK (C-Type = 1) - IPv6 TE_LINK (C-Type = 2) - Unnumbered TE_LINK (C-Type = 3) o DATA_LINK Class name (12) The DATA_LINK Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for private Use. - IPv4 DATA_LINK (C-Type = 1) - IPv6 DATA_LINK (C-Type = 2) - Unnumbered DATA_LINK (C-Type = 3)
The DATA_LINK Sub-object Class name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range of 0-127 are allocated by Standards Action, 128-247 are allocated through an Expert Review, and 248-255 are reserved for private Use. - Interface Switching Type (sub-object Type = 1) - Wavelength (sub-object Type = 2) o CHANNEL_STATUS Class name (13) The CHANNEL_STATUS Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use. - IPv4 INTERFACE_ID (C-Type = 1) - IPv6 INTERFACE_ID (C-Type = 2) - Unnumbered INTERFACE_ID (C-Type = 3) o CHANNEL_STATUS_REQUESTClass name (14) The CHANNEL_STATUS_REQUEST Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use. - IPv4 INTERFACE_ID (C-Type = 1) - IPv6 INTERFACE_ID (C-Type = 2) - Unnumbered INTERFACE_ID (C-Type = 3) o ERROR_CODE Class name (20) The ERROR_CODE Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for private Use. - BEGIN_VERIFY_ERROR (C-Type = 1) - LINK_SUMMARY_ERROR (C-Type = 2)
17. Acknowledgements
The authors would like to thank Andre Fredette for his many contributions to this document. We would also like to thank Ayan Banerjee, George Swallow, Adrian Farrel, Dimitri Papadimitriou, Vinay Ravuri, and David Drysdale for their insightful comments and suggestions. We would also like to thank John Yu, Suresh Katukam, and Greg Bernstein for their helpful suggestions for the in-band control channel applicability.18. Contributors
Jonathan P. Lang Sonos, Inc. 223 E. De La Guerra St. Santa Barbara, CA 93101 EMail: jplang@ieee.org Krishna Mitra Independent Consultant EMail: kmitra@earthlink.net John Drake Calient Networks 5853 Rue Ferrari San Jose, CA 95138 EMail: jdrake@calient.net Kireeti Kompella Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 EMail: kireeti@juniper.net Yakov Rekhter Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 EMail: yakov@juniper.net
Lou Berger Movaz Networks EMail: lberger@movaz.com Debanjan Saha IBM Watson Research Center EMail: dsaha@us.ibm.com Debashis Basak Accelight Networks 70 Abele Road, Suite 1201 Bridgeville, PA 15017-3470 EMail: dbasak@accelight.com Hal Sandick Shepard M.S. 2401 Dakota Street Durham, NC 27705 EMail: sandick@nc.rr.com Alex Zinin Alcatel EMail: alex.zinin@alcatel.com Bala Rajagopalan Intel Corp. 2111 NE 25th Ave Hillsboro, OR 97123 EMail: bala.rajagopalan@intel.com Sankar Ramamoorthi Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 EMail: sankarr@juniper.net
Contact Address
Jonathan P. Lang Sonos, Inc. 829 De La Vina, Suite 220 Santa Barbara, CA 93101 EMail: jplang@ieee.org
Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.