Re: [OPSEC] Paul Wouters' Discuss on draft-ietf-opsec-probe-attribution-07: (with DISCUSS and COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Hello Paul,

Thanks for your review: it is always nice to see another point of view on your work.

Let me repeat the top part of my reply to Roman's DISCUSS (in case you have not read it) as it provides more context and explanations about what is meant by 'probe' in this case.

Then, please in-line some answers for your own points prefixed by EV>

---- start of copy -----
My understanding of your DISCUSS ballot is that this I-D is worse than the cure.

If the above statement is correct, then there is probably a disconnect between your view and the actual purpose of this I-D, which is more like "if you bumped into another car on a parking lot, then please leave a message on the damaged car windshield with your contact information". I.e., propose a reasonably sensible way to contact the researcher(s) sending those probes.

Those probe research are not common; I know about 5 teams doing (and counting me twice) such probing over the public Internet over a period of 10 years... And a vast majority of them (if not all) have applied similar mechanisms, so let's document them in an *informational* document that starts with "This document suggests some simple techniques".

More background: I was contacted only *once* in those 2 measurement campaigns of mine, and it proved really useful as it allowed a forensic analyst to contact me in a matter of hours (more information in a private / confidential discussion if you want). This was really critical and valuable in that case, therefore the suggestions in this I-D, while not perfect, are rather useful.

We could provide more context of course based on the above if it helps the IETF community.

---- end of copy ----

Regards

-éric (with -justin)

On 04/07/2023, 21:11, "Paul Wouters via Datatracker" <[e-mail] <mailto:[e-mail]>> wrote:


Paul Wouters has entered the following ballot position for
draft-ietf-opsec-probe-attribution-07: Discuss


When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)




Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ <https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/> 
for more information about how to handle DISCUSS and COMMENT positions.




The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsec-probe-attribution/ <https://datatracker.ietf.org/doc/draft-ietf-opsec-probe-attribution/>






----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


I have a few issues I would like to further discuss.


This document suggests the best method for getting probe information is to use
the content of the PTR record to fire of a web request. Unfortunately, anyone
who controls their own in-addr.arpa zone can but whatever they want in their
PTR record. Eg I could probe using 193.110.157.66 and give it the PTR of
victim.com. Then I start scanning the internet, causing lots of queries to
victim.com. This can be abused as both an amplification factor and as a method
to hide my IP from victim.com's webserver. If you have the resources to run a
large scale probe from your own IP address, you can run a webserver on that IP
address (and/or portforward/NAT it your favourite CDN). I suggest removing the
suggestion of looking up the PTR record and explicitly state to MUST NOT use
the PTR record for anything but logging purposes.

EV> FYI, there is no expectation in the I-D that probed 'targets' will automatically reach to the reverse DNS server and the associated web page. The intent (and the use of it in real cases) is that a forensic security analyst looks at the packet trace dump manually, apply their common sense, then use the contact information if required. I.e., the amplification is vastly reduced to nearly zero as nothing is automated. The measurement campaign using probing are not relying on this I-D to get a reply.
EV> Moreover, in the case of out-of-band attribution relying on the source address, there is nothing in the probes themselves, i.e., even without this I-D, the probed targets (or even a real DoS attack) could also do reverse DNS and/or visiting the home page.

Section 4 is missing guidance on HTTP based probes, which can (SHOULD?) use
HTTP headers to share their information. I also feel the rest of Section 4
might not work well in practice. Inlining the probe data is usually not
possible if probing for specific TCP or UDP based protocols - and surely not
"must start at the first octet". But even if it is, and for ICMP/ICMPv6 and
HTTP based probes as well, it would reveal who is sending the probe. That could
influence the results. Eg one might want to block any probes from commercial
entities that don't reimburse, competitors, unfriendly nation states, etc. So
in practice, I doubt this is a feasible suggestion. Not even with "If the Probe
Description URI cannot be placed at the beginning of the payload, then it must
be preceded by an octet of 0x00". And lastly:

EV> About HTTP, we tried in the I-D to specify the use case to layer-3 measurements. I.e., similar technique could be used for HTTP probing indeed (e.g., by using a HTTP header), but this is out of scope for this I-D.


Note: using a magic string (i.e., a unique special opaque marker) to
signal the presence of the Probe Description URI is not recommended as
some transit nodes could apply a different processing for packets
containing this magic string.


But the probe URI is already a "magic string".

EV> I would not consider the occurrence of 'https://' in a packet as a magic string (too many false positives), but you are correct: it makes them a little more recognizable and could influence the measurement

It is expected that only researchers with good intentions will use these
techniques


No. Attackers will also use it to appear as good researchers, even point
specifically at those researchers to try and blend in. This is the exact same
problem as security.txt. It is just never really trustable. The only thing that
can be trusted is the IP address, combined with WHOIS information (and
specifically not in-addr.arpa zone content)

EV> I am afraid that our I-D is not clear enough about what the 'probing' is, hence a similar disconnect as with Roman. Probing is usually done in one packet, so hard time for an attacker to hide behind a research (the 'ping of death' excluded of course).
EV> Personally, I would not even trust an IP address as long as BCP 38 is not enforced everywhere ;-)

If a recipient cannot confirm the information or does not wish to do so,
it should treat the flows as if there were no probe attribution.


This would basically cover every single probe case except the
http://probe.ip.address/.well-known/probing.txt <http://probe.ip.address/.well-known/probing.txt> case. And even that one could
be questionable since a compromised network used for probing could pretend to
be Honest Achmed Security Research

EV> Sure, but please note that this is the opposite of the E-bit, i.e., it allows attribution to ethical researchers, these techniques are not a 'blessing' that the traffic is trusted. 

As the Probe Description URI is transmitted in the clear and as the Probe
Description File is publicly readable, Personally Identifiable
Information (PII) should not be used for email address and phone number;
a generic / group email address and phone number should be preferred.


Why does this matter? The published probing.txt contains the information
already, so it should be considered publicly leaked already. (Ironically,
scanners will indeed go looking for /.well-known/probing.txt and use the
contact info for fishing attacks etc.)

EV> Correct, it is more or less trivial to scan for probing.txt and collect the information.
EV> But, you can do this as well by scanning the home page of many sites to fetch for the 'contact' information (like our own https://www.ietf.org/contact/)

The Security Considerations also does not contain a warning that the Probe URI
might in fact be a honeypot / malicious target, trying to cause any browser
visiting it to be compromised. Or be otherwise malicious (eg hooked to
/dev/random)

EV> We could add a 'caution' in the I-D about the probing.txt could contain bad things and should not be trusted. Would it address your concerns ?


As I said about security.txt, I think probing.txt is also a bad idea. Let's
have a discussion on this. If I am in the minority, I will not block the
document from publication but will abstain.

EV> On a semi-serious note, I would love to have an ABSTAIN to have all the colors on the ballot ;-)
EV> More seriously, similar techniques have been used and are still used. Let's document them: better than nothing. I appreciate your concerns, but in the absence of another feasible solution, ABSTAIN sounds more logical to mark your opposition. Up to you obviously



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


The "one line description without a line break" seems to have its own line
break in the document. Using a .txt format suggests "human readable" which also
kind of implies 80 character width :P (similar to the security.txt discussion
not wanting to use json but kinda not wanting free flow text either)

EV> Oups, we forgot to use the \ notation of RFC 8792. Good catch, thanks
EV> a side effect of using .MD as the main file...