[secdir] Secdir review of draft-ietf-l3vpn-virtual-hub-06

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Wed, 26 June 2013 15:52 UTC

Return-Path: <jsalowey@cisco.com>
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 539DA21E8087; Wed, 26 Jun 2013 08:52:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 tC-szk5kXfIA; Wed, 26 Jun 2013 08:52:00 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B2EA121F991F; Wed, 26 Jun 2013 08:52:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=890; q=dns/txt; s=iport; t=1372261920; x=1373471520; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Ms2KfbjWvSadEI9w2cx2tPpbjGzpkPTHToTKcttRAWk=; b=Xyx2v8qFJDU6GPB8I3O2UdHuAkU+LHfxmQ0Qr8nGR1Hmqox9b8TG4I6x 7I4nBsL0gd14KbgnYZ/9rdPo3C2G0XGboBnE0UDCfKMRLAgGiDUN/pVgv 8XkTrmEkVCykxZp9DxIsw55xaJxEuasp5oq7D7Qdb1Is8rTEHIUdD0oZt E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAAoNy1GtJV2d/2dsb2JhbABagwl6vn2BARZ0giUBBDpRASoUQicEARqIBro+jxqDOmEDqQqDEYIo
X-IronPort-AV: E=Sophos;i="4.87,945,1363132800"; d="scan'208";a="227796941"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 26 Jun 2013 15:52:00 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5QFq0oY029947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Jun 2013 15:52:00 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Wed, 26 Jun 2013 10:51:59 -0500
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-l3vpn-virtual-hub.all@tools.ietf.com" <draft-ietf-l3vpn-virtual-hub.all@tools.ietf.com>, "<iesg@ietf.org> IESG" <iesg@ietf.org>
Thread-Topic: Secdir review of draft-ietf-l3vpn-virtual-hub-06
Thread-Index: AQHOcoUXnQzzTkLyh0ixcnNbf10m9A==
Date: Wed, 26 Jun 2013 15:51:59 +0000
Message-ID: <A95B4818FD85874D8F16607F1AC7C628D199F9@xmb-rcd-x09.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.33.248.222]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1657B00FDCF8DA488E9EBB7795BC8DA5@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [secdir] Secdir review of draft-ietf-l3vpn-virtual-hub-06
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: Wed, 26 Jun 2013 15:52:06 -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.

The document describes a hub and spoke topology for BGP/MPLS VPNs.  The security considerations refer to RFC4364.   While I share the concern in Stephen's Comment, I have thought about it a bit and have not come up with significant  recommendations that are not covered in RFC4364.   The document does discuss multicast routing a bit so I'm wondering if it should also reference the security considerations in RFC 6513 and/or RFC 6514. 

Aside from this comment I think the document is ready to go.   

Cheers,

Joe