Hello, i heard there is a way to run MPLS for layer3 VPN(2547) service without needing to run label switching in the core(LDP/TDP/RSVP) but straight IP (aka iMPLS). Anyone running this in a live network yet? Thanks in advance for any information. Suki Lim Blacksburg, VA ee.VA.TECH --------------------------------- Do you Yahoo!? Yahoo! Search - Find what you�re looking for faster.
Hey Suki, On Thu, Mar 04, 2004 at 02:14:20PM -0800, sonet twister wrote:
Hello,
i heard there is a way to run MPLS for layer3 VPN(2547) service without needing to run label switching in the core(LDP/TDP/RSVP) but straight IP (aka iMPLS).
ftp://ftp.ietf.org/internet-drafts/draft-townsley-l2tpv3-mpls-01.txt See also Mark's talk from the last NANOG http://nanog.org/mtg-0402/townsley.html
Anyone running this in a live network yet? Thanks in advance for any information.
Yes. Dave
Suki Lim Blacksburg, VA ee.VA.TECH
--------------------------------- Do you Yahoo!? Yahoo! Search - Find what you?re looking for faster.
Dave,
Hey Suki,
On Thu, Mar 04, 2004 at 02:14:20PM -0800, sonet twister wrote:
Hello,
i heard there is a way to run MPLS for layer3 VPN(2547) service without needing to run label switching in the core(LDP/TDP/RSVP) but straight IP (aka iMPLS).
ftp://ftp.ietf.org/internet-drafts/draft-townsley-l2tpv3-mpls-01.txt
See also Mark's talk from the last NANOG
That requires to run L2TP. An alternative is to run GRE (or even plain IP). The latter (GRE) is implemented by quite a few vendors (and is known to be interoperable among multiple vendors). The spec is draft-ietf-l3vpn-gre-ip-2547-01.txt. Yakov.
On Fri, Mar 05, 2004 at 10:02:10AM -0800, Yakov Rekhter wrote:
Dave,
Hey Suki,
On Thu, Mar 04, 2004 at 02:14:20PM -0800, sonet twister wrote:
Hello,
i heard there is a way to run MPLS for layer3 VPN(2547) service without needing to run label switching in the core(LDP/TDP/RSVP) but straight IP (aka iMPLS).
ftp://ftp.ietf.org/internet-drafts/draft-townsley-l2tpv3-mpls-01.txt
See also Mark's talk from the last NANOG
That requires to run L2TP. An alternative is to run GRE (or even plain IP). The latter (GRE) is implemented by quite a few vendors (and is known to be interoperable among multiple vendors).
The spec is draft-ietf-l3vpn-gre-ip-2547-01.txt.
Yep, you are correct. Sorry not to cite that one too. Dave
David Meyer wrote:
On Fri, Mar 05, 2004 at 10:02:10AM -0800, Yakov Rekhter wrote:
Dave,
Hey Suki,
On Thu, Mar 04, 2004 at 02:14:20PM -0800, sonet twister wrote:
Hello,
i heard there is a way to run MPLS for layer3 VPN(2547) service without needing to run label switching in the core(LDP/TDP/RSVP) but straight IP (aka iMPLS).
ftp://ftp.ietf.org/internet-drafts/draft-townsley-l2tpv3-mpls-01.txt
See also Mark's talk from the last NANOG
That requires to run L2TP. An alternative is to run GRE (or even plain IP). The latter (GRE) is implemented by quite a few vendors (and is known to be interoperable among multiple vendors).
The only multi-vendor interoperable mode of GRE that I am aware of requires manual provisioning of point-to-point GRE tunnels between MPLS networks and to each and every IP-only reachable PE. The BGP extension defined in the draft below allows "iMPLS" for 2547 VPN support without requiring any manually provisioned tunnels (and works for "mGRE" or L2TPv3). http://www.watersprings.org/pub/id/draft-nalawade-kapoor-tunnel-safi-01.txt Note that "mGRE" (multipoint GRE) is *not* the same as the point-to-point GRE method that Yakov is referring to. Same header, different usage. Enabling MPLS over any type of IP tunnel changes the security characteristics of your 2547 deployment, in particular with respect to packet spoofing attacks. The L2TPv3 encapsulation used with the extension defined above provides anti-spoofing protection for blind attacks (e.g., the kind that a script kiddie could launch fairly easily) with miniscule operational overhead vs. GRE which relies on IPsec. - Mark
The spec is draft-ietf-l3vpn-gre-ip-2547-01.txt.
Yep, you are correct. Sorry not to cite that one too.
Dave
Mark,
>i heard there is a way to run MPLS for layer3 VPN(2547) >service without needing to run label switching in the >core(LDP/TDP/RSVP) but straight IP (aka iMPLS).
ftp://ftp.ietf.org/internet-drafts/draft-townsley-l2tpv3-mpls-01.txt
See also Mark's talk from the last NANOG
That requires to run L2TP. An alternative is to run GRE (or even plain IP). The latter (GRE) is implemented by quite a few vendors (and is known to be interoperable among multiple vendors).
The only multi-vendor interoperable mode of GRE that I am aware of requires manual provisioning of point-to-point GRE tunnels between MPLS networks and to each and every IP-only reachable PE.
I guess you are *not* aware of the Redback implementation of 2547 over GRE, as this implementation is (a) available today, (b) interoperable with other implementations of 2547 over GRE, and (c) does *not* require manual provisioning of point-to-point GRE tunnels between MPLS networks and to each and every IP-only reachable PE. And, just for the record, (stating the obvious) I don't work for Redback.
The BGP extension defined in the draft below allows "iMPLS" for 2547 VPN support without requiring any manually provisioned tunnels (and works for "mGRE" or L2TPv3).
http://www.watersprings.org/pub/id/draft-nalawade-kapoor-tunnel-safi-01.txt
The question to ask is whether the extension you mentioned above is truly necessary for supporting 2547 over GRE. The Redback implementation I mentioned above is an existence proof that the extension is *not* necessary for 2547 over GRE that does *not* involve manually provisioned GRE tunnels.
Note that "mGRE" (multipoint GRE) is *not* the same as the point-to-point GRE method that Yakov is referring to. Same header, different usage.
Enabling MPLS over any type of IP tunnel changes the security characteristics of your 2547 deployment, in particular with respect to packet spoofing attacks. The L2TPv3 encapsulation used with the extension defined above provides anti-spoofing protection for blind attacks (e.g., the kind that a script kiddie could launch fairly easily) with miniscule operational overhead vs. GRE which relies on IPsec.
GRE relies on IPSec in *some*, but *not all* cases. Another alternative is to use packet filtering. Quoting from the 2547 over GRE spec: Protection against spoofed IP packets requires having all the boundary routers perform filtering; either filtering out packets from "outside" which are addressed to PE routers, or filtering out packets from "outside" which have source addresses that belong "inside" and filtering on each PE all packets which have source addresses that belong "outside". Yakov.
Please see inline. Yakov Rekhter wrote:
Mark,
>>i heard there is a way to run MPLS for layer3 VPN(2547) >>service without needing to run label switching in the >>core(LDP/TDP/RSVP) but straight IP (aka iMPLS).
ftp://ftp.ietf.org/internet-drafts/draft-townsley-l2tpv3-mpls-01.txt
See also Mark's talk from the last NANOG
That requires to run L2TP. An alternative is to run GRE (or even plain IP). The latter (GRE) is implemented by quite a few vendors (and is known to be interoperable among multiple vendors).
The only multi-vendor interoperable mode of GRE that I am aware of requires manual provisioning of point-to-point GRE tunnels between MPLS networks and to each and every IP-only reachable PE.
I guess you are *not* aware of the Redback implementation of 2547 over GRE, as this implementation is (a) available today, (b) interoperable with other implementations of 2547 over GRE, and (c) does *not* require manual provisioning of point-to-point GRE tunnels between MPLS networks and to each and every IP-only reachable PE.
And, just for the record, (stating the obvious) I don't work for Redback.
Are you referring to draft-raggarwa-ppvpn-tunnel-encap-sig-03.txt? (Just guessing as the principal author used to work for Redback). Thanks for the update, I was in fact not aware that companies other than Redback had implemented it. You didn't name those companies, but I will happily stand corrected here. In any case, the point I was trying to make was that there is more than one way to do "MPLS over GRE" and that they are not all necessarily interoperable as you seemed to imply in your message. You have helped to make that quite clear.
The BGP extension defined in the draft below allows "iMPLS" for 2547 VPN support without requiring any manually provisioned tunnels (and works for "mGRE" or L2TPv3).
http://www.watersprings.org/pub/id/draft-nalawade-kapoor-tunnel-safi-01.txt
The question to ask is whether the extension you mentioned above is truly necessary for supporting 2547 over GRE. The Redback implementation I mentioned above is an existence proof that the extension is *not* necessary for 2547 over GRE that does *not* involve manually provisioned GRE tunnels.
Both draft-nalawade-kapoor-tunnel-safi-01.txt and draft-raggarwa-ppvpn-tunnel-encap-sig-03.txt use BGP to advertise capabilities for carrying MPLS-labeled packets over various encapsulation types. Proof of one is essentially proof for the other, though the existence of both definitions highlights an unfortunate interoperability concern (particularly so for GRE, since each identify slightly different ways to advertise MPLS over GRE). If you are not advertising capabilities at all, then you either have to maintain a list of which PEs can and will perform 2547 over GRE (and we are back to manual provisioning of tunnels), or you have to assume that ALL will in precisely the same way (eliminating all native MPLS processing for PEs that are reachable via MPLS directly).
Note that "mGRE" (multipoint GRE) is *not* the same as the point-to-point GRE method that Yakov is referring to. Same header, different usage.
Enabling MPLS over any type of IP tunnel changes the security characteristics of your 2547 deployment, in particular with respect to packet spoofing attacks. The L2TPv3 encapsulation used with the extension defined above provides anti-spoofing protection for blind attacks (e.g., the kind that a script kiddie could launch fairly easily) with miniscule operational overhead vs. GRE which relies on IPsec.
GRE relies on IPSec in *some*, but *not all* cases. Another alternative is to use packet filtering. Quoting from the 2547 over GRE spec:
Protection against spoofed IP packets requires having all the boundary routers perform filtering; either filtering out packets from "outside" which are addressed to PE routers, or filtering out packets from "outside" which have source addresses that belong "inside" and filtering on each PE all packets which have source addresses that belong "outside".
And the same paragraph goes on to say: "The maintenance of these filter lists can be management-intensive, and the their use at all border routers can affect the performance seen by all traffic entering the SP's network." So, 2547 over GRE without IPsec relies upon a valid source/dest IP check for each packet at all boundary points in the network. Rather than rely only on this, the 2547 over L2TPv3 encapsulation defines its own (randomly selected and advertised along with the tunnel capabilities for that PE) 64-bit value to be validated before processing a packet at the router which is actually performing the 2547 VPN service. Both of these methods are filtering on cleartext header information in order to avoid the complexity and overhead of IPsec while inhibiting "script-kiddie-like" IP spoofing attacks attempting to infiltrate a VPN, but 2547 over L2TPv3 gets around the concerns with 2547 over GRE identified above as there are no filter lists to be manually maintained, and the filtering is performed only on the routers actually participating in 2547 over L2TPv3 service. - Mark
Mark,
Please see inline.
in-line...
>>>i heard there is a way to run MPLS for layer3 VPN(2547) >>>service without needing to run label switching in the >>>core(LDP/TDP/RSVP) but straight IP (aka iMPLS). > > ftp://ftp.ietf.org/internet-drafts/draft-townsley-l2tpv3-mpls-0 1.txt > > See also Mark's talk from the last NANOG > > http://nanog.org/mtg-0402/townsley.html
That requires to run L2TP. An alternative is to run GRE (or even plain IP). The latter (GRE) is implemented by quite a few vendors (and is known to be interoperable among multiple vendors).
The only multi-vendor interoperable mode of GRE that I am aware of requires manual provisioning of point-to-point GRE tunnels between MPLS networks and to each and every IP-only reachable PE.
I guess you are *not* aware of the Redback implementation of 2547 over GRE, as this implementation is (a) available today, (b) interoperable with other implementations of 2547 over GRE, and (c) does *not* require manual provisioning of point-to-point GRE tunnels between MPLS networks and to each and every IP-only reachable PE.
And, just for the record, (stating the obvious) I don't work for Redback.
Are you referring to draft-raggarwa-ppvpn-tunnel-encap-sig-03.txt? (Just guessing as the principal author used to work for Redback). Thanks for the update, I was in fact not aware that companies other than Redback had implemented it. You didn't name those companies, but I will happily stand corrected here.
No, I was *not* referring to draft-raggarwa-ppvpn-tunnel-encap-sig-03.txt. Redback's implementation that does not require manual provisioning of point-to-point GRE tunnels between MPLS networks and to each and every IP-only reachable PE is *purely* an implementation matter, and does *not* require any new communities and/or attributes.
In any case, the point I was trying to make was that there is more than one way to do "MPLS over GRE" and that they are not all necessarily interoperable as you seemed to imply in your message. You have helped to make that quite clear.
The BGP extension defined in the draft below allows "iMPLS" for 2547 VPN support without requiring any manually provisioned tunnels (and works for "mGRE" or L2TPv3).
http://www.watersprings.org/pub/id/draft-nalawade-kapoor-tunnel-safi-01.txt
The question to ask is whether the extension you mentioned above is truly necessary for supporting 2547 over GRE. The Redback implementation I mentioned above is an existence proof that the extension is *not* necessary for 2547 over GRE that does *not* involve manually provisioned GRE tunnels.
Both draft-nalawade-kapoor-tunnel-safi-01.txt and draft-raggarwa-ppvpn-tunnel-encap-sig-03.txt use BGP to advertise capabilities for carrying MPLS-labeled packets over various encapsulation types. Proof of
And *neither* of these are requires in order to avoid manual provisioning of point-to-point GRE tunnels. Yakov.
Yakov Rekhter wrote:
No, I was *not* referring to draft-raggarwa-ppvpn-tunnel-encap-sig-03.txt. Redback's implementation that does not require manual provisioning of point-to-point GRE tunnels between MPLS networks and to each and every IP-only reachable PE is *purely* an implementation matter, and does *not* require any new communities and/or attributes.
OK, you made me go out to www.redback.com and read about their implementation. A quote: "This means that the ingress router can learn these next-hop addresses through MP-BGP, and then dynamically append the GRE encapsulation and outer IP header to a VPN packet destined for an egress router. In essence, these GRE tunnels can be considered as “soft” or dynamic because they do not need to be configured. " Whether it is implicit from the next-hop address in BGP, or explicit in the next-hop update via draft-nalawade-kapoor-tunnel-safi-01.txt or draft-raggarwa-ppvpn-tunnel-encap-sig-03.txt, we are still talking about MP-BGP as the vehicle for advertising how to reach a PE by GRE. We now have identified three variants for MPLS over GRE in this thread, (outside of manually configured "hard" GRE tunnels) -- back to my original point that "MPLS over GRE" can mean a lot of things. IMHO, a PE explicitly identifying that it can receive MPLS over GRE (or MPLS over foo) traffic is a bit safer and more deterministic than implicitly assuming it can from a learned next-hop address. I don't want to speak for another company, but perhaps Redback did too which is why they helped sponser draft-raggarwa-ppvpn-tunnel-encap-sig-03.txt in the first place. Go knock on Rahul's cube now that the two of you work at the same company and ask him ;-) - Mark
Mark, [clipped...]
Enabling MPLS over any type of IP tunnel changes the security characteristi cs of your 2547 deployment, in particular with respect to packet spoofing attacks. The L2TPv3 encapsulation used with the extension defined above provides anti-spoofing protection for blind attacks (e.g., the kind that a script kiddie could launch fairly easily) with miniscule operational overhead vs. GRE which relies on IPsec.
GRE relies on IPSec in *some*, but *not all* cases. Another alternative is to use packet filtering. Quoting from the 2547 over GRE spec:
Protection against spoofed IP packets requires having all the boundary routers perform filtering; either filtering out packets from "outside" which are addressed to PE routers, or filtering out packets from "outside" which have source addresses that belong "inside" and filtering on each PE all packets which have source addresses that belong "outside".
And the same paragraph goes on to say:
"The maintenance of these filter lists can be management-intensive, and the their use at all border routers can affect the performance seen by all traffic entering the SP's network."
When talking about impact of packet filtering on the performance it is important to keep in mind that this is really an *implementation* issue. Moreover, we have an existence proof (means products on the market) that support packet filtering at line rate, with *no* adverse impact on forwarding performance. And while the maintenance of these filters certainly imposes an additional operational overhead, such filters may be requires for reasons other than protection against spoofing of VPN packets, in which case the *additional* operational overhead of using these filters to protect (among other things) against spoofing of VPN packets may be of no practical significance. Yakov.
participants (4)
-
David Meyer -
sonet twister -
W. Mark Townsley -
Yakov Rekhter