[secdir] secdir review of draft-li-pwe3-ms-pw-pon-04

Glen Zorn <glenzorn@gmail.com> Sun, 28 August 2011 12:37 UTC

Return-Path: <glenzorn@gmail.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 6E42921F883A; Sun, 28 Aug 2011 05:37:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.549
X-Spam-Level:
X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 PC7Xa2C2cacu; Sun, 28 Aug 2011 05:37:24 -0700 (PDT)
Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id C3CA021F8770; Sun, 28 Aug 2011 05:37:24 -0700 (PDT)
Received: by pzk33 with SMTP id 33so16178040pzk.18 for <multiple recipients>; Sun, 28 Aug 2011 05:38:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=RxZ+3PUPsbtc5KAqEiT4x7aDyj0v1iLsGUgbkCmMCKo=; b=ShUHesxsIQSseh4ZONXLFwajgJDfY2FpdXTKsXsOcVVQpfCBxZRuCVutmddqsRkoEn RE9KqImPgtEEu6DO6ulE82x84pcRI6aklegRbvf4jnm+5UVh+tYKpGUzHoXYW4pGds4a VQP7T+GQ2mPIvxv3b+FAD727lMO/8jJzMCsCQ=
Received: by 10.142.188.10 with SMTP id l10mr1876723wff.9.1314535124177; Sun, 28 Aug 2011 05:38:44 -0700 (PDT)
Received: from [192.168.1.98] (ppp-124-121-211-19.revip2.asianet.co.th. [124.121.211.19]) by mx.google.com with ESMTPS id m1sm12958591pbf.3.2011.08.28.05.38.38 (version=SSLv3 cipher=OTHER); Sun, 28 Aug 2011 05:38:42 -0700 (PDT)
Message-ID: <4E5A36CC.6070506@gmail.com>
Date: Sun, 28 Aug 2011 19:38:36 +0700
From: Glen Zorn <glenzorn@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: hongyu.lihongyu@huawei.com, daniel@olddog.co.uk, robin@huawei.com, The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, pwe3-chairs@ietf.org, adrian@olddog.co.uk
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [secdir] secdir review of draft-li-pwe3-ms-pw-pon-04
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, 28 Aug 2011 12:37:25 -0000

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.

I have virtually no knowledge of MPLS and no desire to acquire any.  I
do know a little bit about PON, probably enough to be dangerous.  For
these reasons I will not comment upon the technical aspects of the
document, instead limiting my comments to editorial issues and the
Security Considerations section.  I do have one general question,
though: just out of curiosity, why is this not a pwe3 WG document?


EDITORIAL

Abstract

The acronym "MPLS" should be expanded on first use

s/an MPLS Packet Switched Network/a MPLS Packet Switched Network/

It is sometimes lamented that the people writing the IETF standards are
most often not the people implementing said standards.  I think that
this may actually be a blessing in disguise, however: if the people
writing the standards really don't know the difference between a pointer
to an object (e.g, "[RFC3985]") and the object itself (RFC 3985), I
don't want them writing code!


Section 7.1

The references to  G.987 and G.987.3 are formatted differently from
those for the other ITU-T documents.

The references for RFC 3031, RFC 4447 and RFC 5036 are formatted
incorrectly (leading '"' and trailing '".' characters).


SECURITY CONSIDERATIONS

This section seems woefully inadequate to me.  It is a single paragraph,
reproduced in full (with interspersed commentary) below.

   G-PON/XG-PON has its own security mechanism to guarantee each ONU is
   isolated on the G-PON/XG-PON link layer.

Where is the G-PON security mechanism defined?  Presumably in one of the
6 ITU-T standards referenced, but which one?

   Other security issues are
   unchanged from those applying as standard to PWs and MS-PWs.  Please
   refer to the referenced architectures and protocol specifications for
   further details.

One of the referenced architectures, specified in RFC 3895, says

   It is outside the scope of this
   specification to fully analyze and review the risks of PWE3,
   particularly as these risks will depend on the PSN.  An example
   should make the concern clear.  A number of IETF standards employ
   relatively weak security mechanisms when communicating nodes are
   expected to be connected to the same local area network.  The Virtual
   Router Redundancy Protocol [RFC3768] is one instance.  The relatively
   weak security mechanisms represent a greater vulnerability in an
   emulated Ethernet connected via a PW.

This seems to me to specifically assign risk analysis and review of
novel pseudowires (which this would seem to be) to the designers of
such, but this draft does not show any evidence of that analysis.