[secdir] secdir review of draft-ietf-rtgwg-cl-requirement-10

Tom Yu <tlyu@MIT.EDU> Thu, 20 June 2013 03:58 UTC

Return-Path: <tlyu@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 5226B11E80F4; Wed, 19 Jun 2013 20:58:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nxow8ws1GZEr; Wed, 19 Jun 2013 20:58:26 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0A62311E80F6; Wed, 19 Jun 2013 20:58:25 -0700 (PDT)
X-AuditID: 1209190f-b7fa58e000000953-12-51c27de1f28c
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id A2.AE.02387.1ED72C15; Wed, 19 Jun 2013 23:58:25 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id r5K3wOvj005984; Wed, 19 Jun 2013 23:58:24 -0400
Received: from cathode-dark-space.mit.edu (cathode-dark-space.mit.edu [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r5K3wLL3020491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Jun 2013 23:58:23 -0400
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r5K3wL4j024735; Wed, 19 Jun 2013 23:58:21 -0400 (EDT)
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org
From: Tom Yu <tlyu@MIT.EDU>
Date: Wed, 19 Jun 2013 23:58:21 -0400
Message-ID: <ldvbo71v3fm.fsf@cathode-dark-space.mit.edu>
Lines: 30
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsUixG6nrvuw9lCgwduLihY7urQtZvyZyGzx YeFDFgdmjyVLfjJ5fLn8mS2AKYrLJiU1J7MstUjfLoEro+/iZfaCPTwVlz6eYWlgXMbVxcjB ISFgIjHpc3YXIyeQKSZx4d56ti5GLg4hgX2MEltOt7CBJIQENjJKrF8eDZE4xyRxYtdqFgin i1FiystL7CBVIgLxEr86+8BsYQEbiS/X5rKCbGATkJY4urgMJMwioCrxbW4LO0iYV8BC4sDX ApAwjwCnxKOzl5lAbF4BQYmTM5+wgNjMAloSN/69ZJrAyDcLSWoWktQCRqZVjLIpuVW6uYmZ OcWpybrFyYl5ealFuiZ6uZkleqkppZsYQUHGKcm/g/HbQaVDjAIcjEo8vBqXDwYKsSaWFVfm HmKU5GBSEuW9WHEoUIgvKT+lMiOxOCO+qDQntfgQowQHs5IIb0IqUI43JbGyKrUoHyYlzcGi JM4rdmtnoJBAemJJanZqakFqEUxWhoNDSYL3TQ1Qo2BRanpqRVpmTglCmomDE2Q4D9DwTyA1 vMUFibnFmekQ+VOMilLivAdBEgIgiYzSPLheWBJ4xSgO9Iow70+QKh5gAoHrfgU0mAlosND3 fSCDSxIRUlINjGy3HJdnzomRFPgs8uPplkrnwOwFrv+dpij7TrUqNPvnyLSl0lemTPTqgZpX W74eOfHRZMNC7SDuV6tETQWtN4Uan/m684/bqSqZjTLxjDkNUY0REj9P5mR0WnxQMuORUBc5 m7raJMT/hM7/WaqJvKaT43ZNUe1cfeVLgV/4361ffu76LsrEq8RSnJFoqMVcVJwIAAobFS/d AgAA
Subject: [secdir] secdir review of draft-ietf-rtgwg-cl-requirement-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 20 Jun 2013 03:58:34 -0000

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 document states many requirements on properties of proposed
solutions, but it seems that none of these requirements is a security
requirement.  If nodes need to send new information that existing
routing or signaling protocols do not currently send, what level of
protection does that information require?

In the Security Considerations section, I'm not sure what the intent
is in using the phrasing "man-in-the-middle confidentiality breach".
I generally consider "man-in-the-middle" to mean an active attacker
(one that can receive, suppress, modify, and transmit arbitrary data);
this type of attacker primarily has consequences for integrity.  (An
active attacker could also compromise the confidentiality of a channel
that is secure against passive attackers).  A passive attack is often
sufficient to compromise confidentiality, especially if a protocol
sends information in the clear.

What scope of compromise does "provider breach" designate?

Editorial:

This document uses many acronyms without expanding them -- almost all
of them, from what I can see.  Some of the more prominent ones include
DSCP, LDP, LSP, PW, RSVP-TE.  Arguably terms such as MPLS, VLAN, and
VPN count as well-known acronyms in the IETF community.