Skip to main content

Last Call Review of draft-ietf-tsvwg-le-phb-08
review-ietf-tsvwg-le-phb-08-secdir-lc-rose-2019-02-11-00

Request Review of draft-ietf-tsvwg-le-phb
Requested revision 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
I-D 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 E. Carpenter (diff)
Assignment Reviewer Kyle Rose
State Completed
Request Last Call review on draft-ietf-tsvwg-le-phb by Security Area Directorate Assigned
Reviewed revision 08 (document currently at 10)
Result Has nits
Completed 2019-02-11
review-ietf-tsvwg-le-phb-08-secdir-lc-rose-2019-02-11-00
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.