North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: iMPLS benefit
- From: W. Mark Townsley
- Date: Mon Mar 15 13:19:37 2004
Please see inline.
Yakov Rekhter wrote:
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
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 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).
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).
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.
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.
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).
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).
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
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).
And the same paragraph goes on to say:
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".
"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.