[j-nsp] out-bound anti-spoofing rules when using community-based routing

[David Ball]

   I suppose uRPF would do the trick, though since I have some
customers with redundant connectivity to us, asymmetry is possible.
So, in that case we'd end up having to maintain prefix-lists after
all, which we'd reference in the 'rpf-check fail-filter'.
   I had done away with prefix-lists for the most part for our BGP
customers and simply listed their blocks in their policy-statements,
but I guess reverting back to referencing prefix-lists using
'prefix-list-filter <name> orlonger' would work the same, and allow me
to reference same prefix-list in a fail-filter.  Serves me right for
trying to save a few lines of config.
   Thanks for the comments.  On a related note, did anything ever
happen with the idea of 'feasible path' RPF, which would consider
multiple paths to the same prefix, instead of just the active one?

David



On 24/01/2008, Pekka Savola <pekkas at netcore.fi> wrote:
> On Thu, 24 Jan 2008, David Ball wrote:
> >  I'm now struggling to find another way to prevent our customers from
> > spoofing.  The previous method relied on a firewall filter which
> > indeed references a prefix-list of all our customers' space.  I'm
> > having a hard time getting away from this, as I can't create a
> > firewall filter which will look up the community assigned to a
> > source-address (to see if it's legitimately a customer).
> >  How have others gotten around this?  Am I overlooking something?  Or
> > is maintaining large lists the only way to go ?
>
> Firewall filters are programmed on the ASICs.  As a result, they can't
> change dynamically based on control plane information (routes), at
> least this wasn't possible a couple of years ago.
>
> You'll need the list of prefixes in any case.  You'll want to have
> inbound policy reject routes that advertise more specifics of your
> address space (routing hijack).  Community based mechanism won't help
> with that so you'll need a static list.
>
> If you build the prefix lists in a flexible manner, you can also
> use the same prefix lists to do egress/ingress filtering at your
> peering/upstream edges.
>
> At the customer edge you can probably use uRPF and static prefix lists
> for BGP customers.
>
> This is a bit more generic but may be useful to you (comments
> welcome):
> http://tools.ietf.org/id/draft-savola-rtgwg-backbone-attacks-03.txt
>
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>