Skip to main content

Last Call Review of draft-ietf-pwe3-segmented-pw-

Request Review of draft-ietf-pwe3-segmented-pw
Requested revision No specific revision (document currently at 18)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-09-08
Requested 2009-08-22
Authors Matthew Bocci , Thomas Nadeau , Luca Martini , Chris Metz , Mustapha Aissaoui
I-D last updated 2009-09-10
Completed reviews Secdir Last Call review of -?? by Hilarie Orman
Assignment Reviewer Hilarie Orman
State Completed
Request Last Call review on draft-ietf-pwe3-segmented-pw by Security Area Directorate Assigned
Completed 2009-09-10
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.