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

"Bless, Roland (TM)" <roland.bless@kit.edu> Thu, 14 February 2019 16:01 UTC

Return-Path: <roland.bless@kit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0396131088; Thu, 14 Feb 2019 08:01:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gC0ez7A-HTZ6; Thu, 14 Feb 2019 08:01:46 -0800 (PST)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [IPv6:2a00:1398:2::10:81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16A4213104A; Thu, 14 Feb 2019 08:01:45 -0800 (PST)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtpsa port 25 iface 141.3.10.8 id 1guJSI-0004uy-1e; Thu, 14 Feb 2019 17:01:42 +0100
Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id E93464200AA; Thu, 14 Feb 2019 17:01:41 +0100 (CET)
To: Kyle Rose <krose@krose.org>, secdir@ietf.org
Cc: ietf@ietf.org, tsvwg@ietf.org
References: <154992443765.29641.355119587706336977@ietfa.amsl.com>
From: "Bless, Roland (TM)" <roland.bless@kit.edu>
Openpgp: preference=signencrypt
Autocrypt: addr=roland.bless@kit.edu; prefer-encrypt=mutual; keydata= xsFNBFi0OxABEACy2VohJ7VhSu/xPCt4/6qCrw4Pw2nSklWPfAYEk1QgrbiwgvLAP9WEhAIU w45cojBaDxytIGg8eaYeIKSmsXjHGbV/ZTfo8r11LX8yPYR0WHiMWZpl0SHUd/CZIkv2pChO 88vF/2FKN95HDcp24pwONF4VhxJoSFk6c0mDNf8Em/Glt9BcWX2AAvizTmpQDshaPje18WH3 4++KwPZDd/sJ/hHSXiPg1Gdhs/OG/C0CJguOAlqbgSVAe3qKOr1M4K5M+wVpsk373pXRfxd7 ZAmZ05iBTn+LfgVcz+AfaKKcsWri5CdTT+7JDL6QNQpox+b5FXZFSHnEIST+/qzfG7G2LqqY mml6TYY8XbaNyXZP0QKncfSpRx8uTRWReHUa1YbSuOxXYh6bXpcugD25mlC/Lu0g7tz4ijiK iIwq9+P2H1KfAAfYyYZh6nOoE6ET0TjOjUSa+mA8cqjPWX99kEEgf1Xo+P9fx9QLCLWIY7zc mSM+vjQKgdUFpMSCKcYEKOuwlPuOz8bVECafxaEtJJHjCOK8zowe2eC9OM+G+bmtAO3qYcYZ hQ/PV3sztt/PjgdtnFAYPFLc9189rHRxKsWSOb4xPkRw/YQAI9l15OlUEpsyOehxmAmTsesn tSViCz++PCdeXrQc1BCgl8nDytrxW+n5w1aaE8aL3hn8M0tonQARAQABzShSb2xhbmQgQmxl c3MgKFRNKSA8cm9sYW5kLmJsZXNzQGtpdC5lZHU+wsGABBMBCAAqAhsDBQkSzAMABQsJCAcC BhUICQoLAgQWAgMBAh4BAheABQJYtYdHAhkBAAoJEKON2tlkOJXuzWkP+wfjUnDNzRm4r34a AMWepcQziTgqf4I1crcL6VD44767HhyFsjcKH31E5G5gTDxbpsM4pmkghKeLrpPo30YK3qb7 E9ifIkpJTvMu0StSUmcXq0zPyHZ+HxHeMWkosljG3g/4YekCqgWwrB62T7NMYq0ATQe1MGCZ TAPwSPGCUZT3ioq50800FMI8okkGTXS3h2U922em7k8rv7E349uydv19YEcS7tI78pggMdap ASoP3QWB03tzPKwjqQqSevy64uKDEa0UgvAM3PRbJxOYZlX1c3q/CdWwpwgUiAhMtPWvavWW Tcw6Kkk6e0gw4oFlDQ+hZooLv5rlYR3egdV4DPZ1ugL51u0wQCQG9qKIMXslAdmKbRDkEcWG Oi2bWAdYyIHhhQF5LSuaaxC2P2vOYRHnE5yv5KTV3V7piFgPFjKDW+giCRd7VGfod6DY2b2y zwidCMve1Qsm8+NErH6U+hMpMLeCJDMu1OOvXYbFnTkqjeg5sKipUoSdgXsIo4kl+oArZlpK qComSTPhij7rMyeu/1iOwbNCjtiqgb55ZE7Ekd84mr9sbq4Jm/4QGnVI30q4U2vdGSeNbVjo d1nqjf3UNzP2ZC+H9xjsCFuKYbCX6Yy4SSuEcubtdmdBqm13pxua4ZqPSI0DQST2CHC7nxL1 AaRGRYYh5zo2vRg3ipkEzsFNBFi0OxABEAC2CJNp0/Ivkv4KOiXxitsMXZeK9fI0NU2JU1rW 04dMLF63JF8AFiJ6qeSL2mPHoMiL+fG5jlxy050xMdpMKxnhDVdMxwPtMiGxbByfvrXu18/M B7h+E1DHYVRdFFPaL2jiw+Bvn6wTT31MiuG9Wh0WAhoW8jY8IXxKQrUn7QUOKsWhzNlvVpOo SjMiW4WXksUA0EQVbmlskS/MnFOgCr8q/FqwC81KPy+VLHPB9K/B65uQdpaw78fjAgQVQqpx H7gUF1EYpdZWyojN+V8HtLJx+9yWAZjSFO593OF3/r0nDHEycuOjhefCrqr0DDgTYUNthOdU KO2CzT7MtweRtAf0n27zbwoYvkTviIbR+1lV1vNkxaUtZ6e1rtOxvonRM1O3ddFIzRp/Qufu HfPe0YqhEsrBIGW1aE/pZW8khNQlB6qt20snL9cFDrnB6+8kDG3e//OjK1ICQj9Y/yyrJVaX KfPbdHhLpsgh8TMDPoH+XXQlDJljMD0++/o7ckO3Sfa8Zsyh1WabyKQDYXDmDgi9lCoaQ7Lf uLUpoMvJV+EWo0jE4RW/wBGQbLJp5usy5i0fhBKuDwsKdLG3qOCf4depIcNuja6ZmZHRT+3R FFjvZ/dAhrCWpRTxZANlWlLZz6htToJulAZQJD6lcpVr7EVgDX/y4cNwKF79egWXPDPOvQAR AQABwsFlBBgBCAAPBQJYtDsQAhsMBQkSzAMAAAoJEKON2tlkOJXukMoP/jNeiglj8fenH2We 7SJuyBp8+5L3n8eNwfwY5C5G+etD0E6/lkt/Jj9UddTazxeB154rVFXRzmcN3+hGCOZgGAyV 1N7d8xM6dBqRtHmRMPu5fUxfSqrM9pmqAw2gmzAe0eztVvaM+x5x5xID2WZOiOq8dx9KOKrp Zorekjs3GEA3V1wlZ7Nksx/o8KZ04hLeKcR1r06zEDLN/yA+Fz8IPa0KqpuhrL010bQDgAhe 9o5TA0/cMJpxpLqHhX2As+5cQAhKDDsWJu3oBzZRkN7Hh/HTpWurmTQRRniLGSeiL0zdtilX fowyxGXH6QWi3MZYmpOq+etr7o4EGGbm2inxpVbM+NYmaJs+MAi/z5bsO/rABwdM5ysm8hwb CGt+1oEMORyMcUk/uRjclgTZM1NhGoXm1Un67+Rehu04i7DA6b8dd1H8AFgZSO2H4IKi+5yA Ldmo+ftCJS83Nf6Wi6hJnKG9aWQjKL+qmZqBEct/D2uRJGWAERU5+D0RwNV/i9lQFCYNjG9X Tew0BPYYnBtHFlz9rJTqGhDu4ubulSkbxAK3TIk8XzKdMvef3tV/7mJCmcaVbJ2YoNUtkdKJ goOigJTMBXMRu4Ibyq1Ei+d90lxhojKKlf9yguzpxk5KYFGUizp0dtvdNuXRBtYrwzykS6vB zTlLqHZ0pvGjNfTSvuuN
Organization: Institute of Telematics, Karlsruhe Institute of Technology
Message-ID: <03bfb567-cc86-56fa-6db1-8a42040a6d97@kit.edu>
Date: Thu, 14 Feb 2019 17:01:41 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <154992443765.29641.355119587706336977@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de esmtpsa 1550160102.109889558
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/adPxpZQKjKxajw-Is8ZmMhLAHQQ>
Subject: Re: [secdir] [tsvwg] Secdir last call review of draft-ietf-tsvwg-le-phb-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Thu, 14 Feb 2019 16:01:50 -0000

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