Stateless Reverse Traceroute
draft-heiwin-intarea-reverse-traceroute-stateless-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Valentin Heinrich , Rolf Winter | ||
| Last updated | 2024-08-28 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-heiwin-intarea-reverse-traceroute-stateless-03
Internet Area Working Group V. Heinrich
Internet-Draft R. Winter
Intended status: Standards Track University of Applied Sciences Augsburg
Expires: 1 March 2025 28 August 2024
Stateless Reverse Traceroute
draft-heiwin-intarea-reverse-traceroute-stateless-03
Abstract
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.
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 1 March 2025.
Copyright Notice
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
Heinrich & Winter Expires 1 March 2025 [Page 1]
Internet-Draft Stateless Reverse Traceroute August 2024
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Traceroute Request . . . . . . . . . . . . . . . . . . . 6
3.2. Traceroute Response . . . . . . . . . . . . . . . . . . . 8
3.3. Traceroute Payload Structure . . . . . . . . . . . . . . 10
4. Probes . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Client . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
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.
Heinrich & Winter Expires 1 March 2025 [Page 2]
Internet-Draft Stateless Reverse Traceroute August 2024
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.
Heinrich & Winter Expires 1 March 2025 [Page 3]
Internet-Draft Stateless Reverse Traceroute August 2024
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.
1.1. Terminology
Client: The machine that sends reverse traceroute requests.
Server: The machine that responds to reverse traceroute requests,
i.e. the machine that actually performs the traceroute operation.
Probe, probe packet, traceroute probe: A packet, that is sent as
part of a traceroute operation, intended to expire at a certain
router, causing it to respond with a ICMP Time Exceeded message.
Typically these are UDP packets, but they could also be ICMP or
TCP packets.
1.2. 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. .
Heinrich & Winter Expires 1 March 2025 [Page 4]
Internet-Draft Stateless Reverse Traceroute August 2024
2. Overview
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 |
+------+ +------+
Figure 1: Exemplary scenario
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:
1. A 1ms 2ms 1ms
2. B 3ms 3ms 2ms
Heinrich & Winter Expires 1 March 2025 [Page 5]
Internet-Draft Stateless Reverse Traceroute August 2024
3. C 5ms 6ms 6ms
4. F 340ms 320ms 350ms
5. server 345ms 310ms 360ms
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:
1. F 1ms 2ms 1ms
2. E 3ms 2ms 3ms
3. D 300ms 320ms 310ms
4. A 330ms 315ms 332ms
5. client 345ms 360ms 360ms
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.
3. Protocol Design
Reverse traceroute messages are defined for both ICMPv4 and ICMPv6.
3.1. Traceroute Request
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.
Heinrich & Winter Expires 1 March 2025 [Page 6]
Internet-Draft Stateless Reverse Traceroute August 2024
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 ...
+-+-+-+-+-
Figure 2
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)
* Code: Reverse traceroute messages are identified by code TBD1.
* Identifier: The ICMP query identifier of the message.
* Unused: MUST be set to 0 and ignored by the receiver.
* Data: The request carries ICMP Echo Data in a fixed format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exp | Proto | Flow |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Exp: The hop at which the traceroute probe is expected to
expire. This translates to the Time-To-Live (IPv4)/Hop Limit
(IPv6) value the traceroute probe MUST use.
- 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.
- Flow: The flow identifier the traceroute probe MUST use.
Heinrich & Winter Expires 1 March 2025 [Page 7]
Internet-Draft Stateless Reverse Traceroute August 2024
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.
3.2. Traceroute Response
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 ...
+-+-+-+-+-
Figure 3
Header fields:
* Type: The ICMP type of the message.
The value for ICMPv4 is 0. The value for ICMPv6 is 129. (Echo
Reply)
* Code: Reverse traceroute messages are identified by code TBD2.
* Identifier: The ICMP query identifier of the message.
* Unused: MUST be set to 0 and ignored by the receiver.
Heinrich & Winter Expires 1 March 2025 [Page 8]
Internet-Draft Stateless Reverse Traceroute August 2024
* 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
- Length: The length of the optional error message following the
header.
- 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:
o 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o 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.
Heinrich & Winter Expires 1 March 2025 [Page 9]
Internet-Draft Stateless Reverse Traceroute August 2024
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).
3.3. Traceroute Payload Structure
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 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4
* 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.
Heinrich & Winter Expires 1 March 2025 [Page 10]
Internet-Draft Stateless Reverse Traceroute August 2024
If the server was not able to determine the timespan this field
MUST be omitted.
4. Probes
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:
Flow identifier: An identifier that affects the next-hop forwarding
decision in load-balancing routers. Depending on the protocol
used for the probes (ICMP, TCP or UDP), the flow identifier
affects different fields in the probe packet's header.
Probe identifier: A constant identifier that identifies the packet
as a reverse traceroute probe. This identifier is needed to
distinguish an answer to a reverse traceroute probe from an ICMP
Time Exceeded message triggered by the traceroute tool running on
the same machine.
Query identifier: An identifier that is used by the server to match
traceroute probes with their responses. It is identical to the
identifier inside the traceroute request, which the client uses to
match traceroute requests and responses.
Timestamp: The current timestamp when issuing the probe in
nanoseconds resolution. By extracting this information from the
probe's response the RTT can be computed.
[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
Heinrich & Winter Expires 1 March 2025 [Page 11]
Internet-Draft Stateless Reverse Traceroute August 2024
influence load-balancing at that level as well. Further information
on load-balancing and flow identifiers can be found in
[paris-traceroute].
4.1. ICMP
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5
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.
4.2. UDP
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6
Heinrich & Winter Expires 1 March 2025 [Page 12]
Internet-Draft Stateless Reverse Traceroute August 2024
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.
4.3. TCP
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7
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.
5. Extensions
This section defines ICMP multi-part extension objects, which are
part of an extension structure defined in [RFC4884].
5.1. Padding
The padding extension allows an endpoint to append variable length
padding to ICMP messages.
Heinrich & Winter Expires 1 March 2025 [Page 13]
Internet-Draft Stateless Reverse Traceroute August 2024
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) // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6. Operation
6.1. Client
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.
Heinrich & Winter Expires 1 March 2025 [Page 14]
Internet-Draft Stateless Reverse Traceroute August 2024
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.
6.2. Server
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:
1. 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.
2. Response from client:
Heinrich & Winter Expires 1 March 2025 [Page 15]
Internet-Draft Stateless Reverse Traceroute August 2024
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.
7. IANA Considerations
If this document is to be published as an RFC, IANA is asked to:
* assign a unique user port number to be encoded as the probe
identifier in the source port of reverse traceroute probes (
Section 4 )
* extend type 8 with code TBD1 as reverse traceroute request in the
list of ICMP Parameters
* extend type 0 with code TBD2 as reverse traceroute response in the
list of ICMP Parameters
* extend type 128 with code TBD1 as reverse traceroute request in
the list of ICMPv6 Parameters
* extend type 129 with code TBD2 as reverse traceroute response in
the list of ICMPv6 Parameters
* assign an ICMP Multi-Part Extension Object with Class-Num TBD4 for
the padding extension
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.
Heinrich & Winter Expires 1 March 2025 [Page 16]
Internet-Draft Stateless Reverse Traceroute August 2024
8. Discussion
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.
9. Security Considerations
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.
Heinrich & Winter Expires 1 March 2025 [Page 17]
Internet-Draft Stateless Reverse Traceroute August 2024
10. Acknowledgments
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].
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
"Extended ICMP to Support Multi-Part Messages", RFC 4884,
DOI 10.17487/RFC4884, April 2007,
<https://www.rfc-editor.org/info/rfc4884>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References
[paris-traceroute]
Augustin, B., Cuvellier, X., Orgogozo, B., Viger, F.,
Friedman, T., Latapy, M., Magnien, C., and R. Teixeira,
"Avoiding traceroute anomalies with Paris traceroute",
Internet Measurement Conference (IMC) 06, October 2006.
Heinrich & Winter Expires 1 March 2025 [Page 18]
Internet-Draft Stateless Reverse Traceroute August 2024
[proxy-trace]
Ytti, S., "Proxy Trace: A Utility for Programmatic
Discovery of Forward and Reverse Path", March 2019,
<https://ytti.github.io/proxy-trace/draft-ytti-intarea-
proxy-trace.html>.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>.
[RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393,
DOI 10.17487/RFC1393, January 1993,
<https://www.rfc-editor.org/info/rfc1393>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC4560] Quittek, J., Ed. and K. White, Ed., "Definitions of
Managed Objects for Remote Ping, Traceroute, and Lookup
Operations", RFC 4560, DOI 10.17487/RFC4560, June 2006,
<https://www.rfc-editor.org/info/rfc4560>.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095,
DOI 10.17487/RFC5095, December 2007,
<https://www.rfc-editor.org/info/rfc5095>.
[RFC5837] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen,
N., and JR. Rivers, "Extending ICMP for Interface and
Next-Hop Identification", RFC 5837, DOI 10.17487/RFC5837,
April 2010, <https://www.rfc-editor.org/info/rfc5837>.
[RFC6814] Pignataro, C. and F. Gont, "Formally Deprecating Some IPv4
Options", RFC 6814, DOI 10.17487/RFC6814, November 2012,
<https://www.rfc-editor.org/info/rfc6814>.
[RFC6918] Gont, F. and C. Pignataro, "Formally Deprecating Some
ICMPv4 Message Types", RFC 6918, DOI 10.17487/RFC6918,
April 2013, <https://www.rfc-editor.org/info/rfc6918>.
[RFC7279] Shore, M. and C. Pignataro, "An Acceptable Use Policy for
New ICMP Types and Codes", BCP 189, RFC 7279,
DOI 10.17487/RFC7279, May 2014,
<https://www.rfc-editor.org/info/rfc7279>.
Heinrich & Winter Expires 1 March 2025 [Page 19]
Internet-Draft Stateless Reverse Traceroute August 2024
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8335] Bonica, R., Thomas, R., Linkova, J., Lenart, C., and M.
Boucadair, "PROBE: A Utility for Probing Interfaces",
RFC 8335, DOI 10.17487/RFC8335, February 2018,
<https://www.rfc-editor.org/info/rfc8335>.
[stateless-rtr]
Heinrich, V. and R. Winter, "Towards a Stateless Reverse
Traceroute Protocol", International Conference on
Communications (ICC) 24, June 2024.
Authors' Addresses
Valentin Heinrich
University of Applied Sciences Augsburg
Email: valentin.heinrich@tha.de
Rolf Winter
University of Applied Sciences Augsburg
Email: rolf.winter@tha.de
Heinrich & Winter Expires 1 March 2025 [Page 20]