Re: [tsvwg] Secdir last call review of draft-ietf-tsvwg-le-phb-08

[Kyle Rose <[e-mail]>]

> > and/or behavior. The reason the privacy impact is unremarkable is that
it is

> > highly likely the case that such traffic is already classifiable as
> unimportant
> > via the sort of traffic analysis that troubles privacy advocates, when
> > considering the endpoint, payload length, pacing, etc.
>
> The LE DSCP marking does not say that this traffic is "unimportant",
> it basically classifies the traffic as being of low priority/urgency.
>

Right, "unimportant" is the wrong word. I meant "uninteresting" from the
perspective of an observer interested in learning about the user behind
some traffic (e.g., a state level actor). Software downloads, for instance,
are less likely to be interesting for surveillance purposes than general
web traffic, which is not going to be LE. The net effect of marking some
packets LE is to reduce the chaff/noise from which wheat/signal can be
extracted.


> I think that the statement "However, this disclosed information is only
> useful if some form of identification happened at the same time" is
> still correct, but probably needs a bit more explanation that this
> is often given due to the IP addresses in the packet. Compared to the
> plethora of traffic analysis possibilities and general privacy threats
> (e.g., see RFC 6973) the impact of disclosed information by the LE DSCP
> is likely negligible in most cases. So my suggestion is the following
> text:
>
> "However, this disclosed information is only useful if some form of
> identification happened at the same time, which is often given due to
> the presence of IP addresses in the packet. Compared to the numerous
> traffic analysis possibilities and general privacy threats (e.g., see
> [RFC 6973]) the impact of disclosed information by the LE DSCP is likely
> negligible in most cases."
>

I think the wording here is a bit awkward, and simultaneity isn't really
the limiting factor. I might start with:

"However, this disclosed information is useful only if correlation with
metadata (such as the user's IP address) and/or other flows reveal user
identity. ..."


> I agree that the multicast congestion-induced loss in LE is no worse
> than congestion problems with multicast in general, but there is a
> subtle difference. the multicast LE replication problem is covered in
> section 9. Depending on the implementation replication of LE multicast
> packets inside a node may impact other traffic in an undesired way:
> the expectation is that LE packets only scavenge otherwise unused
> resources. I think that this is covered by the first sentence of the
> last paragraph in sec.9:
>    While the resource contention problem caused by multicast packet
>    replication is also true for other Diffserv PHBs, LE forwarding is
>    special, because often it is assumed that LE packets get only
>    forwarded in case of available resources at the output ports.
>
> So what is missing in your point of view for a better understanding?
>

Nothing. I think I'm happy with this explanation.

Thanks,
Kyle