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

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 3 Mar 2022 09:41:28 +0000

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-masked]> on behalf of "Eric Vyncke (evyncke)" <evyncke=[email-masked]>
Date: Sunday, 20 February 2022 at 12:06
To: Fernando Gont <fernando.gont=[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Benoît <[email-masked]>
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 <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 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.”

    _______________________________________________
    OPSEC mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/opsec