Re: [OPSEC] [Last-Call] Tsvart last call review of draft-ietf-opsec-probe-attribution-05

[Magnus Westerlund <[e-mail]>]

Hi,

Regarding the multiple DNS records and the possibility to do reverse lookups. I understand that for IP level probing one will require to have a dedicated machine attached to the general internet without any middleboxes that do not accept this traffic. However, this is not necessarily as true for some of the transport layer measurements that I was thinking of that might be able to put this probe data into either dedicated fields, or in padding fields. But, yes it depends on use case if you can operate from behind any type of middlebox including NAT. So I think this work is having some overlap with research where it might be possible to have multiple services behind an IP and where it would make any sense or possibility to use. But it is clearly a subset of the total potential usages. I guess not specifying it is acceptable, but maybe a note of warning to ensure that reverse lookup is providing a single domain.

Also, when it comes to transport layer research you often have transport header structures in place but may be able to stick in the attribution information somewhere where it will not interfere with your actual research, like in payload fields. Thus, you have a mix of structured fields and dummy payload of fields whose content may not matter. So I think this is one more case of different views depending on which protocols one attempt to do research/probing of.

I have re-read the -06 version.

I will note that the introduction is inconsistent, as the first paragraph do discuss the L4 headers and the last narrows the scope back to L3 almost exclusively.

Section 4: I think for UDP and TCP one could state that if there is an actual higher layer protocol in place that if one has a field which has no structure or one can define a probe attribution field it is recommended to do that.

Section 4: “Inserting the Probe Description URI could obviously bias the measurement itself if the probe packet becomes larger than the path MTU.” I think this is not the only possible bias that could occur due to the probe URI insertion. Especially as an URI in itself is likely a “magic string” and have the issues the next paragraph notes. I think the MTU issue, is not only about bias, there is a question if that impacts the intended measurement by for example resulting a larger smallest possible packet.

Section 5:
I find this part puzzling to me: “too many endpoints to run a web server on,”. For the out-of-band isn’t the idea that you just ensure that the reverse lookup resolves to a domain name, that is then its turn looked up and resolved? That way one only need one web-server, as long as the reverse lookup for the IP address points to that domain name?

Section 5:
“The primary disadvantage is that it could potentially bias the measurements, since packets with the Probe Description URI might be discarded. ”
I would note that for network performance probes the general problem with “public” measurement tools, e.g. ookla speed test,  have been the desire to cheat in the other direction by prioritizing that traffic.

To conclude, I think the document has improved but could benefit from some more work and consideration on the applicability for L4 research.


Cheers

Magnus Westerlund









From: Eric Vyncke (evyncke) <[e-mail]>
Date: Monday, 19 June 2023 at 16:33
To: Magnus Westerlund <[e-mail]>, Justin Iurman <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [Last-Call] Tsvart last call review of draft-ietf-opsec-probe-attribution-05
Hello Magnus,

Let me renew Justin's appreciation for your review, as he is currently on vacations, I am holding the pen.

About, multiple PRT records for a single IP address: while permitted by DNS, the authors do not believe that it is common enough to add some text. AFAIK, the only case when it may be used is for hosted web servers sharing the same IP and measurements cannot really be done from a shared resource, i.e., this will never happen.

About section 4/5, you are probably aware that most of those measurements are application-protocol unaware as they usually rarely use well-known ports. I.e., the URI cannot be part of a structured payload as there are none. This is very similar to the UDP traceroute (even of the latter often uses 33435). From our point of view, the URI could really be anywhere in the transport payload, even from the very first byte after the layer-4 header.

Good idea to add some examples in an appendix, i.e., a tcpdump packet dump.

About IPPM, it would indeed been useful to explicitly request an early review by the IPPM WG (or MAPRG). Anyway, the current state is IETF-wide last call, i.e., also including IPPM WG.

Looking forward to reading your additional comments,

Regards

-éric

From: Magnus Westerlund <[e-mail]>
Date: Monday, 19 June 2023 at 10:25
To: Justin Iurman <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Last-Call] Tsvart last call review of draft-ietf-opsec-probe-attribution-05
Resent from: <[e-mail]>
Resent to: Eric Vyncke <[e-mail]>, <[e-mail]>, <[e-mail]>, Ron Bonica <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Resent date: Monday, 19 June 2023 at 10:24

Hi Justin,

I think you addressed some points.

However, did you miss to add text on what to do when there are multiple DNS records for the reverse lookup?

In regards to section 4. I think you new text is more correct, but it does not really discusses structured data payloads that would allow the URI In a particular field without negatively impacting the protocol. I think one may attempt such usages, especially considering that you are actually recommending the IPv6 PadN which you know will not work on some endpoints. So I think you are a bit inconsistent in your recommendations. Going for first in the payload always, except in some exceptions.

