Hi Andrew,
Thanks for the suggestion. The reason why we had such list was to have
some sort of recommendations for probe makers, which may not be that
accurate, as you pointed out. We will translate the list into pros &
cons as you suggest, so that probe makers can freely decide the best
option for their cases, without recommendations.
Thanks,
Justin & Éric
On 3/30/23 14:10, Andrew S2 wrote:
Hi Éric and Justin,
Thanks very much for your response to the review, and I'm happy for you to
reference our scanning information in the document as you have in the new
version. Noted on your use of in-band attribution in those scenarios where
out-of-band would have issues. I think documenting the cases where each method
will be problematic, as you do in the draft, is valuable. Given the cases where
out-of-band does work well, and in-band may alter scan results, I wonder if,
rather than the ordered list of recommendations currently in the draft, just
documenting the upsides/downsides of each method might be best? Then scanners
can make the best decision for the tradeoffs they're happy with.
Thanks,
Andy
-----Original Message-----
From: Eric Vyncke (evyncke) <[email protected]>
Sent: 28 March 2023 14:01
To: Andrew S2 <[email protected]>; Justin Iurman <[email protected]>; opsec
WG <[email protected]>
Cc: [email protected]
Subject: Re: [OPSEC] Fwd: I-D Action: draft-ietf-opsec-probe-attribution-01.txt
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" <[email protected]
<mailto:[email protected]>> 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, 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
EV> in-band probe attribution, we understand that it increases the
EV> packet drops but we prefer to be 'clean' even if the results are
EV> 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 <[email protected] <mailto:[email protected]>> On Behalf
Of Justin Iurman
Sent: 05 March 2023 12:47
To: opsec WG <[email protected] <mailto:[email protected]>>
Cc: [email protected]
<mailto:[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] <mailto:[email protected]>
Reply-To: [email protected] <mailto:[email protected]>
To: [email protected] <mailto:[email protected]>
CC: [email protected] <mailto:[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
