< draft-ietf-mpls-ldp-gtsm-04.txt   draft-ietf-mpls-ldp-gtsm-05.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 November 13, 2011 Intended status: Standards Track April 11, 2012
Expires: May 16, 2012 Expires: October 13, 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-04 draft-ietf-mpls-ldp-gtsm-05
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 packets 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 Label Distribution protocols. This document defines the GTSM use for Label Distribution
Protocol (LDP). Protocol (LDP).
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 May 16, 2012. This Internet-Draft will expire on October 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 22 skipping to change at page 2, line 22
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . . . 3 1.1. Specification of Requirements . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. GTSM Procedures for LDP . . . . . . . . . . . . . . . . . . . . 4 2. GTSM Procedures for LDP . . . . . . . . . . . . . . . . . . . . 4
2.1. GTSM Flag in Common Hello Parameter TLV . . . . . . . . . . 4 2.1. GTSM Flag in Common Hello Parameter TLV . . . . . . . . . . 4
2.2. GTSM Sending and Receiving Procedures for LDP Link 2.2. GTSM Sending and Receiving Procedures for LDP Link
Hello . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Hello . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. GTSM Sending and Receiving Procedures for LDP 2.3. GTSM Sending and Receiving Procedures for LDP
Initialization . . . . . . . . . . . . . . . . . . . . . . 5 Initialization . . . . . . . . . . . . . . . . . . . . . . 6
3. LDP Peering Scenarios and GTSM Considerations . . . . . . . . . 6 3. LDP Peering Scenarios and GTSM Considerations . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
LDP [RFC5036] specifies two peer discovery mechanisms, a Basic one LDP [RFC5036] specifies two peer discovery mechanisms, a Basic one
and an Extended one, both using UDP transport. The Basic Discovery and an Extended one, both using UDP transport. The Basic Discovery
mechanism is used to discover LDP peers that are directly connected mechanism is used to discover LDP peers that are directly connected
at the link level, whereas the Extended Discovery mechanism is used at the link level, whereas the Extended Discovery mechanism is used
to locate LSR neighbors that are not directly connected at the link to locate LSR neighbors that are not directly connected at the link
skipping to change at page 4, line 14 skipping to change at page 4, line 14
1.2. Scope 1.2. Scope
This document defines procedures for LDP using IPv4 routing, but not This document defines procedures for LDP using IPv4 routing, but not
for LDP using IPv6 routing, since the latter has GTSM built into the for LDP using IPv6 routing, since the latter has GTSM built into the
protocol definition [I-D.ietf-mpls-ldp-ipv6]. protocol definition [I-D.ietf-mpls-ldp-ipv6].
Additionally, the GTSM for LDP specified in this document applies Additionally, the GTSM for LDP specified in this document applies
only to single-hop LDP peering sessions, and not to multi-hop LDP only to single-hop LDP peering sessions, and not to multi-hop LDP
peering sessions, in line with Section 5.5 of [RFC5082]. peering sessions, in line with Section 5.5 of [RFC5082].
Consequently, any LDP method or feature that relies on multi-hop LDP Consequently, any LDP method or feature (such as LDP IGP
peering sessions would not work with GTSM and will require Synchronization [RFC5443], or LDP Session Protection [LDP-SPROT])
(statically or dynamically) disabling GTSM. See Section 3. that relies on multi-hop LDP peering sessions would not work with
GTSM and will require (statically or dynamically) disabling GTSM.
See Section 3.
2. GTSM Procedures for LDP 2. GTSM Procedures for LDP
2.1. GTSM Flag in Common Hello Parameter TLV 2.1. GTSM Flag in Common Hello Parameter TLV
A new flag in Common Hello Parameter TLV, named G flag (for GTSM), is A new flag in Common Hello Parameter TLV, named G flag (for GTSM), is
defined by this document in a previously reserved bit. An LSR defined by this document in a previously reserved bit. An LSR
indicates that it is capable of applying GTSM procedures, as defined indicates that it is capable of applying GTSM procedures, as defined
in this document, to the subsequent LDP peering session, by setting in this document, to the subsequent LDP peering session, by setting
the GTSM flag to 1. The Common Hello Parameters TLV, defined in the GTSM flag to 1. The Common Hello Parameters TLV, defined in
skipping to change at page 6, line 43 skipping to change at page 7, line 20
doing a Basic Discovery, due to the way IP routing is setup doing a Basic Discovery, due to the way IP routing is setup
between them (either temporarily or permanently) between them (either temporarily or permanently)
c. Two adjacent LSRs (i.e. back-to-back PE routers) forming a c. Two adjacent LSRs (i.e. back-to-back PE routers) forming a
single-hop LDP peering session after doing both Basic and single-hop LDP peering session after doing both Basic and
Extended Discovery. Extended Discovery.
In the first case (a), GTSM is not enabled for the LDP peering In the first case (a), GTSM is not enabled for the LDP peering
session by default. In the second case (b), GTSM is actually enabled session by default. In the second case (b), GTSM is actually enabled
by default and enforced for the LDP peering session, and hence, it by default and enforced for the LDP peering session, and hence, it
would prohibit the LDP peering session from getting established. In would prohibit the LDP peering session from getting established (note
the third case (c), GTSM is enabled by default for Basic Discovery that this may impact features such as LDP IGP Synchronization
and enforced on the subsequent LDP peering, and not for Extended [RFC5443], or LDP Session Protection [LDP-SPROT]). en the third case
Discovery. However, if each LSR uses the same IPv4 transport address (c), GTSM is enabled by default for Basic Discovery and enforced on
object value in both Basic and Extended discoveries, then it would the subsequent LDP peering, and not for Extended Discovery. However,
result in a single LDP peering session and that would be enabled with if each LSR uses the same IPv4 transport address object value in both
GTSM. Otherwise, GTSM would not be enforced on the second LDP Basic and Extended discoveries, then it would result in a single LDP
peering session corresponding to the Extended Discovery. peering session and that would be enabled with GTSM. Otherwise, GTSM
would not be enforced on the second LDP peering session corresponding
to the Extended Discovery.
This document allows for the implementation to provide an option to This document allows for the implementation to provide an option to
statically (e.g., via configuration) and/or dynamically override the statically (e.g., via configuration) and/or dynamically override the
default behavior and enable/disable GTSM on a per-peer basis. This default behavior and enable/disable GTSM on a per-peer basis. This
would address all the exceptions listed above. would address all the exceptions listed above.
4. IANA Considerations 4. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
skipping to change at page 8, line 8 skipping to change at page 8, line 29
[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.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
Pignataro, "The Generalized TTL Security Mechanism Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007. (GTSM)", RFC 5082, October 2007.
7.2. Informative References 7.2. Informative References
[I-D.ietf-mpls-ldp-ipv6] [I-D.ietf-mpls-ldp-ipv6]
Asati, R., Manral, V., Papneja, R., and C. Pignataro, Pignataro, C., Asati, R., Papneja, R., and V. Manral,
"Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-05 "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-06
(work in progress), August 2011. (work in progress), January 2012.
[LDP-SPROT]
Cisco Systems, Inc., "MPLS LDP Session Protection", <http:
//www.cisco.com/en/US/docs/ios-xml/ios/mp_ldp/
configuration/12-4m/mp-ldp-sessn-prot.html>.
[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP
Synchronization", RFC 5443, March 2009.
Authors' Addresses Authors' Addresses
Carlos Pignataro Carlos Pignataro
Cisco Systems Cisco Systems
7200-12 Kit Creek Road 7200-12 Kit Creek Road
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
US US
Email: cpignata@cisco.com Email: cpignata@cisco.com
 End of changes. 9 change blocks. 
22 lines changed or deleted 34 lines changed or added

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