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

Reply via email to