Attribution of Internet Probes

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 19 December 2023.¶

Copyright Notice

Copyright (c) 2023 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.¶

Table of Contents

1. Introduction

Active measurements can target either collaborating parties or non-collaborating ones. Such measurements, also called probes, include [LARGE_SCALE] and [RFC7872].¶

Sending unsolicited probes should obviously be done at a rate low enough to not unduly impact the other parties' resources. But even at a low rate, those probes could trigger an alarm that will request some investigation by either the party receiving the probe (i.e., when the probe destination address is one address assigned to the receiving party) or by a third party having some devices through which those probes are transiting (e.g., an Internet transit router).¶

This document suggests some simple techniques for a source to identify its probes, allowing any party or organization to understand:¶

• what an unsolicited probe packet is,¶
• what its purpose is,¶
• and more importantly who to contact for further information.¶

Note: it is expected that only researchers with good intentions will use these techniques, although anyone might use them. This is discussed in Section 7.¶

2. Probe Description

This section provides a way for a source to describe (i.e., to identify) its probes.¶

    # Canonical URI (if any)
    Canonical: https://example.net/measurement.txt

    # Contact address
    Contact: mailto:user@example.net

    # Validity
    Expires: 2023-12-31T18:37:07z

    # Languages
    Preferred-Languages: en, es, fr

    # Probes description
    Description: This is a one-line string description of the
    probes, with no line break.

3. Out-of-band Probe Attribution

A possibility for probe attribution is to build a specific URI based on the source address of the probe packet, following [RFC8615]. For example, with a probe source address 2001:db8::dead, the following URI is built:¶

• if the reverse DNS record for 2001:db8::dead exists, e.g., "example.net", then the Probe Description URI is "https://example.net/.well-known/probing.txt";¶
• else (or in addition), the Probe Description URI is "https://[2001:db8::dead]/.well-known/probing.txt". In this case, there might be a certificate verification issue.¶

The built URI must be a reference to the Probe Description File (see Section 2.2).¶

As an example, the UK National Cyber Security Centre [NCSC] uses a similar attribution. They scan for vulnerabilities across internet-connected systems in the UK and publish information on their scanning ([NCSC_SCAN_INFO]), providing the address of the webpage in reverse DNS.¶

4. In-band Probe Attribution

Another possibility for probe attribution is to include a Probe Description URI in the probe itself:¶

• For an ICMPv6 echo request [RFC4443], include it in the data field;¶
• For an ICMPv4 echo request [RFC792], include it in the data field;¶
• For a UDP datagram [RFC768], include it in the data payload if its content has no structure;¶
• For a TCP segment [RFC9293], include it in the data payload if its content has no structure;¶
• For an IPv6 packet [RFC8200], include it in a PadN option either inside a Hop-by-Hop or Destination Options header.¶

The Probe Description URI must start at the first octet of the payload and must be terminated by an octet of 0x00, i.e., it must be null terminated. If the Probe Description URI cannot be placed at the beginning of the payload, then it must be preceded by an octet of 0x00. Inserting the Probe Description URI could obviously bias the measurement itself if the probe packet becomes larger than the path MTU.¶

For the record, the in-band probe attribution was used in [I-D.draft-vyncke-v6ops-james].¶

5. Operational and Technical Considerations

Using either the out-of-band or in-band technique, or even both combined, highly depends on intent or context. This section describes the upsides and downsides of each technique, so that probe owners or probe makers can freely decide what works best for their cases.¶

The advantages of using the out-of-band technique are that the probing measurement is not impacted by the probe attribution but also that it is easy to setup, i.e., by running a web server on a probe device to describe the measurements. Unfortunately, there are some disadvantages too. In some cases, using the out-of-band technique might not be possible due to several conditions: the presence of a NAT, too many endpoints to run a web server on, the probe source IP address cannot be known (e.g., RIPE Atlas [RIPE_ATLAS] probes are sent from IP addresses not owned by the probe owner), dynamic source addresses, etc.¶

The primary advantage of using the in-band technique is that it covers the cases where the out-of-band technique is not feasible (as described above). The primary disadvantage is that it could potentially bias the measurements, since packets with the Probe Description URI might be discarded. For example, data is allowed in TCP segments with the SYN flag ([RFC9293]) but may change the way they are processed, i.e., TCP segments with the SYN flag containing the Probe Description URI might be discarded. Another example is the Probe Description URI included in a Hop-by-Hop or Destination Options header, inside a PadN option. As per the informational [RFC4942], section 2.1.9.5, it is suggested that a PadN option should only contain 0's and be smaller than 8 octets, thus limiting its use for probe attribution. If a PadN option does not respect the recommendation, it is suggested that one may consider dropping such packets. For example, the Linux Kernel follows these recommendations and discards such packets since its version 3.5;¶

Having both the out-of-band and in-band techniques combined also has a big advantage, i.e., it could be used as an indirect means of "authenticating" the Probe Description URI in the in-band probe, thanks to a correlation with the out-of-band technique (e.g., a reverse DNS lookup). While the out-of-band technique alone is less prone to spoofing, the combination with the in-band technique offers a more complete solution.¶

6. Ethical Considerations

Executing measurement experiences over the global Internet obviously requires ethical consideration, especially when unsolicited transit/destination parties are involved.¶

This document proposes a common way to identify the source and the purpose of active probing in order to reduce the potential burden on the unsolicited parties.¶

But there are other considerations to be taken into account: from the payload content (e.g., is the encoding valid?) to the transmission rate (see also [IPV6_TOPOLOGY] and [IPV4_TOPOLOGY] for some probing speed impacts). Those considerations are out of scope of this document.¶

7. Security Considerations

It is expected that only researchers with good intentions will use these techniques, which will simplify and reduce the time to identify probes across the Internet.¶

This information is provided to identify the source and intent of specific probes, but there is no authentication possible for the inline information. Therefore, a malevolent actor could provide false information while conducting the probes, so that the action is attributed to a third party. In that case, not only would this third party be wrongly accused, but it might also be exposed to unwanted solicitations (e.g., angry emails or phone calls, if the malevolent actor used someone else's email address or phone number). As a consequence, the recipient of this information cannot trust it without confirmation. If a recipient cannot confirm the information or does not wish to do so, it should treat the flows as if there were no probe attribution.¶

8. IANA Considerations

The "Well-Known URIs" registry should be updated with the following additional values (using the template from [RFC8615]):¶

• URI suffix: probing.txt¶
• Change controller: IETF¶
• Specification document(s): this document¶
• Status: permanent¶

Acknowledgments

The authors would like to thank Alain Fiocco, Fernando Gont, Ted Hardie, Mehdi Kouhen, and Mark Townsley for helpful discussions as well as Raphael Leas for an early implementation.¶

The authors would also like to gracefully acknowledge useful review and comments received from Jen Linkova, Prapanch Ramamoorthy, Warren Kumari, and Andrew Shaw.¶

Authors' Addresses