Re: [OPSEC] Secdir last call review of draft-ietf-opsec-probe-attribution

[tirumal reddy <[e-mail]>]

On Fri, 23 Jun 2023 at 12:55, Eric Vyncke (evyncke) <[e-mail]>
wrote:

> Hello Tiru,
>
>
>
> Thank you for your detailed review. I have submitted a revised I-D
> incorporating your suggestions.
>
>
>
> Look below for EV> for further comments.
>
>
>
> Best regards
>
>
>
> -éric
>
>
>
> *From: *OPSEC <[e-mail]> on behalf of tirumal reddy <
> [e-mail]>
> *Date: *Tuesday, 20 June 2023 at 08:08
> *To: *"[e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <
> [e-mail]>
> *Subject: *[OPSEC] Secdir last call review of
> draft-ietf-opsec-probe-attribution
>
>
>
> Reviewer: Tirumaleswar Reddy
> Review result:  Ready with issues
>
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG. These comments were written primarily for the benefit of the
> security area directors. Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> The summary of the review is Ready with issues.
>
> [1]
>       else (or in addition), the Probe Description URI is
>       "https://[2001:db8::dead]/.well-known/probing.txt".  In this case,
>       there might be a certificate verification issue.
>
> Comment> It is possible to get a certificate with IP address from a public
> CA
> (see https://datatracker.ietf.org/doc/html/rfc8738).
>
> EV> good catch, text amended
>
>
> [2]
>
> You may want to consider referring to
> https://datatracker.ietf.org/doc/draft-ietf-6man-hbh-processing/,
> It discusses HBH option processing by intermediate nodes and
> recommendations to process new HBH options.
>
>
>
> EV> I would prefer not to refer to a draft (and I fear that the 6MAN HbH
> is far from being published).
>

Sure but I suggest to high-light the issues with HBH options like the ones
discussed in Section 4 of draft-ietf-6man-hbh-processing that at the time
of writing this specification routers are typically configured to drop HBH
options.


>
> [3]
> I suggest discussing the privacy implications that an eavesdropper will be
> able to view the PII data in the Probe.
>
> EV> Added some note in the security section that no PII should be in the
> Probe Description (notably no personal address/email/phone). Good catch.
>
>
> [4]
>    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 probe attribution.
>
> Comment> How can the recipient of the probe information validate it is
> authentic for confirmation ?
>
>
>
> EV> applying common sense and doing some basic verification (e.g., is the
> email address valid ?). This is all about good faith.
>

Okay but you should suggest all possible checks like the scheme for the
probe URI must be "https", email address is valid etc.

-Tiru


>
>
> Cheers,
>
> -Tiru
>