tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 4204

 
 
 

Link Management Protocol (LMP)

Part 4 of 4, p. 71 to 86
Prev RFC Part

 


prevText      Top      Up      ToC       Page 71 
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.

Top      Up      ToC       Page 72 
   [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.

Top      Up      ToC       Page 73 
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.

Top      Up      ToC       Page 74 
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.

Top      Up      ToC       Page 75 
      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.

Top      Up      ToC       Page 76 
      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.

Top      Up      ToC       Page 77 
   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.

Top      Up      ToC       Page 78 
   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)

   ------------------------------------------------------------------

Top      Up      ToC       Page 79 
   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.

Top      Up      ToC       Page 80 
     - 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)

Top      Up      ToC       Page 81 
   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)

Top      Up      ToC       Page 82 
   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)

Top      Up      ToC       Page 83 
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

Top      Up      ToC       Page 84 
   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

Top      Up      ToC       Page 85 
Contact Address

   Jonathan P. Lang
   Sonos, Inc.
   829 De La Vina, Suite 220
   Santa Barbara, CA 93101

   EMail: jplang@ieee.org

Top      Up      ToC       Page 86 
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.