MPLS Working Group M. Shao, Ed.
Internet-Draft Ericsson Inc.
Updates: RFC4379 (if approved) June 23, 2016
Intended status: Standards Track
Expires: December 25, 2016

Relaxing IP TTL setting in MPLS Ping and traceroute
draft-shao-mpls-ping-ttl-00

Abstract

Packets with IP TTL 1 might be filtered by TTL-filtering access control lists deployed to mitigate TTL expiry attacks [CISCO]. Thus MPLS ping and traceroute will be inoperable in these networks if IP TTL is set to 1 according to RFC 4379 [RFC4379] chapter 4.3.

This document discuss and updates IP TTL setting in MPLS Ping and traceroute.

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 25, 2016.

Copyright Notice

Copyright (c) 2016 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

RFC 4379 [RFC4379] suggests to set IP TTL as 1 in MPLS echo request packet for MPLS ping and traceroute. However packets with IP TTL 1 may be dropped by TTL filtering access control list deployed to mitigate TTL expiry attacks, with the assumption that legitimate packets unlikely have low TTL values. Then MPLS ping and traceroute will be inoperable in these networks.

RFC 4379 [RFC4379] suggests " The IP TTL is set to 1.", and requires that "The Router Alert option MUST be set in the IP header", and "sending an MPLS echo request to the control plane is triggered by one of the following packet processing exceptions: Router Alert option, IP TTL expiration, MPLS TTL expiration, MPLS Router Alert label, or the destination address in the 127/8 address range.". Setting IP TTL as 1 isn't necessary for sending an MPLS echo request to the control plane because it's mandatory to include Router Alert option in the IP header. And it makes MPLS echo request susceptible to TTL filtering thus render it inoperable.

1.1. Requirements Language

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 RFC 2119 [RFC2119].

2. How MPLS echo request gets received by control plane

For MPLS ping, the MPLS echo request will eventually be fowarded to the egress node if the fowarding path is normal. And sending the MPLS echo request to control plane at the egress node will be triggered by the Router Alert option in the IP header. And this is regardless whether IP TTL is 1 or not.

For MPLS traceroute, the MPLS echo request will arrive at the transit or egress node depending on the MPLS TTL if the forwarding path is working correctly. The transit or egress nodes will send the MPLS echo request to their control plane when MPLS TTL expires. This works regardless whether IP TTL is 1 or not.

If the fowarding path isn't normal, the MPLS echo request may be received by routers or hosts outside of the normal forarding path. But since the destination address is in 127/8 address range, the packet won't be forwarded according to RFC 1112 [RFC1112] and RFC 1812 [RFC1812], regardless whether IP TTL is 1 or not.

In summary, MPLS echo request packet will get either received or discarded properly regardless IP TTL settings, as long as it has a valid value.

3. Proposed changes

It's proposed that IP TTL MAY be set to non-zero values other than 1. For example, it could be set to 255 by default. Routers SHOULD NOT expect IP TTL to be a specific value on receving MPLS echo request packet. And routers SHOULD process MPLS echo request packet according to RFC 4379 [RFC4379] as long as IP TTL is not zero.

3.1. Sending MPLS echo request

While sending MPLS echo request, IP TTL MAY be set to any non-zero value. It's RECOMMENDED to set IP TTL to a larger value (e.g. 255) to avoid the MPLS echo request being filtered by TTL-filtering access control lists deployed to mitigate TTL expiry attacks.

3.2. Receiving MPLS echo request

On receiving MPLS echo request, fowarding plane SHOULD NOT expect a specific value of IP TTL as long as it's not zero. Routers MAY choose to discard MPLS echo request packet with IP TTL 0 according to their general IP TTL processing rules.

4. Acknowledgements

5. IANA Considerations

This memo includes no request to IANA.

6. Security Considerations

Setting IP TTL to non-zero values other than 1 in MPLS echo request doesn't introduce new security concerns. The MPLS echo request will be received or discarded properly for both normal and abnormal forwarding paths. Setting IP TTL to non-zero values other than 1 allows MPLS ping and traceroute to function properly even if there are TTL-filtering rules deployed to mitigate TTL expiry attacks.

7. References

7.1. Normative References

[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, June 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, DOI 10.17487/RFC4379, February 2006.

7.2. Informative References

[CISCO] Cisco Systems, Inc., "TTL Expiry Attack Identification and Mitigation", 2016.

Author's Address

Mingchao Shao (editor) Ericsson Inc. 300 Holger Way San Jose, CA 95134 US EMail: michael.shao@ericsson.com