Subject: [secdir] secdir review of draft-ietf-pwe3-mpls-transport-04

From: Radia Perlman <[email-masked]>
Date: Mon, 03 Aug 2009 07:53:07 -0700

This document describes how to make an MPLS-TP path one one party (party A)
appear to be an MPLS-TP link of another (party B), in other words, tunneling
party B's MPLS-TP information over party A's -provided path.

As noted in the security considerations section, there are no new security
issues raised by using this already-existing mechanism for this purpose.

One comment: Rao Cherukuri's email address seems to be missing
from "authors' addresses".

A couple of questions, really...it looks like the term "Transport" is used
in the MPLS/ITU context to mean more like layer 3, rather than end-to-end
layer 4 (like TCP). Although this always seemed a much more natural use
of the term "transport" (since layer 3 and layer 2 really do transport 
things
and layer 4 doesn't), why is it is called "TP" here?

And in the security considerations section it mentions the problem of
static configuration having the possibility of a forwarding loop. Again just
a comment -- admittedly a packet can go round the loop a few times before
the TTL expires, but given that there is a TTL, it seems like a looping MPLS
path might not be too bad. Especially if part of the static 
configuration would
be the TTL to initiate packets on, for a particular MPLS path.

But as for the document being reviewed -- no security issues.

Radia

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 03 Aug 2009 16:37:04 +0100

Radia

Thank you for the review.

> and layer 4 doesn't), why is it is called "TP" here?
Yes we are using the term transport in the way that ITU-T SG15 use the term.
I would say that we are defining it the same way, but that do not seem to
have a crisp definition themselves :) in other words we are designing a
replacement for SDH and similar methods of providing long distance
physical connectivity

The term MPLS-TP stands for MPLS Transport Profile. This is the subset
of the MPLS protocol suite needed to provide Transport Network Connectivity.

> path might not be too bad. 
Transport networks are traffic engineered rather than best effort
so the impact is that the packet consumes remaining TTL times the budgeted
capacity, which effects the bandwidth/delay provided to other services.

> Especially if part of the static configuration would
An interesting thought, which I would like to ponder. It turns out
that we often know the TTL since we use TTL expiry to deliver
OAM messages to MIPS.
> But as for the document being reviewed -- no security issues.
Thanks

Stewart