Operational Security Capabilities for IP Network InfrastructureE. Vyncke
Internet-Draft Cisco
Intended status: Informational B. Donnet
Expires: 19 December 2023 J. Iurman
Université de Liège
17 June 2023
Attribution of Internet Probes
draft-ietf-opsec-probe-attribution-06
Abstract
Active measurements 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.
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 19 December 2023 [Page 1]
Internet-Draft Probes Attribution June 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 19 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 . . . . . . . . . . . . . . . . . . . . . . . . 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. Operational and Technical Considerations . . . . . . . . . . 5
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 can target either collaborating parties or non-
collaborating ones. Such measurements, also called probes, include
[LARGE_SCALE] and [RFC7872].
Vyncke, et al. Expires 19 December 2023 [Page 2]
Internet-Draft Probes Attribution June 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 through
which those probes are transiting (e.g., an Internet transit router).
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.
Note: it is expected that only researchers with good intentions will
use these techniques, although anyone might use them. This is
discussed in Section 7.
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:
* 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: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 "/.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
Vyncke, et al. Expires 19 December 2023 [Page 3]
Internet-Draft Probes Attribution June 2023
* 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
# Probes description
Description: This is a one-line string description of the
probes, with no line break.
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, 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).
Vyncke, et al. Expires 19 December 2023 [Page 4]
Internet-Draft Probes Attribution June 2023
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
0x00. Inserting the Probe Description URI could obviously bias the
measurement itself if the probe packet becomes larger than the path
MTU.
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 setup, i.e., by running a web server on a probe
device to describe the measurements. Unfortunately, there are some
Vyncke, et al. Expires 19 December 2023 [Page 5]
Internet-Draft Probes Attribution June 2023
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;
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.
Vyncke, et al. Expires 19 December 2023 [Page 6]
Internet-Draft Probes Attribution June 2023
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.
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>.
Vyncke, et al. Expires 19 December 2023 [Page 7]
Internet-Draft Probes Attribution June 2023
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://doi.org/10.17487/RFC0792>.
[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
[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>.
Vyncke, et al. Expires 19 December 2023 [Page 8]
Internet-Draft Probes Attribution June 2023
[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://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, Warren
Kumari, and Andrew Shaw.
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
Vyncke, et al. Expires 19 December 2023 [Page 9]
Internet-Draft Probes Attribution June 2023
Justin Iurman
Université de Liège
Belgium
Email: justin.iurman@uliege.be
Vyncke, et al. Expires 19 December 2023 [Page 10]