Skip to main content

Attribution of Internet Probes
draft-ietf-opsec-probe-attribution-07

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 9511.
Authors Éric Vyncke , Benoit Donnet , Justin Iurman
Last updated 2023-07-06 (Latest revision 2023-06-23)
Replaces draft-vyncke-opsec-probe-attribution
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Jen Linkova
Shepherd write-up Show Last changed 2023-05-18
IESG IESG state Became RFC 9511 (Informational)
Consensus boilerplate Yes
Telechat date (None)
Has enough positions to pass.
Responsible AD Warren "Ace" Kumari
Send notices to furry13@gmail.com
IANA IANA review state IANA OK - Actions Needed
IANA expert review state Expert Reviews OK
IANA expert review comments Expert approved the assignment, but had the following comments re version -05: * Section 2.2 says 'As defined in Section 8, the probe description file must be made available at "https://example.net/.well-known/probing.txt"'. This is not correct, as it hardcodes the domain 'example.net' and the scheme 'https'. If you want to only use the scheme 'https', that should be explicitly required (remember, Well-Known URIs are defined for many URI schemes). * It would be helpful to more clearly state the purpose of the Probe Description up front; to a new reader, it's not clear whether it's describing a particular probe, or a policy for probing (which could be implied by the normative reference to RFC9116). It might help to more clearly and definitely describe what a probe is and is not. * What is "URI inclusion" (mentioned in Section 3)?
draft-ietf-opsec-probe-attribution-07
Operational Security Capabilities for IP Network InfrastructureE. Vyncke
Internet-Draft                                                     Cisco
Intended status: Informational                                 B. Donnet
Expires: 25 December 2023                                      J. Iurman
                                                     Université de Liège
                                                            23 June 2023

                     Attribution of Internet Probes
                 draft-ietf-opsec-probe-attribution-07

Abstract

   Active measurements over the public Internet can target either
   collaborating parties or non-collaborating ones.  Sometimes these
   measurements, also called probes, are viewed as unwelcome or
   aggressive.

   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.  The technique relies on off-line
   analysis of the probe, therefore it does not require any change in
   the data or control plane.  It has been designed mainly for layer-3
   measurements.

About This Document

   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-ietf-opsec-
   probe-attribution.html.  Status information for this document may be
   found at https://datatracker.ietf.org/doc/draft-ietf-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/.

   Source for this draft and an issue tracker can be found at
   https://github.com/evyncke/opsec-probe-attribution.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

Vyncke, et al.          Expires 25 December 2023                [Page 1]
Internet-Draft             Probes Attribution                  June 2023

   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 25 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Probe Description . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Probe Description URI . . . . . . . . . . . . . . . . . .   3
     2.2.  Probe Description File  . . . . . . . . . . . . . . . . .   4
       2.2.1.  Example . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Out-of-band Probe Attribution . . . . . . . . . . . . . . . .   5
   4.  In-band Probe Attribution . . . . . . . . . . . . . . . . . .   5
   5.  Operational and Technical Considerations  . . . . . . . . . .   6
   6.  Ethical Considerations  . . . . . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  10
   Appendix B.  Appendix Examples of in-band Attribution . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

Vyncke, et al.          Expires 25 December 2023                [Page 2]
Internet-Draft             Probes Attribution                  June 2023

1.  Introduction

   Many measurement researches ([LARGE_SCALE], [RFC7872], and
   [I-D.draft-vyncke-v6ops-james]) are about sending IP packets
   (sometimes with extension headers or layer-4 headers) over the public
   Internet and those packets can be destined to either collaborating
   parties or non-collaborating ones.  Such packets are called probes in
   this document.

   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 investigations 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).
   The investigation will be done off-line by using packet captures,
   therefore the probe attribution does not require any change in the
   data or control planes.

   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.

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

   While the technique could be used to mark measurements done at any
   layer of the protocol stack, it is mainly designed to work for
   measurements done at layer 3 (and its associated options or extension
   headers).

2.  Probe Description

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

