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]