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
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
--
Fernando Gont
SI6 Networks
e-mail: [email protected]
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
