[secdir] Review of draft-ietf-pwe3-segmented-pw-13

"Hilarie Orman" <ho@alum.mit.edu> Tue, 08 September 2009 02:11 UTC

Return-Path: <hilarie@purplestreak.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 5321B3A68FF for <secdir@core3.amsl.com>; Mon, 7 Sep 2009 19:11:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.688
X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[AWL=-0.578, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id TbfO0g2UNEOS for <secdir@core3.amsl.com>; Mon, 7 Sep 2009 19:11:21 -0700 (PDT)
Received: from out01.mta.xmission.com (out01.mta.xmission.com []) by core3.amsl.com (Postfix) with ESMTP id 019103A68E9 for <secdir@ietf.org>; Mon, 7 Sep 2009 19:11:17 -0700 (PDT)
Received: from mx01.mta.xmission.com ([]) by out01.mta.xmission.com with esmtp (Exim 4.62) (envelope-from <hilarie@purplestreak.com>) id 1MkqBe-0000d9-UW; Mon, 07 Sep 2009 20:12:02 -0600
Received: from 166-70-57-249.ip.xmission.com ([] helo=fermat.rhmr.com) by mx01.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <hilarie@purplestreak.com>) id 1MkqBM-00066r-QT; Mon, 07 Sep 2009 20:11:45 -0600
Received: from fermat.rhmr.com (localhost []) by fermat.rhmr.com (8.14.3/8.14.3/Debian-6) with ESMTP id n882Bd20022974; Mon, 7 Sep 2009 20:11:39 -0600
Received: (from ho@localhost) by fermat.rhmr.com (8.14.3/8.14.3/Submit) id n882Bbt7022971; Mon, 7 Sep 2009 20:11:37 -0600
Date: Mon, 7 Sep 2009 20:11:37 -0600
Message-Id: <200909080211.n882Bbt7022971@fermat.rhmr.com>
X-Authentication-Warning: fermat.rhmr.com: ho set sender to hilarie using -f
From: "Hilarie Orman" <ho@alum.mit.edu>
To: secdir@ietf.org
X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx01.mta.xmission.com; ; ; ip=; ; ; frm=hilarie@purplestreak.com; ; ; spf=none
X-XM-DomainKey: sender_domain=alum.mit.edu; ; ; sender=ho@alum.mit.edu; ; ; status=no signature
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa03 1397; Body=1 Fuz1=1 Fuz2=1
X-Spam-Combo: ;secdir@ietf.org
X-SA-Exim-Version: 4.2.1 (built Thu, 25 Oct 2007 00:26:12 +0000)
X-SA-Exim-Scanned: Yes (on mx01.mta.xmission.com)
Cc: vach.kompella@alcatel-lucent.com, Shane.Amante@Level3.com, alex.zinin@alcatel-lucent.com, rdroms@cisco.com, florin.balus@alcatel-lucent.com, jari.arkko@piuha.net, mustapha.aissaoui@alcatel-lucent.com
Subject: [secdir] Review of draft-ietf-pwe3-segmented-pw-13
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Hilarie Orman <ho@alum.mit.edu>
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: Tue, 08 Sep 2009 02:11:22 -0000

Review of draft-ietf-pwe3-segmented-pw-13

Do not be alarmed.  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

This document extends the pseudo-wire (PWE3) architecture by defining
multi-segment pseudo-wires.  A pseudowire (PW) links two Terminating
Provider Edges (T-PEs).  PWs are transmitted through a tunnel between
the T-PEs.  I'll call this a bundle of PW's.  A multi-segment PW
connects two bundles and (de)multiplexes the PWs to the correct

At this point I need to disclose that I have never before heard of PWs
and have only a foggy notion of their purpose.  I'm sorry for being
ignorant.  There is more to PWs than I can absorb in the time
available for a review.  I can, however be slightly helpful in noting
that section 3.i. uses the term "cryptogtaphiclly (sic) sign" where
"include a cryptographic message authenticator" is more accurate.

Again, on the apology side of the ledger, I cannot follow the first
example motivating the need for multi-segment PWs.  Somehow, if
authentication is used between two AS's, and if they use a single PW,
then they would have to include an authenticator on all T-PE messages.
And that is somehow bad.

The second example involves a routing protocol that sets up a path
involving concatenated PWs.  In that case, multi-segments with
switching can dynamically (?) carry the traffic between the intended
T-PEs.  That's good because it avoids setting up PWs for all possible

The third example is even harder, and in that one, multi-segment
switching has the potential (why not guarantee?) of reducing the
number of PWE3 control channels.

The diagrams showing the evolution of the architecture from a single
tunnel with a bundle of PWs to multiple tunnels and then to switched
tunnels is very helpful, but I don't really see how the examples fit
into it.

The gist of the document is that single-segment PWs can be joined into
multi-segment PWs, with all of the security problems that attend to
any similar graph building procedure.  The document relies on several
preceding documents for exchanging control information, all of which
have security considerations, all of which apparently apply to the
multi-segment case.

I failed to get an elemental understanding of how the signalling and
control messages extend the single-segment PWs to multi-segment PWs.

In section 10.3 this sentence appears to have a missing or incorrect

   However T-PE
   participating a MS-PW, SHOULD be able to process the S-PE TLV.

The looming security problem is that the only way to make sure that
connections are made correctly is to have a table of endpoints and
pre-placed shared keys between them.  Is this at all realistic, given
that multi-segment PWs are for situations in which an organization has
developed an architecture too rich for single-segement PWs? 

Because I don't fully understand PWs, and because the underlying
protocols for exchanging control information rely on pre-placed keys,
I cannot recommend anything better.  I do hope that anyone using this
kind of architecture is clueful and careful.