RE: MPLS over L2TPv3 encap for RFC 2547 VPNs

[[e-mail]]

Mark,

The justification for using L2TP as opposed to IP or GRE encapsulation over an IP PSN seems to be that security is improved. However, from what I understand security in an IP/GRE encapsulated PSN using 2547 is exactly the same as a PSN using MPLS, i.e. security is not an issue and is comparable to FR/ATM. That is unless the same PSN is to be used for carrying Internet traffic (natively, not inside a VPN) and customer VPN traffic, in which case the same security risks apply to MPLS 2547 networks and IP 2547 networks anyway. 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).

>From an L2 perspective I can see that L2TP could be useful as it is well suited for encapsulating and signalling L2 tunnels. However, I do not see why L2TP is useful for L3 VPNs, why not just use GRE or IP encapsulations, which don't require any signalling? I could maybe understand if a provider was using L2TP for L2 services and wanted to reuse L2Tp for L3 services, but if so, why use BGP signalling why not use L2TP signalling?

Also, I do not agree with the use of the phrase "RFC 2547 Style VPNs", which is used several times within this draft. I would not consider RFC2547 to be a 'style' of VPNs, I would consider RFC2547 to be a specific VPN implementation, just like FR or ATM are specific VPN implantations. Why is the word 'style' used? Why not just say RFC 2547 VPNs?

Richard 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf Of Yakov
> Rekhter
> Sent: 04 February 2004 20:55
> To: W. Mark Townsley
> Cc: [e-mail]; [e-mail]
> Subject: Re: MPLS over L2TPv3 encap for RFC 2547 VPNs 
> 
> 
> Mark,
> 
> > Yakov Rekhter wrote:
> > 
> > > Please document in your draft what is exactly "prudent" about BGP.
> > 
> > Using draft-ietf-l3vpn-ipsec-2547-01.txt as a guide:
> > 
> > "RFC2547 already provides an egress-to-ingress signaling 
> capability via BGP, 
> > and we specify below how to extend this to the signalling 
> of security policy."
> > 
> > I will add this text to the l3vpn-l2tpv3 document:
> > 
> > "RFC2547 already provides an egress-to-ingress signaling 
> capability via BGP, 
> > [NALAWADE] or [RAGGARWA] specifies how to extend this to 
> the signaling of 
> > L2TPv3 reachability information for a PE."
> 
> Sorry, but the analogy with draft-ietf-l3vpn-ipsec-2547-01.txt does
> not work. This is because draft-ietf-l3vpn-ipsec-2547-01.txt does
> *not* replace IPSec signaling with BGP. All it does is specifying
> how to use BGP to indicate whether a particular VPN on a PE should
> use IPSec to get traffic to that PE.
> 
> In contrast your draft uses BGP not just to specify whether a
> particular VPN on a PE should use l2tp to get traffic to that PE,
> but also uses BGP to carry the l2tp session and cookie (l2tp signaling
> information). That is, in contrast to 
> draft-ietf-l3vpn-ipsec-2547-01.txt
> your draft does replace the l2tp signaling protocol with BGP, thus
> eliminating the need for l2tp signaling with the l2tp signaling
> protocol.
> 
> Just tell us why BGP signaling is any better than l2tp signaling.
> 
> > > 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.
> > 
> > No, the l3vpn-l2tpv3 draft specifies carrying an MPLS label 
> for a VPN-IPv4 
> > address distributed via RFC2547 extensions to BGP between 
> PEs. I should not 
> > extend this draft to cover other L3VPN models any more than 
> > draft-ietf-l3vpn-ipsec-2547-01.txt or 
> draft-ietf-l3vpn-gre-ip-2547-00.txt 
> > should. Shall I rename it to something with "2547" in the 
> title to be 
> > more clear?
> 
> First of all I'd like to thank you for pointing that both
> draft-ietf-l3vpn-ipsec-2547-01.txt or 
> draft-ietf-l3vpn-gre-ip-2547-00.txt
> took a fairly narrow point of view. This is a bug, not a feature,
> and therefore it should be fixed.
> 
> Second, the restriction on the applicability of your draft to 2547 is
> quite arbitrary. That is, there are *no* technical justifications
> for this restriction. And the fact that some other drafts 
> took a fairly 
> narrow view of the problem is no justification for continuing this.
> 
> > >>>3. The security claims have to be reviewed by the Security ADs.
> > 
> > I am more than happy to have discussions with Security ADs 
> on this topic.
> 
> Thanks. Please post the outcome of this discussion to the list.
>  
> Yakov. 
>