draft-ietf-mpls-ldp-gtsm-08.txt   draft-ietf-mpls-ldp-gtsm-09.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 June 2, 2012 Intended status: Standards Track July 3, 2012
Expires: December 4, 2012 Expires: January 4, 2013
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-08 draft-ietf-mpls-ldp-gtsm-09
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 December 4, 2012. This Internet-Draft will expire on January 4, 2013.
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 29 skipping to change at page 2, line 29
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 . . . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 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
transport connection. transport connection.
The Generalized TTL Security Mechanism (GTSM) [RFC5082] is a The Generalized TTL Security Mechanism (GTSM) [RFC5082] is a
mechanism based on IPv4 Time To Live (TTL) or (IPv6) Hop Limit value mechanism based on IPv4 Time To Live (TTL) or (IPv6) Hop Limit value
verification so as to provide a simple and reasonably robust defense verification so as to provide a simple and reasonably robust defense
from infrastructure attacks using forged protocol packets from from infrastructure attacks using forged protocol packets from
outside the network. GTSM can be applied to any protocol peering outside the network. GTSM can be applied to any protocol peering
session that is established between routers that are adjacent. session that is established between routers that are adjacent.
Therefore, GTSM can fully benefit LDP protocol peering session Therefore, GTSM can protect an LDP protocol peering session
established using Basic Discovery. established using Basic Discovery.
This document specifies LDP enhancements to accommodate GTSM. In This document specifies LDP enhancements to accommodate GTSM. In
particular, this document specifies the enhancements in the following particular, this document specifies the enhancements in the following
areas: areas:
1. Common Hello Parameter TLV of LDP Link Hello message 1. Common Hello Parameter TLV of LDP Link Hello message
2. Sending and Receiving procedures for LDP Link Hello message 2. Sending and Receiving procedures for LDP Link Hello message
skipping to change at page 5, line 30 skipping to change at page 5, line 30
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 meaningful only if the T flag is set to 0 (which must The G flag is meaningful only if the T flag is set to 0 (which must
be the case for Basic Discovery), otherwise, the value of G flag be the case for Basic Discovery), otherwise, the value of G flag is
SHOULD be ignored on receipt. 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 does not support GTSM (either because it is not the G flag but that does not support GTSM (either because it is not
implemented, or because it is so configured), would not set the G implemented, or because it is so configured), would not set the G
flag (i.e.,g G=0) when sending LDP Link hellos and would effectively flag (i.e., G=0) when sending LDP Link hellos and would effectively
ignore the G flag when receiving LDP Link hello messages. 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 are
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
the LDP Link Hello message [RFC5036]. the LDP Link Hello message [RFC5036].
If an LSR that supports GTSM and is configured to use it recognizes If an LSR that supports GTSM and is configured to use it recognizes
the presence of G flag (in Common Hello Parameter TLV) with the value the presence of G flag (in Common Hello Parameter TLV) with the value
=1 in the received LDP Link Hello message, then it MUST enforce GTSM =1 in the received LDP Link Hello message, then it MUST enforce GTSM
for LDP in the subsequent TCP/LDP peering session with the neighbor for LDP in the subsequent TCP/LDP peering session with the neighbor
skipping to change at page 6, line 43 skipping to change at page 6, line 43
neighbor. neighbor.
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=1), but not for Extended Discovery is
that the usage of Basic Discovery typically relates to 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 relates to 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
skipping to change at page 8, line 6 skipping to change at page 8, line 6
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 As discussed in Section 3, it is possible that
o GTSM for LDP may not always be enforced on a single-hop LDP 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 peering session and LDP may still be susceptible to forged/spoofed
protocol packets, if a single-hop LDP peering session is set up protocol packets, if a single-hop LDP peering session is set up
using Extended Discovery. using Extended Discovery.
o GTSM for LDP may cause LDP peering session to not get established o GTSM for LDP may cause the LDP peering session to not get
(or may be torn down), if IP routing ever declares that the established (or may be torn down), if IP routing ever declares
directly connected peer is more than one IP hop away. Suffice to that the directly connected peer is more than one IP hop away.
say, use of cryptographic integrity (e.g., [RFC5925]) is Suffice to say, use of cryptographic integrity (e.g., [RFC5925])
recommended as an alternate solution for detecting forged protocol is recommended as an alternate solution for detecting forged
packets (especially for the multi-hop case). protocol packets (especially for the multi-hop case).
The GTSM specification [RFC5082] says that protocol messages used for
dynamic negotiation of GTSM support MUST be authenticated. However,
LDP discovery [RFC5036] uses UDP transport and does not have an
authentication mechanism. The GTSM specification further elaborates
by saying that GTSM is not substitute for authentication and it does
not secure against insider on-the-wire attacks. LDP Basic Discovery
uses link-level multicast address (224.0.0.2 or "all routers") that
are never forwarded beyond the link, and this acts as a basic
protection against off-the-wire attacks.
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".
skipping to change at page 8, line 43 skipping to change at page 9, line 8
[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]
Pignataro, C., Asati, R., Papneja, R., and V. Manral, Asati, R., Manral, V., Papneja, R., and C. Pignataro,
"Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-06 "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-07
(work in progress), January 2012. (work in progress), June 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 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
 End of changes. 11 change blocks. 
20 lines changed or deleted 30 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/