Re: [secdir] RESEND: Secdir review of draft-ietf-pwe3-oam-msg-map-14.txt

"Malis, Andrew G. (Andy)" <andrew.g.malis@verizon.com> Fri, 07 January 2011 15:52 UTC

Return-Path: <andrew.g.malis@verizon.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 05AB33A6919; Fri, 7 Jan 2011 07:52:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.837
X-Spam-Level:
X-Spam-Status: No, score=-2.837 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 8OM6M-Q4C-KB; Fri, 7 Jan 2011 07:52:23 -0800 (PST)
Received: from tpamail4.verizon.com (tpamail4.verizon.com [192.76.82.161]) by core3.amsl.com (Postfix) with ESMTP id A72BF3A6905; Fri, 7 Jan 2011 07:52:23 -0800 (PST)
Received: from tpaintrmemf3.verizon.com (tpaintrmemf3.verizon.com [138.83.67.58]) by tpamail4.verizon.com (8.13.6/8.13.3) with ESMTP id p07FmDUH017377; Fri, 7 Jan 2011 10:48:22 -0500 (EST)
X-AuditID: 8a53433a-b7b57ae0000011e0-1c-4d273730d229
Received: from smtptpa4.verizon.com ( [138.83.71.177]) by tpaintrmemf3.verizon.com (EMF) with SMTP id 21.8D.04576.037372D4; Fri, 7 Jan 2011 10:54:24 -0500 (EST)
Received: from FHDP1LUMXC7HB02.us.one.verizon.com (fhdp1lumxc7hb02.verizon.com [166.68.59.189]) by smtptpa4.verizon.com (8.13.3/8.13.3) with ESMTP id p07FsNX9017584; Fri, 7 Jan 2011 10:54:23 -0500 (EST)
Received: from fhdp1lumxc7v22.us.one.verizon.com ([fe80::30d0:a653:fa92:eedb]) by FHDP1LUMXC7HB02.us.one.verizon.com ([2002:a644:3bbd::a644:3bbd]) with mapi; Fri, 7 Jan 2011 10:54:23 -0500
From: "Malis, Andrew G. (Andy)" <andrew.g.malis@verizon.com>
To: Charlie Kaufman <charliek@microsoft.com>, "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-pwe3-oam-msg-map.all@tools.ietf.org" <draft-ietf-pwe3-oam-msg-map.all@tools.ietf.org>
Date: Fri, 7 Jan 2011 10:54:22 -0500
Thread-Topic: RESEND: Secdir review of draft-ietf-pwe3-oam-msg-map-14.txt
Thread-Index: AcuuKd9EKwp+v9B5SwSfHxd1LFfVUgAWUc4a
Message-ID: <C94CA15E.15196%andrew.g.malis@one.verizon.com>
In-Reply-To: <D80EDFF2AD83E648BD1164257B9B09122C2F151A@TK5EX14MBXC115.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-Entourage/13.8.0.101117
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C94CA15E15196andrewgmalisoneverizoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Fri, 07 Jan 2011 08:40:55 -0800
Subject: Re: [secdir] RESEND: Secdir review of draft-ietf-pwe3-oam-msg-map-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: Fri, 07 Jan 2011 15:52:25 -0000

Charlie,

On behalf of the WG, many thanks for your review and comments.

Cheers,
Andy

On 1/7/11 0:15 , "Charlie Kaufman" <charliek@microsoft.com>; wrote:

**Please ignore previous version; I had a typo in an email address and draft name. **

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 specifies a standardized way of translating error notification codes between several different protocols. The need comes up in the context of using Pseudowire (PW) protocol to replace a physical link in a network. Pseudowires replace physical wires imperfectly in that they can have more complex failure modes. These can interact in complex ways with the failure modes of the protocols running over the pseudowires.

There are no real security considerations in the code mappings. This document references the security considerations sections of other RFCs where the translated error codes are handled. This seems appropriate.

The only thing that came to my mind that relates to security that was not discussed was emergent errors, where the pseudowire could introduce an error not detectable at its endpoints that could nevertheless cause problems at a higher layer. Examples would be a pseudowire that duplicated, selectively lost, or reordered packets. There are also interesting problems to be had where the pseudowire capacity is variable and its carrying capacity falls below the higher layer protocol’s ability to use it. An example would be a link between two routers that should be declared down when it gets slow enough so that higher layers will find better routes. Even so, any such discussion would belong in a different document.

I’d like to express my great appreciation for Section 4.1, which expands almost all of the acronyms used in the document. It made it possible for me – with almost no previous knowledge of the subject matter – to read and mostly understand most of the document. I wish such a thing could be made mandatory for all RFCs.

                --Charlie