Attribution of Internet Probes
draft-ietf-opsec-probe-attribution-09
Yes
Warren Kumari
No Objection
Erik Kline
Jim Guichard
Abstain
Recuse
Note: This ballot was opened for revision 07 and is now closed.
Warren Kumari
Yes
Erik Kline
No Objection
Jim Guichard
No Objection
Paul Wouters
(was Abstain, Discuss)
No Objection
Comment
(2023-07-10 for -08)
Sent
I have updated my ballot to No Objection. While I believe it is very dangerous for the content published by probes, inline or out-of-band, to be used and trusted by the targets to contact researchers (and not end up at malicious content), on second thought I believe those who need to look into the probes into their networks causing accidental (or purposeful) damage are capable to safely look at the various methods of probe identification data. Furthermore, abuse at scale is unlikely. As such, if this content helps a target network to quickly contact a real researchers probe causing unintentional damage, then this document is useful and reduces unintentional harm on the internet.
Roman Danyliw
(was Discuss)
Abstain
Comment
(2023-08-29)
Sent
Thank you to Tiru Reddy for the SECDIR review. Thank you for addressing my COMMENT feedback. === 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?). The mechanism defined here seems to expect circumstances on the internet which are inconsistent with the internet threat model (RFC3552) that cautions against assuming that entities on a path having "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 (if automated processing of this information is done by the network defender). Just because the probe description file is specified as a text file doesn't mean that this is what will be served by the attacker controlled infrastructure. -- 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?
Éric Vyncke
Recuse
Comment
(2023-06-26 for -07)
Not sent
As I am one of the authors...
Andrew Alston Former IESG member
No Objection
No Objection
(2023-07-06 for -07)
Not sent
Thanks for this document, I am however supportive of Paul's discuss.
Martin Duke Former IESG member
(was Discuss)
No Objection
No Objection
(2023-07-12 for -08)
Sent
Thanks for replying to my DISCUSS. Now that I understand this does not need to be interoperable, DISCUSS points no longer apply. Thanks to Magnus Westerlund for the TSVART review. I note that Magnus's last message in the thread makes some good (non-DISCUSS) points that do not have a public reply. (S4) Is this meant to be an exhaustive list of transports for the URI, or are they examples? I wonder if it would be better for the UDP and TCP versions to use an option, instead of just putting it in the payload.
Robert Wilton Former IESG member
No Objection
No Objection
(2023-07-05 for -07)
Sent
Hi, I appreciate that the SEC ADs have raised some security concerns about the approach and whether you could ever trust the probe description information, but I do think that there is general value in publishing something here. I.e., there have been cases where the probes themselves have unintentionally caused network issues, and hence having some mechanism that a network operator can use to help contact the entity responsible for sending the probes generally seems like a helpful thing to do. Regards, Rob