Re: [OPSEC] AD Review of: draft-ietf-opsec-probe-attribution

[Warren Kumari <[e-mail]>]

On Mon, May 22, 2023 at 11:42 AM, Justin Iurman <[e-mail]>
wrote:

> Hi Warren,
>
> Thanks for that, I'll publish the revision right after your confirmation
> (for the security question). Please see inline ([JI] tag).
>
> On 5/20/23 22:02, Warren Kumari wrote:
>
> Hi there, authors (and WG),
>
> Thank you for this document. In general  I found it clear, useful, and an
> easy read.
>
> I do have a few comments/nits; addressing these now should help the IETF
> LC and IESG evaluation go more smoothly.
>
> The majority of these are simply readability comments, but it does end
> with a more important question…
>
> Please SHOUT loudly once you've had a chance to address these, and I'll
> start IETF LC.
> S1:
> O: "Active measurements at Internet-scale can target either collaborating
>    parties or non-collaborating ones."
> P: "Active measurements can target either collaborating
>    parties or non-collaborating ones."
> C: Even at none Internet-scale the target can be collaborating, or not.
>
> [JI] Applied 2 times (abstract and intro).
>
> O: "This document suggests some simple techniques allowing any party or
>    organization to understand:"
> P: "This document suggests some simple techniques to allow any party or
>    organization to understand:"
> C: Flow / grammar.
>
> [JI] Applied.
>
> O: "Note: it is expected that only researchers with no bad intentions will
> use these techniques, although anyone might use them.  This is discussed in
> Section 7."
> C: "with no bd intentions" seems a bit clunky - perhaps "with good
> intentions" instead?
>
> [JI] Applied 2 times ("with good intentions").
>
> S4:
> O: "This could be:
>   * thing
>   * other thing
>   * more other thing
>   * etc."
> P: "Examples of this include:
>   * thing
>   * other thing
>    * more other thing"
> C: Having 'etc' as it's own bullet seems somewhat odd.
>
> [JI] Applied ("etc" bullet removed).
>
> O: "The probe description URI should start at the first octet of the
> payload and should be terminated by an octet of 0x00, i.e., it must be null
> terminated."
> C: So, which is it? It should be null terminated. or it must be null
> terminated?
>
> [JI] Good catch! Applied ("must" for all).
>
> S5:
> O: "The advantage of using the in-band technique is to cover the cases
>    where the out-of-band technique is not possible, as listed above." P:
> "The primary advantage of using the in-band technique is that it covers the
> cases where the out-of-bounds technique is not feasible (as
>
> [JI] you probably meant out-of-band, right? :-D
>

Stoopid autocorrect :-P



> described above)"
> C: Readability.
>
> [JI] Applied.
>
> P: "The primary disadvantage is that it potentially biases the
> measurements, since packets with the Probe Description URI might be
> discarded."
> C: Readability
>
> [JI] Applied.
>
> S6:
> O: "Executing some measurement experiences over the global Internet
>    obviously require some ethical considerations when transit/
>    destination non-solicited parties are involved." P: "Executing
> measurement experiments over the global Internet
>    obviously requires ethical consideration, especially when transit/
>    destination non-solicited parties are involved." C: Readability.
>
> [JI] Applied (+ s/non-solicited/unsolicited/g).
>
> S7: Security Considerations
> C: I wonder if this should speak more about "false flag" operations? I
> send 1Mpps, and include a probe-attribution saying that I'm Eric Vynke, at
> [phone]?? Suddenly you have hundreds of irate network admins
> calling you at 3AM....
>
> [JI] What about:
>
> [JI] OLD: "This information is provided to identify the source and intent
> of specific probes, but there is no authentication possible for the inline
> information. As a result, a malevolent actor could provide false
> information while conducting the probes, so that the action is attributed
> to a third party. As a consequence, the recipient of this information
> cannot trust this information without confirmation. If a recipient cannot
> confirm the information or does not wish to do so, it should treat the
> flows as if there were no attribution."
>
> [JI] NEW: "This information is provided to identify the source and intent
> of specific probes, but there is no authentication possible for the inline
> information. Therefore, a malevolent actor could provide false information
> while conducting the probes, so that the action is attributed to a third
> party. In that case, not only this third party would be wrongly accused,
> but it might also be exposed to unwanted solicitations (e.g., angry emails
> or phone calls, if the malevolent actor used someone else's email address
> or phone number). As a consequence, the recipient of this information
> cannot trust it without confirmation. If a recipient cannot confirm the
> information or does not wish to do so, it should treat the flows as if
> there were no attribution."
>
> Thank you again; I know that making edits to address nits can be annoying,
> but we are expecting many people to read and review the document, and so
> having it polished is important and polite (also, once people start
> commenting on nits, they seem to continue :-) )
>
>

Thank you, works for me!
W



> [JI] Thank YOU!
> Justin
>
> W
>
>