[secdir] secdir review of draft-ietf-l3vpn-2547bis-mcast-08

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Thu, 17 September 2009 14:11 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 06B9E3A6B3A; Thu, 17 Sep 2009 07:11:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.096
X-Spam-Level:
X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[AWL=-0.936, BAYES_05=-1.11, HELO_EQ_DE=0.35, J_CHICKENPOX_53=0.6]
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 P45FSLflA8Ro; Thu, 17 Sep 2009 07:11:25 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A2EE03A6A9C; Thu, 17 Sep 2009 07:11:23 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E391EC0047; Thu, 17 Sep 2009 16:12:05 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id H6i77gmbySti; Thu, 17 Sep 2009 16:12:04 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7D8E6C0063; Thu, 17 Sep 2009 16:11:58 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id BB7C6CB9230; Thu, 17 Sep 2009 16:11:56 +0200 (CEST)
Date: Thu, 17 Sep 2009 16:11:56 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: rahul@juniper.net, erosen@cisco.com
Message-ID: <20090917141156.GC7271@elstar.local>
Mail-Followup-To: rahul@juniper.net, erosen@cisco.com, iesg@ietf.org, secdir@ietf.org, l3vpn-chairs@tools.ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: l3vpn-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: [secdir] secdir review of draft-ietf-l3vpn-2547bis-mcast-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
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: Thu, 17 Sep 2009 14:11:26 -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.

First of all, let me state that I did not do a detailed review of the
document. The ID is ~90 pages and depends on another twin ID (~60
pages)and they again depend on some other RFCs of some 30 pages each
and since I am not deeply involved in BGP/MPLS VPNs it would have
taken me days to do a detailed review. So I ended up trying to
understand what the document is about and then making sense of the
security considerations section. Here is what I found:

a) p90: I assume 2547 means RFC 2547, so

   s/of 2547 VPNs/of RFC 2547 VPNs/

   but then I checked and RFC 2547 has been obsoleted by RFC 4364
   so probably this should be

   s/of 2547 VPNs/of RFC 4364 VPNs/

b) p91: missing opening bracket

   s/BGP MVPN-BGP]/BGP [MVPN-BGP]/

c) p91: double "as"

   s/techniques as as/techniques as/

d) The paragraph talking about P-tunnel construction should probably
   be using stronger MUST language, e.g.

   [...] P or PE router receiving a control MUST ensure that the
   control message comes from another P or PE router, not from a CE
   router.

   Right now, I find the message of the paragraph somewhat unclear.

e) I am wondering why "should not allow" is used in the discussion of
   extending multicast distribution trees. Perhaps some text can be
   added under which circumstances it makes sense to configure the
   ASBR to allow this and which risks this involves. (Perhaps this
   just shows my ignorance. ;-)

/js


-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>