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 21 August 2022.¶

Copyright Notice

Copyright (c) 2022 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 at Internet-scale can target either collaborating parties or non-collaborating ones. Such measurements include [LARGE_SCALE] and [RFC7872].¶

Sending unsolicited probes should obviously be done at a rate low enough to avoid wasting 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 where those probes are transiting (e.g., an Internet transit router).¶

This document suggests a couple of simple techniques allowing any party or organization to understand:¶

• what this unsolicited packet is,¶
• what is its purpose,¶
• and more significantly who to contact for further information or stop the probing.¶

Note: it is expected that only good-willing researchers will use these techniques.¶

2. Probe / Measurement Description

3. In-band Probe Attribution

When the desired measurement allows for it, one "probe description URI" should be included in the payload of all probes sent. This could be:¶

• for a [RFC4443] ICMPv6 echo request: in the optional data (see section 4.1 of [RFC443]);¶
• for a [RFC792] ICMPv4 echo request: in the optional data;¶
• for a [RFC768] UDP datagram: in the data part;¶
• for a [RFC793] TCP packet with the SYN flag: data is allowed in TCP packets with the SYN flag per section 3.4 of [RFC793] (2nd paragraph);¶
• for a [RFC8200] IPv6 packet with either hop-by-hop or destination options headers, in the PadN option. Note that, per the informational [RFC4942] section 2.1.9.5, it is suggested that PadN option should only contain 0x0 and be smaller than 8 octets, so the proposed insertion of the URI in PadN option could have influence on the measurement itself;¶
• etc.¶

The URI should start at the first octet of the payload and should be terminated by an octet of 0x0, i.e., it must be null terminated.¶

Note: using the above technique produces a valid and legit packet for all the nodes forwarding and receiving the probe. The node receiving the probe may or may not process the received packet, but this should cause no harm if the probing rate is very low as compared to the network bandwidth and to the processing capacity of all the nodes.¶

4. Out-of-band Probe Attribution

When it is not possible to include the "probe description URI" in the probe, then a specific URI must be constructed based on the source address of the probe packet following [RFC8615], e.g., for a probe source address of 2001:db8::dead, the following URI are constructed:¶

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

The constructed URI must be a reference to the "Probe description Text" (see Section 2.2).¶

5. Ethical Considerations

Executing some measurement experiences over the global Internet obviously require some ethical considerations when transit/destination non-solicited parties are involved.¶

This document proposes a common way to identity the source and the purpose of active probing in order to reduce the potential burden on the non-solicited 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.¶

6. Security Considerations

While it is expected that only good-willing researchers will use these techniques, they will simplify and shorten the time to identify a probing across the Internet.¶

As both proposed techniques rely on the IP source address, they are vulnerable to IP spoofing.¶

7. 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, Mehdi Kouhen, and Mark Townsley for helpful discussions as well as Raphael Leas for an early implementation.¶

Authors' Addresses