Re: [secdir] secdir review of draft-ietf-tsvwg-diffserv-intercon-09

Benjamin Kaduk <kaduk@MIT.EDU> Thu, 22 September 2016 00:42 UTC

Return-Path: <kaduk@mit.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 ABE27127077; Wed, 21 Sep 2016 17:42:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.537
X-Spam-Level:
X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, 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 y-gjhRegFneX; Wed, 21 Sep 2016 17:42:52 -0700 (PDT)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 A0FDF12BC58; Wed, 21 Sep 2016 17:42:52 -0700 (PDT)
X-AuditID: 12074424-263ff70000004d93-c6-57e3290a2e04
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id C4.6D.19859.A0923E75; Wed, 21 Sep 2016 20:42:50 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u8M0gnC5013651; Wed, 21 Sep 2016 20:42:50 -0400
Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u8M0ghMg007884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Sep 2016 20:42:48 -0400
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u8M0ggqe017791; Wed, 21 Sep 2016 20:42:42 -0400 (EDT)
Date: Wed, 21 Sep 2016 20:42:42 -0400 (EDT)
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: "Black, David" <David.Black@dell.com>
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949362F69D7C8@MX307CL04.corp.emc.com>
Message-ID: <alpine.GSO.1.10.1609212037020.5272@multics.mit.edu>
References: <alpine.GSO.1.10.1609132359590.5272@multics.mit.edu> <CE03DB3D7B45C245BCA0D243277949362F69D7C8@MX307CL04.corp.emc.com>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrMul+Tjc4PlsM4uPsxazWDxZ94PN YsaficwWHxY+ZHFg8Zg0cwazx5IlP5kCmKK4bFJSczLLUov07RK4Mo6deMdecE+q4uTRvcwN jK2iXYycHBICJhJ3r+5m62Lk4hASaGOSOHaymQnC2cgo0bV1BiuEc4hJYufEicwQTgOjxJGd bxhB+lkEtCUmXZ/IBmKzCahIzHyzEcjm4BAR0JR4ONcFpJ5ZYB2jROP/NWD1wgLOEhu3zGQC sTkF/CSeNh4D6+UVcJB4uOokC4gtJNDEKLF2OT+ILSqgI7F6/xQWiBpBiZMzn4DZzAJaEsun b2OZwCgwC0lqFpLUAkamVYyyKblVurmJmTnFqcm6xcmJeXmpRbrmermZJXqpKaWbGEGByu6i soOxu8f7EKMAB6MSD29E96NwIdbEsuLK3EOMkhxMSqK83VuAQnxJ+SmVGYnFGfFFpTmpxYcY JTiYlUR4lZQfhwvxpiRWVqUW5cOkpDlYlMR5u2YcCBcSSE8sSc1OTS1ILYLJynBwKEnw1qgD NQoWpaanVqRl5pQgpJk4OEGG8wANXwlSw1tckJhbnJkOkT/FqCglzvtdDSghAJLIKM2D6wUn kt1Mqq8YxYFeEebtAWnnASYhuO5XQIOZgAZv+fkAZHBJIkJKqoFx+2F9a7nYbxempH+7vOgD n9rP6y8vH9yfUMlkdHa73B82pfS1LoqyDG7OcWo+p1t7heZP3PI78HVUmbN9leSiZVuf34y6 5FDjYKJ1bArLnWXnd155sFm1etZsT/W783RY5xQodc9a78rdobg7cn27lEp2ZOd2V6kfERN7 Slm6N/v9y+ie7W6mxFKckWioxVxUnAgAjzTPaf8CAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/mQgOLJX35Eqwg4uGvkTObP3Bkfw>
Cc: "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-tsvwg-diffserv-intercon@ietf.org" <draft-ietf-tsvwg-diffserv-intercon@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-diffserv-intercon-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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, 22 Sep 2016 00:42:55 -0000

Hi David,

On Wed, 21 Sep 2016, Black, David wrote:

> Hi Ben,
>
> Thanks for the review.
>
> > However, I do think it's worth giving a little bit of new thought to the
> > potential privacy considerations -- a new way of marking traffic, in
> > abstract, has the potential to leak classification information about the
> > traffic in question (e.g., is this IP address doing telephony?).  That
> > said, the classification added by this document is something that could be
> > done by any party with access to the raw network traffic, so I don't think
> > there are actually any new considerations in play; it's just something to
> > keep in mind.
>
> On balance, it seems like a good idea to add a sentence or two to point out
> that additional traffic classification information is exposed at network
> interconnections by comparison to DSCP remarking to zero - if that traffic
> classification info is sensitive, remarking DSCPs to zero to hide the classification
> is the countermeasure, at the cost of loss of QoS info and traffic handling
> on the interconnect.

Thanks.  I think the document would be fine without such a sentence, but
am happy to see one added.

>  Also, here are a few comments on your editorial suggestions:
>
> > Top of page 3, last sentence of first paragraph ("This draft assumes that
> > latter approach by defining additional DSCPs that are known and expected
> > at network interconnection interfaces.") -- I think maybe "subsumes" is a
> > better verb than "assumes", as it is true that unknown/unexpected DSCPs
> > are remarked to zero, but there is additional functionality in the
> > known/expected DSCPs that are preserved.
>
> Well, "subsumes" isn't quite right either.   Here's a longer rewrite that I hope
> makes things clearer:
>
> OLD
>    This draft assumes that latter approach by defining additional DSCPs
>    that are known and expected at network interconnection interfaces.
> NEW
>    This draft is based on the latter approach, and defines additional DSCPs
>    that are known and expected at network interconnection interfaces in
>    order to reduce the amount of traffic whose DSCPs are remarked to zero.

The transition to "and defines additional" could probably be tweaked a bit
more, but this is definitely an improvement -- thanks.

> > Across the page 3/page 4 boundary, the part after the semicolon is a
> > sentence fragment ... I can't even tell what it's trying to say.  Maybe,
> > "remarking to zero is performed in the absence of [...]" (but put a comma
> > before "for").
>
> Yes, it's a fragment - here's a suggested rewrite:
>
> OLD
>    remarking in the absence of
>    additional agreement(s) when the MPLS Short Pipe model is used for
>    reasons explained in this document.
> NEW
>    use of the MPLS Short Pipe model favors remarking unexpected DSCPs
>    to zero in the absence of additional agreement(s), as explained further
>    in this document.

Makes sense.

> > Section 1.1, first paragraph, is this work really intended to *complement*
> > RFC 5160?  It seems to me that rather it is building upon 5160, or
> > implementing its suggestions, or something like that.
>
> The activities are independent, so "complement" is a  reasonable summary.

I'll have to take your word for it, since my understanding seems to be
incomplete.  Sorry for the noise, then.

-Ben