draft-ietf-mpls-ldp-gtsm-07.txt   draft-ietf-mpls-ldp-gtsm-08.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 29, 2012 Intended status: Standards Track June 2, 2012
Expires: November 30, 2012 Expires: December 4, 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-07 draft-ietf-mpls-ldp-gtsm-08
Abstract Abstract
The Generalized TTL Security Mechanism (GTSM) describes a generalized The Generalized TTL Security Mechanism (GTSM) describes a generalized
use of a packet's 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).
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 30, 2012. This Internet-Draft will expire on December 4, 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 2, line 26 skipping to change at page 2, line 26
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 . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
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 Label Switching Router (LSR) neighbors that are not to locate Label Switching Router (LSR) neighbors that are not
directly connected at the link level. Once discovered, the LSR directly connected at the link level. Once discovered, the LSR
neighbors can establish the LDP peering session, using the TCP neighbors can establish the LDP peering session, using the TCP
skipping to change at page 6, line 44 skipping to change at page 6, line 44
3. LDP Peering Scenarios and GTSM Considerations 3. LDP Peering Scenarios and GTSM Considerations
This section discusses GTSM considerations arising from the LDP This section discusses GTSM considerations arising from the LDP
peering scenarios used, including single-hop versus multi-hop LDP peering scenarios used, including single-hop versus multi-hop LDP
neighbors, as well as the use of LDP basic discovery versus extended neighbors, as well as the use of LDP basic discovery versus extended
discovery. discovery.
The reason that the GTSM capability negotiation is enabled for Basic The reason that the GTSM capability negotiation is enabled for Basic
Discovery by default (i.e.,g G=1), but not for Extended Discovery is Discovery by default (i.e.,g G=1), but not for Extended Discovery is
that the usage of Basic Discovery typically results in a single-hop that the usage of Basic Discovery typically relates to a single-hop
LDP peering session, whereas the usage of Extended Discovery LDP peering session, whereas the usage of Extended Discovery
typically results in a multi-hop LDP peering session. GTSM typically relates to a multi-hop LDP peering session. GTSM
protection for multi-hop LDP sessions is outside the scope of this protection for multi-hop LDP sessions is outside the scope of this
specification (see Section 1.2). However, it is worth clarifying the specification (see Section 1.2). However, it is worth clarifying the
following exceptions that may occur with Basic or Extended Discovery following exceptions that may occur with Basic or Extended Discovery
usage: usage:
a. Two adjacent LSRs (i.e., back-to-back PE routers) forming a a. Two adjacent LSRs (i.e., back-to-back PE routers) forming a
single-hop LDP peering session after doing an Extended Discovery single-hop LDP peering session after doing an Extended Discovery
(e.g., for Pseudowire signaling) (e.g., for Pseudowire signaling)
b. Two adjacent LSRs forming a multi-hop LDP peering session after b. Two adjacent LSRs forming a multi-hop LDP peering session after
skipping to change at page 7, line 46 skipping to change at page 7, line 46
4. IANA Considerations 4. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
5. 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. Security considerations for GTSM are resilient to off-link attacks. Security considerations for GTSM are
detailed in Section 5 of [RFC5082]. detailed in Section 5 of [RFC5082].
As discussed in Section 3, it is possible that
o GTSM for LDP may not always be enforced on a single-hop LDP
peering session and LDP may still be susceptible to forged/spoofed
protocol packets, if a single-hop LDP peering session is set up
using Extended Discovery.
o GTSM for LDP may cause LDP peering session to not get established
(or may be torn down), if IP routing ever declares that the
directly connected peer is more than one IP hop away. Suffice to
say, use of cryptographic integrity (e.g., [RFC5925]) is
recommended as an alternate solution for detecting forged protocol
packets (especially for the multi-hop case).
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, Eric Rosen, and Eric Gray for a thorough Vero Zheng, Adrian Farrel, Eric Rosen, Eric Gray, and Brian Weis for
review and most useful comments and suggestions. a thorough 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.
skipping to change at page 9, line 5 skipping to change at page 9, line 9
(work in progress), January 2012. (work in progress), January 2012.
[LDP-SPROT] [LDP-SPROT]
Cisco Systems, Inc., "MPLS LDP Session Protection", <http: Cisco Systems, Inc., "MPLS LDP Session Protection", <http:
//www.cisco.com/en/US/docs/ios-xml/ios/mp_ldp/ //www.cisco.com/en/US/docs/ios-xml/ios/mp_ldp/
configuration/12-4m/mp-ldp-sessn-prot.html>. configuration/12-4m/mp-ldp-sessn-prot.html>.
[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP
Synchronization", RFC 5443, March 2009. Synchronization", RFC 5443, March 2009.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
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. 10 change blocks. 
10 lines changed or deleted 27 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/