draft-ietf-mpls-ldp-gtsm-05.txt   draft-ietf-mpls-ldp-gtsm-06.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 April 11, 2012 Intended status: Standards Track May 14, 2012
Expires: October 13, 2012 Expires: November 15, 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-05 draft-ietf-mpls-ldp-gtsm-06
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 the Label
Protocol (LDP). 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 This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 October 13, 2012. This Internet-Draft will expire on November 15, 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 3, line 11 skipping to change at page 3, line 11
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 . . . . . . . . . . . . . . . . . . . . . . . . 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 Label Switching Router (LSR) neighbors that are not
level. Once discovered, the LSR neighbors can establish the LDP directly connected at the link level. Once discovered, the LSR
peering session, using the TCP transport connection. neighbors can establish the LDP peering session, using the TCP
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 fully benefit 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
3. Sending and Receiving procedures for LDP Initilization message 3. Sending and Receiving procedures for LDP Initilization 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; this remain backward-compatible with the unmodified protocol" (see Section
document specifies having a built-in dynamic GTSM capability 3 of [RFC5082]). This document specifies a "built-in dynamic GTSM
negotiation for LDP to suggest the use of GTSM, provided GTSM is not capability negotiation" for LDP to suggest the use of GTSM. GTSM
enabled unless both peers can detect each others' support for GTSM will be used as specified in this document provided both peers on an
procedures and agree on its usage as described in this document. 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
negotiation mechanics) is enabled by default.
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].
skipping to change at page 4, line 17 skipping to change at page 4, line 17
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 (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 relies on multi-hop LDP peering sessions would not work with that relies on multi-hop LDP peering sessions would not work with
GTSM and will require (statically or dynamically) disabling GTSM. GTSM and will require (statically or dynamically) disabling the GTSM
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 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 5, line 29 skipping to change at page 5, line 29
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 Common Hello Parameter TLV
The G flag is meaingful only if T and R flags are set to 0 (which The G flag is meaingful only if the T flag is set to 0 (which must be
must be the case for Basic Discovery), otherwise, the value of G flag the case for Basic Discovery), otherwise, the value of G flag SHOULD
SHOULD be ignored on receipt. be 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
would continue to ignore the G flag, independent of T and R flags' (i.e., an LSR that does not recognize the G flag), would continue to
value, as per Section 3.5.2 of [RFC5036]. 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
the G flag but that it does not support GTSM (either because it is
not implemented, or because it is so configured), would clear the G
flag (i.e.,g G=0) on send and would effectively ignore the G flag on
receipt.
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
assumed to have their IP TTL or Hop Count = 1. RECOMMENDED to have their IP TTL or Hop Count = 1.
An LSR that is capable of applying GTSM procedures to the subsequent Unless configured otherwise, an LSR that supports GTSM procedures
TCP/LDP peering session MUST set the G flag (for GTSM) to 1 in Common MUST set the G flag (for GTSM) to 1 in Common Hello Parameter TLV in
Hello Parameter TLV in the LDP Link Hello message [RFC5036]. the LDP Link Hello message [RFC5036].
An LSR, upon receiving an LDP Link Hello message, would recognize the If an LSR that supports GTSM and is configured to use it recognizes
presence of G flag (in Common Hello Parameter TLV) only if it the presence of G flag (in Common Hello Parameter TLV) with the value
supports GTSM for LDP, as specified in this document. If an LSR =1 in the received LDP Link Hello message, then it MUST enforce GTSM
recognizes the presence of G flag with the value =1 in the received for LDP in the subsequent TCP/LDP peering session with the neighbor
LDP Link Hello message, then it MUST enforce GTSM for LDP in the that sent the Hello message, as specified in Section 2.3 of this
subsequent TCP/LDP peering session with the neighbor that sent the document.
Hello message, as specified in Section 2.3 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 G flag (in Common Hello
Parameter TLV of Link Hello message), or recognizes the presence of G Parameter TLV of Link Hello message), or recognizes the presence of G
flag with the value = 0, then the LSR MUST NOT enforce GTSM for LDP flag with the value = 0, then the LSR MUST NOT enforce GTSM for LDP
in the subsequent TCP/LDP peering session with the neighbor that sent in the subsequent TCP/LDP peering session with the neighbor that sent
the Hello message. This ensures backward compatibility as well as the Hello message. This ensures backward compatibility as well as
automatic GTSM de-activation. automatic GTSM de-activation.
If an LSR that has sent the LDP Link Hello with G flag = 1, then the
LSR MUST set IP TTL or Hop Count = 255 in the forthcoming TCP
Transport Connection(s) with that neighbor (e.g., LSR2). Please see
Section 2.3 for more details about the TCP transport connection
specifics.
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 (LSR2), then the LSR MUST from the directly-connected neighbor, then the LSR MUST enforce GTSM
enforce GTSM procedures, as defined in Section 3 of [RFC5082], in the procedures, as defined in Section 3 of [RFC5082], in the forthcoming
forthcoming TCP Transport Connection with that neighbor (LSR2). This TCP Transport Connection with that neighbor. This means that the LSR
means that the LSR MUST check for the incoming unicast packets' TTL MUST check for the incoming unicast packets' TTL or Hop Count to be
or Hop Count to be 255 for the particular LDP/TCP peering session and 255 for the particular LDP/TCP peering session and decide the further
decide the further processing as per the [RFC5082]. 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 then the LSR MUST NOT enforce GTSM procedures, as defined in Section
Section 3 of [RFC5082], in the forthcoming TCP Transport Connection 3 of [RFC5082], in the forthcoming TCP Transport Connection with that
with that neighbor (LSR2). 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 GTSM is enabled for Basic Discovery by default, but not The reason that the GTSM capability negotiation is enabled for Basic
for Extended Discovery is that the usage of Basic Discovery typically Discovery by default (i.e.,g G=1), but not for Extended Discovery is
results in a single-hop LDP peering session, whereas the usage of that the usage of Basic Discovery typically results in a single-hop
Extended Discovery typically results in a multi-hop LDP peering LDP peering session, whereas the usage of Extended Discovery
session. GTSM protection for multi-hop LDP sessions is outside the typically results in a multi-hop LDP peering session. GTSM
scope of this specification (see Section 1.2). However, it is worth protection for multi-hop LDP sessions is outside the scope of this
clarifying the following exceptions that may occur with Basic or specification (see Section 1.2). However, it is worth clarifying the
Extended Discovery usage: following exceptions that may occur with Basic or Extended Discovery
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 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 (note would prohibit the LDP peering session from getting established (note
that this may impact features such as LDP IGP Synchronization that this may impact features such as LDP IGP Synchronization
[RFC5443], or LDP Session Protection [LDP-SPROT]). en the third case [RFC5443], or LDP Session Protection [LDP-SPROT]). In the third case
(c), GTSM is enabled by default for Basic Discovery and enforced on (c), GTSM is enabled by default for Basic Discovery and enforced on
the subsequent LDP peering, and not for Extended Discovery. However, the subsequent LDP peering, and not for Extended Discovery. However,
if each LSR uses the same IPv4 transport address object value in both 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 Basic and Extended discoveries, then it would result in a single LDP
peering session and that would be enabled with GTSM. Otherwise, GTSM peering session and that would be enabled with GTSM. Otherwise, GTSM
would not be enforced on the second LDP peering session corresponding would not be enforced on the second LDP peering session corresponding
to the Extended Discovery. 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.
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. resilient to off-link attacks. Security considerations for GTSM are
detailed in Section 5 of [RFC5082].
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".
 End of changes. 18 change blocks. 
60 lines changed or deleted 63 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/