Hello Andy, Sorry for belated reply... and thank you for your detailed review.
Based on our own experiences, the authors would like to keep the in-band probe attribution in the text. It of course lacks several properties of the out-of-band attribution, and it also can bias the experiment results, but in-band has the following advantages: - can be used in RIPE Atlas (or similar probes) where the actual source is *not* the researcher - can be used behind an (ugly) NAT device And, I have seen the case where the probe packet had lost its IP header when it was observed... I.e., in-band attribution is not perfect, but it is still useful. See below for EV> for additional replies. Regards -éric & -justin On 14/03/2023, 18:55, "Andrew S2" <andrew...@ncsc.gov.uk <mailto:andrew...@ncsc.gov.uk>> wrote: 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 <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. EV> would you mind if the UK NCSC reference is added in the document ? * 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. EV> in our JAMES experiment (V6OPS) we have preferred to include the in-band probe attribution, we understand that it increases the packet drops but we prefer to be 'clean' even if the results are less nice * 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. EV> Possibly, I have hard time seeing an operator doing deep packet inspection to find a potential probe at the risk of many false positives and at the expense of CPU. But, you are right: in-band probe attribution does impact the experiment. I hope these comments are helpful, thanks again to the authors for putting this useful document together. Thanks, Andy -----Original Message----- From: OPSEC <opsec-boun...@ietf.org <mailto:opsec-boun...@ietf.org>> On Behalf Of Justin Iurman Sent: 05 March 2023 12:47 To: opsec WG <opsec@ietf.org <mailto:opsec@ietf.org>> Cc: draft-ietf-opsec-probe-attribut...@ietf.org <mailto:draft-ietf-opsec-probe-attribut...@ietf.org> 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: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> Reply-To: opsec@ietf.org <mailto:opsec@ietf.org> To: i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org> CC: opsec@ietf.org <mailto:opsec@ietf.org> 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 OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec
