Return-Path: 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)" To: Charlie Kaufman , "secdir@ietf.org" , "iesg@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: In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 15:52:25 -0000 --_000_C94CA15E15196andrewgmalisoneverizoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Charlie, On behalf of the WG, many thanks for your review and comments. Cheers, Andy On 1/7/11 0:15 , "Charlie Kaufman" wrote: **Please ignore previous version; I had a typo in an email address and draf= t 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 co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document specifies a standardized way of translating error notificatio= n codes between several different protocols. The need comes up in the conte= xt of using Pseudowire (PW) protocol to replace a physical link in a networ= k. Pseudowires replace physical wires imperfectly in that they can have mor= e complex failure modes. These can interact in complex ways with the failur= e modes of the protocols running over the pseudowires. There are no real security considerations in the code mappings. This docume= nt 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 d= iscussed 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 b= elow the higher layer protocol=92s ability to use it. An example would be a= link between two routers that should be declared down when it gets slow en= ough so that higher layers will find better routes. Even so, any such discu= ssion would belong in a different document. I=92d 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= =96 with almost no previous knowledge of the subject matter =96 to read an= d mostly understand most of the document. I wish such a thing could be made= mandatory for all RFCs. --Charlie --_000_C94CA15E15196andrewgmalisoneverizoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Re: RESEND: Secdir review of draft-ietf-pwe3-oam-msg-map-14.txt= 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 doc= ument as part of the security directorate's ongoing effort to review all IE= TF documents being processed by the IESG.  These comments were written= primarily for the benefit of the security area directors.  Document e= ditors and WG chairs should treat these comments just like any other last c= all comments.
 
This document specifies a standardized way of translating error notificatio= n codes between several different protocols. The need comes up in the conte= xt of using Pseudowire (PW) protocol to replace a physical link in a networ= k. Pseudowires replace physical wires imperfectly in that they can have mor= e complex failure modes. These can interact in complex ways with the failur= e modes of the protocols running over the pseudowires.
 
There are no real security considerations in the code mappings. This docume= nt 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 d= iscussed 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 b= elow the higher layer protocol=92s ability to use it. An example would be a= link between two routers that should be declared down when it gets slow en= ough so that higher layers will find better routes. Even so, any such discu= ssion would belong in a different document.
 
I=92d 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= =96 with almost no previous knowledge of the subject matter =96 to read an= d mostly understand most of the document. I wish such a thing could be made= mandatory for all RFCs.
 
            &nb= sp;   --Charlie

--_000_C94CA15E15196andrewgmalisoneverizoncom_--