Proxy Trace: A Utility for Programmatic Discovery of Forward and Reverse Path
draft-ytti-intarea-proxy-trace-00

Abstract

This document describes a network diagnostic tool called Proxy Trace. Proxy Trace has similarities with PING and TRACEROUTE in that it uses PING style ICMP request to ask the remote host to trigger a single packet TRACEROUTE query and deliver the reply in PING style ICMP reply.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

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 https://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 September 16, 2019.

Copyright Notice

Copyright (c) 2019 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 (https://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
• 2. Terminology
• 3. Operation
• 4. ICMP Proxy Trace Request
• 5. ICMP Proxy Trace Reply
• 6. Proxy Trace Probe Request Payload
• 7. Stateless Operation
• 8. Timestamp format
• 9. ICMP Message Processing
• 10. Implementation Considerations
• 11. Error Handling
• 12. IANA Considerations
• 13. Security Considerations
• 14. References
• 14.1. Normative References
• 14.2. Informative References
• Appendix A. Acknowledgments
• Author's Address

1. Introduction

Network operators use TRACEROUTE to discover the path between the client host and a target host. An Operator does this by running the traceroute software on the client host and giving as an argument target host to which operator wants to discover the network path. This information helps network operator to understand and troubleshoot issues on the network.

This document describes a network diagnostic tool called Proxy Trace. Proxy Trace is similar to TRACEROUTE in that it can be used to discover path between two hosts, but it differs from TRACEROUTE in that it can discover the path between two arbitrary hosts, allowing operator not only discover the reverse path but also removes the requirement that the operator must have access to a host in the path.

Further unlike alternative solutions such as looking glasses, Proxy Trace replies are formal and machine parseable. This enables programmatic discovery of both directions of the path. Motivation for Proxy Trace is to reduce outage times by reducing the time it takes to identify the issue, while also enabling programmatic identification and recovery of an outage.

2. Terminology

This document uses the following terms:

Proxy Trace Request:

An ICMP packet Proxy Trace Client sends to a Proxy Trace Server.

Proxy Trace Reply:

An ICMP packet Proxy Trace Server sends to a Proxy Trace Client.

Proxy Trace Client:

Client host requesting for a Proxy Trace

Proxy Trace Server:

Server listening to a Proxy Trace Requests, sending Proxy Trace Probe Request, receiving Proxy Trace Probe Reply and sending Proxy Trace Reply

Proxy Trace Target:

Destination address of the Proxy Trace Probe Request

Proxy Trace Probe Request:

Packet Proxy Trace Server sends towards the Proxy Trace Target. Equivalent to the packet generated by TRACEROUTE

Proxy Trace Probe Reply:

Packet received from the network as a reply to the Proxy Trace Probe Request, usually ICMP TTL Exceeded or ICMP Host Unreachable message

3. Operation

+-----------+
| PT Client |
+-----------+
|
~~~~~~~~~~~~
~ internet ~
~~~~~~~~~~~~
|
+-----------+    +------+    +------+    +-------+   +-----------+
| PT Server |----| Hop1 |----| Hop2 |----| Hop3  |---| PT Target |
+-----------+    +------+    +------+    +-------+   +-----------+

Figure 1

In the attached diagram PT Client wants to discover the path from PT Server to a PT Target. The same process is repeated for each Hop:

Send Proxy Trace Request:

PT Client sends Proxy Trace Request to PT Server with Hop-Limit '1' and Destination Address 'PT Target'.

Receive Proxy Trace Request:

PT Server receives Proxy Trace Request, verifies its size and TLVs.

Send Proxy Trace Probe Request:

PT Server sends Proxy Trace Probe Request towards PT Target out from the Interface where FIB informs PT Target to be located. PT Server SHOULD use the same FIB for Proxy Trace Probe Request as where it received the Proxy Trace Request.

Receive Proxy Trace Probe Request:

Hop1 received the Proxy Trace Probe Request, because TTL has expired it punts the packet from data-plane to control-plane.

Send Proxy Trace Probe Reply:

Hop1 sends ICMP TTL Exceeded message to the PT Server

Receive Proxy Trace Probe Reply:

PT Server received the Proxy Trace Probe Reply and relates it to the open Proxy Trace Request.

Send Proxy Trace Reply:

PT Server generates Proxy Trace Reply message and adds Proxy Trace Probe Reply packet as TLV 0 to the Proxy Trace Reply message. PT Server sends the Proxy Trace Reply message to the PT Client.

Receive Proxy Trace Reply:

PT Client receives the Proxy Trace Reply from PT Server learning that Hop Limit 1 in the path between PT Server and PT Target it Hop1

PT Client is free to send multiple Proxy Trace Request messages without waiting for a Proxy Trace Reply message.

4. ICMP Proxy Trace Request

The ICMP Proxy Trace Request is defined for both ICMPv4 and ICMPv6. Like any ICMP message, the ICMP Proxy Trace Request is encapsulated in an IP header. The ICMPv4 version of the ICMP Proxy Trace Request message is encapsulated in an IPv4 header, while the ICMPv6 version is encapsulated in an IPv6 header. ICMP Proxy Trace Request message's minimum size on IPv4 level is 576B and on IPv6 level 1280B.

Figure 2. depicts the ICMP Proxy Trace Request message.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Identifier          |        Sequence Number        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  ICMP Proxy Trace Request TLV Structure

Figure 2

IP Header fields:

Source Address:

The Source Address identifies the Proxy Trace Client. It MUST be a valid IPv4 or IPv6 unicast address.

Destination Address:

The Destination Address identifies the Proxy Trace Server. It MUST be a valid IPv4 or IPv6 unicast address.

ICMP fields:

Type:

Proxy Trace Request. The value for ICMPv4 is FIX44. The value for ICMPv6 is FIX162.

Code:

MUST be set to 0 and MUST be ignored upon receipt.

Checksum:

For ICMPv4, see [RFC0792]. For ICMPv6, see [RFC4443].

Identifier:

And Identifier to aid in matching ICMP Proxy Trace Replies to ICMP Proxy Trace Requests. May be 0. See [RFC0792] Echo/Echo Reply.

Sequence Number:

A Sequence Number to aid in matching ICMP Proxy Trace Replies to ICMP PRoxy Trace Requests. May be 0. See [RFC0792] Echo/Echo Reply.

TLVs:

Padding:

Client added padding to reach the desired Proxy Trace Request mesages size. Padding Length is set to 0 both to remove possibility of using it as a packet size verification method and to remove possibility of adding TLV after it. Length field may be omitted if 2 byte of padding is sufficient. Implementation being aware of packet size can stop reading after it has read Type value.

Type:

0

Length:

0

Value:

Any

Times:

0 or 1

Implementation:

Mandatory

Honor:

Yes

Location:

Last

Default:

None

Source Address:

Source Address of the Proxy Trace Probe Request message.

Type:

1

Length:

4 for IPv4 and 16 for IPv6

Value:

Any

Times:

0 or 1

Implementation:

Optional

Honor:

Opt-In

Location:

Any

Default:

Destination Address of ICMP Proxy Trace Request

Destination Address:

Destination Address of the Proxy Trace Probe Request mesasge.

Type:

2

Length:

4 for IPv4 and 16 for IPv6

Value:

Any

Times:

0 or 1

Implementation:

Mandatory

Honor:

Opt-Out

Location:

Any

Default:

Source Address of ICMP Proxy Trace Request

Hop Limit:

Hop Limit of the Proxy Trace Probe Request message.

Type:

3

Length:

1 Byte

Value:

1-255, NOT 0

Times:

1

Implementation:

Mandatory

Honor:

Yes

Location:

Any

Default:

None

IP Protocol:

IP Protocol number of the Proxy Trace Probe Request message.

Type:

4

Length:

1 Byte

Value:

Any

Times:

0 or 1

Implementation:

Optional

Honor:

Opt-In

Location:

Any

Default:

17 (UDP)

Source Port:

L4 Source Port number of the Proxy Trace Probe Request message.

Type:

5

Length:

2 Bytes

Value:

Any

Times:

0 or 1

Implementation:

Optional

Honor:

Opt-In

Location:

Any

Default:

49200 from the Ephemeral Port Range ([RFC6056])

Destination Port:

L4 Destination Port number of the Proxy Trace Probe Request message.

Type:

6

Length:

2 Bytes

Value:

Any

Times:

0 or 1

Implementation:

Optional

Honor:

Opt-In

Location:

Any

Default:

33688 + hop-limit (33689-33943)

Payload Length:

Payload Length in bytes of the Proxy Trace Probe Request message.

Type:

7

Length:

2 Bytes

Value:

Any

Times:

0 or 1

Implementation:

Optional

Honor:

Opt-In

Location:

Any

Default:

26 for IPv4 and 38 for IPv6

Traffic Class:

Traffic Class byte of the Proxy Trace Probe Request message.

Type:

8

Length:

1 Byte

Value:

Any

Times:

0 or 1

Implementation:

Optional

Honor:

Opt-In

Location:

Any

Default:

Local choice

Bit Pattern:

Bit Pattern of a payload of the Proxy Trace Probe Request message.

Type:

9

Length:

Any, the implementation MAY choose to limit arbitrarily what it accepts

Value:

Any

Times:

0 or 1

Implementation:

Optional

Honor:

Opt-In

Location:

Any

Default:

See Proxy Trace Probe Request Payload section

Flow Label:

IPv6 20b Flow Label

Type:

10

Length:

3 Bytes

Value:

Any, four most significant bits are ignored

Times:

0 or 1

Implementation:

Optional

Honor:

Opt-In

Location:

Any

Default:

0

Future Use:

Type:

11-59999

Local Use:

Type:

60000-65535

5. ICMP Proxy Trace Reply

The ICMP Proxy Trace Reply is defined for both ICMPv4 and ICMPv6. Like any ICMP message, the ICMP Proxy Trace Reply is encapsulated in an IP header. The ICMPv4 version of the ICMP Proxy Trace Reply message is encapsulated in an IPv4 header, while the ICMPv6 version is encapsulated in an IPv6 header.

Figure 3. depicts the ICMP Proxy Trace Reply message.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Identifier          |        Sequence Number        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  ICMP Proxy Trace Reply TLV Structure

Figure 3

IP Header fields:

Source Address:

The Source Address identifies the Proxy Trace Server. It MUST be a valid IPv4 or IPv6 unicast address.

Destination Address:

The Destination Address identifies the Proxy Trace Client. It MUST be a valid IPv4 or IPv6 unicast address.

ICMP fields:

Type:

Proxy Trace Reply. The value for ICMPv4 is FIX45. The value for ICMPv6 is FIX163.

Code:

MUST be set to 0 and MUST be ignored upon receipt.

Checksum:

For ICMPv4, see [RFC0792]. For ICMPv6, see [RFC4443].

Identifier:

And Identifier to aid in matching ICMP Proxy Trace Replies to ICMP Proxy Trace Requests. May be 0. See [RFC0792] Echo/Echo Reply.

Sequence Number:

A Sequence Number to aid in matching ICMP Proxy Trace Replies to ICMP Proxy Trace Requests. May be 0. See [RFC0792] Echo/Echo Reply.

TLVs:

Proxy Trace Probe Reply message:

The ICMP TTL exceeded or Unreachable Message Server received, verbatim. Includes extension objects such as [RFC4950] and [RFC5837].

Type:

0

Length:

Any

Value:

Any

Times:

0 or 1

Implementation:

Mandatory

Location:

Any

Default:

None

Proxy Trace Probe Request Timestamp:

Timestamp of Proxy Trace Probe Request leaving the Proxy Trace Server

Type:

1

Length:

6 Bytes

Value:

Any

Times:

0 or 1

Implementation:

Optional

Location:

Any

Default:

None

Proxy Trace Probe Reply Timestamp:

Timestamp of Proxy Trace Probe Reply arriving at the Proxy Trace Server

Type:

2

Length:

6 Bytes

Value:

Any

Times:

0 or 1

Implementation:

Optional

Location:

Any

Default:

None

Honored TLV:

If Proxy Trace Request contains one or more TLVs which implementations does not support or does not honor, implementation responds with list of honored TLVs

Type:

401

Length:

Any

Value:

2 bytes per Honored TLV

Times:

0 or 1

Implementation:

Mandatory

Location:

Any

Default:

None

Bad TLV Count:

List of TLV type numbers occurring more or less time than expected

Type:

402

Length:

Any

Value:

2 bytes per Bad TLV

Times:

0 or 1

Implementation:

Mandatory

Location:

Any

Default:

None

Bad TLV Length:

List of TLV type numbers having Length implementation rejects as valid

Type:

403

Length:

Any

Value:

2 bytes per Bad TLV

Times:

0 or 1

Implementation:

Mandatory

Location:

Any

Default:

None

Bad TLV Value:

List of TLV type numbers having Value implementation rejects as valid

Type:

404

Length:

Any

Value:

2 bytes per Bad TLV

Times:

0 or 1

Implementation:

Mandatory

Location:

Any

Default:

None

Future Use:

Type:

7-59999

Local Use:

Type:

60000-65535

6. Proxy Trace Probe Request Payload

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Timestamp                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Timestamp           |           Identifier          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Sequence Number        |          Payload Hash         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Payload Hash         |         Source Address        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address 

Figure 4

Proxy Trace Probe Request Payload Fields:

Timestamp:

6B timestamp, as documented in the TIMESTAMP section

Identifier:

2B Identifier from the Proxy Trace Request Message

Sequence Number:

2B Sequence Number from the Proxy Trace Request Message

Payload Hash:

4B hash of the Proxy Trace Probe Request Payload Fields + Local Secret

Source Address

4B or 16B Source Address from the Proxy Trace Request

7. Stateless Operation

Implementation MAY choose to do an entirely stateless Proxy Trace Server implementation. The benefit of stateless implementation is that it is friendly towards implementation in the hardware. Stateless implementation MUST use Payload Hash to verify Proxy Trace Probe Reply for correctness, otherwise an unsolicited Proxy Trace Probe Reply message may create 52B amplification, with hash verification there is 1:4294967296 attenuation for the unsolicited Proxy Trace Probe Reply messages. Implication of stateless operation is that the Proxy Trace Probe Reply message must contain the original Proxy Trace Probe Request up-to the Source Address, otherwise payload hash verification will fail. This further implies that for IPv4 the host sending the Proxy Trace Probe Reply message needs to support [RFC4884] for stateless operation to function. Proxy Trace Server using stateless operation has no obligation to function when Proxy Trace Probe Reply message does not facilitate stateless operation, more specifically there is no requirement for stateful operation as a fallback.

8. Timestamp format

The timestamp should be 6 bytes or 48 bits wide, most significant bit is a flag called 'non-canonical epoch'. If 'non-canonical epoch' flag is not set timestamp's epoch is UTC midnight, if 'non-canonical epoch' flag is set then epoch is unspecified but not UTC midnight. Timestamp unit is nanoseconds.

9. ICMP Message Processing

When a host receives an ICMP Proxy Trace Request message and any of the following conditions apply, the node MUST silently discard the incoming message:

• The node does not recognize ICMP Proxy Trace Request messages.
• The node has disabled the ICMP Proxy Trace Request functionality.
• The incoming ICMP Proxy Trace Request message is too small.
• The Source Address of the incoming message is not a unicast address.
• The Destination Address of the incoming message is a multicast address.

Discard SHOULD happen in the date-plane

Otherwise, when a node receives an ICMPv4 Proxy Trace Request, it MUST format an ICMPv4 Proxy Trace Reply as follows:

Don't Fragment (DF) flag:

1

More Fragments flag:

0

Fragment Offset:

0

TTL:

255

Protocol:

ICMP

When a node receives an ICMPv6 Proxy Trace Request, it MUST format an ICMPv6 Proxy Trace Reply as follows:

Hop Limit:

255

Next Header:

ICMPv6

In either case, the responding node MUST do the following:

• Copy the Source Address from the Proxy Trace Request message to the Destination Address of the Proxy Trace Reply message.
• Copy the Destination Address from the Proxy Trace Request message to the Source Address of the Proxy Trace Reply message.
• Set the ICMP Type to Proxy Trace Reply.
• Copy the Identifier from the Proxy Trace Request message to the Proxy Trace Reply message.
• Copy the Sequence Number from the Proxy Trace Request message to the Proxy Trace Reply message.
• Set the Code field to 0.
• Set the Checksum appropriately.
• Set the TLVs appropriately.
• Forward the Proxy Trace Reply to the Proxy Trace Client.

10. Implementation Considerations

A host implementing Proxy Trace SHOULD have it turned on by default in all interfaces and MUST allow turning it off/on per interface. The implementation MUST police rate of received Proxy Trace Request messages at the data-plane to 1000 pps, implementation SHOULD allow policer to be configured.

Proxy Trace Server SHOULD timeout after 1 second of waiting for a Proxy Trace Probe Reply message and MAY timeout earlier. Proxy Trace Server SHOULD NOT send Proxy Trace Reply message if it timed out.

11. Error Handling

Proxy Trace Server encountering any problem in the Proxy Trace Request message MUST not send any Proxy Trace Probe Reqeust message out and SHOULD send Proxy Trace Reply message to the Proxy Trace Client informing of the issue. Proxy Trace Server may give up parsing the Proxy Trace Request message after one or more problems.

Proxy Trace Server receiving too small Proxy Trace Request message should silently discard it in the data-plane.

12. IANA Considerations

Per this document, IANA is requested to reference this document in the "Internet Control Message Control (ICMP) Parameters" and the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registries under the "Code Fields" group.

13. Security Considerations

Allowing the client to set arbitrary Payload will create amplification potential.

Allowing the client to define Protocol, Port and Bit Pattern allows client to craft arbitrary packets enabling it to perform port knocking and trigger packet-of-death bugs.

Opt-In Request TLVs should only be honored in trusted networks.

By default, unlike ICMP Echo, there is bps attenuation because the Proxy Request messages are much larger than the Proxy Trace Probe Request and the Proxy Trace Probe Reply messages.

By default there is potentially 2 x pps amplification, however this is a minor concern as other more common vectors, such as TCP SYN spoofing allow for much higher pps amplification.

There is no way for the Client to cause the Server to send more than two packets per each packet the Client sends.

Other than gleaning information about UDP TRACEROUTE ports, there are no security implications identified in setting the destination address TLV. Attacker setting the destination address TLV will necessarily create less traffic towards the victim compared to not setting the destination address TLV and spoofing the source address. Without setting the destination address TLV Attacker will be able to send two packets to a single Victim, whereas by setting the destination address TLV Attacker can only send one packet per victim.

Precedent exists in [RFC8335] where we can ask the server to return information to us which would normally not be visible to us. Like every packet received on control-plane there are always risks involved in software defects, however we need to balance the cost of those risks with the cost savings afforded by diagnostic tools due to reduced outage times. Historically we have had security issues in ICMP Echo, including f00fc7c8 and +++ATH, but we continue to utilize ICMP Echo because the perceived diagnostic value in reducing outage times exceeds the perceived risk carried.

14. References

14.1. Normative References

14.2. Informative References

Appendix A. Acknowledgments

Author's Address