iMPLS benefit

Yakov Rekhter yakov at juniper.net
Mon Mar 15 20:13:36 UTC 2004


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.



More information about the NANOG mailing list