I guess this is getting closer to “almost ready”. However, I think the section on embedding the URL could be written with more general guidance first, then exemplify a couple of them. People will use this if they use it to their best competence. Thus, I would expect raising the potential issues are more relevant.

Cheers

Magnus

From: Justin Iurman <[e-mail]>
Date: Saturday, 17 June 2023 at 17:15
To: Magnus Westerlund <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [Last-Call] Tsvart last call review of draft-ietf-opsec-probe-attribution-05
Hi Magnus,

We hope that the new published version (-06) addresses most of your
comments/concerns. We'll also forward it to ippm, as suggested.

Thanks,
Justin

On 6/12/23 13:26, Magnus Westerlund wrote:
> Hi,
>
> Comments inline.
>
> *From: *last-call <[e-mail]> on behalf of Justin
> Iurman <[e-mail]>
> *Date: *Friday, 9 June 2023 at 17:26
> *To: *Magnus Westerlund <[e-mail]>,
> [e-mail] <[e-mail]>
> *Cc: *[e-mail]
> <[e-mail]>, [e-mail]
> <[e-mail]>, [e-mail] <[e-mail]>
> *Subject: *Re: [Last-Call] Tsvart last call review of
> draft-ietf-opsec-probe-attribution-05
>
> Hi Magnus,
>
> Thanks for the review. Please see inline ([JI]).
>
> On 6/5/23 12:30, Magnus Westerlund via Datatracker wrote:
>> Reviewer: Magnus Westerlund
>> Review result: Not Ready
>>
>> This document has been reviewed as part of the transport area review team's
>> ongoing effort to review key IETF documents. These comments were written
>> primarily for the transport area directors, but are copied to the document's
>> authors and WG to allow them to address any issues raised and also to the IETF
>> discussion list for information.
>>
>> When done at the time of IETF Last Call, the authors should consider this
>> review as part of the last-call comments they receive. Please always CC
>> [e-mail] if you reply to or forward this review.
>>
>> I questions why this document is published as informational status. It appears
>> to at least define a format with a well known URI. I would think a standards
>> track would be a more approrpiate status.
>
> [JI] As you mentioned at the end of your email, RFC 9116 is
> informational and did get a permanent well known URI, which is similar
> to this draft. Initially, we wanted to keep things simple (hence the
> informational status), so we would prefer to keep the current status as
> is (although we do not have a strong opinion), unless consensus decides
> otherwise.
>
> [MW] If the registry experts are fine with this overstep of the rules I
> have no reason to raise it more.
>
>
>
>> Section 3:
>>
>> "if the reverse DNS record for 2001:db8::dead exists"
>>
>> What should one do if there are multiple PTR records for a given address? This
>> I would expect to be fairly likely in some multi-tennant systems.
>
> [JI] Good catch, we'll clarify that part.
>
>> Section 4:
>>
>> • for a [RFC4443] ICMPv6 echo request: in the optional data (see section 4.1 of
>> [RFC4443]); • for a [RFC792] ICMPv4 echo request: in the optional data;
>>
>> First of all there are no "optional data" there is a "data" field. I think the
>> reference to which field should be clearer, i.e. "in the data field".
>>
>> "for a [RFC768] UDP datagram: in the data part. Note that if the probe is
>> destined to a listened-to/well-known UDP port, the inclusion of the probe
>> description URI may produce undefined results;"
>>
>> I think this is really understating the issue. If the probe is done using a
>> protocol that has any fields in the UDP payload it is unlikely that the
>> placement of the URI first will work at all, unless the measurement protocol is
>> updated. I would think an placement in the end would be more likely to
>> function, unless the UDP payload has no other than random data. However, in
>> some case it will simply not work without updating the probe protocol.
>>
>> For the future including the attribution URI in an UDP options would be a
>> potential solution that can be looked into.
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/
> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/>
>
> [JI] Indeed. Probe attribution should probably be restricted to probes
> with random data payload. Otherwise, it becomes too complicated (see the
> explanation below, at the end).
>
>
>
>> "for a [RFC9293] TCP packet with the SYN flag: data is allowed in TCP packets
>> with the SYN flag per section 3.4 of [RFC9293] (2nd paragraph). However, it may
>> change the way the packet is processed, i.e., SYN packets containing data might
>> be discarded;"
>>
>> So from an TCP using protocol, there are little difference in sending the data
>> in syn, or sending it in the first packets after established state. The data
>> will reach the application layer, this does not bypass the issue of the data
>> ending up in the upper layer application. So why are there specific discussion
>> of the data in TCP syn.
>
> [JI] Unfortunately, if you have SYN+data, you are more exposed to a drop
> (hence the discussion).
>
> [MW] So the issue is that this bullet appears to be general advice for
> TCP, and only talks about data in SYN. So it can easily be interpreted
> to mean that if one uses TCP one should put the abbtribution in the data
> payload of the SYN, rather than just include it first in the data.
>
> I would suggest that you reformulate this bullet to something like:
>
>   * For a TCP packet [RFC9293] include it first in the data payload of
>     this TCP connection if the data payload content has no structure.
>
> Using something like this I don’t think you necessarily need to add a
> note about data in syn at all. If you really want you can, but I think
> this usage should be if the goal of the probing is to determine if this
> works or not otherwise I think most probing will benefit from a more
> base line usage of TCP.
>
>
>> Also, I think the reference to Section 3.4 of RFC9293 is pointing to the wrong
>> section. Because that paragraph discusses sequence number space wrapping which
>> appear not that relevant here.
>>
>> So in general I think the attempt to apply in-band URI to UDP and TCP are
>> likely problematic and may have to be dialed back into being recommended to be
>> included in protocol fields that otherwise would include random data. Have it
>> been considered to define a magical word that would prefix the URI so that it
>> might be easier to look for potential matches in the payloads? It makes sense
>> to volunteerily include this URI in probe packets for measurements that can do
>> that without making there packets unusable for their main purpose.
>
> [JI] Yes, having a magical word was considered. However, as mentioned,
> we wanted to keep things simple. Besides, having a magical word would
> allow for an easy filtering, which could be worse. Indeed, if I'm the
> researcher and decide to identify my probes (good intention), I don't
> want to get shot for that in return (if so, why should I bother
> identifying my probes?). So this is a double-edged weapon and my
> measurements could be biased in that case.
>
> [MW] I understand this issue. And you mention it briefly in Section 5
> for example. I think what I struggle with is the inconsistency in the
> recommendation for in-band attribution. To me it appears that the
> decision process for inband attribution is to consider several aspects:
>
>  1. Will attribution result in filtering or other biasing of the probes?
>  2. Where in the packet can the in-band attribution be placed?
>
>      1. Follow protocol specific recommendation and if multiple options
>         exists, like IPv6 options vs others consider the rest of the
>         questions.
>      2. If payload is random one is recommended to put it first
>      3. Else put it where it is possible to not affect the probe protocol
>
> Based on the motivation text it appears that it is more important to
> have the attribution somewhere than first as it a tool for someone that
> like to understand what the traffic is and thus can be expected to do a
> bit more work to find the attribution.
>
>
>> Section 8.
>>
>> I noted that you expect permanent status.
>>
>> Reading RFC 8615 I noticed this paragraph:
>>
>> Values defined by Standards Track RFCs and other open standards (in
>>     the sense of [RFC2026], Section 7.1.1) have a status of "permanent".
>>     Other values can also be registered as permanent, if the experts find
>>     that they are in use, in consultation with the community.  Other
>>     values should be registered as "provisional".
>>
>> This document is targeting informational status. Which I personally questions.
>> However, I do see the point of having this format have a well-known URI that
>> are permanent, but according to instruction this ends up in a grey zone. It
>> might be that the expert want to waive this. I do also note that RFC 9116 did
>> get permanent.
>>
>> Another aspect that I find worrying.
>>
>> This draft appear to never to have been even mentioned in the IPPM group. Being
>> a WG that define active measurements it should have been done, and
>> consideration of how to include the attribution in the IPPM protocols should
>> have taken place. Although IPPM targets measurements between collaborating
>> nodes, it appears some of the concerns from on path nodes about measurement
>> could still be relevant. So I would recommend that this work is at least
>> brought up in IPPM to discuss if there are need to extend.
>
> [JI] The problem is, what is the limit then? If we do this, we should
> also ask other WGs to have probe attribution extended to many, MANY
> protocols. Besides, this draft does not necessarily target
> IPPM/measurement protocols specifically. I think we should definitely
> clarify that, and maybe provide a solution for UDP and TCP with
> non-random payload data (i.e., real traffic), with e.g., UDP and TCP
> options, although it is probably expected to have a probe attribution
> for weird, crafted or unexpected probes rather than real traffic.
>
> [MW] my point is that you are doing work, and you are not informing the
> one WG that do works with active measurements using probe traffic, I
> find this strange. Sure some of the participants may follow OPSEC, but
> you could have easily informed IPPM by sending an email. And you would
> likely have gotten more feedback on this work.
>
> Cheers
>
> Magnus
>