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
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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
Precedence: list

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 additio=
n, in thinking about this, I realized that there are aspects of the encapsu=
lation 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 timin=
g requirements in Section 5 sufficient to take down an FC PW link in a fash=
ion 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=A0 01748
+1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778=
6
david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 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
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> Thanks,
>=20
> Steve Hanna
>=20