Re: [OPSEC] draft-ietf-opsec-probe-attribution: WGLC

Hi, All,

My apologies for the delay in my response -- I've clearly missed the 
WGLC deadline. But, hopefully "better late than never".

Some comments on version -01 of this document:

* Section 4:
I believe some discussion is warranted about how this might affect the 
measurements themselves. e.g.,

* SYN-scans containing data might be discarded

* Also, if you're UDP-probing, the UDP probe packet needs to impleent 
the target protocol, or else it won't elicit a response. This in turn 
means that most likely you won´t be able to encode the URI in the probe 
packet.

* When probing over IPv6, including EHs will definitely affect the probe 
results (as per e.g. RFC7872)

* Section 4, page 5:
>    *  for a [RFC793] TCP packet with the SYN flag: data is allowed in
>       TCP packets with the SYN flag per section 3.4 of [RFC793] (2nd
>       paragraph).  However, it may change the way the packet is
>       processed;

s/793/9293/

* Section 4, page 5:
>    *  for a [RFC8200] IPv6 packet with either hop-by-hop or destination
>       options headers, in a PadN option.  However, the PadN option is
>       not recommended: as per the informational [RFC4942], section
>       2.1.9.5, it is suggested that PadN options should only contain 0's
>       and be smaller than 8 octets, thus limiting its use for probe
>       attribution.  Indeed, inserting the probe description URI in PadN
>       options could bias the measurement itself.  

So... what would be the recommended approach for including the URI, if 
any, in an IPv6 probe packet?

* Section 4, page 5:
> For example, the Linux
>       Kernel follows these recommendations since its version 3.5;

Is the "recommendation" to drop these packets? Either way, please 
clarify this.

* Section 4, page 5:
>    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.  If the probe description URI cannot be placed at
>    the beginning of the payload, then it should be preceded by an octet
>    of 0x00.

There should be some discussion about MTU related issues. e.g., what if 
including the URI would cause the probe packet to be larger than the 
minimum IPv4 MTU (68 bytes) or minimum IPv6 MTU (1280 bytes)?
(since this would also affect the probe results themselves)

* Section 5, page 6:
>    Both out-of-band and in-band combined should be preferred.  It could
>    be used as an indirect means of "authenticating" the probe
>    description URI in the in-band probe, thanks to a correlation with
>    the out-of-band technique (e.g., a reverse DNS lookup).  However, the
>    out-of-band technique might not be possible due to several
>    conditions: the presence of a NAT, too many endpoints to run a web
>    server on (e.g., RIPE Atlas probes)

I'd add a reference for RIPE Atlas.

* Section 7, page 6:

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

This probably also make a case for favoring out-of-band signaling...

* Section 8, page 7:
> 
> 8.  IANA Considerations
> 
>    The "Well-Known URIs" registry should be updated with the following
>    additional values (using the template from [RFC8615]):
> 
>    *  URI suffix: probing.txt
> 
>    *  Change controller: IETF
> 
>    *  Specification document(s): this document

Should the document be std track for this? (particularly when the tet 
says "specification")

Thanks, and my apologies for my sub-optimal timing!

Regards,
Fernando

On 10/1/23 21:17, Jen Linkova wrote:
> Hello,
> 
> This email starts the WGLC for draft-ietf-opsec-probe-attribution
> (https://datatracker.ietf.org/doc/draft-ietf-opsec-probe-attribution/).
> 
> The WGLC ends on Sun, Jan 29th, 23:59:59UTC.
> 
> Please review the draft and send comments/suggestions/opinions to the list.
> 
> Thank you!
> 
> --
> SY, Jen Linkova aka Furry on behalf of OpSec chairs.
> 
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec

-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494