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

Kyle Rose <krose@krose.org> Mon, 11 February 2019 22:33 UTC

Return-Path: <krose@krose.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B42E51228B7; Mon, 11 Feb 2019 14:33:57 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Kyle Rose <krose@krose.org>
To: secdir@ietf.org
Cc: ietf@ietf.org, draft-ietf-tsvwg-le-phb.all@ietf.org, tsvwg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.91.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154992443765.29641.355119587706336977@ietfa.amsl.com>
Date: Mon, 11 Feb 2019 14:33:57 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/fZwbpptUZTNgBaKp6b-mNHLFeL4>
Subject: [secdir] Secdir last call review of draft-ietf-tsvwg-le-phb-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Feb 2019 22:33:58 -0000

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.