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

Benjamin Kaduk <kaduk@MIT.EDU> Wed, 14 September 2016 03:55 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9D37612B19A; Tue, 13 Sep 2016 20:55:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.709
X-Spam-Status: No, score=-5.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id VpK7uYMZ3mhH; Tue, 13 Sep 2016 20:55:23 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu []) (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 77D0312B1AF; Tue, 13 Sep 2016 20:55:22 -0700 (PDT)
X-AuditID: 1209190f-58fff70000006995-9c-57d8ca29bd7d
Received: from mailhub-auth-1.mit.edu ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 57.67.27029.92AC8D75; Tue, 13 Sep 2016 23:55:21 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu []) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u8E3tKda010075; Tue, 13 Sep 2016 23:55:21 -0400
Received: from multics.mit.edu (system-low-sipb.mit.edu []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u8E3tHA2021260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Sep 2016 23:55:20 -0400
Received: (from kaduk@localhost) by multics.mit.edu ( id u8E3tHaT014301; Tue, 13 Sep 2016 23:55:17 -0400 (EDT)
Date: Tue, 13 Sep 2016 23:55:17 -0400
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-tsvwg-diffserv-intercon@MIT.EDU
Message-ID: <alpine.GSO.1.10.1609132324180.5272@multics.mit.edu>
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+NgFtrJIsWRmVeSWpSXmKPExsUixCmqrKt56ka4wbJpKhYz/kxktviw8CGL A5PHkiU/mQIYo7hsUlJzMstSi/TtErgy7rRuYStYIVdx6u16xgbGmxJdjJwcEgImEhfuvWbr YuTiEBJoY5L40X+GFcLZyCix9uEMKOcQk8ST9sfMEE4Do8S9qV+YQfpZBLQldjW3s4HYbAIq EjPfbASzRQT8JGZf+w9WIyxgL/G3ZzlYnFfAQaL5yVZGEFtUQEdi9f4pLBBxQYmTM5+A2cwC WhLLp29jmcDIOwtJahaS1AJGplWMsim5Vbq5iZk5xanJusXJiXl5qUW6Jnq5mSV6qSmlmxjB ISTJv4NxToP3IUYBDkYlHt6AH9fDhVgTy4orcw8xSnIwKYny9vrfCBfiS8pPqcxILM6ILyrN SS0+xCjBwawkwit/CCjHm5JYWZValA+TkuZgURLn7ZpxIFxIID2xJDU7NbUgtQgmK8PBoSTB K38SqFGwKDU9tSItM6cEIc3EwQkynAdoOD9IDW9xQWJucWY6RP4Uo6KUOG84SEIAJJFRmgfX C47x3UyqrxjFgV4R5hUGqeIBpge47ldAg5mABm9Zcx1kcEkiQkqqgbGsYobvzYeVEfbym1OW dzP6Oqzcn1t5/77nr80367mlbkxddaL9stzNvg7FXbaqW0xSFr6ZwDKRifP5l2PPTJ7NnK5z 3znCfmnNh5pde/6qy2xsP2yxvvLUz02bIr/cXff4q9/2v0mzdjy3dl5T27Ij+EPR8ic/Kw6b WYq+YLJ6GMa5ksVdZcEOJZbijERDLeai4kQA056SS8wCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/ExObpc3QunwOzE5bxGxT7ngIJ7Q>
Subject: [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: Wed, 14 Sep 2016 03:55:25 -0000

Hi all,

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.

This draft is Ready.

I had to do some background reading (RFC 2475, mostly, and skimming some
other references) to really understand what's going on here; I'll probably
use some wrong terminology as a result. This draft describes a standard
set of 4 Treatment Aggregates that can be used by MPLS networks using the
Short-Pipe tunnel mode to preserve IP Differentiated Service code point
markings and the corresponding per-hop behaviors as traffic traverses the
network boundary.  DSCP translation is expected to be done both at entry
and exit from the network (as applicable; not all traffic is through
traffic, of course) betwen the standard DSCPs and network-internal DSCPs
used to apply PHBs, but the benfit of this scheme is the standardized
interface, much as how it is easier for a user to accept a two-clause BSD
software license that is well-known than it is for that user to accept a
software EULA that was custom written by a company's lawyers.  Otherwise,
everything described in this document could be done already by two peered
networks that negotiate an SLA.  With this document, they still must
negotiate an SLA, but there are standard terms to simplify the process.

The security considerations accordingly note (correctly) that this
document does not introduce new features; rather, it describes how to use
existing ones.  It refers to the security considerations in RFCs 2475 and
4594, which seem to be complete, noting that differentiated services
introduce the possibility of fasely marked/prioritized traffic and the
potential for denial of service.  Only calling out IPsec as the example is
a bit dated, but the general principles still seem fine -- the physical
network has to be protected and traffic sanitized on entry.

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.

A few editorial comments follow:

Please expand PHBs in the abstract, not just in the introduction

Introduction, first paragraph, space between ')' and 'and'.
Just a few words later, is it clearer to s/at/for use at/?

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.

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

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.

Section 4, Telephony Service Treatment Aggregate, it looks like the
convention would have the DSCP be formatted as "101 100" with a space.