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
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 Actually, the justification is 3-fold. As detailed in Section 5 "Applicability" of draft-townsley-l3vpn-l2tpv3-00.txt, the first two reasons have more to do with whether or not you are using L2TPv3 for other services on your network and wish to maintain a homogeneous type of tunneling encapsulation for MPLS as well as FR, ATM, etc. Incidentally, these two are precisely the same two reasons given for why one might choose a GRE encap vs. an IP encap. Security against blind spoofing attacks via the Cookie is identified as an additional reason for L2TPv3 over and above the other two reasons. > 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. There are a number of references to the security concerns with respect to packet spoofing when running MPLS over IP or GRE. These stem from the comparative ability between MPLS and IP to block exterior traffic from penetrating the core network where the VPN is operating, and thus disallowing spoofed packets into the customer VPN. As I understand the argument, it is purported to be far easier to isolate an MPLS core by dropping labeled traffic from any non-core-facing interface than it would be to configure and maintain similarly-purposed L3ACLs on all non-core-facing interfaces of an IP core. This argument is mentioned in more detail in a number of places, including: draft-ietf-l3vpn-gre-ip-2547-00.txt, Section 7 draft-ietf-l3vpn-ipsec-2547-01.txt, Section 1.1, paragraph 3 "MPLS Technology and Applications," Davie, Rekhter, pg 217 > 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)? > >> 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? We are only advertising a single Session/Cookie per PE (not per PE pair, per VPN, etc). So, for the 2547 L3VPN case, we can include this Session/Cookie in the BGP Next Hop Update allowing it to become part of the single adjacency that gets built for sending all 2547 traffic over L2TPv3/IP to that PE. If we were performing any sort of p2p signaling, advertising any customer-facing interface parameters or IDs, signaling interface status, utilizing keepalives, etc. I would be more inclined to use the L2TP signaling, establishing individual sessions between PEs. > > 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? "RFC 2547 Style" - it's not my word. In fact, I was stumped as to what term to use myself, so I referred to draft-andersson-ppvpn-terminology-04.txt which uses "RFC 2547 Style" and "Virtual Router (VR) style" (Page 8-9 and in some figures) to differentiate between the two VPN methods. I'm happy to use any other accepted term. Hope this clarifies things, and thanks for the feedback, - Mark > > 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. >> > >
|
|