Re: [OPSEC] Martin Duke's Discuss on draft-ietf-opsec-probe-attribution-08: (with DISCUSS and COMMENT)

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

Hello Martin,

Thanks for your review of this informational draft. 

Please find below some replies to your points, look for EV>

If required, then Justin will follow up with a revised I-D.

Regards

-éric

On 10/07/2023, 18:52, "Martin Duke via Datatracker" <[e-mail] <mailto:[e-mail]>> wrote:


Martin Duke has entered the following ballot position for
draft-ietf-opsec-probe-attribution-08: 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:
----------------------------------------------------------------------


Is this meant to be an interoperable design or not? Sections of this document
propose "some techniques" which might inform a future protocol design, while
others are very specific about terminating bytes and so on. Some of these
objections might not apply depending on the answer.

EV> I would not qualify this as interoperable as there is a human being in the loop: the security/forensic analyst that will act on the in-band or out-of-band probe attribution.
EV> I.e., there is no automatic replies required by a device receiving or forwarding probe packets *beyond* the already specified behavior, e.g., RFC 4443 for ICMP ECHO_REQUEST. We tried to be clear on this based on previous directorate reviews but it seems that we are still unclear.

(S2.2) RFC9116 defines the "Canonical" field as "the canonical URIs where the
'security.txt' file is located, which is usually something like
'https://example.com/.well-known/security.txt' <https://example.com/.well-known/security.txt&#39;>. Obviously you do not mean that
this field should be the location of that file! But maybe you mean the
"probing.txt" file instead, as that is the well-known name. But then the
example has "measurement.txt"? Is this an intentional difference, or the result
of an incomplete revision?

EV> We simply wanted to re-use the syntax of RFC 9116
EV> and nothing in RFC 9116 says that the actual filename must be security.txt
EV> hence, in our example, we use "measurement.txt" on purpose

(S4) Is this meant to be an exhaustive list of transports for the URI, or are
they examples?

EV> unsure whether it should rather be a comment ;-) but you are correct: these are examples (and we should accordingly update the draft). Thanks.

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


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.

EV> I think we did our best to reply to all points (of course, sometimes with a disagreement). Sorry if we skip a reply or two.

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.

EV> Using TCP or UDP options (especially the latter IMHO) could actually bias the measurement itself. But, this is debatable of course.