Subject: RE: MPLS over L2TPv3 encap for RFC 2547 VPNs

From: [email-masked]
Date: Wed, 4 Feb 2004 09:26:19 -0000

Yakov/Mark,

This discussion seems to have 2 major themes:
-	the appropriate functional use (or misuse) of protocols
-	security implications of functional protocol use (or misuse).

I would much prefer we split the VPN problem into its 3 major components (see below) and folks can use whichever protocol is considered the most appropriate to that component.  Further, and speaking as an operator, I'd like to see as much *appropriate* re-use of components across the 3 networking modes of co-cs, co-ps and cl-p as possible when creating VPNs so that I can get my capex/opex costs down....and this has impact through to the NMS/OSS supporting these.

Now when I look at the VPN problem I see 3 major component areas:

1	Discovery/authentication:  One needs a method of knowing which addressable access points of a given server layer technology belong to a given VPN.  A query/response behaviour seems most appropriate here, not a broadcast approach that one gets with BGP4.  So an approach based on Radius say seems a good solution here.

2	Server layer topology creation:  One needs a method of creating forwarding paths between the identified (from above) addressable access points of the server layer technology belonging to the VPN.  This needs a proper signalling protocol IMO and not a broadcast behaviour like BGP4.  Several signalling protocols could be used, and the selection is dependent upon which networking mode is being used for the server layer technology.  For example, if the server layer is IP (cl-ps mode) one can use L2TP (but I could also 'signal' the set-up of GRE tunnels say).  If the server layer is MPLS (co-ps mode) one can use RSVP-TE.....and in theory I could also use PNNI.  If the server layer is SDH (co-cs mode) one can again use RSVP-TE....or I could also use PNNI.

There are three important observations at this point:
-	within a given mode there can be more than 1 choice of signalling protocol....some signalling protocols have better functional specification/behaviour than others;
-	the use of an out-of-band (OOB), logical and/or physical, date-plane network for the important *internal* control/management traffic should be very high on any operator's requirements list for obvious security reasons.  So where this is possible this should be done (this should be a no-brainer requirement IMO for both the co-ps and co-cs modes);
-	if we stop the VPN creation process at steps 1 and 2 above we have the essence of automating the creation of a simple managed BW VPN is some technology.....some folk call these 'L2 VPNs', not a good term IMO but it is in general usage.

3	Client layer reachability information:  This is a component that can be added to the above 'L2 VPN' base-case to create a so-called 'L3 VPN'.  The type of client should not be prescriptive....and this is why it is architecturally wrong to assume 'L3 VPN'=> IP VPN, and why I think the term 'L3 VPN' is misleading.  Indeed, I recall seeing a draft from Chris Metz (draft-metz-switched-atm-l2vpn-00.txt) a while ago that was using a rfc2547 approach with BGP4 distributing ATM NSAP address reachability over MPLS as the server layer technology, ie ATM was the client in this 'L3 VPN'

Now here a limited broadcast functional behaviour is what is required to distribute information regarding which *client* layer access point addresses lie above/behind which *server* layer access point addresses....noting these are 2 disjoint layer networks.

It is my opinion that if folks started to regard VPNs in the above terms then much of the squabbling (eg 'my protocol is better than yours') could be avoided.  And we may also be able to provide operator's with better solutions in the future (esp noting my points on functional re-use to get capex/opex down and the use of an OOB control/management plane where this is appropriate to improve security).

