Re: [secdir] secdir review of draft-ietf-ccamp-gmpls-ethernet-pbb-te-06.txt
Adrian Farrel <Adrian.Farrel@huawei.com> Mon, 04 October 2010 15:50 UTC
Return-Path: <Adrian.Farrel@huawei.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 241033A6CE1; Mon, 4 Oct 2010 08:50:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.433
X-Spam-Level:
X-Spam-Status: No, score=-102.433 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100]
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 pX4BTdxvlPGw; Mon, 4 Oct 2010 08:50:53 -0700 (PDT)
Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id B026A3A6C9D; Mon, 4 Oct 2010 08:50:52 -0700 (PDT)
Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9R00JFJW27QM@usaga01-in.huawei.com>; Mon, 04 Oct 2010 08:51:43 -0700 (PDT)
Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L9R00A5BW24EL@usaga01-in.huawei.com>; Mon, 04 Oct 2010 08:51:43 -0700 (PDT)
Date: Mon, 04 Oct 2010 16:51:29 +0100
From: Adrian Farrel <Adrian.Farrel@huawei.com>
To: "Fedyk, Donald (Don)" <donald.fedyk@alcatel-lucent.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, iesg@ietf.org, secdir@ietf.org, draft-ietf-ccamp-gmpls-ethernet-pbb-te.all@tools.ietf.org
Message-id: <7B88DDE4B8FF4613B501B2CD57DE5424@your029b8cecfe>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5994
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
Content-type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <20101003173341.GA16738@elstar.local> <D3F33DCB7804274A890F9215F86616580AC958A70E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com>
Subject: Re: [secdir] secdir review of draft-ietf-ccamp-gmpls-ethernet-pbb-te-06.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Adrian Farrel <Adrian.Farrel@huawei.com>
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, 04 Oct 2010 15:50:54 -0000
Additions in-line... --- 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. I have reviewed -05 and my editorial comments have been addressed in the -06 version. My other comments have apparently not been acted on nor did I receive any response from the authors. The comments were: Security wise, this document essentially refers to other documents, namely RFC 4872 amd RFC 4873. These documents again refer to other documents and ultimately to IPsec as a security solution. If this is correct, perhaps this could be made clearer so people like me do not have to recursively resolve security considerations to find out how things are protected. [DF] This is correct. This is also the way we have documented for some time with many documents referring backwards. Ultimately for control plane it comes down to some form restricted access/private networks or some mechanism such as IPSec to protect public exposed portions of signaling. [AF] I believe that RFC 5920 provides the global view that Juergen is looking for, and is referenced from the Security Section. The security considerations of this document also refer to 802.1AE Media Access Control Security for the protection of "transport" Ethernet. It is not clear what "transport" Ethernet is, perhaps it is the Ethernet traffic carried over the paths. If my interpretation is correct, I would argue that this pointer does not really belong into the security considerations of this document since this specification deals with a part of the signaling plane, not the data plane. [DF] transport Ethernet is a term that we use to describe Ethernet technologies that offer similar service typically associated with L1 transport networks (OAM (monitoring, tracing, integrity checking, fault signaling), protection switching). PBB-TE is one type of transport Ethernet. MACSEC can be used between the elements of the Ethernet network providing transport. If signaling is inland then MACSEC could be providing part of the security for the signaling. If the signaling is out of band over other technologies then IPSEC or other may ultimately be providing protection. [AF] The term and concept are discussed in draft-ietf-ccamp-gmpls-ethernet-arch. Maybe a reference could be inserted? Section 5 states that "configuration should be consistent". What happens security wise if configuration is not consistent? This might deserve some discussion in the security considerations. [DF] When configuration is not consistent it is normal for the connection simply not to come up. The dual ended nature of the configuration requires the source must match the destination. This draft is currently is covering PBB-TE which is defined for a single administrative domain so the result of the misconnection is that the signaling will report some form of failure through the management plane. [DF] In my opinion these items have been covered at a level that is consistent with GMPLS documents in the past but if there additional text or clarification we need on any of these points please indicate and I will work with the authors, chairs and ADs to correct. Regards, Don /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-ccamp-gmpls-… Juergen Schoenwaelder
- Re: [secdir] secdir review of draft-ietf-ccamp-gm… Adrian Farrel
- Re: [secdir] secdir review of draft-ietf-ccamp-gm… Fedyk, Donald (Don)