[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/>
- [secdir] secdir review of draft-ietf-l3vpn-2547bi… Juergen Schoenwaelder