[secdir] secdir review of draft-ietf-l3vpn-mvpn-considerations-06

scott@hyperthought.com Mon, 08 March 2010 19:25 UTC

Return-Path: <scott@hyperthought.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA5743A6B50 for <secdir@core3.amsl.com>; Mon, 8 Mar 2010 11:25:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1s8tm6UjEOk for <secdir@core3.amsl.com>; Mon, 8 Mar 2010 11:25:42 -0800 (PST)
Received: from smtp222.iad.emailsrvr.com (smtp222.iad.emailsrvr.com [207.97.245.222]) by core3.amsl.com (Postfix) with ESMTP id C5C473A69EA for <secdir@ietf.org>; Mon, 8 Mar 2010 11:25:42 -0800 (PST)
Received: from relay12.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay12.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 8295E20D39C; Mon, 8 Mar 2010 14:25:46 -0500 (EST)
Received: from dynamic1.wm-web.iad.mlsrvr.com (dynamic1.wm-web.iad.mlsrvr.com [192.168.2.150]) by relay12.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 66D7520D05A; Mon, 8 Mar 2010 14:25:46 -0500 (EST)
Received: from hyperthought.com (localhost [127.0.0.1]) by dynamic1.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id 3FAFDC98070; Mon, 8 Mar 2010 14:25:46 -0500 (EST)
Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Mon, 8 Mar 2010 11:25:46 -0800 (PST)
Date: Mon, 8 Mar 2010 11:25:46 -0800 (PST)
From: scott@hyperthought.com
To: draft-ietf-l3vpn-mvpn-considerations-06.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-Type: plain
Message-ID: <1268076346.258521810@192.168.2.227>
X-Mailer: webmail7.0
Subject: [secdir] secdir review of draft-ietf-l3vpn-mvpn-considerations-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Mon, 08 Mar 2010 19:25:43 -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 defines a set of mandatory-to-implement features for L3 mcast BGP/MPLS VPN implementations, with the underlying motivation being that due to the current lack of a minimal necessary and sufficient set of mandatory features, currently deployed implementations may be compliant, yet not interoperate. 

I think the security ADs will want to pay attention to this document. The security considerations section is very brief:

  "This document does not by itself raise any particular security
   considerations."

After reading this, I was surprised to find a page-and-a-half discussion earlier in the document entitled "3.3.5  Security and robustness". This section seems to indicate that there *are* security considerations, although the section could really use some editorial attention. 

I would suggest a couple of things: first, thoroughly review 3.3.5 to ensure that it is complete. Second, try to make this section more intelligible. For example, here is the first paragraph:

   BGP supports MD5 authentication of its peers for additional security,
   thereby possibly benefit directly to multicast VPN customer multicast
   routing, whether for intra-AS or inter-AS communications.  By
   contrast, with a PIM-based approach, no mechanism providing a
   comparable level of security to authenticate communications between
   remote PEs has been yet fully described yet
   [I-D.ietf-pim-sm-linklocal][], and in any case would require
   significant additional operations for the provider to be usable in a
   multicast VPN context.

I've read this several times, yet I still have no idea what this is meant to communicate.

Third, it wouldn't hurt to refer the reader to other places where relevant security requirements are already discussed (e.g., RFC4834).

--Scott