MPLS Working Group                                          C. Pignataro
Internet-Draft                                                  R. Asati
Intended status: Standards Track                           Cisco Systems
Expires: December 13, 2011                                 June 11, February 23, 2012                               August 22, 2011

  The Generalized TTL Security Mechanism (GTSM) for Label Distribution
                             Protocol (LDP)
                      draft-ietf-mpls-ldp-gtsm-01
                      draft-ietf-mpls-ldp-gtsm-02

Abstract

   The Generalized TTL Security Mechanism (GTSM) describes a generalized
   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,
   thereby protecting the router's IP control-plane from CPU utilization
   based attacks.  This technique improves security and is used by many
   protocols.  This document defines the GTSM use for Label Distribution
   Protocol (LDP).

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
   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
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 13, 2011. February 23, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Specification of Requirements . . . . . . . . . . . . . . . 3
     1.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  GTSM Procedures for LDP . . . . . . . . . . . . . . . . . . . . 4
     2.1.  GTSM Flag in Common Hello Parameter TLV . . . . . . . . . . 4
     2.2.  GTSM Sending and Receiving Procedures for LDP Link
           Hello . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     2.3.  GTSM Sending and Receiving Procedures for LDP
           Initialization  . . . . . . . . . . . . . . . . . . . . . . 5
   3.  Multi-Hop LDP peering Considerations for GTSM . . . . . . . . . 6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   4.
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   5. 7
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
   6. 7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     6.1. 7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     6.2. 7
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7 8

1.  Introduction

   LDP [RFC5036] specifies two peer discovery mechanisms, a Basic one
   and an Extended one, both using UDP transport.  The Basic Discovery
   mechanism is used to discover LDP peers that are directly connected
   at the link level, whereas the Extended Discovery mechanism is used
   to locate LSR neighbors that are not directly connected at the link
   level.  Once discovered, the LSR neighbors can establish the LDP
   peering session, using the TCP transport connection.

   The Generalized TTL Security Mechanism (GTSM) [RFC5082] is a
   mechanism based on IPv4 Time To Live (TTL) or (IPv6) Hop Limit value
   verification so as to provide a simple and reasonably robust defense
   from infrastructure attacks using forged protocol packets from
   outside the network.  GTSM can be applied to any protocol peering
   session that is established between routers that are adjacent.
   Therefore, GTSM can fully benefit LDP protocol peering session
   established using Basic Discovery.

   This document specifies LDP enhancements to accommodate GTSM.  In
   particular, this document specifies the enhancements in the following
   areas:

   1.  Common Hello Parameter TLV of LDP Link Hello message

   2.  Sending and Receiving procedures for LDP Link Hello message

   3.  Sending and Receiving procedures for LDP Initilization message

   GTSM specifies that it SHOULD NOT be enabled by default in order to
   remain backward-compatible with the unmodified protocol; this
   document specifies having a built-in dynamic GTSM capability
   negotiation for LDP to suggest the use of GTSM, provided GTSM is not
   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

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.2.  Scope

   This document defines procedures for LDP using IPv4 routing, but not
   for LDP using IPv6 routing, since the latter has GTSM built into the
   protocol definition [I-D.ietf-mpls-ldp-ipv6].

   Additionally, the GTSM for LDP specified in this document applies
   only to single-hop LDP peering sessions set up
   using Basic Discovery only. sessions, and not to multi-hop LDP
   peering sessions set up using
   Extended Discovery are outside the scope of this document (see sessions, in line with Section 5.5 of [RFC5082]). [RFC5082].
   Consequently, any LDP method or feature that relies on multi-hop LDP
   peering sessions would not work with GTSM and will require
   (statically or dynamically) disabling GTSM.  See Section 3.

2.  GTSM Procedures for LDP

2.1.  GTSM Flag in Common Hello Parameter TLV

   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
   applying GTSM procedures, as defined in this document, to 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],
   is updated as shown in Figure 1.

     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|0| Common Hello Parms(0x0400)|      Length                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Hold Time                |T|R|G|   Reserved              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    T, Targeted Hello
       As specified in [RFC5036].

    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

   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
   SHOULD be ignored on receipt.

   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'
   value, as per Section 3.5.2 of [RFC5036].

