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

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

Hello Roman,

Thank you for your review.

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.

Please below some answers prefixed by EV>

Regards

-éric (with -justin)

On 04/07/2023, 15:13, "Roman Danyliw via Datatracker" <[e-mail] <mailto:[e-mail]>> wrote:


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


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:

EV> better than nothing...

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

EV> as written above, the probes are not an attack but could look suspicious enough to the eyes of a network security analyst. And the download by the security analyst is just a plain ASCII file pointing to another page. Let's hope that forensic analysts do not click on any link...
EV> Usure how it could become a dDoS attack as it would require multiple sites receiving this probe, doing the off-line analysis, and contacting phone/email the research team. There are many other and more efficient ways to distribute 3rd party contact information in the hope that they will be called / sent email messages.


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

EV> sure, and they can be spoofed, ... 

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

EV> we (the authors but also some other measurement teams) have considered this issue and were unable to find something 'really secure', probes are atomic packets with often size constraints (for the measurements) to non-collaborative parties. 
EV> I would be glad to accept any suggestion of yours to do it correctly.


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


Thank you to Tiru Reddy for the SECDIR review.


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

EV> if you do it well, there will be only one (again assuming that the sender is a well-behaved sender)

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

EV> suggest then to remove the last sentence  

** 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”?

EV> what about s/if its content has no structure/if there is no upper-layer protocol after the transport layer/

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

EV> Please note that RFC 9288 is informational and is not so assertive on dropping HbH extension headers
EV> Finally, even if RFC 9288 was standard track and with a MUST discard, then doing the measurement is still valuable if only to check how many routers are implementing this putative RFC 9288-bis