Cisco

De Kleetlaan 64 Diegem 1831 Belgium evyncke@cisco.com

Université de Liège

Belgium benoit.donnet@uliege.be

Université de Liège

Belgium justin.iurman@uliege.be

Operations and Management Operational Security Capabilities for IP Network Infrastructure Internet-Draft 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 The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Operational Security Capabilities for IP Network Infrastructure Working Group mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction Active measurements at Internet-scale can target either collaborating parties or non-collaborating ones. Such measurements include and . 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 .

Probe Description

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

• a probe description file (see ) as defined in : "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".

Probe Description File As defined in , 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 and should contain the following fields defined in section 2 of :

• 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 , this field must be a one line string.

Example

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 . 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 ). As an example, the UK National Cyber Security Centre uses a similar attribution. They scan for vulnerabilities across internet-connected systems in the UK and publish information on their scanning (), providing the address of the webpage in reverse DNS.

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 ICMPv6 echo request: in the optional data (see section 4.1 of );
• for a ICMPv4 echo request: in the optional data;
• for a 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 TCP packet with the SYN flag: data is allowed in TCP packets with the SYN flag per section 3.4 of (2nd paragraph). However, it may change the way the packet is processed, i.e., SYN packets containing data might be discarded;
• for a 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 , 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 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.

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

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 and for some probing speed impacts). Those considerations are out of scope of this document.

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.

IANA Considerations The "Well-Known URIs" registry should be updated with the following additional values (using the template from ):

• URI suffix: probing.txt
• Change controller: IETF
• Specification document(s): this document
• Status: permanent

References Normative References When security vulnerabilities are discovered by researchers, proper reporting channels are often lacking. As a result, vulnerabilities may be left unreported. This document defines a machine-parsable format ("security.txt") to help organizations describe their vulnerability disclosure practices to make it easier for researchers to report vulnerabilities. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK] This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168. This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. Informative References Université Pierre & Marie Curie Laboratoire LiP6–CNRS Université Pierre & Marie Curie Laboratoire LiP6–CNRS Université Pierre & Marie Curie Laboratoire LiP6–CNRS Boston University Computer Science Department Naval Postgraduate School University of Oregon Akamai Technologies Naval Postgraduate School Naval Postgraduate School n.d. n.d. n.d. This document presents real-world data regarding the extent to which packets with IPv6 Extension Headers (EHs) are dropped in the Internet (as originally measured in August 2014 and later in June 2015, with similar results) and where in the network such dropping occurs. The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 EHs so that the situation improves over time. This document also explains how the results were obtained, such that the corresponding measurements can be reproduced by other members of the community and repeated over time to observe changes in the handling of packets with IPv6 EHs. The transition from a pure IPv4 network to a network where IPv4 and IPv6 coexist brings a number of extra security considerations that need to be taken into account when deploying IPv6 and operating the dual-protocol network and the associated transition mechanisms. This document attempts to give an overview of the various issues grouped into three categories: o issues due to the IPv6 protocol itself, o issues due to transition mechanisms, and o issues due to IPv6 deployment. This memo provides information for the Internet community.

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.