RFC 9511

Attribution of Internet Probes

📅 published November 2023, from ietf

RFC 9511: Attribution of Internet Probes 🎀

okay bestie, let's get into this one 💖 here's the header tea:

  • Authors: É. Vyncke (Cisco), B. Donnet and J. Iurman (Université de Liège) ✨
  • Category: Informational 📚 (not a Standards Track thing, just for info)
  • Date: November 2023 📅
  • ISSN: 2070-1721
  • Obsoletes / Updates: nothing is listed in the header 🙅

Abstract

so, active measurements over the public Internet can target either collaborating parties or non-collaborating ones 🌐 and sometimes these measurements (aka "probes") get seen as unwelcome or aggressive 😬

this doc suggests some simple techniques so a source can identify its probes 🦋 that way any party or organization can figure out what an unsolicited probe packet is, what it's for, and most importantly, who to contact 📞 the technique relies on offline analysis of the probe, so it doesn't need any change in the data or control plane 🙌 it was mainly designed for layer 3 measurements 🧚

Status of This Memo

this one is not an Internet Standards Track spec 🙈 it's published just for info 💅

this doc is a product of the Internet Engineering Task Force (IETF) 👑 it represents the consensus of the IETF community and got public review, then the Internet Engineering Steering Group (IESG) approved it for publication ✨ not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 for the deets 🤓

for the current status, errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9511 🔗

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. ©️

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they were on the publication date 📜 please actually read them, because they explain your rights and restrictions with this doc 🫶 any Code Components pulled out of this doc must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in that Revised BSD License 💀

Table of Contents

1.  Introduction
2.  Probe Description
  2.1.  Probe Description URI
  2.2.  Probe Description File
    2.2.1.  Example
3.  Out-of-Band Probe Attribution
4.  In-Band Probe Attribution
5.  Operational and Technical Considerations
6.  Ethical Considerations
7.  Security Considerations
8.  IANA Considerations
9.  References
  9.1.  Normative References
  9.2.  Informative References
Appendix A.  Examples of In-Band Attribution
Acknowledgments
Authors' Addresses

1. Introduction 🌸

okay so most measurement research (think [LARGE_SCALE], [RFC7872], and [JAMES]) is about sending IP packets over the public Internet 🛰️ sometimes with extension headers or layer 4 headers too, and those packets can be aimed at collaborating parties or non-collaborating ones 👀 we call those packets "probes" in this doc 🦋

sending unsolicited probes SHOULD obviously be done at a rate low enough that it doesn't unduly hit the other parties' resources 🫶 but even at a low rate, probes can set off an alarm 🚨 and that can kick off an investigation by either the party getting the probe (aka the probe destination address is one address assigned to them) or a third party with devices the probes pass through, like an Internet transit router 🛤️ the investigation happens offline with packet captures, so probe attribution doesn't need any change in the data or control planes ✨

this doc suggests some simple techniques for a source to identify its probes 💖 so any party or org can understand:

  • what an unsolicited probe packet is 🔍
  • what its purpose is 🎯
  • most importantly, who to contact for further info 📞

it's expected that only researchers with good intentions will use these techniques, although anyone could use them 😤 this is discussed in Section 7 🫣

while the technique could mark measurements at any layer of the protocol stack, it's mainly designed for measurements at layer 3 (and its options or extension headers) 🧚

2. Probe Description 💅

this section gives a way for a source to describe (aka identify) its probes 💜

2.1. Probe Description URI 🔗

this doc defines a Probe Description URI as a URI pointing to one of these:

  • a Probe Description File (see Section 2.2) as defined in Section 8, e.g., https://example.net/.well-known/probing.txt 📄
  • an email address, e.g., mailto:lab@example.net 💌
  • a phone number, e.g., tel:+1-201-555-0123 📱

2.2. Probe Description File 📄

as defined in Section 8, the Probe Description File MUST be made available at /.well-known/probing.txt 🏠 it MUST follow the format defined in Section 4 of [RFC9116] and SHOULD contain these fields defined in Section 2 of [RFC9116]:

  • Canonical 🪞
  • Contact 📞
  • Expires ⏰
  • Preferred-Languages 🌍

a new field Description SHOULD also be included to describe the measurement ✨ to match the format in Section 4 of [RFC9116], this field MUST be a one-line string with no line break 🧵

