Internet-Draft Probes Attribution March 2023
Vyncke, et al. Expires 6 September 2023 [Page]
Workgroup:
Operational Security Capabilities for IP Network Infrastructure
Internet-Draft:
draft-ietf-opsec-probe-attribution-01
Published:
Intended Status:
Informational
Expires:
Authors:
E. Vyncke
Cisco
B. Donnet
Université de Liège
J. Iurman
Université de Liège

Attribution of Internet Probes

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

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

Table of Contents

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

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
  • 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:

The built URI must be a reference to the probe description file (see Section 2.2).

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:

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.

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 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 (e.g., RIPE Atlas probes), 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.

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]):

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, , <https://doi.org/10.17487/RFC4443>.
[RFC768]
Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, , <https://doi.org/10.17487/RFC0768>.
[RFC792]
Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, , <https://doi.org/10.17487/RFC0792>.
[RFC793]
Postel, J., "Transmission Control Protocol", RFC 793, DOI 10.17487/RFC0793, , <https://doi.org/10.17487/RFC0793>.
[RFC8200]
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, , <https://doi.org/10.17487/RFC8200>.
[RFC8615]
Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, , <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, , <https://doi.org/10.17487/RFC9116>.

9.2. Informative References

[IPV4_TOPOLOGY]
Beverly, R., "Yarrp'ing the Internet Randomized High-Speed Active Topology Discovery", DOI 10.1145/2987443.2987479, , <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, , <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, , <https://dl.acm.org/doi/pdf/10.1145/1071690.1064256>.
[RFC4942]
Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/Co-existence Security Considerations", RFC 4942, DOI 10.17487/RFC4942, , <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, , <https://doi.org/10.17487/RFC7872>.

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
Benoît Donnet
Université de Liège
Belgium
Justin Iurman
Université de Liège
Belgium