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

Stewart Bryant <stbryant@cisco.com> Fri, 07 January 2011 10:31 UTC

Return-Path: <stbryant@cisco.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 D32A43A6816; Fri, 7 Jan 2011 02:31:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.537
X-Spam-Level:
X-Spam-Status: No, score=-110.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 efwD6h3IJQ+L; Fri, 7 Jan 2011 02:31:39 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B64E13A680F; Fri, 7 Jan 2011 02:31:39 -0800 (PST)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAG56Jk1AZnwN/2dsb2JhbACkJXOkGoJQDgGVTIVMBIsJ
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 07 Jan 2011 10:33:46 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p07AXjw9002816; Fri, 7 Jan 2011 10:33:45 GMT
Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p07AXa822305; Fri, 7 Jan 2011 10:33:43 GMT
Message-ID: <4D26EC00.4060904@cisco.com>
Date: Fri, 07 Jan 2011 10:33:36 +0000
From: Stewart Bryant <stbryant@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: Charlie Kaufman <charliek@microsoft.com>
References: <D80EDFF2AD83E648BD1164257B9B09122C2F151A@TK5EX14MBXC115.redmond.corp.microsoft.com>
In-Reply-To: <D80EDFF2AD83E648BD1164257B9B09122C2F151A@TK5EX14MBXC115.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "draft-ietf-pwe3-oam-msg-map.all@tools.ietf.org" <draft-ietf-pwe3-oam-msg-map.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
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
Reply-To: stbryant@cisco.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: Fri, 07 Jan 2011 10:31:41 -0000

Hi Charlie

Thank you for the review.
>
> 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.
>

The issue of capacity and congestion has been the subject of 
longstanding discussion with the Transport Area. There is text in the PW 
framework RFCs on topics similar to those that you highlight above.

The problem is substantially mitigated by the fact that PW are usually 
deployed as part of a service provider offering and are thus subject to 
capacity planing and reliability network engineering considerations, and 
are likely to be monitored by the provider.

Regards

Stewart