2.2.1. Example 🍓

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

# Contact address
Contact: mailto:lab@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.

3. Out-of-Band Probe Attribution 🌈

one way to attribute probes is to build a specific URI from the probe's source address, following [RFC8615] 🧠 for example, with a probe source address of 2001:db8:dead::1, you build this URI:

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] does something similar 🇬🇧 they scan for vulnerabilities across Internet-connected systems in the UK and publish info on their scanning [NCSC_SCAN_INFO], giving the address of the web page in reverse DNS 🕵️

4. In-Band Probe Attribution 🫧

another way is to put a Probe Description URI inside the probe itself 💫 here's a non-exhaustive list of examples:

  • for an ICMPv6 echo request [RFC4443], include it in the data field 🏓
  • for an ICMPv4 echo request [RFC0792], include it in the data field 🏓
  • for a UDP datagram [RFC0768], include it in the data payload if there is no upper-layer protocol after the transport layer 📦
  • for a TCP segment [RFC9293], include it in the data payload if there is no upper-layer protocol after the transport layer 📦
  • for an IPv6 packet [RFC8200], include it in a PadN option inside either 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 can't 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 📏 some examples are in Appendix A 👀

⚠️ using a magic string (a unique, special opaque marker) to signal the presence of the Probe Description URI is NOT RECOMMENDED, because some transit nodes could apply different processing to packets containing that magic string 🙅‍♀️

for the record, in-band probe attribution was used in [JAMES] 📼

5. Operational and Technical Considerations 🧁

using the out-of-band technique, the in-band technique, or both combined really depends on intent or context 🎀 this section lays out the upsides and downsides of each so probe owners or probe makers can freely decide what works best for them 💖

the perks of out-of-band are that the probing measurement isn't impacted by probe attribution, and it's easy to set up, e.g., by running a web server on a probe device to describe the measurements 🥰 but there are some downsides too 😩 out-of-band might not be possible in some cases: there's a NAT, there are too many endpoints to run a web server on, the probe source IP address can't 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 main perk of in-band is that it covers the cases where out-of-band isn't feasible (as described above) 🙌 the main downside is that it could bias the measurements, since packets carrying the Probe Description URI might get discarded 💔 for example, data is allowed in TCP segments with the SYN flag [RFC9293] but may change the way they're processed, i.e., TCP segments with the SYN flag containing the Probe Description URI might get discarded 🚫 another example is the Probe Description URI in a Hop-by-Hop or Destination Options header inside a PadN option 🎀 Section 2.1.9.5 of [RFC4942] (an Informational RFC) suggests that a PadN option should only contain 0s and be smaller than 8 octets, which limits its use for probe attribution 📉 if a PadN option doesn't follow that recommendation, it's suggested that one may consider dropping such packets 🗑️ for example, since version 3.5, the Linux Kernel follows these recommendations and discards such packets 🐧

having both out-of-band and in-band combined also has a big advantage 👑 it could work 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) 🕸️ out-of-band alone is less prone to spoofing, but combining it with in-band gives a more complete solution 🌟

6. Ethical Considerations 🫶

Okay bestie, running measurements across the global Internet is a whole ethics situation 😭. [ANRW_PAPER] digs into it, especially when unsolicited transit or destination parties get pulled in.

This document proposes a common way to identify the source and the purpose of active probing, so the unsolicited parties don't get stuck with as much of the burden 🌸.

But there are other things to think about too 👀. That covers everything from the payload content (like, is the encoding valid?) to the transmission rate (see also [IPV6_TOPOLOGY] and [IPV4_TOPOLOGY] for some probing speed impacts) 🚀. Those topics are out of scope for this document, so they're not covered here 💅.

7. Security Considerations 🔐

This document proposes simple techniques for probe attribution 🎀. Only ethical researchers are expected to use them, which would make it way easier and faster to identify probes across the Internet ✨. But ngl, anyone can use these techniques, malicious or not 💀. That means the information you get back can't be blindly trusted 🙈. Using these techniques does not mean a probe can be trusted either! Instead, third parties should use this solution to figure out where a probe came from and what it's for 🧚. It's not perfect, but it's a way to do probe attribution, which is way better than no solution at all 💖.

