rfc9511.original   rfc9511.txt 
Operational Security Capabilities for IP Network InfrastructureE. Vyncke Internet Engineering Task Force (IETF) É. Vyncke
Internet-Draft Cisco Request for Comments: 9511 Cisco
Intended status: Informational B. Donnet Category: Informational B. Donnet
Expires: 24 January 2024 J. Iurman ISSN: 2070-1721 J. Iurman
Université de Liège Université de Liège
23 July 2023 November 2023
Attribution of Internet Probes Attribution of Internet Probes
draft-ietf-opsec-probe-attribution-09
Abstract Abstract
Active measurements over the public Internet can target either Active measurements over the public Internet can target either
collaborating parties or non-collaborating ones. Sometimes these collaborating parties or non-collaborating ones. Sometimes these
measurements, also called probes, are viewed as unwelcome or measurements, also called "probes", are viewed as unwelcome or
aggressive. aggressive.
This document suggests some simple techniques for a source to This document suggests some simple techniques for a source to
identify its probes, allowing any party or organization to understand identify its probes. This allows any party or organization to
what an unsolicited probe packet is, what its purpose is, and more understand what an unsolicited probe packet is, what its purpose is,
importantly who to contact. The technique relies on off-line and, most importantly, who to contact. The technique relies on
analysis of the probe, therefore it does not require any change in offline analysis of the probe; therefore, it does not require any
the data or control plane. It has been designed mainly for layer-3 change in the data or control plane. It has been designed mainly for
measurements. 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/.
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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 24 January 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9511.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Probe Description . . . . . . . . . . . . . . . . . . . . . . 3 2. Probe Description
2.1. Probe Description URI . . . . . . . . . . . . . . . . . . 3 2.1. Probe Description URI
2.2. Probe Description File . . . . . . . . . . . . . . . . . 4 2.2. Probe Description File
2.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.1. Example
3. Out-of-band Probe Attribution . . . . . . . . . . . . . . . . 5 3. Out-of-Band Probe Attribution
4. In-band Probe Attribution . . . . . . . . . . . . . . . . . . 5 4. In-Band Probe Attribution
5. Operational and Technical Considerations . . . . . . . . . . 6 5. Operational and Technical Considerations
6. Ethical Considerations . . . . . . . . . . . . . . . . . . . 7 6. Ethical Considerations
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References
9.2. Informative References . . . . . . . . . . . . . . . . . 9 9.2. Informative References
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 10 Appendix A. Examples of In-Band Attribution
Appendix B. Examples of in-band Attribution . . . . . . . . . . 10 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses
1. Introduction 1. Introduction
Many measurement researches ([LARGE_SCALE], [RFC7872], and Most measurement research (e.g., [LARGE_SCALE], [RFC7872], and
[I-D.draft-vyncke-v6ops-james]) are about sending IP packets [JAMES]) is about sending IP packets (sometimes with extension
(sometimes with extension headers or layer-4 headers) over the public headers or layer 4 headers) over the public Internet, and those
Internet and those packets can be destined to either collaborating packets can be destined to either collaborating parties or non-
parties or non-collaborating ones. Such packets are called probes in collaborating ones. Such packets are called "probes" in this
this document. document.
Sending unsolicited probes should obviously be done at a rate low Sending unsolicited probes should obviously be done at a rate low
enough to not unduly impact the other parties' resources. But even enough to not unduly impact the other parties' resources. But even
at a low rate, those probes could trigger an alarm that will request at a low rate, those probes could trigger an alarm that will request
some investigations by either the party receiving the probe (i.e., some investigations by either the party receiving the probe (i.e.,
when the probe destination address is one address assigned to the when the probe destination address is one address assigned to the
receiving party) or by a third party having some devices through receiving party) or a third party having some devices through which
which those probes are transiting (e.g., an Internet transit router). those probes are transiting (e.g., an Internet transit router). The
The investigation will be done off-line by using packet captures, investigation will be done offline by using packet captures;
therefore the probe attribution does not require any change in the therefore, probe attribution does not require any change in the data
data or control planes. or control planes.
This document suggests some simple techniques for a source to This document suggests some simple techniques for a source to
identify its probes, allowing any party or organization to identify its probes. This allows any party or organization to
understand: understand:
* what an unsolicited probe packet is, * what an unsolicited probe packet is,
* what its purpose is, * what its purpose is, and
* and more importantly who to contact for further information. * most importantly, who to contact for further information.
It is expected that only researchers with good intentions will use It is expected that only researchers with good intentions will use
these techniques, although anyone might use them. This is discussed these techniques, although anyone might use them. This is discussed
in Section 7. in Section 7.
While the technique could be used to mark measurements done at any While the technique could be used to mark measurements done at any
layer of the protocol stack, it is mainly designed to work for layer of the protocol stack, it is mainly designed to work for
measurements done at layer 3 (and its associated options or extension measurements done at layer 3 (and its associated options or extension
headers). headers).
2. Probe Description 2. Probe Description
This section provides a way for a source to describe (i.e., to This section provides a way for a source to describe (i.e., to
identify) its probes. identify) its probes.
2.1. Probe Description URI 2.1. Probe Description URI
This document defines a Probe Description URI as a URI pointing to This document defines a Probe Description URI as a URI pointing to
either: one of the following:
* a Probe Description File (see Section 2.2) as defined in * a Probe Description File (see Section 2.2) as defined in
Section 8, e.g., "https://example.net/.well-known/probing.txt"; Section 8, e.g., "https://example.net/.well-known/probing.txt";
* an email address, e.g., "mailto:lab@example.net"; * an email address, e.g., "mailto:lab@example.net"; or
* a phone number, e.g., "tel:+1-201-555-0123". * a phone number, e.g., "tel:+1-201-555-0123".
2.2. Probe Description File 2.2. Probe Description File
As defined in Section 8, the Probe Description File must be made As defined in Section 8, the Probe Description File must be made
available at "/.well-known/probing.txt". The Probe Description File available at "/.well-known/probing.txt". The Probe Description File
must follow the format defined in section 4 of [RFC9116] and should must follow the format defined in Section 4 of [RFC9116] and should
contain the following fields defined in section 2 of [RFC9116]: contain the following fields defined in Section 2 of [RFC9116]:
* Canonical * Canonical
* Contact * Contact
* Expires * Expires
* Preferred-Languages * Preferred-Languages
A new field "Description" should also be included to describe the A new field "Description" should also be included to describe the
measurement. To match the format defined in section 4 of [RFC9116], measurement. To match the format defined in Section 4 of [RFC9116],
this field must be a one-line string with no line break. this field must be a one-line string with no line break.
2.2.1. Example 2.2.1. Example
# Canonical URI (if any) # Canonical URI (if any)
Canonical: https://example.net/measurement.txt Canonical: https://example.net/measurement.txt
# Contact address # Contact address
Contact: mailto:lab@example.net Contact: mailto:lab@example.net
# Validity # Validity
Expires: 2023-12-31T18:37:07z Expires: 2023-12-31T18:37:07z
# Languages # Languages
Preferred-Languages: en, es, fr Preferred-Languages: en, es, fr
# Probes description # Probes description
Description: This is a one-line string description of the probes. Description: This is a one-line string description of the probes.
3. Out-of-band Probe Attribution 3. Out-of-Band Probe Attribution
A possibility for probe attribution is to build a specific URI based A possibility for probe attribution is to build a specific URI based
on the source address of the probe packet, following [RFC8615]. For on the source address of the probe packet, following [RFC8615]. For
example, with a probe source address 2001:db8:dead::1, the following example, with a probe source address 2001:db8:dead::1, the following
URI is built: URI is built:
* if the reverse DNS record for 2001:db8:dead::1 exists, e.g., * If the reverse DNS record for 2001:db8:dead::1 exists, e.g.,
"example.net", then the Probe Description URI is "example.net", then the Probe Description URI is
"https://example.net/.well-known/probing.txt". There should be "https://example.net/.well-known/probing.txt". There should be
only one reverse DNS record; otherwise, the Probe Description File only one reverse DNS record; otherwise, the Probe Description File
should also exist for all reverse DNS records and be identical; should also exist for all reverse DNS records and be identical.
* else (or in addition), the Probe Description URI is * Else (or in addition), the Probe Description URI is
"https://[2001:db8:dead::1]/.well-known/probing.txt". "https://[2001:db8:dead::1]/.well-known/probing.txt".
The built URI must be a reference to the Probe Description File (see The built URI must be a reference to the Probe Description File (see
Section 2.2). Section 2.2).
As an example, the UK National Cyber Security Centre [NCSC] uses a As an example, the UK National Cyber Security Centre [NCSC] uses a
similar attribution. They scan for vulnerabilities across internet- similar attribution. They scan for vulnerabilities across Internet-
connected systems in the UK and publish information on their scanning connected systems in the UK and publish information on their scanning
([NCSC_SCAN_INFO]), providing the address of the webpage in reverse [NCSC_SCAN_INFO], providing the address of the web page in reverse
DNS. DNS.
4. In-band Probe Attribution 4. In-Band Probe Attribution
Another possibility for probe attribution is to include a Probe Another possibility for probe attribution is to include a Probe
Description URI in the probe itself. Here is a non-exhaustive list Description URI in the probe itself. Here is a non-exhaustive list
of examples: of examples:
* For an ICMPv6 echo request [RFC4443], include it in the data * For an ICMPv6 echo request [RFC4443], include it in the data
field; field.
* For an ICMPv4 echo request [RFC792], include it in the data field; * For an ICMPv4 echo request [RFC0792], include it in the data
field.
* For a UDP datagram [RFC768], include it in the data payload if * For a UDP datagram [RFC0768], include it in the data payload if
there is no upper-layer protocol after the transport layer; there is no upper-layer protocol after the transport layer.
* For a TCP segment [RFC9293], include it in the data payload if * For a TCP segment [RFC9293], include it in the data payload if
there is no upper-layer protocol after the transport layer; there is no upper-layer protocol after the transport layer.
* For an IPv6 packet [RFC8200], include it in a PadN option either * For an IPv6 packet [RFC8200], include it in a PadN option inside
inside a Hop-by-Hop or Destination Options header. either a Hop-by-Hop or Destination Options header.
The Probe Description URI must start at the first octet of the 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 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 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 the beginning of the payload, then it must be preceded by an octet of
0x00. Inserting the Probe Description URI could obviously bias the 0x00. Inserting the Probe Description URI could obviously bias the
measurement itself if the probe packet becomes larger than the path measurement itself if the probe packet becomes larger than the path
MTU. Some examples are given in the appendix Appendix B. MTU. Some examples are given in Appendix A.
Note: using a magic string (i.e., a unique special opaque marker) to Using a magic string (i.e., a unique, special opaque marker) to
signal the presence of the Probe Description URI is not recommended signal the presence of the Probe Description URI is not recommended
as some transit nodes could apply a different processing for packets as some transit nodes could apply different processing for packets
containing this magic string. containing this magic string.
For the record, the in-band probe attribution was used in For the record, in-band probe attribution was used in [JAMES].
[I-D.draft-vyncke-v6ops-james].
5. Operational and Technical Considerations 5. Operational and Technical Considerations
Using either the out-of-band or in-band technique, or even both Using either the out-of-band or in-band technique, or even both
combined, highly depends on intent or context. This section combined, highly depends on intent or context. This section
describes the upsides and downsides of each technique, so that probe describes the upsides and downsides of each technique so that probe
owners or probe makers can freely decide what works best for their owners or probe makers can freely decide what works best for their
cases. cases.
The advantages of using the out-of-band technique are that the The advantages of using the out-of-band technique are that the
probing measurement is not impacted by the probe attribution but also probing measurement is not impacted by probe attribution and that it
that it is easy to set up, i.e., by running a web server on a probe is easy to set up, i.e., by running a web server on a probe device to
device to describe the measurements. Unfortunately, there are some describe the measurements. Unfortunately, there are some
disadvantages too. In some cases, using the out-of-band technique disadvantages too. In some cases, using the out-of-band technique
might not be possible due to several conditions: the presence of a 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 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 address cannot be known (e.g., RIPE Atlas [RIPE_ATLAS] probes are
sent from IP addresses not owned by the probe owner), dynamic source sent from IP addresses not owned by the probe owner), dynamic source
addresses, etc. addresses, etc.
The primary advantage of using the in-band technique is that it 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 covers the cases where the out-of-band technique is not feasible (as
described above). The primary disadvantage is that it could described above). The primary disadvantage is that it could
potentially bias the measurements, since packets with the Probe potentially bias the measurements, since packets with the Probe
Description URI might be discarded. For example, data is allowed in Description URI might be discarded. For example, data is allowed in
TCP segments with the SYN flag ([RFC9293]) but may change the way TCP segments with the SYN flag [RFC9293] but may change the way they
they are processed, i.e., TCP segments with the SYN flag containing are processed, i.e., TCP segments with the SYN flag containing the
the Probe Description URI might be discarded. Another example is the Probe Description URI might be discarded. Another example is the
Probe Description URI included in a Hop-by-Hop or Destination Options Probe Description URI included in a Hop-by-Hop or Destination Options
header, inside a PadN option. As per the informational [RFC4942], header inside a PadN option. Section 2.1.9.5 of [RFC4942] (an
section 2.1.9.5, it is suggested that a PadN option should only Informational RFC) suggests that a PadN option should only contain 0s
contain 0's and be smaller than 8 octets, thus limiting its use for and be smaller than 8 octets, thus limiting its use for probe
probe attribution. If a PadN option does not respect the attribution. If a PadN option does not respect the recommendation,
recommendation, it is suggested that one may consider dropping such it is suggested that one may consider dropping such packets. For
packets. For example, the Linux Kernel follows these recommendations example, since version 3.5, the Linux Kernel follows these
and discards such packets since its version 3.5; recommendations and discards such packets.
Having both the out-of-band and in-band techniques combined also has 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 a big advantage, i.e., it could be used as an indirect means of
"authenticating" the Probe Description URI in the in-band probe, "authenticating" the Probe Description URI in the in-band probe,
thanks to a correlation with the out-of-band technique (e.g., a 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 reverse DNS lookup). While the out-of-band technique alone is less
prone to spoofing, the combination with the in-band technique offers prone to spoofing, the combination with the in-band technique offers
a more complete solution. a more complete solution.
6. Ethical Considerations 6. Ethical Considerations
Executing measurement experiences over the global Internet obviously Executing measurement experiences over the global Internet obviously
requires ethical consideration, which is discussed in [ANRW_PAPER], requires ethical consideration, which is discussed in [ANRW_PAPER],
especially when unsolicited transit or destination parties are especially when unsolicited transit or destination parties are
involved. involved.
This document proposes a common way to identify the source and the This document proposes a common way to identify the source and the
purpose of active probing in order to reduce the potential burden on purpose of active probing in order to reduce the potential burden on
the unsolicited parties. the unsolicited parties.
But there are other considerations to be taken into account: from the But there are other considerations to be taken into account, from the
payload content (e.g., is the encoding valid?) to the transmission payload content (e.g., is the encoding valid?) to the transmission
rate (see also [IPV6_TOPOLOGY] and [IPV4_TOPOLOGY] for some probing rate (see also [IPV6_TOPOLOGY] and [IPV4_TOPOLOGY] for some probing
speed impacts). Those considerations are out of scope of this speed impacts). Those considerations are out of scope of this
document. document.
7. Security Considerations 7. Security Considerations
This document proposes simple techniques for probe attribution. It This document proposes simple techniques for probe attribution. It
is expected that only ethical researchers would use them, which would is expected that only ethical researchers would use them, which would
simplify and reduce the time to identify probes across the Internet. simplify and reduce the time to identify probes across the Internet.
In fact, these techniques could be used by anyone, malicious or not, In fact, these techniques could be used by anyone, malicious or not,
which means that the information obtained cannot be blindly trusted. which means that the information obtained cannot be blindly trusted.
Using these techniques should not mean that a probe can be trusted. Using these techniques should not mean that a probe can be trusted.
Instead, it should be considered as a solution for third parties to Instead, third parties should use this solution to potentially
potentially understand the origin and context of such probes. This understand the origin and context of such probes. This solution is
solution is not perfect but it provides a way for probe attribution, not perfect, but it provides a way for probe attribution, which is
which is better than no solution at all. better than no solution at all.
The probe attribution is provided to identify the source and intent Probe attribution is provided to identify the source and intent of
of specific probes, but there is no authentication possible for the specific probes, but there is no authentication possible for the
inline information. Therefore, a malevolent actor could provide inline information. Therefore, a malevolent actor could provide
false information while conducting the probes, or spoof them, so that false information while conducting the probes or spoof them so that
the action is attributed to a third party. In that case, not only 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 would this third party be wrongly accused, but it might also be
exposed to unwanted solicitations (e.g., angry emails or phone calls, exposed to unwanted solicitations (e.g., angry emails or phone calls
if the malevolent actor used someone else's email address or phone if the malevolent actor used someone else's email address or phone
number). As a consequence, the recipient of this information cannot number). As a consequence, the recipient of this information cannot
trust it without confirmation. If a recipient cannot confirm the trust it without confirmation. If a recipient cannot confirm the
information or does not wish to do so, it should treat the flows as information or does not wish to do so, it should treat the flows as
if there were no probe attribution. Note that using the probe if there were no probe attribution. Note that using probe
attribution do not create a new DDoS vector since there is no attribution does not create a new DDoS vector since there is no
expectation that third parties would automatically confirm the expectation that third parties would automatically confirm the
information obtained. information obtained.
As the Probe Description URI is transmitted in the clear and as the As the Probe Description URI is transmitted in the clear and as the
Probe Description File is publicly readable, Personally Identifiable Probe Description File is publicly readable, Personally Identifiable
Information (PII) should not be used for email address and phone Information (PII) should not be used for an email address and a phone
number; a generic or group email address and phone number should be number; a generic or group email address and phone number should be
preferred. Also, the Probe Description File could contain malicious preferred. Also, the Probe Description File could contain malicious
data (e.g., links) and therefore should not be blindly trusted. data (e.g., links) and therefore should not be blindly trusted.
8. IANA Considerations 8. IANA Considerations
The "Well-Known URIs" registry should be updated with the following IANA has added the following URI suffix to the "Well-Known URIs"
additional values (using the template from [RFC8615]): registry in accordance with [RFC8615]:
* URI suffix: probing.txt URI Suffix: probing.txt
* Change controller: IETF Change Controller: IETF
* Specification document(s): this document Reference: RFC 9511
* Status: permanent Status: permanent
9. References 9. References
9.1. Normative 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 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89, Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://doi.org/10.17487/RFC4443>. <https://www.rfc-editor.org/info/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>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://doi.org/10.17487/RFC8200>. <https://www.rfc-editor.org/info/rfc8200>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://doi.org/10.17487/RFC8615>. <https://www.rfc-editor.org/info/rfc8615>.
[RFC9116] Foudil, E. and Y. Shafranovich, "A File Format to Aid in [RFC9116] Foudil, E. and Y. Shafranovich, "A File Format to Aid in
Security Vulnerability Disclosure", RFC 9116, Security Vulnerability Disclosure", RFC 9116,
DOI 10.17487/RFC9116, April 2022, DOI 10.17487/RFC9116, April 2022,
<https://doi.org/10.17487/RFC9116>. <https://www.rfc-editor.org/info/rfc9116>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)", [RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://doi.org/10.17487/RFC9293>. <https://www.rfc-editor.org/info/rfc9293>.
9.2. Informative References 9.2. Informative References
[ANRW_PAPER] [ANRW_PAPER]
Fiebig, T., "Crisis, Ethics, Reliability & a Fiebig, T., "Crisis, Ethics, Reliability & a
measurement.network - Reflections on Active Network measurement.network - Reflections on Active Network
Measurements in Academia", DOI 10.1145/3606464.3606483, Measurements in Academia", DOI 10.1145/3606464.3606483,
2023, July 2023,
<https://pure.mpg.de/rest/items/item_3517635/component/ <https://pure.mpg.de/rest/items/item_3517635/component/
file_3517636/content>. file_3517636/content>.
[I-D.draft-vyncke-v6ops-james] [IPV4_TOPOLOGY]
Vyncke, E., Léas, R., and J. Iurman, "Just Another 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)", Measurement of Extension header Survivability (JAMES)",
Work in Progress, Internet-Draft, draft-vyncke-v6ops- Work in Progress, Internet-Draft, draft-vyncke-v6ops-
james-03, 9 January 2023, james-03, 9 January 2023,
<https://datatracker.ietf.org/doc/html/draft-vyncke-v6ops- <https://datatracker.ietf.org/doc/html/draft-vyncke-v6ops-
james-03>. 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] [LARGE_SCALE]
Donnet, B., Raoult, P., Friedman, T., and M. Crovella, Donnet, B., Raoult, P., Friedman, T., and M. Crovella,
"Efficient Algorithms for Large-Scale Topology Discovery", "Efficient Algorithms for Large-Scale Topology Discovery",
DOI 10.1145/1071690.1064256, 2005, DOI 10.1145/1071690.1064256, DOI 10.1145/1071690.1064256,
June 2005,
<https://dl.acm.org/doi/pdf/10.1145/1071690.1064256>. <https://dl.acm.org/doi/pdf/10.1145/1071690.1064256>.
[NCSC] "The National Cyber Security Centre", n.d., [NCSC] UK NCSC, "The National Cyber Security Centre",
<https://www.ncsc.gov.uk/>. <https://www.ncsc.gov.uk/>.
[NCSC_SCAN_INFO] [NCSC_SCAN_INFO]
"NCSC Scanning information", n.d., UK NCSC, "NCSC Scanning information",
<https://www.ncsc.gov.uk/information/ncsc-scanning- <https://www.ncsc.gov.uk/information/ncsc-scanning-
information>. information>.
[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
Co-existence Security Considerations", RFC 4942, Co-existence Security Considerations", RFC 4942,
DOI 10.17487/RFC4942, September 2007, DOI 10.17487/RFC4942, September 2007,
<https://doi.org/10.17487/RFC4942>. <https://www.rfc-editor.org/info/rfc4942>.
[RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu,
"Observations on the Dropping of Packets with IPv6 "Observations on the Dropping of Packets with IPv6
Extension Headers in the Real World", RFC 7872, Extension Headers in the Real World", RFC 7872,
DOI 10.17487/RFC7872, June 2016, DOI 10.17487/RFC7872, June 2016,
<https://doi.org/10.17487/RFC7872>. <https://www.rfc-editor.org/info/rfc7872>.
[RIPE_ATLAS] [RIPE_ATLAS]
"RIPE Atlas", n.d., <https://atlas.ripe.net/>. RIPE Network Coordination Centre (RIPE NCC), "RIPE Atlas",
<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 [SCAPY] "Scapy", <https://scapy.net/>.
and comments received from Warren Kumari, Jen Linkova, Mark
Nottingham, Prapanch Ramamoorthy, Tirumal Reddy, Andrew Shaw, and
Magnus Westerlund.
Appendix B. Examples of in-band Attribution Appendix A. Examples of In-Band Attribution
Here are several examples generated by [SCAPY] and displayed in the Here are several examples generated by [SCAPY] and displayed in the
'tcpdump' format: 'tcpdump' format:
* IP packet with Probe Description URI inside a Destination Options IP packet with Probe Description URI inside a Destination Options
extension header 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
IP6 2001:db8:dead::1 > 2001:db8:beef::1: DSTOPT 60878 > traceroute: IP6 2001:db8:dead::1 > 2001:db8:beef::1: DSTOPT 60878 > traceroute:
Flags [S], seq 0, win 8192, length 0 Flags [S], seq 0, win 8192, length 0
0x0000: 6000 0000 0044 3c40 2001 0db8 dead 0000 `....D<@........ 0x0000: 6000 0000 0044 3c40 2001 0db8 dead 0000 `....D<@........
0x0010: 0000 0000 0000 0001 2001 0db8 beef 0000 ................ 0x0010: 0000 0000 0000 0001 2001 0db8 beef 0000 ................
0x0020: 0000 0000 0000 0001 0605 012c 6874 7470 ...........,http 0x0020: 0000 0000 0000 0001 0605 012c 6874 7470 ...........,http
0x0030: 733a 2f2f 6578 616d 706c 652e 6e65 742f s://example.net/ 0x0030: 733a 2f2f 6578 616d 706c 652e 6e65 742f s://example.net/
0x0040: 2e77 656c 6c2d 6b6e 6f77 6e2f 7072 6f62 .well-known/prob 0x0040: 2e77 656c 6c2d 6b6e 6f77 6e2f 7072 6f62 .well-known/prob
0x0050: 696e 672e 7478 7400 edce 829a 0000 0000 ing.txt......... 0x0050: 696e 672e 7478 7400 edce 829a 0000 0000 ing.txt.........
0x0060: 0000 0000 5002 2000 2668 0000 ....P...&h.. 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: IP6 2001:db8:dead::1.15581 > 2001:db8:beef::1.traceroute:
Flags [S], seq 0:23, win 8192, length 23 Flags [S], seq 0:23, win 8192, length 23
0x0000: 6000 0000 002b 0640 2001 0db8 dead 0000 `....+.@........ 0x0000: 6000 0000 002b 0640 2001 0db8 dead 0000 `....+.@........
0x0010: 0000 0000 0000 0001 2001 0db8 beef 0000 ................ 0x0010: 0000 0000 0000 0001 2001 0db8 beef 0000 ................
0x0020: 0000 0000 0000 0001 3cdd 829a 0000 0000 ........<....... 0x0020: 0000 0000 0000 0001 3cdd 829a 0000 0000 ........<.......
0x0030: 0000 0000 5002 2000 c9b7 0000 6d61 696c ....P.......mail 0x0030: 0000 0000 5002 2000 c9b7 0000 6d61 696c ....P.......mail
0x0040: 746f 3a6c 6162 4065 7861 6d70 6c65 2e6e to:lab@example.n 0x0040: 746f 3a6c 6162 4065 7861 6d70 6c65 2e6e to:lab@example.n
0x0050: 6574 00 et. 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, IP6 2001:db8:dead::1 > 2001:db8:beef::1: ICMP6, echo request, id 0,
seq 0, length 28 seq 0, length 28
0x0000: 6000 0000 001c 3a40 2001 0db8 dead 0000 `.....:@........ 0x0000: 6000 0000 001c 3a40 2001 0db8 dead 0000 `.....:@........
0x0010: 0000 0000 0000 0001 2001 0db8 beef 0000 ................ 0x0010: 0000 0000 0000 0001 2001 0db8 beef 0000 ................
0x0020: 0000 0000 0000 0001 8000 2996 0000 0000 ..........)..... 0x0020: 0000 0000 0000 0001 8000 2996 0000 0000 ..........).....
0x0030: 7465 6c3a 2b31 2d32 3031 2d35 3535 2d30 tel:+1-201-555-0 0x0030: 7465 6c3a 2b31 2d32 3031 2d35 3535 2d30 tel:+1-201-555-0
0x0040: 3132 3300 123. 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 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....@....... 0x0000: 4500 0033 0001 0000 4001 8e93 c000 0201 E..3....@.......
0x0010: c633 0a01 0800 ea74 0000 0000 6d61 696c .3d....t....mail 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 0x0020: 746f 3a6c 6162 4065 7861 6d70 6c65 2e6e to:lab@example.n
0x0030: 6574 00 et. 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 Authors' Addresses
Éric Vyncke Éric Vyncke
Cisco Cisco
De Kleetlaan 6A De Kleetlaan 6A
1831 Diegem 1831 Diegem
Belgium Belgium
Email: evyncke@cisco.com Email: evyncke@cisco.com
Benoît Donnet Benoît Donnet
Université de Liège Université de Liège
Belgium Belgium
 End of changes. 74 change blocks. 
192 lines changed or deleted 178 lines changed or added

This html diff was produced by rfcdiff 1.48.