Hi Kyle, see inline, please. Am 14.02.19 um 21:22 schrieb Kyle Rose: >> > 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. Thank you for this explanation, now I got your point! > 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. ..." My apologies, but I'm not a native speaker, so some phrases may be awkward indeed (I think that the RFC editor will catch the most obvious ones). Thanks for the suggestion. I tried to rephrase that paragraph based on the better understanding of your point (will be in the next draft revision). > 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. Ok, great. Regards, Roland
