draft-ietf-mpls-ldp-gtsm-06.txt   draft-ietf-mpls-ldp-gtsm-07.txt 
MPLS Working Group C. Pignataro MPLS Working Group C. Pignataro
Internet-Draft R. Asati Internet-Draft R. Asati
Updates: 5036 (if approved) Cisco Systems Updates: 5036 (if approved) Cisco Systems
Intended status: Standards Track May 14, 2012 Intended status: Standards Track May 29, 2012
Expires: November 15, 2012 Expires: November 30, 2012
The Generalized TTL Security Mechanism (GTSM) for Label Distribution The Generalized TTL Security Mechanism (GTSM) for Label Distribution
Protocol (LDP) Protocol (LDP)
draft-ietf-mpls-ldp-gtsm-06 draft-ietf-mpls-ldp-gtsm-07
Abstract Abstract
The Generalized TTL Security Mechanism (GTSM) describes a generalized The Generalized TTL Security Mechanism (GTSM) describes a generalized
use of a packets Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to
verify that the packet was sourced by a node on a connected link, verify that the packet was sourced by a node on a connected link,
thereby protecting the router's IP control-plane from CPU utilization thereby protecting the router's IP control-plane from CPU utilization
based attacks. This technique improves security and is used by many based attacks. This technique improves security and is used by many
protocols. This document defines the GTSM use for the Label protocols. This document defines the GTSM use for the Label
Distribution Protocol (LDP). Distribution Protocol (LDP).
This specification uses a bit reserved in RFC 5036 and therefore This specification uses a bit reserved in RFC 5036 and therefore
updates RFC 5036. updates RFC 5036.
Status of this Memo Status of this Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 15, 2012. This Internet-Draft will expire on November 30, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 42 skipping to change at page 3, line 42
3. Sending and Receiving procedures for LDP Initilization message 3. Sending and Receiving procedures for LDP Initilization message
GTSM specifies that "it SHOULD NOT be enabled by default in order to GTSM specifies that "it SHOULD NOT be enabled by default in order to
remain backward-compatible with the unmodified protocol" (see Section remain backward-compatible with the unmodified protocol" (see Section
3 of [RFC5082]). This document specifies a "built-in dynamic GTSM 3 of [RFC5082]). This document specifies a "built-in dynamic GTSM
capability negotiation" for LDP to suggest the use of GTSM. GTSM capability negotiation" for LDP to suggest the use of GTSM. GTSM
will be used as specified in this document provided both peers on an will be used as specified in this document provided both peers on an
LDP session can detect each others' support for GTSM procedures and LDP session can detect each others' support for GTSM procedures and
agree to use it. That is, the desire to use GTSM (i.e., its agree to use it. That is, the desire to use GTSM (i.e., its
negotiation mechanics) is enabled by default. negotiation mechanics) is enabled by default without any
configuration.
This specification uses a bit reserved in Section 3.5.2 of [RFC5036] This specification uses a bit reserved in Section 3.5.2 of [RFC5036]
and therefore updates [RFC5036]. and therefore updates [RFC5036].
1.1. Specification of Requirements 1.1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 5, line 29 skipping to change at page 5, line 29
G, GTSM G, GTSM
A value of 1 specifies that this LSR supports GTSM procedures, A value of 1 specifies that this LSR supports GTSM procedures,
where a value of 0 specifies that this LSR does not support GTSM. where a value of 0 specifies that this LSR does not support GTSM.
Reserved Reserved
This field is reserved. It MUST be set to zero on transmission This field is reserved. It MUST be set to zero on transmission
and ignored on receipt. and ignored on receipt.
Figure 1: GTSM Flag in Common Hello Parameter TLV Figure 1: GTSM Flag in Common Hello Parameter TLV
The G flag is meaingful only if the T flag is set to 0 (which must be The G flag is meaningful only if the T flag is set to 0 (which must
the case for Basic Discovery), otherwise, the value of G flag SHOULD be the case for Basic Discovery), otherwise, the value of G flag
be ignored on receipt. SHOULD be ignored on receipt.
Any LSR not supporting GTSM for LDP as defined in this document Any LSR not supporting GTSM for LDP as defined in this document
(i.e., an LSR that does not recognize the G flag), would continue to (i.e., an LSR that does not recognize the G flag), would continue to
ignore the G flag, independent of T and R flags' value, as per ignore the G flag, independent of T and R flags' value, as per
Section 3.5.2 of [RFC5036]. Similarly, an LSR that does recognize Section 3.5.2 of [RFC5036]. Similarly, an LSR that does recognize
the G flag but that it does not support GTSM (either because it is the G flag but that does not support GTSM (either because it is not
not implemented, or because it is so configured), would clear the G implemented, or because it is so configured), would not set the G
flag (i.e.,g G=0) on send and would effectively ignore the G flag on flag (i.e.,g G=0) when sending LDP Link hellos and would effectively
receipt. ignore the G flag when receiving LDP Link hello messages.
2.2. GTSM Sending and Receiving Procedures for LDP Link Hello 2.2. GTSM Sending and Receiving Procedures for LDP Link Hello
Firstly, LSRs using LDP Basic Discovery [RFC5036] send LDP Hello Firstly, LSRs using LDP Basic Discovery [RFC5036] send LDP Hello
messages to link-level multicast address (224.0.0.2 or "all messages to link-level multicast address (224.0.0.2 or "all
routers"). Such messages are never forwarded beyond one hop and routers"). Such messages are never forwarded beyond one hop and
RECOMMENDED to have their IP TTL or Hop Count = 1. RECOMMENDED to have their IP TTL or Hop Count = 1.
Unless configured otherwise, an LSR that supports GTSM procedures Unless configured otherwise, an LSR that supports GTSM procedures
MUST set the G flag (for GTSM) to 1 in Common Hello Parameter TLV in MUST set the G flag (for GTSM) to 1 in Common Hello Parameter TLV in
skipping to change at page 8, line 10 skipping to change at page 8, line 10
6. Acknowledgments 6. Acknowledgments
The authors of this document do not make any claims on the The authors of this document do not make any claims on the
originality of the ideas described. The concept of GTSM for LDP has originality of the ideas described. The concept of GTSM for LDP has
been proposed a number of times, and is documented in both the been proposed a number of times, and is documented in both the
Experimental and Standards Track specifications of GTSM. Among other Experimental and Standards Track specifications of GTSM. Among other
people, we would like to acknowledge Enke Chen and Albert Tian for people, we would like to acknowledge Enke Chen and Albert Tian for
their document "TTL-Based Security Option for the LDP Hello Message". their document "TTL-Based Security Option for the LDP Hello Message".
The authors would like to thank Loa Andersson, Bin Mo, Mach Chen, The authors would like to thank Loa Andersson, Bin Mo, Mach Chen,
Vero Zheng, Adrian Farrel, and Eric Rosen for a thorough review and Vero Zheng, Adrian Farrel, Eric Rosen, and Eric Gray for a thorough
most useful comments and suggestions. review and most useful comments and suggestions.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
 End of changes. 8 change blocks. 
15 lines changed or deleted 16 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/