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

Kyle Rose <krose@krose.org> Thu, 14 February 2019 20:22 UTC

Return-Path: <krose@krose.org>
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 986B112EB11 for <secdir@ietfa.amsl.com>; Thu, 14 Feb 2019 12:22:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
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 xDWlaGpDWRLH for <secdir@ietfa.amsl.com>; Thu, 14 Feb 2019 12:22:47 -0800 (PST)
Received: from mail-yw1-xc33.google.com (mail-yw1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5611F12F1AB for <secdir@ietf.org>; Thu, 14 Feb 2019 12:22:45 -0800 (PST)
Received: by mail-yw1-xc33.google.com with SMTP id n12so2827323ywn.13 for <secdir@ietf.org>; Thu, 14 Feb 2019 12:22:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zw0UZvxpBbSuaUrhSQ3QH2WCVZUY4kQhyinOoe5YtMs=; b=l0xXdx+M80O1kl+iLKMQU6kyQ+Z/qRF+lNaQARKsnwBIAd1fiwwBwsW1qzYEPerEN+ Rq2nWD4tbWS9THLt92e96weaSyRLGlHKwW2mSFNmX3Zzw8GspTkzNftz3n5TfcDOfEBl XdtkuBiH/MGrCYzHHUxUQGht8KUvf8BQash4U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zw0UZvxpBbSuaUrhSQ3QH2WCVZUY4kQhyinOoe5YtMs=; b=OX+bYGTC8XM1jpQJScVHlGXEeVPtqnha9lVWcjhQRfx+ymV/lPvsvFYqJJRDzhjiu+ TpOdWEA3vw2A6FT9+I/tWUmbRSAP5tR5s3vM656//SU2gbqlI7d5iltPxx/jljNGTz6f tW89mxXsfAA7cNPd6h46Pk7Omad0JkE0kJ7oS5sGLhrN8VDLp2I6M5/EKZekkZ0mirSw RN9YQACnPT4SaUketdwN3d2erB0njmeZPB6wpWE28wrTDjdkcSNoTAC7phecGjOivD8J HdvzR5R3KVNBOW2sxHQQ00hQ5KweKc/kfO2CwLuFZ1hw97W1lw9Bn0tLTnAczF1gvEb9 hmKA==
X-Gm-Message-State: AHQUAuasaKVyAp5liUAyt29B1DuOlJiLepbvkLwH8sv44aWImpgX6hBJ JdAtRVi6f0ki9cvcQkZW/6eMeghbNt0lqdaSdgbZ8Q==
X-Google-Smtp-Source: AHgI3IaWaSF8a60FVYiN2y6MJZU5hXT7kfjLK1GussDoGUrEMFpVzfu5AUdqplQPp6YmrK/o2UQyvk4O0Fi43AJEk88=
X-Received: by 2002:a81:d008:: with SMTP id v8mr4905718ywi.464.1550175764168; Thu, 14 Feb 2019 12:22:44 -0800 (PST)
MIME-Version: 1.0
References: <154992443765.29641.355119587706336977@ietfa.amsl.com> <03bfb567-cc86-56fa-6db1-8a42040a6d97@kit.edu>
In-Reply-To: <03bfb567-cc86-56fa-6db1-8a42040a6d97@kit.edu>
From: Kyle Rose <krose@krose.org>
Date: Thu, 14 Feb 2019 15:22:33 -0500
Message-ID: <CAJU8_nVBMObpDys34Ld7qJPfD5VGZkkvEAssCmAJWEG-etLj9g@mail.gmail.com>
To: "Bless, Roland (TM)" <roland.bless@kit.edu>
Cc: IETF SecDir <secdir@ietf.org>, IETF Discussion Mailing List <ietf@ietf.org>, tsvwg@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c357560581e06b67"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/LVWQX1HnaSAQln4zvB7rlJiLgjs>
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 20:22:49 -0000

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

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.


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


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

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

Thanks,
Kyle