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

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw 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:
----------------------------------------------------------------------

It isn’t clear how the safest practice is not to always ignore this attribution
information?

** The text notes in numerous places that this is only intended for
“researchers with good intentions” (Section 1 and 7) but it isn’t clear how
this intention translates into the workflow of the probe recipient (i.e., how
does a recipient know it came from someone with good intentions?).   
Specifically:

-- Per the out-of-band attribution (Section 3), the suggested workflow is
directing a network defender to visit an arbitrary location of the attackers
choosing (i.e., by spoofing the probe source address) or by redirecting the
defender to an infrastructure controlled by the attacker.  This seems risky as
this location could be serving malware or the connection itself could be
facilitating a DDOS reflector-style attack.

-- Per the in-path attribution (Section 4), there are no integrity guarantees
so any on-path attacker could also modify legitimate attribution information to
information of their choosing.  See out-of-band attribution.

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

What does confirmation mean in this case?  How is that realized?  Per the
URI-based attribution, there is no strong binding between the sender and the
information.  As the Section 7 text notes, nothing prevents false attribution
(i.e., attributing the traffic to someone else to cover my own behavior) or a
false flag (e.g., attributing the traffic to someone else so as to blame them)?
 Additionally, nothing prevents an attacker from staffing a response to an
email or telephone provided in the URI.  If the network defender makes contact
via provided mechanisms, why should there be any confidence in that
communication?


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

Thank you to Tiru Reddy for the SECDIR review.

** Section 3.  What is the procedure for handling multiple reverse DNS records
being returned?

** Section 3
   *  else (or in addition), the Probe Description URI is
      "https://[2001:db8:dead::1]/.well-known/probing.txt".  If there is
      no certificate associated to this address (e.g., via [RFC8738]),
      then there will be a certificate verification issue.

-- RF8738 is cited as an example.  Can its relationship to the described
workflow be explained

-- What is the implication of there being a certificate verification issue? 
Does the information get discarded?

** Section 4.

   *  For a UDP datagram [RFC768], include it in the data payload if its
      content has no structure;

   *  For a TCP segment [RFC9293], include it in the data payload if its
      content has no structure;

What does “… has no structure mean”?

** Section 4.
   *  For an IPv6 packet [RFC8200], include it in a PadN option either
      inside a Hop-by-Hop or Destination Options header.

Doesn’t Section 3.5.1.1 of RFC9288 guide transit routers to drop hop-by-hop
traffic?