| Internet-Draft | Stateless Reverse Traceroute | August 2024 |
| Heinrich & Winter | Expires 1 March 2025 | [Page] |
Only very few troubleshooting tools exist, that universally work on the public internet. Ping and traceroute are the ones that are most frequently used, when issues arise that are outside the user's administrative reach. Both perform quite basic checks. Ping can only confirm basic reachability of an interface. Traceroute can enumerate routers in the forward direction of a path but remains blind to the reverse path. In this memo, ICMP extensions are defined, that allow to build a reverse traceroute tool for the public internet without having to store state on the host performing the actual reverse traceroute operation.¶
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 1 March 2025.¶
Copyright (c) 2024 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Network operators use traceroute to troubleshoot problems that occur within their own but also outside their own network. While traceroute provides valuable information about the path to the target node, it can not gather information about the reverse path. As the internet proves to be widely asymmetric, meaning that forward and reverse path differ, traceroute's output cannot easily be used to identify problems arising on the reverse path. This memo addresses this limitation by defining a simple protocol and associated extensions that allow network operators to use traceroute's functionality from a target host back towards a client.¶
In the past, a few attempts have been made within the IETF to provide similar functionality. [RFC1393] e.g. defines an IPv4 Traceroute option. A packet carrying that option is signaling to routers, that they should send an ICMP Traceroute message, which is also defined in [RFC1393], to the originator of that packet. When the packet finally arrives at the target host, it also uses the IP Traceroute option in its answer to enable reverse traceroute. It does so by copying the IPv4 address of the originator into the option. Routers use that address to again send ICMP Traceroute message to the originator while forwarding the answer towards it. This method differs from regular traceroute in particular in its use of IP options and the need to have routers support a new feature. The IP option defined in [RFC1393] was subsequently obsoleted in [RFC6814] and the ICMP traceroute message was deprecated in [RFC6918].¶
IPv6 was also in principle capable to perform reverse traceroute from the start. The IPv6 specification in [RFC2460] defined the type 0 routing header (RH0). Adding ones own source address into that option and sending it to a destination would make said destination send a packet back to the original source. The Hop Limit for that packet is copied from the original packet and decremented by one. This way the Hop Limit can be carefully manipulated in a way to achieve a reverse traceroute with some trial and error involved. It however does not provide accurate timing information as a source will measure full round trip times for each hop on the reverse path. Just as the aforementioned IP options and ICMP messages, RH0 has also been deprecated for quite some time now ([RFC5095]) and has been removed from the updated IPv6 specification in [RFC8200].¶
The mechanism defined in this memo does not require router changes and does neither rely on IPv4 options nor on IPv6 extension headers. In fact, as much as possible, the traceroute operation as in use today is utilized to implement reverse traceroute itself.¶
Another attempt at remotely triggering traceroute is documented in [RFC4560]. Performing traceroute on a remote host and collecting the results is essentially reverse traceroute if the performed traceroute is towards the client that actually triggered it. The document specifies an elaborate SNMP MIP module to perform this function. It does however not restrict the host to which the traceroute can be sent, and access to SNMP functionality is typically restricted and not a good choice for a facility that is supposed to work across the public internet. The mechanism defined in this document does rely on ICMP and restricts the reverse traceroute operation to the client that issues the request.¶
Most closely resembling reverse traceroute as defined in this document is Proxy Trace [proxy-trace]. Besides different message encodings, code points and some smaller differences in design decisions, Proxy Trace is specified to allow a client to ask a server to traceroute towards arbitrary hosts on the internet. Reverse traceroute however only allows for measuring the path back towards the client. We believe this to be a useful restriction for server operators without severely compromising the general usefulness for clients.¶
Most basic OAM tasks on the public internet involve ICMP and the fact that ICMP is still being actively developed and enhanced shows its continued relevance and utility. [RFC4884] e.g. has made ICMP messages more extensible by defining multi-part messages. ICMP has also been extended to probe interfaces similar to ping, but without the need to have bidirectional connectivity between the probing and probed interface in [RFC8335]. ICMP has also been extended to aid the operation of traceroute to, amongst other things, indicate the interface where the expiring packet has been received, as that might differ from the interface that was used to send the ICMP Time Exceeded message (see [RFC5837]).¶
Mechanisms defining new ICMP types and codes are supposed to fall into one of two categories as per [RFC7279]. They either should serve to inform about forwarding plane anomalies or they should facilitate the discovery of dynamic information about the network. The mechanism described in this memo falls into the latter category.¶
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. .¶
Before describing protocol extensions and the detailed operation of the protocol, the following outlines a rough sketch of how reverse traceroute operates. The general aim is to define a protocol that allows a host (the client) to identify the routers on a path from another host (the server) towards itself. In addition, just as with the classic traceroute, RTT measurements should also be part of the information provided to the client.¶
Below is an illustrative example, showing why such a function could help troubleshoot problems that are difficult to identify using classic traceroute today.¶
+------+ +------+
|router| |router|
+---->| +--->| +-----+
| | B | | C | |
| +------+ +------+ v
+------+ +---+--+ +------+ +------+
| | |router| |router| | |
|client|<-->| | | |<--->|server|
| | | A | | F | | |
+------+ +------+ +--+---+ +------+
^ +------+ +------+ |
| |router| |router| |
+-----+ +----+ |<----+
| D | | E |
+------+ +------+
In the figure above we see a client and a server connected through a network of routers. A packet from the client towards the server is sent along the path consisting of routers A, B, C, and F. A packet from the server towards the client follows a different set of routers, namely, F, E, D and A. Assuming that all routers will send ICMP Time Exceeded messages when the TTL/Hop Limit of an IP packet becomes zero and currently are not hitting any rate limiting for ICMP message generation, using traceroute today, the client would only see routers A, B, C and F as part of traceroute's output.¶
To make the example more interesting, let us assume that there is a problem between routers D and E causing unusually high delay. Using traceroute today, the output might look similar to this:¶
This could be misinterpreted as a problem between F and C because starting at F, the reverse path is different and the additional delay starts to appear in traceroute's output.¶
Reverse traceroute would make the path between the server towards the client visible. Therefore its corresponding output should look similar to this, indicating the problem between D and E:¶
A client requesting a reverse traceroute does so by using new ICMP messages defined in this document. The same is true for reporting the result of a reverse traceroute operation. Everything else relies as much as possible on existing traceroute operations.¶
Clearly, the ability to trigger a traceroute on a remote host offers plenty of potential concerns, in particular in terms of amplification attacks, when a single reverse traceroute request could trigger a larger traceroute operation involving tens of packets. Therefore, the general design of the protocol requires the client to send a single request for each and every packet that the server is supposed to send. In other words, a single traceroute request from the client only triggers the emission of a single traceroute probe at the server.¶
A detailed description of the operation follows in Section 6. A further discussion about security considerations follows in Section 9.¶
Reverse traceroute messages are defined for both ICMPv4 and ICMPv6.¶
A traceroute request is sent by the client to the server to prompt the server for the creation of a single traceroute probe addressed to the client.¶
The traceroute request MAY be followed by an ICMP extension structure as defined by [RFC4884]. See Section 5 for the currently defined extensions.¶
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=TBD1 | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | (Unused) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-
Header fields:¶
NOTE: see Section 8 for why those protocol field values were chosen.¶
Type: The ICMP type of the message.¶
The value for ICMPv4 is 8. The value for ICMPv6 is 128. (Echo)¶
Data: The request carries ICMP Echo Data in a fixed format:¶
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Exp | Proto | Flow | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Protocol: The protocol the traceroute probe MUST use.¶
Supported SHOULD be ICMP, TCP and UDP. The code points for this are defined by IANA in the list of protocol numbers.¶
The identifier is employed by a client application to match traceroute requests with traceroute responses. The Exp field specifies the value of the Time-To-Live/Hop Limit field of the resulting traceroute probe.¶
The protocol field specifies the protocol to be employed in the traceroute probes. A value of 0 indicates to the server endpoint that it MUST choose a suitable protocol on its own.¶
The Flow field contains a number that impacts the next-hop forwarding decision in load-balancing routers. Adjusting the Flow field can result in the probes taking different paths. In other words, pinning the Flow field to a fixed value will make sure that all probes with the same Flow value will follow the same path. A value of 0 indicates to the server endpoint that it MUST choose a suitable flow identifier on its own. See Section 4 for details.¶
A traceroute response is sent by a server to the client containing information about the answer to a traceroute probe such as an ICMP Time Exceeded 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=TBD2 | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | (Unused) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-
Header fields:¶
Type: The ICMP type of the message.¶
The value for ICMPv4 is 0. The value for ICMPv6 is 129. (Echo Reply)¶
Data: The response carries ICMP Echo Data in a fixed format:¶
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Status: Supplies information about the status of a request.¶
Following values are defined:¶
0x00: Success¶
0x01: Invalid TTL/Hop Limit¶
0x02: Invalid Protocol¶
0x03: Invalid Flow¶
0x04: Unsupported Extension¶
0x05: Insufficient Padding¶
Value: Carries additional information depending on the status, SHOULD be set to zero when not defined for a status code. This field is defined for the following status values:¶
Unsupported Extension: Carries the Class-Num and C-Type of the first encountered unsupported extension object¶
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
¶
Insufficient Padding: Carries the number of missing padding bytes¶
The identifier of the response MUST match the the identifier of the corresponding request. If a malformed request is encountered, it MUST be silently dropped. If an invalid probe configuration is supplied by the request, the server MUST respond with a suitable error code. Additional information about an error condition MAY be supplied to the client by specifying an error message, whose length MUST be reflected in the length field.¶
The server MUST respond with an Invalid TTL/Hop Limit status if the requested TTL/Hop Limit equals zero. The server MUST choose suitable default values if the requested protocol or flow values are zero.¶
If the response status indicates success, the length field MUST be set to 0 and the message MUST be followed by a single traceroute payload structure. The traceroute payload structure MUST NOT be appended to the response message if the status does not indicate success.¶
If the server endpoints responds with an Invalid Padding status, it MUST support the Padding extension (see Section 5).¶
The traceroute payload structure contains information about a single successful traceroute probe.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Timespan + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Address: Address of the node that responded to the traceroute probe.¶
The address format is defined in [RFC4291].¶
IPv4 addresses are encoded as IPv4-mapped IPv6 addresses.¶
(Optional) Timespan: The timespan elapsed between sending a traceroute probe and receiving an answer.¶
The timespan is defined in nanoseconds.¶
If the server was not able to determine the timespan this field MUST be omitted.¶
The probes sent by a reverse traceroute server application share a set of common information, that must be encoded inside them. This set of information consists of:¶
[RFC0792] guarantees that Time Exceeded and Destination Unreachable responses contain at least the first eight bytes of the original datagram. As a consequence the needed information MUST be encoded in those eight bytes. This restriction also impacts the RTT estimates of a measurement, as the timestamp stored inside a traceroute probe might not be delivered back in the probe response. In that case the reverse traceroute server will not be able to convey an RTT measurement to the client. This section gives suggestions as to how the state SHOULD be encoded inside different types of probes. In all probes supporting port numbers, e.g. UDP and TCP, the probe identifier is encoded into the source port. As the probe identifier is a constant value, we suggest to assign an unused user port number (see Section 7 ) for reverse traceroute server implementations.¶
The flow identifier is encoded into a field of the probe packet that routers commonly use for load-balancing decisions. The following sections define the exact fields for ICMP, UDP and TCP. In adddition, when used with IPv6, the probe will use the same flow label as found in the traceroute request. This allows the client to influence load-balancing at that level as well. Further information on load-balancing and flow identifiers can be found in [paris-traceroute].¶
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=0 | Checksum (Flow) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier (Query) | Sequence (Probe) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | * Timestamp * | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The payload MUST be adjusted so that the flow identifier encoded inside the checksum is valid. A significant part of the payload SHOULD consist of random bytes to prevent the client from crafting ICMP packets with a predictable payload. It is recommended to set the probe identifier encoded in the ICMP sequence to 0xFFFF to minimize potential clashes with regular traceroute probes.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port (Probe) | Destination Port (Flow) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum (Query) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | * Timestamp * | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The payload MUST be adjusted so that the query identifier encoded inside the checksum is valid. A significant part of the payload SHOULD consist of random bytes to prevent the client from crafting malicious UDP packets with a predictable 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port (Probe) | Destination Port (Flow) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (Query) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset| Res. | Flags | Window | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | * Timestamp * | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The implementation SHOULD append additional payload to a TCP probe packet. In this case a significant part of the payload SHOULD consist of random bytes to prevent the client from crafting malicious TCP packets with a predictable payload.¶
This section defines ICMP multi-part extension objects, which are part of an extension structure defined in [RFC4884].¶
The padding extension allows an endpoint to append variable length padding to ICMP messages.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num=TBD4| C-Type=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | // (Padding) // | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Before sending traceroute requests, a client could first discover whether a server endpoint runs reverse traceroute. It does so by setting the TTL/Hop Limit inside the traceroute request message to 0, thus creating an error condition. If a response with a non-zero status, signaling an error, is received, the server runs reverse traceroute. Otherwise, the originator of the response does not provide a reverse traceroute instance (or other circumstances prevent the instance to respond to or receive requests, such as firewalls).¶
After such a potential discovery phase, the client sends regular traceroute request messages with an increasing TTL/Hop Limit to the server. Each of these request messages SHOULD employ a unique identifier to eliminate false measurements that may arise because of delayed responses to previously issued requests using the same identifier as newer ones. The client SHOULD pace those requests appropriately as to avoid packet loss due to e.g. rate limiting, which is recommended for security reasons (see Section 9). If the specified probe configuration is considered invalid by the server, an error message is immediately dispatched to the client. The client examines the status in order to find the cause of the error and prints the optional error message inside the response. If the error occured due to an invalid protocol or flow, the client can set the respective value to zero in order to ask the server to choose a suitable default value on its own.¶
If the status indicates success, the payload data structure immediately following the header is examined to retrieve the address of the node that responded to the traceroute probe and, if present, the round-trip-time encoded in the timespan field. If no response to a traceroute request message is received in a time interval specified by the client, then the server e.g. did either not receive the request or the response to a probe, or the server's traceroute response message was lost during transit to the client. In either case the client SHOULD assume that the traceroute probe was not answered.¶
The server attempts to parse incoming reverse traceroute requests and the optional multi-part extension structure immediately following the header. The extension structure MUST be parsed by a server endpoint even if all extensions are disabled. If a request with an invalid configuration was received by the server, it MUST respond with a traceroute response message indicating a suitable error status and MAY supplement it with an error message immediately following the header, whose length is encoded in the corresponding field.¶
If a request with a valid configuration was received by the server, a probe with the configuration supplied in the request is formed and sent back towards the client.¶
The server handles incoming packets as follows:¶
ICMP error messages from routers:¶
The original IP header and the first eight bytes of the traceroute probe are contained in the payload of these messages.¶
The server determines if the packet is related to reverse traceroute by checking the original probe identifier.¶
The exact encoding is specific to the protocol of the traceroute probe.¶
The destination address for the reverse traceroute response is the destination address of the original IP header.¶
The query and probe identifiers are probe specific and encoded in the first eight bytes after the original IP header.¶
Response from client:¶
The destination address for the reverse traceroute response is the source address of the packet.¶
The query and probe identifiers are probe specific.¶
If the probe identifier matches the value assigned to reverse traceroute the packet is considered a probe response and a reverse traceroute response MUST be dispatched to the client. The reverse traceroute response is built as follows: The destination address is filled in with the previously extracted value. A traceroute payload structure is appended to the response message and filled with the packet's source address. If the server was able to extract the previously stored timestamp from the packet the payload's timespan is initialized to the computed RTT value, otherwise the timespan field is omitted.¶
If this document is to be published as an RFC, IANA is asked to:¶
We ask IANA to assign the code 1 for both TBD1 and TBD2 as its deployability in the internet has been verified by a measurement study.¶
The ICMP messages defined in this memo use the ICMP types of Echo request and Echo reply but use new codes. The main reason for this is that by reusing these particular types, reverse traceroute has a higher chance of being immediately deployable on the public internet, as middleboxes are familiar with these types and especially a large number of NATs could readily translate these packets.¶
Both client and server endpoints SHOULD support and make use of the Padding extension object (Section 5) to further reduce the potential of amplification attacks. The server endpoint SHOULD require enough padding so that the total size of the packets triggered by a request does not exceed the size of the request itself.¶
A server implementation SHOULD be able to restrict the IP address ranges from which it accepts reverse traceroute requests.¶
When the server runs behind a firewall the reverse-traceroute probes may be used by a malicious user to determine open ports. Hence, reverse traceroute server endpoints SHOULD not be deployed behind a firewall that restricts egress traffic based on destination port numbers.¶
The details of the probe encoding scheme proposed in Section 4 SHOULD be carefully considered. The flow identifier specified inside reverse traceroute requests is encoded into the destination ports for UDP and TCP. If an operator deems the control of a probe's destination port as a security threat, the reverse traceroute server SHOULD be configured to allow only a single flow identifier. If a client attempts to set a flow identifier other than the one configured at the server, the server SHOULD send an appropriate error back.¶
As the probe encoding scheme uses a four-byte payload to balance changes to the checksum, a malicious client could create reverse traceroute requests that carry a known payload. Combined with the control over the destination probes destination port and employment of IP-Spoofing, the probes could be used to deliver a malicious payload to a service running on the spoofed host. The server can mitigate this risk by using payload randomization as discussed in this document.¶
We would like to thank Ole Troan for pointing out that the type 0 routing header was a means to implement reverse traceroute in IPv6.¶
We would also like to thank Saku Ytti for pointing us to his work on Proxy Trace and Ron Bonica for suggesting to avoid updates to other documents.¶
Rolf Winter and Valenin Heinrich have been partially funded by the German Federal Ministry for Economic Affairs and Climate as part of the MAVERIC project. Measurement results relating to reverse traceroute can be found in [stateless-rtr].¶