Dear OPSEC'ers, Fernando, The authors have just published the -01 revision taking into account Fernando's comments + a few other ones received as unicast.
https://datatracker.ietf.org/doc/html/draft-vyncke-opsec-probe-attribution Benoît, Justin, and I will welcome other comments on this short informational IETF drafts. Regards -éric PS: it seems obvious, but the above is posted with just my OPSEC member's hat ;-) -----Original Message----- From: OPSEC <[email protected]> on behalf of "Eric Vyncke (evyncke)" <[email protected]> Date: Sunday, 20 February 2022 at 12:06 To: Fernando Gont <[email protected]>, "[email protected]" <[email protected]> Cc: Benoît <[email protected]> Subject: Re: [OPSEC] New OPSEC individual draft on probe attribution Hello Fernando, Thank you for your quick review, we completely agree with you: 1) the reverse DNS/web server is probably to be preferred, so, we will move the section 4 'out of band' before the inband section to put more focus on this technique 2) on the URI in the payload, indeed this will not work in every case (for the reasons you explained), we will modify the text to make it more clear. BWT, about the "extension header" and RFC 7872, this is indeed what Raphaël (a Master student of Prof. Donnet) is doing right now ;) Our hope is to present it at V6OPS at IETF-113. BTW, do you know of a VM/VPS hoster in South America? Preferrably using Telefonica as tier-1 Regards -éric -----Original Message----- From: Fernando Gont <[email protected]> Date: Friday, 18 February 2022 at 14:55 To: Eric Vyncke <[email protected]>, "[email protected]" <[email protected]> Cc: Benoît <[email protected]>, Justin Iurman <[email protected]> Subject: Re: [OPSEC] New OPSEC individual draft on probe attribution Hi, Eric, and all, Thanks for the heads up on this document! FWIW, I agree with the "principle, but not with the proposed solution. Meta: the easiest way to provide information about the probe is to: 1) simply run a web server on the probing machine, with a web page that describes the experiment, and/or, 2) have a reverse mapping in the DNS that hints about what's going on, and possible leads to a web page as #1 above. Regarding the proposed "in-band probe attribution", this is generally not possible, since it may interfere with the probing experiment itself. e.g.: > 3. In-band Probe Attribution > > When the desired measurement allows for it, one "probe description > URI" should be included in the payload of all probes sent. This > could be: > > * for a [RFC4443] ICMPv6 echo request: in the optional data (see > section 4.1 of [RFC443]); > > * for a [RFC792] ICMPv4 echo request: in the optional data; These two *may* be possible. But: 1) You'd normally not use ping for probing, since it may be filtered and/or rate-limited. 2) Sensors at the target network might be configured to not capture the payload > * for a [RFC768] UDP datagram: in the data part; This one is not possible: When scanning UDP services, the probe packet needs to be a valid request for the target service -- otherwise it would not elicit a response. > * 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); This is theoretically possible -- maybe feasible now. But for quite some time this wouldn;t work (implementation bugs that wouldn't allow data in the SYN, even when protocol-wise legitimate), and because firewalls would block these. > > * for a [RFC8200] IPv6 packet with either hop-by-hop or destination > options headers, in the PadN option. Note that, per the > informational [RFC4942] section 2.1.9.5, it is suggested that PadN > option should only contain 0x0 and be smaller than 8 octets, so > the proposed insertion of the URI in PadN option could have > influence on the measurement itself; You'd probably never use IPv6 EHs for probing, since the reliability of the experiment will be degraded significantly -- unless you're actually trying to measure *that* (as in RFC7872 ;-) ). Thanks! Regards, -- Fernando Gont Director of Information Security EdgeUno PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531 “This communication is the property of EdgeUno or one of its group companies and/or affiliates. This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and if you are not the intended recipient be aware that any non-explicitly authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, and will be considered a criminal offense. Please notify [email protected] about the unintended receipt of this electronic message and delete it.” _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
