Many thanks to the authors for this draft, and the updates in the latest version, it's a great topic for this group to be working on. I think that standardising the suggestions on out-of-band attribution would be really useful. While I'm not too familiar with the situations mentioned in Section 5 where out-of-band attribution will not work, I think there are sufficient issues with in-band attribution that it would be better to focus this draft on the out-of-band mechanisms.
In a little more detail: * The suggestions on Out-of-Band Probe Attribution in Section 3 are easy to implement, lightweight suggestions that are similar to how we attribute our scanning at NCSC (UK National Cyber Security Centre). We scan for vulnerabilities across internet-connected systems in the UK and publish information on our scanning (https://www.ncsc.gov.uk/information/ncsc-scanning-information), providing the address of this webpage in reverse DNS, as the draft suggests. Standardising a .well-known URI is helpful, especially as it is in some sense capturing existing best current practice in this space. * For Section 4, on In-band Probe Attribution, there are a couple of risks: * As mentioned at the end of the section (and discussed on this list), there is a good chance that firewalls or middleboxes drop (or otherwise do something unexpected with) these unusual looking packets, compromising the scan. If following this document compromises the results of the scan, then I think it's unlikely that scanners will choose to add this information. * Providing this information in the packet payloads would provide an easy way for a system to automatically block all scanning that complies with this document. This would provide little benefit to the system owner as it would only allow systems to block benign scanning that is compliant with this document. It would also reduce the amount of information available to researchers, making their scans less representative. It could prove particularly detrimental if systems make uninformed decisions to (attempt to) block all scanning by dropping packets that include this information. I hope these comments are helpful, thanks again to the authors for putting this useful document together. Thanks, Andy -----Original Message----- From: OPSEC <[email protected]> On Behalf Of Justin Iurman Sent: 05 March 2023 12:47 To: opsec WG <[email protected]> Cc: [email protected] Subject: [OPSEC] Fwd: I-D Action: draft-ietf-opsec-probe-attribution-01.txt Hello, This version addresses most of the comments received by Jen, Prapanch and Warren (thanks again for your reviews!). The diff is [1]. @Jen: with Éric, we finally decided that it might be better not to use normative language since this document is informational. Also, regarding your comment about DNS, we just wanted to make sure that you were talking about a TXT record where the value might "authenticate" the probes. Is it what you had in mind? If so, this is indeed a good idea, but we might need to define a new value/keyword for that, which might overcomplicate the document. Thoughts? Thanks, Justin -------- Forwarded Message -------- Subject: [OPSEC] I-D Action: draft-ietf-opsec-probe-attribution-01.txt Date: Sun, 05 Mar 2023 04:21:30 -0800 From: [email protected] Reply-To: [email protected] To: [email protected] CC: [email protected] A New Internet-Draft is available from the on-line Internet-Drafts directories. This Internet-Draft is a work item of the Operational Security Capabilities for IP Network Infrastructure WG of the IETF. Title : Attribution of Internet Probes Authors : Éric Vyncke Benoît Donnet Justin Iurman Filename : draft-ietf-opsec-probe-attribution-01.txt Pages : 9 Date : 2023-03-05 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. _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
