Attribution of Internet Probes
Internet-Draft draft-ietf-opsec-probe-attribution-00
Éric Vyncke
Cisco
De Kleetlaan 64
Diegem
1831
Belgium
evyncke@cisco.com
Benoît Donnet
Université de Liège
Belgium
benoit.donnet@uliege.be
Justin Iurman
Université de Liège
Belgium
justin.iurman@uliege.be
02 September 2022
Operations and Management
Operational Security Capabilities for IP Network Infrastructure
Internet-Draft
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.
About This Document
The latest revision of this draft can be found at https://evyncke.github.io/opsec-probe-attribution/draft-ietf-opsec-probe-attribution.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-opsec-probe/.
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/.
Source for this draft and an issue tracker can be found at https://github.com/evyncke/opsec-probe-attribution.
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.
Probe / Measurement Description
Probe Description URI
This document defines a "probe description URI" (see Section 2.2) as a URI pointing to:
- a "Probe Description", see Section 2.2, e.g., "https://example.net/measurement.txt";
- an email address, e.g., "mailto:eric@example.net";
- a phone number to call, e.g., "tel:+1-201-555-0123".
Probe Description Text
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:
- contact;
- expires;
- preferred-languages.
Plus, another one "description" which is a URI pointing a document describing the measurement.
Out-of-band Probe Attribution
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:
- 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).
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 [RFC4443]);
- 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 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.
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.
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.
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.
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
References
Normative References
[RFC9116]

A File Format to Aid in Security Vulnerability Disclosure
E. Foudil
Y. Shafranovich
April 2022
RFC 9116
DOI 10.17487/RFC9116
[RFC8615]

Well-Known Uniform Resource Identifiers (URIs)
M. Nottingham
May 2019
RFC 8615
DOI 10.17487/RFC8615
[RFC4443]

Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
A. Conta
S. Deering
M. Gupta, Ed.
March 2006
STD 89
RFC 4443
DOI 10.17487/RFC4443
[RFC792]

Internet Control Message Protocol
J. Postel
September 1981
STD 5
RFC 792
DOI 10.17487/RFC0792
[RFC768]

User Datagram Protocol
J. Postel
August 1980
STD 6
RFC 768
DOI 10.17487/RFC0768
[RFC793]

Transmission Control Protocol
J. Postel
September 1981
RFC 793
DOI 10.17487/RFC0793
[RFC8200]

Internet Protocol, Version 6 (IPv6) Specification
S. Deering
R. Hinden
July 2017
STD 86
RFC 8200
DOI 10.17487/RFC8200
Informative References
[LARGE_SCALE]

Efficient Algorithms for Large-Scale Topology Discovery
Benoît Donnet
Université Pierre & Marie Curie Laboratoire LiP6–CNRS
Philippe Raoult
Université Pierre & Marie Curie Laboratoire LiP6–CNRS
Timur Friedman
Université Pierre & Marie Curie Laboratoire LiP6–CNRS
Mark Crovella
Boston University Computer Science Department
2005
DOI 10.1145/1071690.1064256
[IPV6_TOPOLOGY]

In the IP of the Beholder Strategies for Active IPv6 Topology Discovery
Robert Beverly
Naval Postgraduate School
Ramakrishnan Durairajan
University of Oregon
David Plonka
Akamai Technologies
Justin P. Rohrer
Naval Postgraduate School
2018
DOI 10.1145/3278532.3278559
[IPV4_TOPOLOGY]

Yarrp’ing the Internet Randomized High-Speed Active Topology Discovery
Robert Beverly
Naval Postgraduate School
2016
DOI 10.1145/2987443.2987479
[RFC7872]

Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World
F. Gont
J. Linkova
T. Chown
W. Liu
June 2016
RFC 7872
DOI 10.17487/RFC7872
[RFC4942]

IPv6 Transition/Co-existence Security Considerations
E. Davies
S. Krishnan
P. Savola
September 2007
RFC 4942
DOI 10.17487/RFC4942
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.