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

["Eric Vyncke (evyncke)" <[e-mail]>]

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=[e-mail]>
Date: Friday, 18 February 2022 at 14:55
To: Eric Vyncke <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: Benoît <[e-mail]>, Justin Iurman <[e-mail]>
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 [e-mail] about the unintended receipt of this electronic message and delete it.”