Internet DRAFT - draft-chen-ldp-ttl
draft-chen-ldp-ttl
Network Working Group Enke Chen
Internet Draft Albert Tian
Intended status: Standards Track Cisco Systems
Expiration Date: September 10, 2009 March 9, 2009
TTL-Based Security Option for the LDP Hello Message
draft-chen-ldp-ttl-02.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 10, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
To facilitate the deployment of the TTL-based security mechanism for
Chen & Tian [Page 1]
Internet Draft draft-chen-ldp-ttl-02.txt March 2009
LDP, in this document we propose a new optional parameter for the LDP
Hello Message that can be used by a LSR to indicate its support of
the TTL-based mechanism.
1. Introduction
The LDP [LDP] sessions established following the LDP basic discovery
are between two directly connected LSRs. As a result, the TTL-based
security mechanism described in [RFC3682] is fully applicable to such
sessions.
To deploy the TTL-based security mechanism, however, both LSRs
involved in the LDP session must be coordinated and synchronized in
setting and checking the TTL values. The coordination effort may not
be trivial for a large network.
To facilitate the deployment of the TTL-based security mechanism for
LDP, in this document we propose a new optional parameter for the LDP
Hello Message that can be used by a LSR to indicate its support of
the TTL-based mechanism.
2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Protocol Extension
The new optional parameter for the LDP Hello Message is defined as
the following:
Optional Parameter: Support for TTL-based Security
Type: See the IANA Considerations section
Length: 0
U bit: 1
F bit: 0
This optional parameter MAY be used by a LSR to indicate its support
for the TTL-based security mechanism [RFC3682]. When both LSRs
exchanging the LDP Hello Messages support the TTL-based security
mechanism, the LSRs MUST follow the TTL-based security procedures for
the LDP peer to be established between them. More specifically,
o The TTL field of an outbound packet for the LDP session MUST
be set to the maximum value (255).
Chen & Tian [Page 2]
Internet Draft draft-chen-ldp-ttl-01.txt March 2009
o For an inbound packet to be accepted, the TTL field of the
packet MUST be 255 if the TTL value is not decremented by
the receiving LSR. Otherwise, the TTL field MUST be 254. The
choice between these two values is implementation specific,
and is a local matter.
The optional parameter SHOULD NOT be included in a LDP targeted Hello
Message sent by a LSR, and SHOULD be ignored in a targeted Hello
Message received by a LSR.
4. IANA Considerations
This document defines a new optional parameter for the LDP Hello
Message. The type code needs to be assigned by IANA.
5. Security Considerations
This extension to LDP does not change the underlying security
properties with The Generalized TTL Security Mechanism (GTSM)
[RFC5082]. This extension is only application to LDP peers as
a result of the LDP basic discovery. For LDP sessions resulting
from the LDP targeted discovery, the TCP MD5 is recommended by
[LDP].
6. Acknowledgments
The authors would like to thank Rajiv Asati and Carlos Pignataro
for their suggestions and discussions.
7. References
7.1. Normative References
[LDP] L. Andersson, P. Doolan, N. Feldman, A. Fredette, and B.
Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Non-normative References
[RFC5082] V. Gill, J. Heasley, D. Meyer, P. Savola, C. Pignataro,
"The Generalized TTL Security Mechanism (GTSM)", RFC 5082, Oct 2007.
Chen & Tian [Page 3]
Internet Draft draft-chen-ldp-ttl-02.txt March 2009
8. Authors' Addresses
Enke Chen
Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134
Email: enkechen@cisco.com
Albert Tian
Cisco Systems, Inc.
3700 Cisco Way,
San Jose, CA 95134
Email: altian@cisco.com
Chen & Tian [Page 4]
