idnits 2.17.1 draft-vyncke-opsec-probe-attribution-01.txt: -(6): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(289): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 6 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (3 March 2022) is 779 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operational Security Capabilities for IP Network InfrastructureE. Vyncke 3 Internet-Draft Cisco 4 Intended status: Informational B. Donnet 5 Expires: 4 September 2022 J. Iurman 6 Université de Liège 7 3 March 2022 9 Attribution of Internet Probes 10 draft-vyncke-opsec-probe-attribution-01 12 Abstract 14 Active measurements at Internet-scale can target either collaborating 15 parties or non-collaborating ones. This is similar scan and could be 16 perceived as aggressive. This document proposes a couple of simple 17 techniques allowing any party or organization to understand what this 18 unsolicited packet is, what is its purpose, and more importantly who 19 to contact. 21 About This Document 23 This note is to be removed before publishing as an RFC. 25 The latest revision of this draft can be found at 26 https://evyncke.github.io/opsec-probe-attribution/draft-vyncke-opsec- 27 probe-attribution.html. Status information for this document may be 28 found at https://datatracker.ietf.org/doc/draft-vyncke-opsec-probe- 29 attribution/. 31 Discussion of this document takes place on the Operational Security 32 Capabilities for IP Network Infrastructure Working Group mailing list 33 (mailto:opsec@ietf.org), which is archived at 34 https://mailarchive.ietf.org/arch/browse/opsec/. 36 Source for this draft and an issue tracker can be found at 37 https://github.com/evyncke/opsec-probe-attribution. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on 4 September 2022. 56 Copyright Notice 58 Copyright (c) 2022 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 63 license-info) in effect on the date of publication of this document. 64 Please review these documents carefully, as they describe your rights 65 and restrictions with respect to this document. Code Components 66 extracted from this document must include Revised BSD License text as 67 described in Section 4.e of the Trust Legal Provisions and are 68 provided without warranty as described in the Revised BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 73 2. Probe / Measurement Description . . . . . . . . . . . . . . . 3 74 2.1. Probe Description URI . . . . . . . . . . . . . . . . . . 3 75 2.2. Probe Description Text . . . . . . . . . . . . . . . . . 3 76 3. Out-of-band Probe Attribution . . . . . . . . . . . . . . . . 4 77 4. In-band Probe Attribution . . . . . . . . . . . . . . . . . . 4 78 5. Ethical Considerations . . . . . . . . . . . . . . . . . . . 5 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 83 8.2. Informative References . . . . . . . . . . . . . . . . . 7 84 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 87 1. Introduction 89 Active measurements at Internet-scale can target either collaborating 90 parties or non-collaborating ones. Such measurements include 91 [LARGE_SCALE] and [RFC7872]. 93 Sending unsolicited probes should obviously be done at a rate low 94 enough to avoid wasting other parties resources. But even at a low 95 rate, those probes could trigger an alarm that will request some 96 investigation by either the party receiving the probe (i.e., when the 97 probe destination address is one address assigned to the receiving 98 party) or by a third party having some devices where those probes are 99 transiting (e.g., an Internet transit router). 101 This document suggests a couple of simple techniques allowing any 102 party or organization to understand: 104 * what this unsolicited packet is, 106 * what is its purpose, 108 * and more significantly who to contact for further information or 109 stop the probing. 111 Note: it is expected that only good-willing researchers will use 112 these techniques. 114 2. Probe / Measurement Description 116 2.1. Probe Description URI 118 This document defines a "probe description URI" (see Section 2.2) as 119 a URI pointing to: 121 * a "Probe Description", see Section 2.2, e.g., 122 "https://example.net/measurement.txt"; 124 * an email address, e.g., "mailto:eric@example.net"; 126 * a phone number to call, e.g., "tel:+1-201-555-0123". 128 2.2. Probe Description Text 130 Similarly, as in [I-D.draft-foudil-securitytxt], when a node probes 131 other nodes over the Internet, it should create a text file following 132 the syntax described in section 3 of [I-D.draft-foudil-securitytxt] 133 and should have the following fields: 135 * contact; 137 * expires; 139 * preferred-languages. 141 Plus, another one "description" which is a URI pointing a document 142 describing the measurement. 144 3. Out-of-band Probe Attribution 146 When it is not possible to include the "probe description URI" in the 147 probe packet itself, then a specific URI must be constructed based on 148 the source address of the probe packet following [RFC8615], e.g., for 149 a probe source address of 2001:db8::dead, the following URI are 150 constructed: 152 * if the reverse DNS record for 2001:db8::dead exists, e.g., 153 "example.net", then the URI is "https://example.net/.well-known/ 154 probing.txt" ; 156 * else (or in addition), the URI is "https://[2001:db8::dead]/.well- 157 known/probing.txt". Of course, there will be a certificate 158 verification issue. 160 The constructed URI must be a reference to the "Probe description 161 Text" (see Section 2.2). 163 4. In-band Probe Attribution 165 When the desired measurement allows for it, one "probe description 166 URI" should be included in the payload of all probes sent. This 167 could be: 169 * for a [RFC4443] ICMPv6 echo request: in the optional data (see 170 section 4.1 of [RFC4443]); 172 * for a [RFC792] ICMPv4 echo request: in the optional data; 174 * for a [RFC768] UDP datagram: in the data part; 176 * for a [RFC793] TCP packet with the SYN flag: data is allowed in 177 TCP packets with the SYN flag per section 3.4 of [RFC793] (2nd 178 paragraph); 180 * for a [RFC8200] IPv6 packet with either hop-by-hop or destination 181 options headers, in the PadN option. Note that, per the 182 informational [RFC4942] section 2.1.9.5, it is suggested that PadN 183 option should only contain 0x0 and be smaller than 8 octets, so 184 the proposed insertion of the URI in PadN option could have 185 influence on the measurement itself; 187 * etc. 189 The URI should start at the first octet of the payload and should be 190 terminated by an octet of 0x00, i.e., it must be null terminated. If 191 the URI cannot be placed at the beginning of the payload, then it 192 should be preceded also by an octet of 0x00. 194 Note: using the above technique produces a valid and legit packet for 195 all the nodes forwarding the probe. The node receiving the probe may 196 or may not process the received packet, but this should cause no harm 197 if the probing rate is very low as compared to the network bandwidth 198 and to the processing capacity of all the nodes. As the insertion of 199 the URI in the packet may not respect the syntax of the protocol, 200 responses may not be received (such a TCP SYN+ACK) and perhaps an 201 ICMP should be expected or more probably an absence of reply. 203 5. Ethical Considerations 205 Executing some measurement experiences over the global Internet 206 obviously require some ethical considerations when transit/ 207 destination non-solicited parties are involved. 209 This document proposes a common way to identity the source and the 210 purpose of active probing in order to reduce the potential burden on 211 the non-solicited parties. 213 But there are other considerations to be taken into account: from the 214 payload content (e.g., is the encoding valid ?) to the transmission 215 rate (see also [IPV6_TOPOLOGY] and [IPV4_TOPOLOGY] for some probing 216 speed impacts). Those considerations are out of scope of this 217 document. 219 6. Security Considerations 221 While it is expected that only good-willing researchers will use 222 these techniques, they will simplify and shorten the time to identify 223 a probing across the Internet. 225 This information is provided to identify the source and intent of 226 specific probes, but there is no authentication possible for the 227 inline information. As a result, a malevolent actor could provide 228 false information while conducting the probes, so that the action was 229 attributed to a third party. The recipient of this information 230 cannot, as a result, rely on this information without confirmation. 231 If a recipient cannot confirm the information or does not wish to do 232 so, they should treat the flows as if there were no attribution. 234 7. IANA Considerations 236 The "Well-Known URIs" registry should be updated with the following: 238 * additional values (using the template from [RFC8615]): 240 * URI suffix: probing.txt 242 * Change controller: IETF 244 * Specification document(s): this document 246 * Status: permanent 248 8. References 250 8.1. Normative References 252 [I-D.draft-foudil-securitytxt] 253 Foudil, E. and Y. Shafranovich, "A File Format to Aid in 254 Security Vulnerability Disclosure", Work in Progress, 255 Internet-Draft, draft-foudil-securitytxt-12, 24 May 2021, 256 . 259 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 260 Control Message Protocol (ICMPv6) for the Internet 261 Protocol Version 6 (IPv6) Specification", STD 89, 262 RFC 4443, DOI 10.17487/RFC4443, March 2006, 263 . 265 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 266 DOI 10.17487/RFC0768, August 1980, 267 . 269 [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, 270 RFC 792, DOI 10.17487/RFC0792, September 1981, 271 . 273 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, 274 RFC 793, DOI 10.17487/RFC0793, September 1981, 275 . 277 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 278 (IPv6) Specification", STD 86, RFC 8200, 279 DOI 10.17487/RFC8200, July 2017, 280 . 282 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers 283 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, 284 . 286 8.2. Informative References 288 [IPV4_TOPOLOGY] 289 Beverly, R., "Yarrp’ing the Internet Randomized High-Speed 290 Active Topology Discovery", DOI 10.1145/2987443.2987479, 291 2016, . 293 [IPV6_TOPOLOGY] 294 Beverly, R., Durairajan, R., Plonka, D., and J.P. Rohrer, 295 "In the IP of the Beholder Strategies for Active IPv6 296 Topology Discovery", DOI 10.1145/3278532.3278559, 2018, 297 . 299 [LARGE_SCALE] 300 Donnet, B., Raoult, P., Friedman, T., and M. Crovella, 301 "Efficient Algorithms for Large-Scale Topology Discovery", 302 DOI 10.1145/1071690.1064256, 2005, 303 . 305 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 306 Co-existence Security Considerations", RFC 4942, 307 DOI 10.17487/RFC4942, September 2007, 308 . 310 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 311 "Observations on the Dropping of Packets with IPv6 312 Extension Headers in the Real World", RFC 7872, 313 DOI 10.17487/RFC7872, June 2016, 314 . 316 Acknowledgments 318 The authors would like to thank Alain Fiocco, Fernando Gont, Ted 319 Hardie, Mehdi Kouhen, and Mark Townsley for helpful discussions as 320 well as Raphael Leas for an early implementation. 322 Authors' Addresses 324 Éric Vyncke 325 Cisco 326 De Kleetlaan 64 327 1831 Diegem 328 Belgium 329 Email: evyncke@cisco.com 330 Benoît Donnet 331 Université de Liège 332 Belgium 333 Email: benoit.donnet@uliege.be 335 Justin Iurman 336 Université de Liège 337 Belgium 338 Email: justin.iurman@uliege.be