The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] MPLS over L2TPv3 encap for RFC 2547 VPNs
Hi Richard, > in which case the same security > risks apply to MPLS 2547 networks and IP 2547 networks anyway. It would be interesting to see how did you achieved the above conclusion. If any PSN carries internet natively it seems much harder to inject MPLS labeled packets into them then IP packets. Of course one could protect such a network on all ingress points to accept any IP packet destined to a group of PE loopbacks used as next hops for IP 2547 and that is main protection scheme which should be applied in all IP 2547 networks. It is my understanding that Mark's proposal just attempts to deliver an extra protection layer for operator's mistakes where such an ingress ACL could be by mistake omitted or for whatever reason disabled on any external interface. Now signaling wise my personal opinion is that for operator's benefit both ways should be allowed. For those who use L2TPv3 for L2 transport and PE-PE L2TPv3 signaling is already in place it seems much more natural to extend it to carry extra information. For those who do not intend to use L2TP for L2 services using BGP which is already in place seems equally fine. The overhead incurred to distribute required information by BGP is pretty much negligible. Also looking at the extra signaling need when L2TP encapsulation is used in Inter-AS cases for IP 2547 BGP seems a bit better suited as well. In a lot scenarios ingress ACL protection of such a remote islands may not be always at all possible :-). Rgs, R. > richard.spencer@bt.com wrote: > 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: owner-mpls@UU.NET >> [mailto:owner-mpls@UU.NET]On Behalf Of Yakov Rekhter Sent: 04 >> February 2004 20:55 To: W. Mark Townsley Cc: mpls@UU.NET; >> l3vpn@ietf.org 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. >> > >
|
|