[secdir] Secdir review of draft-ietf-pwe3-vccv-impl-survey-results-02

Alexey Melnikov <alexey.melnikov@isode.com> Sun, 08 September 2013 16:39 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21A621F830F; Sun, 8 Sep 2013 09:39:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.337
X-Spam-Level:
X-Spam-Status: No, score=-103.337 tagged_above=-999 required=5 tests=[AWL=-0.738, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4fRTiw-gmTk; Sun, 8 Sep 2013 09:39:11 -0700 (PDT)
Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 6050F21F8BE6; Sun, 8 Sep 2013 09:39:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1378658350; d=isode.com; s=selector; i=@isode.com; bh=evfUQMXCI/iwEtjqn7bkHO1aNu21CQJFEZEVaP5Cad4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ufIpuLKZ06wx1VaSOM6Sy0Y9oexBG3U/hMtlV+ZjKN7xipEDS08uxJjIlXL+tyCZuH7z41 SIO/geFAkCNDTbIR8B0CVM7SmYBTNgGIbL//2A88JrfbN8LkFgCb3m9k+PFUZCXQkClrfs 4wMvourbs4/Ue5r/zpa1ap+c3XAcW54=;
Received: from [192.168.0.4] (cpc5-nmal20-2-0-cust24.19-2.cable.virginmedia.com [92.234.84.25]) by statler.isode.com (submission channel) via TCP with ESMTPA id <UiyoKAA0846z@statler.isode.com>; Sun, 8 Sep 2013 17:39:10 +0100
Message-ID: <522CA828.1010103@isode.com>
Date: Sun, 08 Sep 2013 17:39:04 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
To: IESG <iesg@ietf.org>, draft-ietf-pwe3-vccv-impl-survey-results.all@tools.ietf.org, secdir@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [secdir] Secdir review of draft-ietf-pwe3-vccv-impl-survey-results-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sun, 08 Sep 2013 16:39:16 -0000

Hello,

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.

--

Most pseudowire Emulation Edge-to-Edge (PWE3) encapsulations mandate
the use of the Control Word (CW) to carry information essential to
the emulation, to inhibit Equal-Cost Multipath (ECMP) behavior, and
to discriminate Operations, Administration, and Maintenance (OAM)
from Pseudowire (PW) packets.  However, some encapsulations treat the
Control Word as optional.  As a result, implementations of the CW,
for encapsulations for which it is optional, vary by equipment
manufacturer, equipment model and service provider network.
Similarly, Virtual Circuit Connectivity Verification (VCCV) supports
three Control Channel (CC) types and multiple Connectivity
Verification (CV) Types.  This flexibility has led to reports of
interoperability issues within deployed networks and associated
drafts to attempt to remedy the situation.  This survey of the PW/
VCCV user community was conducted to determine implementation trends.
The survey and results are presented in this document.

As the document is a survey of what existing implementations do in this 
area, I agree with editors that it doesn't introduce new security concerns.
Editors also clarified that they took precautions to ensure the validity 
of the sample and the data, in particular they verified email addresses 
of respondents and that they are representing different companies, not 
including equipment vendors.
I don't have any concerns about security considerations for this document.

With no disrespect to document editors, the WG and the shepherding AD, I 
am however concerns that this document doesn't contain information that 
is useful for publishing as an RFC. I would be happy to be proven wrong 
on this.

Best Regards,
Alexey