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

[Bruce Pinsky]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

christian.macnevin at uk.bnpparibas.com wrote:
|
|>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.
|

Yeah, I realized that when someone else pointed it out too.  I was thinking
about situations where you would be blackholing existing routes or routes
learned from a blackhole route server feed.  Of course you would need to
source the /32 if it wasn't already present or learned via another source.


|
| | 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.
|


I guess my perspective is different since I'm used to dealing with large
scale implementations (1000's VRFs, 10000's CEs, etc, etc).  In those
situations, it is quite common to see overlap.


|
|
|>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.
|


Not necessarily better, just geared toward a network of different scale.
Again, I'm thinking in terms of large scale implementations based on the
networks I regularly deal with.  From your explanation, it sounds
manageable as you described.

- --
=========
bep

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

iD8DBQFCXrBiE1XcgMgrtyYRAsqyAJ4kj8gHIWGDLEx97d6f9IHpcwM65QCg3KRr
sbNa2Iq5hw/SZT1Uq99UOdU=
=0Izu
-----END PGP SIGNATURE-----