2.1.  Probe Description URI

   This document defines a Probe Description URI as a URI pointing to
   either:

Vyncke, et al.          Expires 25 December 2023                [Page 3]
Internet-Draft             Probes Attribution                  June 2023

   *  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".  The Probe Description File
   must follow the format defined in section 4 of [RFC9116] and should
   contain the following 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 defined in section 4 of [RFC9116],
   this field must be a one-line string.

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, with no line break.

Vyncke, et al.          Expires 25 December 2023                [Page 4]
Internet-Draft             Probes Attribution                  June 2023

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::1, the following
   URI is built:

   *  if the reverse DNS record for 2001:db8:dead::1 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::1]/.well-known/probing.txt".  If there is
      no certificate associated to this address (e.g., via [RFC8738]),
      then there will 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

Vyncke, et al.          Expires 25 December 2023                [Page 5]
Internet-Draft             Probes Attribution                  June 2023

   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 given in the appendix Appendix B.

   Note: using a magic string (i.e., a unique special opaque marker) to
   signal the presence of the Probe Description URI is not recommended
   as some transit nodes could apply a different processing for packets
   containing this magic string.

   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 set up, 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;

Vyncke, et al.          Expires 25 December 2023                [Page 6]
Internet-Draft             Probes Attribution                  June 2023

   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.

   As the Probe Description URI is transmitted in the clear and as the
   Probe Description File is publicly readable, Personally Identifiable
   Information (PII) should not be used for email address and phone
   number; a generic / group email address and phone number should be
   preferred.

Vyncke, et al.          Expires 25 December 2023                [Page 7]
Internet-Draft             Probes Attribution                  June 2023

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

9.  References

9.1.  Normative References

   [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/rfc/rfc4443>.

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

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

   [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/rfc/rfc8200>.

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

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

Vyncke, et al.          Expires 25 December 2023                [Page 8]
Internet-Draft             Probes Attribution                  June 2023

9.2.  Informative References

   [I-D.draft-vyncke-v6ops-james]
              Vyncke, E., 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>.

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

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

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

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

   [NCSC_SCAN_INFO]
              "NCSC Scanning information", n.d.,
              <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/rfc/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/rfc/rfc7872>.

Vyncke, et al.          Expires 25 December 2023                [Page 9]
Internet-Draft             Probes Attribution                  June 2023

   [RFC8738]  Shoemaker, R.B., "Automated Certificate Management
              Environment (ACME) IP Identifier Validation Extension",
              RFC 8738, DOI 10.17487/RFC8738, February 2020,
              <https://www.rfc-editor.org/rfc/rfc8738>.

   [RIPE_ATLAS]
              "RIPE Atlas", n.d., <https://atlas.ripe.net/>.

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

Appendix A.  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, Tirumal Reddy, Andrew Shaw, and
   Magnus Westerlund.

Appendix B.  Appendix Examples of in-band Attribution

   Here are several examples generated by [SCAPY] and displayed in the
   'tcpdump' format:

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

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

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

   *  IPv4 echo request with a URI in the data part if the ICMP
      ECHO_REQUEST

Vyncke, et al.          Expires 25 December 2023               [Page 10]
Internet-Draft             Probes Attribution                  June 2023

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

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.

IP6 2001:db8:dead::1 > 2001:db8:beef::1: ICMP6, echo reply, 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 8100 2896 0000 0000  ..........(.....
        0x0030:  7465 6c3a 2b31 2d32 3031 2d35 3535 2d30  tel:+1-201-555-0
        0x0040:  3132 3300                                123.

IP 192.0.2.1 > 198.51.100.1: ICMP echo request, id 0, seq 0, length 31
        0x0000:  4500 0033 0001 0000 4001 8e93 c000 0201  E..3....@.......
        0x0010:  c633 6401 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.

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

Vyncke, et al.          Expires 25 December 2023               [Page 11]
Internet-Draft             Probes Attribution                  June 2023

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

Vyncke, et al.          Expires 25 December 2023               [Page 12]