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

[Justin Iurman <[e-mail]>]

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
>