regards, Neil 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Yakov Rekhter
> Sent: 04 February 2004 01:42
> To: W. Mark Townsley
> Cc: [email-masked]; [email-masked]
> Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs 
> 
> 
> Mark,
> 
> > Based on comments received from the previous IETF meeting, 
> I have split 
> > the MPLS 
> > over L2TPv3 draft into two documents.
> > 
> > draft-townsley-l2tpv3-mpls-01.txt targets mpls, and 
> presents only the 
> > MPLS over L2TPv3 encapsulation.
> > 
> > draft-townsley-l3vpn-l2tpv3-00.txt targets l3vpn, and 
> discusses the use 
> > of MPLS 
> > over L2TPv3 within the context of RFC2547-Style VPNs.
> > 
> > Yakov also had three specific points raised during both 
> meetings that 
> > I promised to bring to the list. These follow:
> > 
> > > 1. Why extending BGP for multipoint-to-point L2TP signaling
> > > is preferred to the existing L2TP signaling (or extending L2TP
> > > to provide multipoint-to-point signaling) ?
> > 
> > Any sort of point to multipoint manual configuration or 
> signaling may 
> > in fact be used. 
> 
> My question was not whether BGP *may* be used, but *why* extend BGP
> to support l2tp signaling when l2tp already has its own signaling
> protocol. 
> 
> > However, BGP does seem prudent for what is effectively 
> > an extension to RFC2547.
> 
> Please document in your draft what is exactly "prudent" about BGP.
> 
> > > 2. The applicability scope is by no means limited to 2547 - it is
> > > applicable to any multipoint-to-point application.
> > 
> > Yes, though the scope does not extend beyond reachability 
> information to 
> > a given PE. The MPLS labels for the VPN routes themselves 
> continue to 
> > be distributed by the existing mechanisms of RFC2547.
> 
> I am glad you agree that that the distribution of l2tp signaling
> information described in your draft  is completely orthogonal to
> 2547. Which is precisely the point I made.  That is, there is nothing
> in your draft that is specific to just 2547. E.g., it is equally
> applicable to VR based L3VPNs. Therefore, the draft has to be 
> generalized
> to cover any multipoint-to-point application of MPLS over l2tp.
> 
> > > 3. The security claims have to be reviewed by the Security ADs.
> > 
> > Yes, as with any potential RFC.
> 
> Since security considerations (and to be more precise, the part
> about implications on packet spoofing) are presented in your draft
> as one of the major justifications for using l2tp, in making a
> decision on whether to accept your drafts as a WG document the WG
> needs to know whether this justification is really accurate. That
> is precisely why I asked the section on implications on packet
> spoofing to be reviewed and evaluated for correctness and accuracy
> by the Security ADs.
> 
> Yakov.
> 
>

---

From: Eric Rosen <[email-masked]>
Date: Thu, 05 Feb 2004 10:54:39 -0500

> If you do not agree with my  conclusion then I would be interested to know
> if this  just your own  personal view?  I ask because  at a seminar  a few
> months ago attendees were assured by Cisco representatives 

Really, should  know better than to  assume that any statement  made on this
list  is a  statement  of corporate  position.   I would  never assume  that
statements made by BT employees here reflect a corporate position.  

> the forwarding  of VPN packets  using IP/GRE was  just as secure  as using
> MPLS headers. 

When  comparing two security  schemes, you  need to  look at  the particular
threat models of  interest, the likelihood making mistakes  in deploying the
scheme,  the limits  of  applicability  of the  scheme,  etc.  Without  this
context, it is meaningless to say that A is as secure as B.

---

From: [email-masked]
Date: Mon, 9 Feb 2004 15:42:19 -0000

Mark,

 > The inherent problem being that IP the control traffic shares the
> same data plane as the public Internet traffic, unlike ATM which uses an
> out-of-band control plane (and is the only sensible solution to the problem,
> i.e. use reserved labels for control/management traffic in MPLS).

Interesting, but how does carrying the control channel out of band help in a
blind spoofing attack on the data plane (where one is merely guessing labels in
attempt to break into a VPN)?
 
RS> Because if the control channel is out of band then anyone with access to the control channel can only effect what goes in the control channel, they cannot attempt VPN spoofing attacks in the data plane. As things currently stand in IP/MPLS, anyone with access to the control channel is free to initiate a VPN spoof attack on the data plane because they share the same address space. 
 
Richard