2.2.  GTSM Sending and Receiving Procedures for LDP Link Hello

   Firstly, LSRs using LDP Basic Discovery [RFC5036] send LDP Hello
   messages to link-level multicast address (224.0.0.2 or "all
   routers").  Such messages are never forwarded beyond one hop and
   assumed to have their IP TTL or Hop Count = 1.

   An LSR that is capable of applying GTSM procedures to the subsequent
   TCP/LDP peering session MUST set the G flag (for GTSM) to 1 in Common
   Hello Parameter TLV in the LDP Link Hello message [RFC5036].

   An LSR, upon receiving an LDP Link Hello message, would recognize the
   presence of G flag (in Common Hello Parameter TLV) only if it
   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
   LDP Link Hello message, then it MUST enforce GTSM for LDP in the
   subsequent TCP/LDP peering session with the neighbor that sent the
   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
   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
   in the subsequent TCP/LDP peering session with the neighbor that sent
   the Hello message.  This ensures backward compatibility as well as
   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

   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
   enforce GTSM procedures, as defined in Section 3 of [RFC5082], in the
   forthcoming TCP Transport Connection with that neighbor (LSR2).  This
   means that the LSR 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 processing as per the [RFC5082].

   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
   (LSR2), then the LSR MUST NOT enforce GTSM procedures, as defined in
   Section 3 of [RFC5082], in the forthcoming TCP Transport Connection
   with that neighbor (LSR2).

3.  Multi-Hop LDP peering Considerations for GTSM

   The reason GTSM is enabled for Basic Discovery by default, but not
   for Extended Discovery is that the usage of Basic Discovery typically
   results in a single-hop LDP peering session, whereas the usage of
   Extended Discovery typically results in a multi-hop LDP peering
   session.  GTSM protection for multi-hop LDP sessions is outside the
   scope of this specification (see Section 1.2).  However, it is worth
   clarifying the following exceptions that may occur with Basic or
   Extended Discovery usage:

   a.  Two adjacent LSRs (i.e., back-to-back PE routers) forming a
       single-hop LDP peering session after doing an Extended Discovery
       (e.g., for Pseudowire signaling)

   b.  Two adjacent LSRs forming a multi-hop LDP peering session after
       doing a Basic Discovery, due to the way IP routing is setup
       between them (either temporarily or permanently)

   c.  Two adjacent LSRs (i.e. back-to-back PE routers) forming a
       single-hop LDP peering session after doing both Basic and
       Extended Discovery.

   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
   by default and enforced for the LDP peering session, and hence, it
   would prohibit the LDP peering session from getting established.  In
   the third case (c), GTSM is enabled by default for Basic Discovery
   and enforced on the subsequent LDP peering, and not for Extended
   Discovery.  However, 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 peering session and that would be enabled with
   GTSM.  Otherwise, GTSM would not be enforced on the second LDP
   peering session corresponding to the Extended Discovery.

   This document allows for the implementation to provide an option to
   statically (e.g., via configuration) and/or dynamically override the
   default behavior and disable GTSM on a per-peer basis.  This would
   address all the exceptions listed above.

4.  IANA Considerations

   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
   policy defined at [I-D.ietf-mpls-ldp-iana].

4.

5.  Security Considerations

   This document increases the security for LDP, making it more
   resilient to off-link attacks.

5.

6.  Acknowledgments

   The authors of this document do not make any claims on the
   originality of the ideas described.  The concept of GTSM for LDP has
   been proposed a number of times, and is documented in both the
   Experimental and Standards Track specifications of GTSM.  Among other
   people, we would like to acknowledge Enke Chen and Albert Tian for
   their document "TTL-Based Security Option for the LDP Hello Message".

   The authors would like to thank Loa Andersson and Bin Mo for a
   thorough review and most useful comments and suggestions.

6.

7.  References

6.1.

7.1.  Normative References

   [I-D.ietf-mpls-ldp-iana]
              Pignataro, C. and R. Asati, "Label Distribution Protocol
              (LDP) Internet Assigned Numbers Authority (IANA)
              Considerations Update", draft-ietf-mpls-ldp-iana-01 (work
              in progress), May 2011.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5036]  Andersson, L., Minei, I., and B. Thomas, "LDP
              Specification", RFC 5036, October 2007.

   [RFC5082]  Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
              Pignataro, "The Generalized TTL Security Mechanism
              (GTSM)", RFC 5082, October 2007.

6.2.

7.2.  Informative References

   [I-D.ietf-mpls-ldp-ipv6]
              Manral, V., Papneja, R., Asati, R., and C. Pignataro,
              "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-04
              (work in progress), May 2011.

Authors' Addresses

   Carlos Pignataro
   Cisco Systems
   7200-12 Kit Creek Road
   Research Triangle Park, NC  27709
   US

   Email: cpignata@cisco.com

   Rajiv Asati
   Cisco Systems
   7025-6 Kit Creek Road
   Research Triangle Park, NC  27709
   US

   Email: rajiva@cisco.com