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

[Paul Wouters via Datatracker <[e-mail]>]

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 json but kinda not wanting free flow text either)