draft-ietf-mpls-ldp-gtsm-01.txt   draft-ietf-mpls-ldp-gtsm-02.txt 
MPLS Working Group C. Pignataro MPLS Working Group C. Pignataro
Internet-Draft R. Asati Internet-Draft R. Asati
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: December 13, 2011 June 11, 2011 Expires: February 23, 2012 August 22, 2011
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-01 draft-ietf-mpls-ldp-gtsm-02
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 37 skipping to change at page 1, line 37
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 December 13, 2011. This Internet-Draft will expire on February 23, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 2, line 19 skipping to change at page 2, line 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . . . 3 1.1. Specification of Requirements . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . . . . 5
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 3. Multi-Hop LDP peering Considerations for GTSM . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 7
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
level. Once discovered, the LSR neighbors can establish the LDP level. Once discovered, the LSR neighbors can establish the LDP
peering session, using the TCP transport connection. peering session, using the TCP transport connection.
skipping to change at page 4, line 5 skipping to change at page 4, line 5
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].
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, this document applies to LDP peering sessions set up Additionally, the GTSM for LDP specified in this document applies
using Basic Discovery only. LDP peering sessions set up using only to single-hop LDP peering sessions, and not to multi-hop LDP
Extended Discovery are outside the scope of this document (see peering sessions, in line with Section 5.5 of [RFC5082].
Section 5.5 of [RFC5082]). Consequently, any LDP method or feature 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. An LSR indicates that it is capable of defined by this document. An LSR indicates that it is capable of
applying GTSM procedures, as defined in this document, to the applying GTSM procedures, as defined in this document, to the
subsequent LDP peering session, by setting the GTSM flag to 1. The subsequent LDP peering session, by setting the GTSM flag to 1. The
Common Hello Parameters TLV, defined in Section 3.5.2 of [RFC5036], Common Hello Parameters TLV, defined in Section 3.5.2 of [RFC5036],
skipping to change at page 6, line 5 skipping to change at page 6, line 7
means that the LSR MUST check for the incoming unicast packets' TTL means that the LSR MUST check for the incoming unicast packets' TTL
or Hop Count to be 255 for the particular LDP/TCP peering session and or Hop Count to be 255 for the particular LDP/TCP peering session and
decide the further processing as per the [RFC5082]. decide the further processing as per the [RFC5082].
If an LSR that has sent LDP Link Hello with G flag = 1, but received If an LSR that has sent LDP Link Hello with G flag = 1, but received
LDP Link Hello with G flag = 0 from the directly-connected neighbor LDP Link Hello with G flag = 0 from the directly-connected neighbor
(LSR2), then the LSR MUST NOT enforce GTSM procedures, as defined in (LSR2), then the LSR MUST NOT enforce GTSM procedures, as defined in
Section 3 of [RFC5082], in the forthcoming TCP Transport Connection Section 3 of [RFC5082], in the forthcoming TCP Transport Connection
with that neighbor (LSR2). with that neighbor (LSR2).
3. IANA Considerations 3. Multi-Hop LDP peering Considerations for GTSM
The reason GTSM is enabled for Basic Discovery by default, but not
for Extended Discovery is that the usage of Basic Discovery typically
results in a single-hop LDP peering session, whereas the usage of
Extended Discovery typically results in a multi-hop LDP peering
session. GTSM protection for multi-hop LDP sessions is outside the
scope of this specification (see Section 1.2). However, it is worth
clarifying the following exceptions that may occur with Basic or
Extended Discovery usage:
a. Two adjacent LSRs (i.e., back-to-back PE routers) forming a
single-hop LDP peering session after doing an Extended Discovery
(e.g., for Pseudowire signaling)
b. Two adjacent LSRs forming a multi-hop LDP peering session after
doing a Basic Discovery, due to the way IP routing is setup
between them (either temporarily or permanently)
c. Two adjacent LSRs (i.e. back-to-back PE routers) forming a
single-hop LDP peering session after doing both Basic and
Extended Discovery.
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
by default and enforced for the LDP peering session, and hence, it
would prohibit the LDP peering session from getting established. In
the third case (c), GTSM is enabled by default for Basic Discovery
and enforced on the subsequent LDP peering, and not for Extended
Discovery. However, if each LSR uses the same IPv4 transport address
object value in both Basic and Extended discoveries, then it would
result in a single LDP 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
statically (e.g., via configuration) and/or dynamically override the
default behavior and disable GTSM on a per-peer basis. This would
address all the exceptions listed above.
4. IANA Considerations
IANA is requested to assign the G, GTSM bit in the Common Hello IANA is requested to assign the G, GTSM bit in the Common Hello
Parameters TLV (see Figure 1 in Section 2.1), as per allocation Parameters TLV (see Figure 1 in Section 2.1), as per allocation
policy defined at [I-D.ietf-mpls-ldp-iana]. policy defined at [I-D.ietf-mpls-ldp-iana].
4. Security Considerations 5. Security Considerations
This document increases the security for LDP, making it more This document increases the security for LDP, making it more
resilient to off-link attacks. resilient to off-link attacks.
5. 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 for a thorough review The authors would like to thank Loa Andersson and Bin Mo for a
and most useful comments and suggestions. thorough review and most useful comments and suggestions.
6. References 7. References
6.1. Normative References 7.1. Normative References
[I-D.ietf-mpls-ldp-iana] [I-D.ietf-mpls-ldp-iana]
Pignataro, C. and R. Asati, "Label Distribution Protocol Pignataro, C. and R. Asati, "Label Distribution Protocol
(LDP) Internet Assigned Numbers Authority (IANA) (LDP) Internet Assigned Numbers Authority (IANA)
Considerations Update", draft-ietf-mpls-ldp-iana-01 (work Considerations Update", draft-ietf-mpls-ldp-iana-01 (work
in progress), May 2011. in progress), May 2011.
[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.
[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.
6.2. Informative References 7.2. Informative References
[I-D.ietf-mpls-ldp-ipv6] [I-D.ietf-mpls-ldp-ipv6]
Manral, V., Papneja, R., Asati, R., and C. Pignataro, Manral, V., Papneja, R., Asati, R., and C. Pignataro,
"Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-04 "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-04
(work in progress), May 2011. (work in progress), May 2011.
Authors' Addresses Authors' Addresses
Carlos Pignataro Carlos Pignataro
Cisco Systems Cisco Systems
 End of changes. 12 change blocks. 
22 lines changed or deleted 65 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/