Hi,
Comments inline.
*From: *last-call <last-call-boun...@ietf.org> on behalf of Justin
Iurman <justin.iur...@uliege.be>
*Date: *Friday, 9 June 2023 at 17:26
*To: *Magnus Westerlund <magnus.westerl...@ericsson.com>,
tsv-...@ietf.org <tsv-...@ietf.org>
*Cc: *draft-ietf-opsec-probe-attribution....@ietf.org
<draft-ietf-opsec-probe-attribution....@ietf.org>, last-c...@ietf.org
<last-c...@ietf.org>, opsec@ietf.org <opsec@ietf.org>
*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
tsv-...@ietf.org 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
