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: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ABE27127077; Wed, 21 Sep 2016 17:42:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.537
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y-gjhRegFneX; Wed, 21 Sep 2016 17:42:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A0FDF12BC58; Wed, 21 Sep 2016 17:42:52 -0700 (PDT)
X-AuditID: 12074424-263ff70000004d93-c6-57e3290a2e04
Received: from ( []) (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 ( []) by (8.13.8/8.9.2) with ESMTP id u8M0gnC5013651; Wed, 21 Sep 2016 20:42:50 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (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 ( id u8M0ggqe017791; Wed, 21 Sep 2016 20:42:42 -0400 (EDT)
Date: Wed, 21 Sep 2016 20:42:42 -0400
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: "Black, David" <>
In-Reply-To: <>
Message-ID: <>
References: <> <>
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: <>
Cc: "" <>, "" <>, "" <>
Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-diffserv-intercon-09
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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:
>    This draft assumes that latter approach by defining additional DSCPs
>    that are known and expected at network interconnection interfaces.
>    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:
>    remarking in the absence of
>    additional agreement(s) when the MPLS Short Pipe model is used for
>    reasons explained in this document.
>    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.