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

From: Kyle Rose <[email-masked]>
Date: Mon, 11 Feb 2019 14:33:57 -0800

Reviewer: Kyle Rose
Review result: Has Nits

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

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.

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

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Thu, 14 Feb 2019 17:01:41 +0100

Hi Kyle,

thanks for the review. See response inline.

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

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

> congestion problems with multicast in general, but I'd like to understand this

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

---

From: Kyle Rose <[email-masked]>
Date: Thu, 14 Feb 2019 15:22:33 -0500

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

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

> So what is missing in your point of view for a better understanding?

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

Thanks,
Kyle

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Fri, 15 Feb 2019 09:43:14 +0100

Hi Kyle,

see inline, please.

Am 14.02.19 um 21:22 schrieb Kyle Rose:
> 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!

> metadata (such as the user's IP address) and/or other flows reveal user

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

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

Ok, great.

Regards,
 Roland

---

From: Kyle Rose <[email-masked]>
Date: Fri, 15 Feb 2019 08:25:57 -0500

The wording in draft 9 looks great. Thanks!

Kyle