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]