Subject: Request for Speaking Slot: draft-behringer-mpls-security-03.txt

From: "Michael H. Behringer" <[email-masked]>
Date: Tue, 05 Nov 2002 15:24:48 +0100

George, Loa,

Recently I submitted an updated version of 
draft-behringer-mpls-security-03.txt. If you consider this work of interest 
to the MPLS WG, I would like to request a speaking slot at the Atlanta 
meeting.

Thanks,
Michael

A New Internet-Draft is available from the on-line Internet-Drafts directories.

         Title           : Analysis of the Security of the MPLS Architecture
         Author(s)       : M. Behringer
         Filename        : draft-behringer-mpls-security-03.txt
         Pages           : 14
         Date            : 2002-11-4

This document analyses the security of the BGP/MPLS VPN architecture as
described in RFC 2547, especially in comparison with other VPN
technologies such as ATM and Frame Relay. The target audience is
service providers and VPN users. The document consists of two main
parts: First the requirements for security in VPN services are defined,
second MPLS is examined with respect to these requirements.

The analysis shows that MPLS VPN networks can be equally secured as
traditional layer-2 VPN networks such as ATM and Frame Relay.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-behringer-mpls-security-03.txt

---

From: "Sumit Garg" <[email-masked]>
Date: Wed, 6 Nov 2002 08:21:20 -0500

Got only as far as page 6.

Some comments:
--------------

Page 6, you write:

"Traffic separation is achieved by prepending VPN-specific labels to the
packets, so that a packet can also on the core be identified as
belonging to a specific VPN.  "

This assumes and implies that the core LSRs know that the label is a VPN
label; OR  more generically that there is something special about a VPN
label.  My understanding is there isn't.  Labels are not looked at in
any specific context.  Infact with independent LSP setup, teardown and
local repair one can run into scenarios where the VPN traffic doesn't
stay so private. Example:

VPN1----A----B----C----D----VPN2

A and D are PEs and B and C and Ps. LSP from A to D comes up (or goes
down) independently and for this example assume the LSP segment between
B and C is missing. A thinks there is a LSP to D (doesn't know of the
hole between B and C) Traffic from A goes to B with the outer label for
the LSP to D and the inner label for VPN sites connected at A and D

B doesn't have an outgoing label; does a pop of the outer label and then
as the end of stack bit is not set looks at the inner label.  This label
might have local significance at B and so the traffic may ge switched to
the wrong LSP and therefore the wrong desitation.

This is a consequence of independent LSP setup.  End to end LSP
continuty cannot be guaranteed.  One possible option is to set the
opcode on the incoming lable on B as discard and not pop and lookup.

Hope you get the idea.  And maybe the MPLS gurus can clarify my ideas?

Some nits:
----------

Page number on page 1 is missing.

Page 2, after the bullet list there is a type ">From "

Doc formatting can be improved so that page numbers do fall on end of
page; most authors do it by embedding a form feed (a CTRL-L).

General observations:
---------------------

Don't see the point of this document wrt the WG.  What are we trying to
achieve?  Seems more like a white paper.  But then these are my 2c.

/Sumit