Hi Kyle, thanks for the review. See response inline. Am 11.02.19 um 23:33 schrieb Kyle Rose: > I agree that there are no remarkable security or privacy considerations for > this draft, but I would wordsmith the privacy paragraph slightly. It says: > > q( However, this disclosed information is only useful if some form of > identification happened at the same time ) > > glossing over the fact that identification is typically present in every > packet: the IP address of the user. It provides at least one bit of information > about what the user is doing, which, in conjunction with metadata from other > flows to/from that address, can potentially reveal more about user identity > 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. 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." > Unrelated to secdir, I am also vaguely concerned about the impact on path > elements that pass along the LE PHB but treat the traffic as BE: especially for > traffic lacking congestion control (e.g., unicast hops for multicast traffic), > can they be put in the position of forwarding large volumes of traffic in vain, > i.e., traffic that will be dropped later? For CC-managed unicast traffic, it Yes, but it's a bit in the responsibility of the DS domain operators. If they just remap the LE PHB to BE, it's at their own risk. The recommendation is to use only congestion controlled transport for LE marked traffic (same as for BE in general). However, even a congestion controlled traffic load can be too high if the number of sources is too high (e.g., many flows with a congestion window of 1 MSS could easily overload links). That is a capacity problem that isn't solved by traditional end-to-end congestion control. > seems that the sender will back off sufficiently following congestion-induced > loss to make this no worse than a highly-lossy destination at BE. It might also > be the case that multicast congestion-induced loss in LE is no worse than > congestion problems with multicast in general, but I'd like to understand this > a bit better. 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? Regards, Roland
