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

[Eric Vyncke (evyncke)]

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" mailto:nore...@ietf.org>> 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/ 
 
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/ 







--
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 

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

[Paul Wouters via Datatracker]

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/ 
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/



--
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.

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:

 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".

  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)

 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 case. And even that one could
be questionable since a compromised network used for probing could pretend to
be Honest Achmed Security Research

  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.)

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)

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.


--
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