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

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 17 Feb 2022 17:29:06 +0000

[Posting as a plain author without any other hat]

Benoît, Justin, and I have just uploaded a new draft (less than 10 pages):
https://datatracker.ietf.org/doc/html/draft-vyncke-opsec-probe-attribution-00

The abstract reads as:
  Active measurements at Internet-scale can target either collaborating
   parties or non-collaborating ones.  This is similar scan and could be
   perceived as aggressive.  This document proposes a couple of simple
   techniques allowing any party or organization to understand what this
   unsolicited packet is, what is its purpose, and more importantly who
   to contact.

We believe that it may be interesting to the OPSEC WG and we will welcome comments and suggestions.

Regards

-éric

---

From: Fernando Gont <[email-masked]>
Date: Fri, 18 Feb 2022 10:55:09 -0300

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

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sun, 20 Feb 2022 11:06:24 +0000

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 <fernando.gont=[email-masked]>
Date: Friday, 18 February 2022 at 14:55
To: Eric Vyncke <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Benoît <[email-masked]>, Justin Iurman <[email-masked]>
Subject: Re: [OPSEC] New OPSEC individual draft on probe attribution

    Hi, Eric, and all,

    Thanks!

    Regards,