Re: [secdir] secdir review of draft-ietf-pwe3-fc-encap-14.txt

<david.black@emc.com> Thu, 24 February 2011 22:42 UTC

Return-Path: <david.black@emc.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 AEE313A6867; Thu, 24 Feb 2011 14:42:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.499
X-Spam-Level:
X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 8gp74bT20Czq; Thu, 24 Feb 2011 14:42:21 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 7C8303A687B; Thu, 24 Feb 2011 14:42:21 -0800 (PST)
Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1OMhBfT006955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Feb 2011 17:43:11 -0500
Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Thu, 24 Feb 2011 17:43:03 -0500
Received: from mxhub10.corp.emc.com (mxhub10.corp.emc.com [10.254.92.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1OMevUA024863; Thu, 24 Feb 2011 17:40:58 -0500
Received: from mx14a.corp.emc.com ([169.254.1.143]) by mxhub10.corp.emc.com ([10.254.92.105]) with mapi; Thu, 24 Feb 2011 17:40:57 -0500
From: <david.black@emc.com>
To: <shanna@juniper.net>, <secdir@ietf.org>, <iesg@ietf.org>
Date: Thu, 24 Feb 2011 17:40:55 -0500
Thread-Topic: secdir review of draft-ietf-pwe3-fc-encap-14.txt
Thread-Index: AcvR2J79mnoqbMWXRHiAcNAfdrQddACmmx3A
Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E03E5B1BE7F@MX14A.corp.emc.com>
References: <AC6674AB7BC78549BB231821ABF7A9AE970E6E1FE2@EMBX01-WF.jnpr.net>
In-Reply-To: <AC6674AB7BC78549BB231821ABF7A9AE970E6E1FE2@EMBX01-WF.jnpr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
X-Mailman-Approved-At: Thu, 03 Mar 2011 07:34:33 -0800
Cc: david.black@emc.com, draft-ietf-pwe3-fc-encap@tools.ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-pwe3-fc-encap-14.txt
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: Thu, 24 Feb 2011 22:42:22 -0000

Steve,

Thanks for reviewing this draft.

> At least, the authors should add a reference to a document
> that describes the attacks to which this protocol is susceptible
> and the countermeasures that can be employed.

Sure, I'll start with references to the security considerations sections of RFC 3985 (PWE3 Architecture) and RFC 4385 (PWE3 Control Word).  In addition, in thinking about this, I realized that there are aspects of the encapsulation that aren't covered by either the PWE3 or FC security material - for example, an attacker who can inject delay can cause violation of the timing requirements in Section 5 sufficient to take down an FC PW link in a fashion that it will stay down (countermeasure to that is delay monitoring via OAM functionality).  I'll add at least that.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Stephen Hanna [mailto:shanna@juniper.net]
> Sent: Monday, February 21, 2011 10:04 AM
> To: secdir@ietf.org; iesg@ietf.org
> Cc: draft-ietf-pwe3-fc-encap@tools.ietf.org
> Subject: secdir review of draft-ietf-pwe3-fc-encap-14.txt
> 
> 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 describes how Fibre Channel traffic can be carried
> over MPLS networks using a Fibre Channel pseudowire (FC PW). I am
> not an expert in Fibre Channel, MPLS, or pseudowires so I will not
> venture any judgment on the content of the draft. I will focus
> exclusively on the Security Considerations section.
> 
> The Security Considerations section is rather brief, only five
> sentences long. While I support brevity, this section seems to
> omit key information. For example, the text says "FC PW shares
> susceptibility to a number of pseudowire-layer attacks and
> implementations SHOULD use whatever mechanisms for confidentiality,
> integrity, and authentication are developed for PWs in general.
> These methods are beyond the scope of this document." That's too
> brief. At least, the authors should add a reference to a document
> that describes the attacks to which this protocol is susceptible
> and the countermeasures that can be employed. If no such document
> exists, either it should be written or this document should describe
> the threats and countermeasures or this document should admit that
> the threats and countermeasures are not understood at this time.
> You can't just leave the analysis of threats and countermeasures
> to the reader.
> 
> Thanks,
> 
> Steve Hanna
>