Probe attribution is there to identify the source and intent of specific probes, but the inline information can't be authenticated 😬. So a malevolent actor could feed in false information while probing, or spoof probes so the action gets pinned on a third party 😱. In that case, the third party gets wrongly accused and might also get unwanted solicitations, like angry emails or phone calls if the bad actor used someone else's email address or phone number 📞. So the recipient can't trust this info without confirming it first 🛑. If a recipient can't confirm the information, or just doesn't want to, they should treat the flows as if there were no probe attribution 🫶. Also, using probe attribution does not create a new DDoS vector, since nobody is expected to automatically confirm the information they get 🌈.

Heads up: the Probe Description URI is sent in the clear and the Probe Description File is publicly readable 👀. So Personally Identifiable Information (PII) should not be used for an email address and a phone number 🚫. A generic or group email address and phone number is the move instead 💜. Also, the Probe Description File could contain malicious data (like links), so it should not be blindly trusted either 💀.

8. IANA Considerations 📋

IANA has added the following URI suffix to the "Well-Known URIs" registry in accordance with [RFC8615] ✨:

URI Suffix:  probing.txt

Change Controller:  IETF

Reference:  RFC 9511

Status:  permanent

9. References 📚

9.1. Normative References

[RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
           DOI 10.17487/RFC0768, August 1980,
           <https://www.rfc-editor.org/info/rfc768>.

[RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
           RFC 792, DOI 10.17487/RFC0792, September 1981,
           <https://www.rfc-editor.org/info/rfc792>.

[RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
           Control Message Protocol (ICMPv6) for the Internet
           Protocol Version 6 (IPv6) Specification", STD 89,
           RFC 4443, DOI 10.17487/RFC4443, March 2006,
           <https://www.rfc-editor.org/info/rfc4443>.

[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>.

[RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
           (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
           <https://www.rfc-editor.org/info/rfc8615>.

[RFC9116]  Foudil, E. and Y. Shafranovich, "A File Format to Aid in
           Security Vulnerability Disclosure", RFC 9116,
           DOI 10.17487/RFC9116, April 2022,
           <https://www.rfc-editor.org/info/rfc9116>.

[RFC9293]  Eddy, W., Ed., "Transmission Control Protocol (TCP)",
           STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
           <https://www.rfc-editor.org/info/rfc9293>.

9.2. Informative References

[ANRW_PAPER]
           Fiebig, T., "Crisis, Ethics, Reliability & a
           measurement.network - Reflections on Active Network
           Measurements in Academia", DOI 10.1145/3606464.3606483,
           July 2023,
           <https://pure.mpg.de/rest/items/item_3517635/component/
           file_3517636/content>.

[IPV4_TOPOLOGY]
           Beverly, R., "Yarrp'ing the Internet: Randomized High-
           Speed Active Topology Discovery",
           DOI 10.1145/2987443.2987479, November 2016,
           <http://www.cmand.org/papers/yarrp-imc16.pdf>.

[IPV6_TOPOLOGY]
           Beverly, R., Durairajan, R., Plonka, D., and J. Rohrer,
           "In the IP of the Beholder: Strategies for Active IPv6
           Topology Discovery", DOI 10.1145/3278532.3278559, October
           2018, <http://www.cmand.org/papers/beholder-imc18.pdf>.

[JAMES]    Vyncke, É., Léas, R., and J. Iurman, "Just Another
           Measurement of Extension header Survivability (JAMES)",
           Work in Progress, Internet-Draft, draft-vyncke-v6ops-
           james-03, 9 January 2023,
           <https://datatracker.ietf.org/doc/html/draft-vyncke-v6ops-
           james-03>.

[LARGE_SCALE]
           Donnet, B., Raoult, P., Friedman, T., and M. Crovella,
           "Efficient Algorithms for Large-Scale Topology Discovery",
           DOI 10.1145/1071690.1064256, DOI 10.1145/1071690.1064256,
           June 2005,
           <https://dl.acm.org/doi/pdf/10.1145/1071690.1064256>.

[NCSC]     UK NCSC, "The National Cyber Security Centre",
           <https://www.ncsc.gov.uk/>.

[NCSC_SCAN_INFO]
           UK NCSC, "NCSC Scanning information",
           <https://www.ncsc.gov.uk/information/ncsc-scanning-
           information>.

[RFC4942]  Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
           Co-existence Security Considerations", RFC 4942,
           DOI 10.17487/RFC4942, September 2007,
           <https://www.rfc-editor.org/info/rfc4942>.

[RFC7872]  Gont, F., Linkova, J., Chown, T., and W. Liu,
           "Observations on the Dropping of Packets with IPv6
           Extension Headers in the Real World", RFC 7872,
           DOI 10.17487/RFC7872, June 2016,
           <https://www.rfc-editor.org/info/rfc7872>.

[RIPE_ATLAS]
           RIPE Network Coordination Centre (RIPE NCC), "RIPE Atlas",
           <https://atlas.ripe.net/>.

[SCAPY]    "Scapy", <https://scapy.net/>.

Appendix A. Examples of In-Band Attribution 🦋

Here are a few examples generated by [SCAPY] and displayed in the 'tcpdump' format, so you can see exactly what in-band attribution looks like on the wire 👀✨.

IP packet with Probe Description URI inside a Destination Options extension header 🎀:

IP6 2001:db8:dead::1 > 2001:db8:beef::1: DSTOPT 60878 > traceroute:
Flags [S], seq 0, win 8192, length 0

0x0000:  6000 0000 0044 3c40 2001 0db8 dead 0000  `....D<@........
0x0010:  0000 0000 0000 0001 2001 0db8 beef 0000  ................
0x0020:  0000 0000 0000 0001 0605 012c 6874 7470  ...........,http
0x0030:  733a 2f2f 6578 616d 706c 652e 6e65 742f  s://example.net/
0x0040:  2e77 656c 6c2d 6b6e 6f77 6e2f 7072 6f62  .well-known/prob
0x0050:  696e 672e 7478 7400 edce 829a 0000 0000  ing.txt.........
0x0060:  0000 0000 5002 2000 2668 0000            ....P...&h..

IP packet with the URI in the data payload of a TCP SYN 🧚:

IP6 2001:db8:dead::1.15581 > 2001:db8:beef::1.traceroute:
Flags [S], seq 0:23, win 8192, length 23

0x0000:  6000 0000 002b 0640 2001 0db8 dead 0000  `....+.@........
0x0010:  0000 0000 0000 0001 2001 0db8 beef 0000  ................
0x0020:  0000 0000 0000 0001 3cdd 829a 0000 0000  ........<.......
0x0030:  0000 0000 5002 2000 c9b7 0000 6d61 696c  ....P.......mail
0x0040:  746f 3a6c 6162 4065 7861 6d70 6c65 2e6e  to:lab@example.n
0x0050:  6574 00                                  et.

IP echo request with another URI in the data part of the ICMP ECHO_REQUEST 💅:

IP6 2001:db8:dead::1 > 2001:db8:beef::1: ICMP6, echo request, id 0,
seq 0, length 28

0x0000:  6000 0000 001c 3a40 2001 0db8 dead 0000  `.....:@........
0x0010:  0000 0000 0000 0001 2001 0db8 beef 0000  ................
0x0020:  0000 0000 0000 0001 8000 2996 0000 0000  ..........).....
0x0030:  7465 6c3a 2b31 2d32 3031 2d35 3535 2d30  tel:+1-201-555-0
0x0040:  3132 3300                                123.

IPv4 echo request with a URI in the data part of the ICMP ECHO_REQUEST 🍓:

IP 192.0.2.1 > 198.51.10.1: ICMP echo request, id 0, seq 0, length 31

0x0000:  4500 0033 0001 0000 4001 8e93 c000 0201  E..3....@.......
0x0010:  c633 0a01 0800 ea74 0000 0000 6d61 696c  .3d....t....mail
0x0020:  746f 3a6c 6162 4065 7861 6d70 6c65 2e6e  to:lab@example.n
0x0030:  6574 00                                  et.

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 reviews and comments received from Warren Kumari, Jen Linkova, Mark Nottingham, Prapanch Ramamoorthy, Tirumaleswar Reddy.K, Andrew Shaw, and Magnus Westerlund 👑✨.

Authors' Addresses 💜

Éric Vyncke Cisco De Kleetlaan 6A 1831 Diegem Belgium Email: evyncke@cisco.com

Benoît Donnet Université de Liège Belgium Email: benoit.donnet@uliege.be

Justin Iurman Université de Liège Belgium Email: justin.iurman@uliege.be

📦 where this page comes from