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

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

Hello Fernando,

Now, it is my turn to apologize for the belated reply ;-)

About the section 4 and the impact of data in the SYN packet, you are correct: this may influence the experiment, hence we wrote " However, it may change the way the packet is processed;" we could be perhaps more explicit.

For UDP probing, when it is done, the expected behavior is not a to receive a UDP but an ICMP error message if there is no listener on this port. This is of course relevant to the probing experiment itself and not really to the inclusion of the probe description URI in the UDP packets. We will update the text: "note that if the probe is destined to a listened-to/well-known UDP port, the inclusion of the probe descriptor URI may be undefined".

For IPv6, the probe attribution text will only be added in the extension headers that are used anyway in the probing (like your RFC 7872 or our JAMES research)

See below for EV>

Thank you a lot for your review

Regards,

-éric


On 13/03/2023, 15:57, "Fernando Gont" <[e-mail] <mailto:[e-mail]>> wrote:


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/

EV> thanks




* 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?

EV> we will fix the text by providing a recommendation


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

EV> Justin (who discovered this) will clarify the text


* 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)

EV> unsure, we can add text but isn't this obvious ?


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

EV> good point, we will add a referene



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

EV> sure, but the authors also really want to cover the in-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")

EV> no, RFC 8126 only requires a permanent publication, it evens contains " including informal documentation."

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

EV> and my apologies for my sub-optimal reply !

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/ <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
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/opsec <https://www.ietf.org/mailman/listinfo/opsec>


-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail] <mailto:[e-mail]>
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494