Re: [OPSEC] New OPSEC individual draft on probe attribution

[Fernando Gont <[e-mail]>]

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 [e-mail] about the unintended receipt of this electronic message and delete it.”