[nsp-sec] Revisiting the DDOS Route Server project

[Smith, Donald]

Gee that sounds familiar:)

http://www.rfc-editor.org/internet-drafts/draft-ietf-opsec-blackhole-urpf-04.txt

Danny was one of the co-authors, I got an acknowledgement and Barry got an Informative reference.

(coffee != sleep) & (!coffee == sleep)
Donald.Smith at qwest.com gcia   

> -----Original Message-----
> From: nsp-security-bounces at puck.nether.net 
> [mailto:nsp-security-bounces at puck.nether.net] On Behalf Of 
> John Fraizer
> Sent: Friday, August 14, 2009 11:35 AM
> To: nsp-security at puck.nether.net
> Subject: Re: [nsp-sec] Revisiting the DDOS Route Server project
> 
> ----------- nsp-security Confidential --------
> 
> On Thu, Aug 13, 2009 at 6:15 AM, Scott A. McIntyre 
> <scott at xs4all.net> wrote:
> 
> > ----------- nsp-security Confidential --------
> >
> > I think that Hank's point is that the way most of us have 
> the DDoS-RS
> > peerings set up we only null-route traffic sent *to* 
> addresses advertised.
> >  I'm not sure how many have tried to make the right 
> router-fu that would
> > actually reject packets *from* entries based on some routing policy
> > statements/maps/whatever.  I've never looked into that, but 
> certainly we
> > only use it as a list of addresses to dump as a destination.
> >
> >
> Not much router-fu involved.
> 
> uRPF will kill the traffic in both directions, provided that 
> the traffic
> passes an interface with uRPF configured.
> 
> IE; Configure loose-mode uRPF on as many interfaces as 
> possible on your
> routers.
> 
> On cisco, add the following to the interface config:
> 
> ip verify unicast source reachable-via any
> 
> On Juniper, it's as simple as adding the following to the 
> interface config:
> 
> rpf-check {
>  mode loose;
> }
> 
> 
> 
> This comes in handy-dandy when you take a DDoS.  You can 
> null-route the
> attacking addresses and their traffic gets dropped on the first uRPF
> interface it reaches on your network.  No muss, no fuss.
> 
> If your peers are RTBH friendly, you can even possibly pass 
> those RTBH NLRIs
> up to them with their RTBH community attached and they'll 
> nuke the traffic
> before it touches your pipe.
> 
> Here's an example from one of our peering connections:
> 
> 
> 
> !
> interface TenGigabitEthernet4/0/0
>  ip address x.x.x.x 255.255.255.252
>  ip verify unicast source reachable-via any
>  ip flow ingress
>  load-interval 30
> end
> !
> ip route 192.0.2.1 255.255.255.255 Null0
> !
> 
> #sh ip route 12.204.121.73
> Routing entry for 12.204.121.73/32
>   Known via "bgp 11456", distance 200, metric 0
>   Tag 65334, type internal
>   Last update from 192.0.2.1 7w0d ago
>   Routing Descriptor Blocks:
>   * 192.0.2.1, from x.x.x.x, 7w0d ago
>       Route metric is 0, traffic share count is 1
>       AS Hops 1
>       Route tag 65334
> 
> Now, since the RTBH NLRI has the next-hop of 192.0.2.1, which 
> is null-routed
> on the router, both traffic to *and* traffic from are 
> null-routed because
> traffic from that host will fail the RPF check since our best 
> route to it is
> null.
> 
> 
> John
> 
> 
> _______________________________________________
> nsp-security mailing list
> nsp-security at puck.nether.net
> https://puck.nether.net/mailman/listinfo/nsp-security
> 
> Please do not Forward, CC, or BCC this E-mail outside of the 
> nsp-security
> community. Confidentiality is essential for effective 
> Internet security counter-measures.
> _______________________________________________
> 
>