draft-ietf-mpls-ldp-gtsm-00.txt   draft-ietf-mpls-ldp-gtsm-01.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: November 21, 2011 May 20, 2011 Expires: December 13, 2011 June 11, 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-00 draft-ietf-mpls-ldp-gtsm-01
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 November 21, 2011. This Internet-Draft will expire on December 13, 2011.
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 16 skipping to change at page 2, line 16
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . 5 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
LDP [RFC5036] specifies two Discovery mechanisms, a Basic one and an LDP [RFC5036] specifies two peer discovery mechanisms, a Basic one
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 LSR neighbors that are directly mechanism is used to discover LDP peers that are directly connected
connected at the link level, whereas the Extended Discovery mechanism at the link level, whereas the Extended Discovery mechanism is used
is used to locate LSR neighbors that are not directly connected at to locate LSR neighbors that are not directly connected at the link
the link level. Once discovered (or located), the LSR neighbors can level. Once discovered, the LSR neighbors can establish the LDP
establish the LDP peering session, using the TCP transport peering session, using the TCP transport connection.
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
While GTSM specifies that it SHOULD NOT be enabled by default in GTSM specifies that it SHOULD NOT be enabled by default in order to
order to remain backward-compatible with the unmodified protocol, remain backward-compatible with the unmodified protocol; this
this document specifies having GTSM for LDP be enabled by default but document specifies having a built-in dynamic GTSM capability
not be enforced unless both peers can detect each others' support for negotiation for LDP to suggest the use of GTSM, provided GTSM is not
GTSM procedures as described in this document. enabled unless both peers can detect each others' support for GTSM
procedures and agree on its usage as described in this document.
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
skipping to change at page 4, line 21 skipping to change at page 4, line 21
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],
is updated as shown in Figure 1. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
G, GTSM T, Targeted Hello
A value of 1 specifies that this LSR wishes to support GTSM As specified in [RFC5036].
procedures, where a value of 0 specifies that this LSR does not
wish to support GTSM. R, Request Send Targeted Hellos
As specified in [RFC5036].
G, GTSM
A value of 1 specifies that this LSR supports GTSM procedures,
where a value of 0 specifies that this LSR does not support GTSM.
Reserved
This field is reserved. It MUST be set to zero on transmission
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 T and R flags are set to 0 (which
must be the case for Basic Discovery), otherwise, the value of G flag must be the case for Basic Discovery), otherwise, the value of G flag
should be ignored on receipt. SHOULD 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' would continue to ignore the G flag, independent of T and R flags'
value, as per Section 3.5.2 of [RFC5036]. value, as per Section 3.5.2 of [RFC5036].
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. assumed to have their IP TTL or Hop Count = 1.
An LSR may indicate that it is capable of applying GTSM procedures to An LSR that is capable of applying GTSM procedures to the subsequent
the subsequent TCP/LDP peering session by setting the G flag (for TCP/LDP peering session MUST set the G flag (for GTSM) to 1 in Common
GTSM) to 1 in Common Hello Parameter TLV in the LDP Link Hello Hello Parameter TLV in the LDP Link Hello message [RFC5036].
message [RFC5036].
An LSR, upon receiving an LDP Link Hello message, would recognize the An LSR, upon receiving an LDP Link Hello message, would recognize the
presence of G flag (in Common Hello Parameter TLV) only if it presence of G flag (in Common Hello Parameter TLV) only if it
supports GTSM for LDP, as specified in this document. If an LSR supports GTSM for LDP, as specified in this document. If an LSR
recognizes the presence of G flag with the value =1 in the received recognizes the presence of G flag with the value =1 in the received
LDP Link Hello message, then it must enforce GTSM for LDP in the LDP Link Hello message, then it MUST enforce GTSM for LDP in the
subsequent TCP/LDP peering session with the neighbor that sent the subsequent TCP/LDP peering session with the neighbor that sent the
Hello message, as specified in Section 2.3 of this 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 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 Transport LSR MUST set IP TTL or Hop Count = 255 in the forthcoming TCP
Connection(s) with that neighbor (LSR2, say). Please see Section 2.3 Transport Connection(s) with that neighbor (e.g., LSR2). Please see
for more details about the TCP transport connection specifics. 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, say), then the LSR must from the directly-connected neighbor (LSR2), then the LSR MUST
enforce GTSM procedures, as defined in Section 3 of [RFC5082], in the enforce GTSM procedures, as defined in Section 3 of [RFC5082], in the
forthcoming Transport Connection with that neighbor (LSR2, say). forthcoming TCP Transport Connection with that neighbor (LSR2). This
This means that the LSR must check for the incoming unicast packets' means that the LSR MUST check for the incoming unicast packets' TTL
TTL or Hop Count to be 255 for the particular LDP/TCP peering session or Hop Count to be 255 for the particular LDP/TCP peering session and
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
(LSR3, say), then the LSR must not enforce GTSM procedures, as (LSR2), then the LSR MUST NOT enforce GTSM procedures, as defined in
defined in Section 3 of [RFC5082], in the forthcoming Transport Section 3 of [RFC5082], in the forthcoming TCP Transport Connection
Connection with that neighbor (LSR2, say). with that neighbor (LSR2).
3. IANA Considerations 3. 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.asati-pignataro-mpls-ldp-iana]. policy defined at [I-D.ietf-mpls-ldp-iana].
4. Security Considerations 4. 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 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 for a thorough review
and most useful comments and suggestions.
6. References 6. References
6.1. Normative References 6.1. Normative References
[I-D.asati-pignataro-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", Considerations Update", draft-ietf-mpls-ldp-iana-01 (work
draft-asati-pignataro-mpls-ldp-iana-01 (work in progress), in progress), May 2011.
March 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.
 End of changes. 22 change blocks. 
54 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/