> > 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
