draft-ietf-mpls-ldp-gtsm-09.txt   rfc6720.txt 
MPLS Working Group C. Pignataro Internet Engineering Task Force (IETF) C. Pignataro
Internet-Draft R. Asati Request for Comments: 6720 R. Asati
Updates: 5036 (if approved) Cisco Systems Updates: 5036 Cisco Systems
Intended status: Standards Track July 3, 2012 Category: Standards Track August 2012
Expires: January 4, 2013 ISSN: 2070-1721
The Generalized TTL Security Mechanism (GTSM) for Label Distribution The Generalized TTL Security Mechanism (GTSM) for
Protocol (LDP) the Label Distribution Protocol (LDP)
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
based attacks. This technique improves security and is used by many utilization-based attacks. This technique improves security and is
protocols. This document defines the GTSM use for the Label used by many protocols. This document defines the GTSM use for the
Distribution Protocol (LDP). Label 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
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on January 4, 2013. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6720.
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
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
1.1. Specification of Requirements . . . . . . . . . . . . . . . 3 1.1. Specification of Requirements ..............................3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 the 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 ...................5
3. LDP Peering Scenarios and GTSM Considerations . . . . . . . . . 6 4. Security Considerations .........................................6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgments .................................................7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. References ......................................................7
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References .......................................7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Informative References .....................................8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 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 protect an 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. The 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
3. Sending and Receiving procedures for LDP Initilization message 3. Sending and Receiving procedures for LDP Initialization 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 without any negotiation mechanics) is enabled by default without any
configuration. 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].
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 [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 (such as LDP IGP Consequently, any LDP method or feature (such as LDP IGP
Synchronization [RFC5443], or LDP Session Protection [LDP-SPROT]) Synchronization [RFC5443] or LDP Session Protection [LDP-SPROT]) that
that relies on multi-hop LDP peering sessions would not work with relies on multi-hop LDP peering sessions would not work with GTSM and
GTSM and will require (statically or dynamically) disabling the GTSM will require (statically or dynamically) disabling the GTSM
capability. See Section 3. capability. 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 the Common Hello Parameter TLV
A new flag in Common Hello Parameter TLV, named G flag (for GTSM), is A new flag in the Common Hello Parameter TLV, named G flag (for
defined by this document in a previously reserved bit. An LSR GTSM), is defined by this document in a previously reserved bit. An
indicates that it is capable of applying GTSM procedures, as defined LSR indicates that it is capable of applying GTSM procedures, as
in this document, to the subsequent LDP peering session, by setting defined in this document, to the subsequent LDP peering session, by
the GTSM flag to 1. The Common Hello Parameters TLV, defined in setting the GTSM flag to 1. The Common Hello Parameters TLV, defined
Section 3.5.2 of [RFC5036], is updated as shown in Figure 1. in Section 3.5.2 of [RFC5036], is updated as shown in Figure 1.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Common Hello Parms(0x0400)| Length | |0|0| Common Hello Parms(0x0400)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hold Time |T|R|G| Reserved | | Hold Time |T|R|G| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
T, Targeted Hello T, Targeted Hello
skipping to change at page 5, line 27 skipping to change at page 4, line 38
As specified in [RFC5036]. As specified in [RFC5036].
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 the 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 is be the case for Basic Discovery); otherwise, the value of the G flag
ignored on receipt. is 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 the values of the T and R flags, as
Section 3.5.2 of [RFC5036]. Similarly, an LSR that does recognize per Section 3.5.2 of [RFC5036]. Similarly, an LSR that does
the G flag but that does not support GTSM (either because it is not recognize the G flag but that does not support GTSM (either because
implemented, or because it is so configured), would not set the G it is not implemented or because it is so configured) would not set
flag (i.e., G=0) when sending LDP Link hellos and would effectively the G flag (i.e., G=0) when sending LDP Link Hellos and would
ignore the G flag when receiving LDP Link hello messages. effectively 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 First, 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 are 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 the Common Hello Parameter TLV
the LDP Link Hello message [RFC5036]. in 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 the G flag (in the Common Hello Parameter TLV) with
=1 in the received LDP Link Hello message, then it MUST enforce GTSM the value = 1 in the received LDP Link Hello message, then it MUST
for LDP in the subsequent TCP/LDP peering session with the neighbor enforce GTSM for LDP in the subsequent TCP/LDP peering session with
that sent the Hello message, as specified in Section 2.3 of this the neighbor that sent the Hello message, as specified in Section 2.3
document. of this document.
If an LSR does not recognize the presence of G flag (in Common Hello If an LSR does not recognize the presence of the G flag (in the
Parameter TLV of Link Hello message), or recognizes the presence of G Common Hello Parameter TLV of Link Hello message), or recognizes the
flag with the value = 0, then the LSR MUST NOT enforce GTSM for LDP presence of G flag with the value = 0, then the LSR MUST NOT enforce
in the subsequent TCP/LDP peering session with the neighbor that sent GTSM for LDP in the subsequent TCP/LDP peering session with the
the Hello message. This ensures backward compatibility as well as neighbor that sent the Hello message. This ensures backward
automatic GTSM de-activation. compatibility as well as automatic GTSM deactivation.
2.3. GTSM Sending and Receiving Procedures for LDP Initialization 2.3. GTSM Sending and Receiving Procedures for LDP Initialization
If an LSR that has sent and received LDP Link Hello with G flag = 1 If an LSR that has sent and received LDP Link Hello with G flag = 1
from the directly-connected neighbor, then the LSR MUST enforce GTSM from the directly connected neighbor, then the LSR MUST enforce GTSM
procedures, as defined in Section 3 of [RFC5082], in the forthcoming procedures, as defined in Section 3 of [RFC5082], in the forthcoming
TCP Transport Connection with that neighbor. This means that the LSR TCP Transport Connection with that neighbor. This means that the LSR
MUST check for the incoming unicast packets' TTL or Hop Count to be MUST check for the incoming unicast packets' TTL or Hop Count to be
255 for the particular LDP/TCP peering session and decide the further 255 for the particular LDP/TCP peering session and decide the further
processing as per the [RFC5082]. processing as per [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,
then the LSR MUST NOT enforce GTSM procedures, as defined in Section then the LSR MUST NOT enforce GTSM procedures, as defined in Section
3 of [RFC5082], in the forthcoming TCP Transport Connection with that 3 of [RFC5082], in the forthcoming TCP Transport Connection with that
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=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
(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
doing a Basic Discovery, due to the way IP routing is setup doing a Basic Discovery, due to the way IP routing is set up
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; hence, it would
would prohibit the LDP peering session from getting established (note prohibit the LDP peering session from getting established (note that
that this may impact features such as LDP IGP Synchronization this may impact features such as LDP IGP Synchronization [RFC5443] or
[RFC5443], or LDP Session Protection [LDP-SPROT]). In the third case LDP Session Protection [LDP-SPROT]). In the third case (c), GTSM is
(c), GTSM is enabled by default for Basic Discovery and enforced on enabled by default for Basic Discovery and enforced on the subsequent
the subsequent LDP peering, and not for Extended Discovery. However, LDP peering, and is not for Extended Discovery. However, if each LSR
if each LSR uses the same IPv4 transport address object value in both uses the same IPv4 transport address object value in both Basic and
Basic and Extended discoveries, then it would result in a single LDP Extended Discoveries, then it would result in a single LDP peering
peering session and that would be enabled with GTSM. Otherwise, GTSM session that would be enabled with GTSM. Otherwise, GTSM would not
would not be enforced on the second LDP peering session corresponding be enforced on the second LDP peering session corresponding to the
to the Extended Discovery. 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. Security Considerations
This document has no IANA actions.
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 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/
protocol packets, if a single-hop LDP peering session is set up spoofed protocol packets, if a single-hop LDP peering session is
using Extended Discovery. set up using Extended Discovery.
o GTSM for LDP may cause the LDP peering session to not get o GTSM for LDP may cause the LDP peering session to not get
established (or may be torn down), if IP routing ever declares established (or may be torn down), if IP routing ever declares
that the directly connected peer is more than one IP hop away. that the directly connected peer is more than one IP hop away.
Suffice to say, use of cryptographic integrity (e.g., [RFC5925]) Suffice to say, use of cryptographic integrity (e.g., [RFC5925])
is recommended as an alternate solution for detecting forged is recommended as an alternate solution for detecting forged
protocol 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 The GTSM specification [RFC5082] says that protocol messages used for
dynamic negotiation of GTSM support MUST be authenticated. However, dynamic negotiation of GTSM support MUST be authenticated. However,
LDP discovery [RFC5036] uses UDP transport and does not have an LDP discovery [RFC5036] uses UDP transport and does not have an
authentication mechanism. The GTSM specification further elaborates authentication mechanism. The GTSM specification further elaborates
by saying that GTSM is not substitute for authentication and it does by saying that GTSM is not a substitute for authentication and does
not secure against insider on-the-wire attacks. LDP Basic Discovery not secure against insider on-the-wire attacks. LDP Basic Discovery
uses link-level multicast address (224.0.0.2 or "all routers") that 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 are never forwarded beyond the link, and this acts as a basic
protection against off-the-wire attacks. protection against off-the-wire attacks.
6. Acknowledgments 5. 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, Eric Gray, and Brian Weis for Vero Zheng, Adrian Farrel, Eric Rosen, Eric Gray, and Brian Weis for
a thorough review and most useful comments and suggestions. their thorough reviews and useful comments and suggestions.
7. References 6. References
7.1. Normative References 6.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.
[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 6.2. Informative References
[I-D.ietf-mpls-ldp-ipv6] [LDP-IPV6] Asati, R., Manral, V., Papneja, R., and C. Pignataro,
Asati, R., Manral, V., Papneja, R., and C. Pignataro, "Updates to LDP for IPv6", Work in Progress, June 2012.
"Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-07
(work in progress), June 2012.
[LDP-SPROT] [LDP-SPROT] Cisco Systems, Inc., "MPLS LDP Session Protection",
Cisco Systems, Inc., "MPLS LDP Session Protection", <http: <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
Authentication Option", RFC 5925, June 2010. 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 USA
Email: cpignata@cisco.com EMail: cpignata@cisco.com
Rajiv Asati Rajiv Asati
Cisco Systems Cisco Systems
7025-6 Kit Creek Road 7025-6 Kit Creek Road
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
US USA
Email: rajiva@cisco.com EMail: rajiva@cisco.com
 End of changes. 54 change blocks. 
140 lines changed or deleted 126 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/