[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                 Sankar Ramamoorthi (Nexsi Systems)
Internet Draft                                Alex Zinin (Nexsi Systems)
Expiration Date: August 2002                               February 2002
File name: draft-sankar-lmp-sec-00.txt




                         LMP Security Mechanism
                      draft-sankar-lmp-sec-00.txt


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet Drafts are working documents of the Internet Engineering
   Task Force (IETF), its Areas, and its Working Groups. Note that other
   groups may also distribute working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months. Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time. It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract
   This memo describes an IPsec-based security mechanism for the LMP
   protocol [LMP].

1 Introduction

   LMP is a link management protocol used in [GMPLS] networks to control
   optical link operation.  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




Ramamoorthi, Zinin                                              [Page 1]


INTERNET DRAFT                LMP Security                 February 2002


     o an adversary may replay control packets

     o an adversary may study a number of control
       packets and try to break the key using crytographic
       tools. If the hash/encryption algorithm used has known weaknesses
       than it becomes easy for the adversary to discover the
       key using simple tools.

   This document specifies an IPsec-based security mechanism for LMP
   protecting the protocol sessions from these attacks.

2 Security Requirements

   The following requiremets are applied to the mechanism described in
   this document.

     o LMP security MUST be able to provide authentication, integrity
       and replay protection.

     o For LMP traffic, confidentiality is not needed. Only authentica-
       tion is needed to ensure the control packets (packets sent along
       the LMP Control Channel) are originating from the right place and
       have not been modified in transit.  LMP packets exchanged through
       TE links do not need to be protected.

     o 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.

     o Ensure the algorithms used for authentication are cryptographi-
       cally sound. Also the security protocol MUST allow for negotiat-
       ing and using different authenticatiion algorithms.

3 Security Mechanisms

   IPsec is a protocol suite which 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], 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 interpreation

   Considering the requirements described in Section 2, it is recom-
   mended that where security is needed for LMP, implementations use
   IPsec as described below:





Ramamoorthi, Zinin                                              [Page 2]


INTERNET DRAFT                LMP Security                 February 2002


     1. IPsec AH, tunnel mode SHOULD be used for packet autentication.


     2. IKE [RFC2409] SHOULD be used as the key exchange mechanism.

   Implementations of LMP over IPsec protocol MUST support manual keying
   mode and dynamic key exchange protocol using IKE. IKE implmentation
   SHOULD use the IPsec DOI [RFC2407].

   For IKE protocol, the identities of the SAs negotiated in Quick Mode
   represent the traffic which the peers agree to protect and are com-
   prised of address space, protocol and port information. For LMP over
   IPsec, it is recommended that the identities be the IP address of the
   communicating peer and the protocol field to be TBD (IANA number
   assigned for LMP protocol) and a value of zero in the port field. A
   value of zero in the port field implies the port field SHOULD be
   ignored.  In LMP exchanges, the channel identifier user by the peer
   is not known beforehand, and hence cannot be used in the SA. Note
   that this restriction implies that LMP authentication is performed on
   a per LMP neighbor basis rather than on a per LMP control channel
   between two neighbors.


4 Security Considerations

   The document specifies security mechanisms for the LMP protocol.

5 Acknowledgements

   TBD

6 References


[LMP]   draft-ietf-ccamp-lmp-02.txt

[GMPLS] draft-ietf-ccamp-gmpls-architecture-01.txt

[RFC2401]
        Kent, S., Atkinson, R., "Security Architecture for the Internet
        Protocol", November 1998

[RFC2402]
        Kent, S., Atkinson, R., "IP Authentication Header", November
        1998

[RFC2406]
        Kent, S., Atkinson, R., "IP Encapsulating Security Payload



Ramamoorthi, Zinin                                              [Page 3]


INTERNET DRAFT                LMP Security                 February 2002


        (ESP)", November 1998

[RFC2407]
        Piper, D., "The Internet IP Security Domain of Interpretation
        for ISAKMP", November 1998

[RFC2409]
        Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)",
        RFC2409, November 1998

7 Authors' addresses


        Sankar Ramamoorthi
        Nexsi Systems
        1959 Concourse Dr
        San Jose,CA 95131
        USA
        E-mail: sankar@nexsi.com


        Alex Zinin
        Nexsi Systems
        1959 Concourse Dr
        San Jose,CA 95131
        USA
        E-mail: azinin@nexsi.com
























Ramamoorthi, Zinin                                              [Page 4]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/