Last Call Review of draft-ietf-tsvwg-le-phb-08

Request Review of draft-ietf-tsvwg-le-phb
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2019-02-12
Requested 2019-01-29
Authors Roland Bless
Draft last updated 2019-02-11
Completed reviews Tsvart Last Call review of -08 by Olivier Bonaventure (diff)
Secdir Last Call review of -08 by Kyle Rose (diff)
Genart Last Call review of -08 by Brian Carpenter (diff)
Assignment Reviewer Kyle Rose 
State Completed
Review review-ietf-tsvwg-le-phb-08-secdir-lc-rose-2019-02-11
Reviewed rev. 08 (document currently at 10)
Review result Has Nits
Review completed: 2019-02-11


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.