[secdir] secdir review of draft-ietf-tsvwg-diffserv-intercon-09
Benjamin Kaduk <kaduk@MIT.EDU> Wed, 14 September 2016 04:00 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 C75AF12B19A; Tue, 13 Sep 2016 21:00:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.729
X-Spam-Level:
X-Spam-Status: No, score=-5.729 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=-1.508, 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 8lKhbhW1LBmD; Tue, 13 Sep 2016 21:00:54 -0700 (PDT)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 A94BB12B1B1; Tue, 13 Sep 2016 21:00:50 -0700 (PDT)
X-AuditID: 1209190d-ec7ff700000035fe-12-57d8cb7156cb
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 94.19.13822.17BC8D75; Wed, 14 Sep 2016 00:00:49 -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 u8E40mNT010535; Wed, 14 Sep 2016 00:00:49 -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 u8E40jpC022606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Sep 2016 00:00:48 -0400
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u8E40jS3014989; Wed, 14 Sep 2016 00:00:45 -0400 (EDT)
Date: Wed, 14 Sep 2016 00:00:44 -0400
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-tsvwg-diffserv-intercon@ietf.org
Message-ID: <alpine.GSO.1.10.1609132359590.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+NgFtrHIsWRmVeSWpSXmKPExsUixCmqrFt4+ka4wdp3yhZP1v1gs5jxZyKz xYeFD1kcmD2WLPnJFMAYxWWTkpqTWZZapG+XwJXR0biQteCtXMXOdwdZGxgnSXYxcnJICJhI LLiznr2LkYtDSKCNSWLp435GCGcjo0T73mVQmUNMEjd6P7BBOA2MEo/unGQF6WcR0JZoe7IP zGYTUJGY+WYjG4gtIhAhsXZiH1hcWMBe4m/PcrA4r4CDxKMVG5lBbFEBHYnV+6ewQMQFJU7O fAJmMwtoSSyfvo1lAiPvLCSpWUhSCxiZVjHKpuRW6eYmZuYUpybrFicn5uWlFuka6eVmluil ppRuYgQHkyTvDsZ/d70OMQpwMCrx8Ab8uB4uxJpYVlyZe4hRkoNJSZS31/9GuBBfUn5KZUZi cUZ8UWlOavEhRgkOZiUR3p8ngXK8KYmVValF+TApaQ4WJXHerhkHwoUE0hNLUrNTUwtSi2Cy MhwcShK8DaeAGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGHwQbXlyQmFucmQ6RP8WoKCXOGw6SEABJ ZJTmwfWCo303k+orRnGgV4R594Ks4AEmCrjuV0CDmYAGb1lzHWRwSSJCSqqBsTrhT1rqiTiz i8t33tIV3rhzBlt30W1HBTvuvMPP4st28nxuLufmrl44h9vS4nvfpsrtJdEGmbMjX55+F+jG v/msn8M+twKmifd/JfneneqsXqv48shlTWOPyZNn6L1599Js5QONcxdjOntv7+ieY32n/5ux 6ZuslIJWEfdrmwU1dkzaPJXtlhJLcUaioRZzUXEiAL+Ma/vRAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/eXkqxr9NM--suCq3mbLZUqHr2uM>
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 04:00:56 -0000
[re-sending with proper recipients list; sorry for the duplicate] 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. -Ben
- [secdir] secdir review of draft-ietf-tsvwg-diffse… Benjamin Kaduk
- [secdir] secdir review of draft-ietf-tsvwg-diffse… Benjamin Kaduk
- Re: [secdir] secdir review of draft-ietf-tsvwg-di… Black, David
- Re: [secdir] secdir review of draft-ietf-tsvwg-di… Benjamin Kaduk