|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: iMPLS benefit
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 > >>>> > >>>> 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. > 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.
|