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

[Stewart Bryant <[e-mail]>]

Radia

Thank you for the review.

Radia Perlman wrote:
> 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?
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.

>
> 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. 
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
> be the TTL to initiate packets on, for a particular MPLS path.
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.
>
> Radia
>
>
Thanks

Stewart
>
>