| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This object contains one or more Interface_Ids.
The Length of this object is 4 + 4N in bytes, where N is the number
of Interface_Ids.
o C-Type = 2, IPv6 INTERFACE_ID
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This object contains one or more Interface_Ids.
The Length of this object is 4 + 16N in bytes, where N is the number
of Interface_Ids.
o C-Type = 3, Unnumbered INTERFACE_ID
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This object contains one or more Interface_Ids.
The Length of this object is 4 + 4N in bytes, where N is the number
of Interface_Ids.
This object is non-negotiable.
13.15. ERROR_CODE Class
Class = 20
o C-Type = 1, BEGIN_VERIFY_ERROR
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ERROR CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following bit-values are defined in network byte order (i.e.,
big-endian byte order):
0x01 = Link Verification Procedure not supported.
0x02 = Unwilling to verify.
0x04 = Unsupported verification transport mechanism.
0x08 = Link_Id configuration error.
0x10 = Unknown object C-Type.
All other bit-values are reserved and should be sent as zero and
ignored on receipt.
Multiple bits may be set to indicate multiple errors.
This object is non-negotiable.
If a BeginVerifyNack message is received with Error Code 2, the node
that originated the BeginVerify SHOULD schedule a BeginVerify
retransmission after Rf seconds, where Rf is a locally defined
parameter.
o C-Type = 2, LINK_SUMMARY_ERROR
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ERROR CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following bit-values are defined in network byte order (i.e.,
big-endian byte order):
0x01 = Unacceptable non-negotiable LINK_SUMMARY parameters.
0x02 = Renegotiate LINK_SUMMARY parameters.
0x04 = Invalid TE_LINK Object.
0x08 = Invalid DATA_LINK Object.
0x10 = Unknown TE_LINK object C-Type.
0x20 = Unknown DATA_LINK object C-Type.
All other bit-values are reserved and should be sent as zero and
ignored on receipt.
Multiple bits may be set to indicate multiple errors.
This object is non-negotiable.
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)