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

Operational Security Capabilities for IP Network InfrastructureE. Vyncke
Internet-Draft                                                     Cisco
Intended status: Informational                                 B. Donnet
Expires: 29 September 2023                                     J. Iurman
                                                     Université de Liège
                                                           28 March 2023

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

Abstract

   Active measurements at Internet-scale can target either collaborating
   parties or non-collaborating ones.  Sometimes these measurements are
   viewed as unwelcome or aggressive.  This document proposes some
   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

   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.

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

Vyncke, et al.          Expires 29 September 2023               [Page 1]
Internet-Draft             Probes Attribution                 March 2023

   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 29 September 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Probe Description . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Probe Description URI . . . . . . . . . . . . . . . . . .   3
     2.2.  Probe Description File  . . . . . . . . . . . . . . . . .   3
       2.2.1.  Example . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Out-of-band Probe Attribution . . . . . . . . . . . . . . . .   4
   4.  In-band Probe Attribution . . . . . . . . . . . . . . . . . .   5
   5.  Recommendations . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Ethical Considerations  . . . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Active measurements at Internet-scale can target either collaborating
   parties or non-collaborating ones.  Such measurements include
   [LARGE_SCALE] and [RFC7872].

Vyncke, et al.          Expires 29 September 2023               [Page 2]
Internet-Draft             Probes Attribution                 March 2023

   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 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 some 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
      to stop the probing.

   Note: it is expected that only researchers with no bad intentions
   will use these techniques, although anyone might use them.  This is
   discussed in Section 7.

2.  Probe Description

2.1.  Probe Description URI

   This document defines a probe description URI as a URI pointing to
   either:

   *  a probe description file (see Section 2.2) as defined in
      Section 8: "https://example.net/.well-known/probing.txt";

   *  an email address, e.g., "mailto:user@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 "https://example.net/.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

Vyncke, et al.          Expires 29 September 2023               [Page 3]
Internet-Draft             Probes Attribution                 March 2023

   *  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:user@example.net

    # Validity
    Expires: 2023-12-31T18:37:07z

    # Languages
    Preferred-Languages: en, es, fr

    # Probe/Measurement description
    Description: This is a description of the measurement. The in-band probe attribution was used by [I-D.draft-vyncke-v6ops-james].

3.  Out-of-band Probe Attribution

   An alternative to URI inclusion 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, the following
   URI is built:

   *  if the reverse DNS record for 2001:db8::dead 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]/.well-known/probing.txt".  In this case,
      there might 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.

Vyncke, et al.          Expires 29 September 2023               [Page 4]
Internet-Draft             Probes Attribution                 March 2023

4.  In-band Probe Attribution

   When the measurement allows for it, a 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.  Note that if the
      probe is destined to a listened-to/well-known UDP port, the
      inclusion of the probe description URI may produce undefined
      results;

   *  for a [RFC9293] TCP packet with the SYN flag: data is allowed in
      TCP packets with the SYN flag per section 3.4 of [RFC9293] (2nd
      paragraph).  However, it may change the way the packet is
      processed, i.e., SYN packets containing data might be discarded;

   *  for a [RFC8200] IPv6 packet with either hop-by-hop or destination
      options headers, in a PadN option.  Indeed, the probe attribution
      URI can only be added to IPv6 packets in some extension headers
      used for the probing.  However, inserting the probe description
      URI in PadN options could bias the measurement itself: 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;

   *  etc.

   The probe description 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 probe description URI cannot be placed at
   the beginning of the payload, then it should 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.

   Note: the above techniques produce a valid and legitimate packet for
   all the nodes forwarding the probe, except maybe for a hop-by-hop
   options header with a PadN option containing the probe description
   URI.  As for the receiver, it may or may not process the packet,
   depending on where the probe description URI is included (e.g., TCP

Vyncke, et al.          Expires 29 September 2023               [Page 5]
Internet-Draft             Probes Attribution                 March 2023

   SYN flag with the probe description URI included in data, destination
   options header with a PadN option containing the probe description
   URI).  As a consequence, a response may not be received.  The choice
   of the probe description URI location is important and highly depends
   on the context, which is why multiple possibilities are proposed in
   this document.

5.  Recommendations

   Using either the out-of-band or in-band technique, or even both
   combined, highly depends on will or context.  The authors recommend
   the following classification of priorities:

   1.  Both out-of-band and in-band

   2.  Out-of-band only

   3.  In-band only

   4.  None

   Both out-of-band and in-band combined should be preferred.  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).  However, 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 researcher), dynamic source addresses, etc.  In that case, the
   in-band solution should be preferred.

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

Vyncke, et al.          Expires 29 September 2023               [Page 6]
Internet-Draft             Probes Attribution                 March 2023

7.  Security Considerations

   While it is expected that only researchers with no bad intentions
   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 is
   attributed to a third party.  As a consequence, the recipient of this
   information cannot trust this information 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 attribution.

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://doi.org/10.17487/RFC4443>.

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

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

Vyncke, et al.          Expires 29 September 2023               [Page 7]
Internet-Draft             Probes Attribution                 March 2023

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://doi.org/10.17487/RFC8200>.

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

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

9.2.  Informative References

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

Vyncke, et al.          Expires 29 September 2023               [Page 8]
Internet-Draft             Probes Attribution                 March 2023

   [RFC4942]  Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
              Co-existence Security Considerations", RFC 4942,
              DOI 10.17487/RFC4942, September 2007,
              <https://doi.org/10.17487/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://doi.org/10.17487/RFC7872>.

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

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 review
   and comments received from Jen Linkova, Prapanch Ramamoorthy, and
   Warren Kumari.

Authors' Addresses

   Éric Vyncke
   Cisco
   De Kleetlaan 64
   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

Vyncke, et al.          Expires 29 September 2023               [Page 9]