[c-nsp] Update: DOS Mitigation on MPLS Networks

[christian.macnevin at uk.bnpparibas.com]

>Am I missing something or is setting the static route to 1.2.3.4 not
required since you are setting the next-hop to that via the route-map?  It
seems redundant to me.

Yup, you're missing something. BGP has to have something to redistribute.
Unless there's a specific /32 route to it, the prefix list won't match
against it for the next-hop to work. The next-hop is necessary above and
beyond the static route because the BGP protocol will natively change the
next-hop to the router id. I see this was tackled in another reply,
actually :) But someone said that using just the prefix list would work -
but unlses I'm just plain wrong (it happens) it won't. A prefix list
matches against a set of information as a filter, it doesn't originate
anything.


| The down side of this is that if you're announcing a /32 of that exact
same
| address in any other VRF on that same router, it will also get
blackholed.|

>And that's the big problem I see here.  While the chance of collision may
be small for a single host, the chances increase if you need to blackhole
an entire subnet, particularly if that subnet is something in RFC1918 space
that is likely to be replicated across multiple customer VRFs.

Actually, this will only happen if the same exact subnet is advertised from
the same PE. So if there's 10.1/16 advertised from the same PE on another
VRF and that's what you've blocked, then yeah, it's a problem. But if
something's being attacked, you're highly, highly unlikely to block
anything bigger than a /24. So the chances of having that collission on the
same PE are small, even with RFC1918 space. The amount of space most CEs
announce is quite small. Yes, it's a risk, but the amount of extra config
required to nail this down is very high.


>Wouldn't it make more sense to incorporate your route-map into a standard
that is applied to all PE->CE peers rather than to the RR peers?  And for
those connections that are statically routed or where routes come in via an
IGP, you can still use a static route as you did in your example above.

Too much work, too much to think about on the day. This is a small, static
configuration which can be worked with very quickly and easily. Your
solution may be technically better, but I'm after the simplest, catch-all
solution here. I don't see that the risks involved are terribly serious at
all.

Thanks for the comments, I appreciate the effort.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)

iD8DBQFCXVqTE1XcgMgrtyYRAinPAKDj+6xcadaLNkShsmwsd7jcucLawgCgvIKJ
ayawu7BhTxD546jJY90DpfM=
=GbPd
 -----END PGP SIGNATURE-----







This message and any attachments (the "message") is 
intended solely for the addressees and is confidential. 
If you receive this message in error, please delete it and 
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole 
or partial, is prohibited except formal approval. The internet 
can not guarantee the integrity of this message. 
BNP PARIBAS (and its subsidiaries) shall (will) not 
therefore be liable for the message if modified. 

**********************************************************************************************

BNP Paribas Private Bank London Branch is authorised 
by CECEI & AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the
United Kingdom.

BNP Paribas Securities Services London Branch is authorised
by CECEI & AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the 
United Kingdom.
  
BNP Paribas Fund Services UK Limited is authorised and 
regulated by the Financial Services Authority.