| Internet-Draft | Probes Attribution | July 2023 |
| Vyncke, et al. | Expires 24 January 2024 | [Page] |
Active measurements at Internet-scale can target either collaborating parties or non-collaborating ones. This is similar scan and could be perceived as aggressive. This document proposes a couple of simple techniques allowing any party or organization to understand what this unsolicited packet is, what is its purpose, and more importantly who to contact.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://evyncke.github.io/opsec-probe-attribution/draft-vyncke-opsec-probe-attribution.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-vyncke-opsec-probe-attribution/.¶
Discussion of this document takes place on the Operational Security Capabilities for IP Network Infrastructure Working Group mailing list (mailto:opsec@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/opsec/. Subscribe at https://www.ietf.org/mailman/listinfo/opsec/.¶
Source for this draft and an issue tracker can be found at https://github.com/evyncke/opsec-probe-attribution.¶
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 24 January 2024.¶
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.¶
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:¶
Note: it is expected that only good-willing researchers will use these techniques.¶
This document defines a "probe description URI" (see Section 2.2) as a URI pointing to:¶
Similarly, as in [RFC9116], when a node probes other nodes over the Internet, it should create a text file following the syntax described in section 3 of [RFC9116] and should have the following fields:¶
Plus, another one "description" which is a URI pointing a document describing the measurement.¶
When it is not possible to include the "probe description URI" in the probe packet itself, 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:¶
The constructed URI must be a reference to the "Probe description Text" (see Section 2.2).¶
When the desired measurement allows for it, one "probe description URI" should be included in the payload of all probes sent. This could be:¶
The URI should start at the first octet of the payload and should be terminated by an octet of 0x00, i.e., it must be null terminated. If the URI cannot be placed at the beginning of the payload, then it should be preceded also by an octet of 0x00.¶
Note: using the above technique produces a valid and legit packet for all the nodes forwarding 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. As the insertion of the URI in the packet may not respect the syntax of the protocol, responses may not be received (such a TCP SYN+ACK) and perhaps an ICMP should be expected or more probably an absence of reply.¶
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.¶
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.¶
This information is provided to identify the source and intent of specific probes, but there is no authentication possible for the inline information. As a result, a malevolent actor could provide false information while conducting the probes, so that the action was attributed to a third party. The recipient of this information cannot, as a result, rely on this information without confirmation. If a recipient cannot confirm the information or does not wish to do so, they should treat the flows as if there were no attribution.¶
The "Well-Known URIs" registry should be updated with the following:¶
The authors would like to thank Alain Fiocco, Fernando Gont, Ted Hardie, Mehdi Kouhen, and Mark Townsley for helpful discussions as well as Raphaël Léas for an early implementation.¶