[nsp-sec] DDoS Chicken and Egg Problem

[David Freedman]

Yeah, cisco also has something similar called "pak priority" for tcp segments 

------------------------------------------------
David Freedman
Group Network Engineering 
Claranet Limited
http://www.clara.net



-----Original Message-----
From: Kevin Oberman [mailto:oberman at es.net]
Sent: Wed 3/26/2008 21:07
To: David Freedman
Cc: Johnson, Ron; nsp-security at puck.nether.net
Subject: Re: [nsp-sec] DDoS Chicken and Egg Problem 
 
> Date: Wed, 26 Mar 2008 20:51:37 -0000
> From: "David Freedman" <david.freedman at uk.clara.net>
> Sender: nsp-security-bounces at puck.nether.net
> 
> ----------- nsp-security Confidential --------
> 
> AFAIK, IOS marks the IP packets containing BGP update messages with IP Precedence 6, you could use this.
> 
> ------------------------------------------------
> David Freedman
> Group Network Engineering 
> Claranet Limited
> http://www.clara.net
> 
> 
> 
> -----Original Message-----
> From: nsp-security-bounces at puck.nether.net on behalf of Johnson, Ron
> Sent: Wed 3/26/2008 20:49
> To: nsp-security at puck.nether.net
> Subject: Re: [nsp-sec] DDoS Chicken and Egg Problem
>  
> ----------- nsp-security Confidential --------
> 
>  
> It is a shame that there is no mechanism that I am aware of to easily
> flag BGP traffic with an IP priority bit on direct peers. 
> The provider could then setup a QOS queuing policy to always forward
> priority traffic first. 
> 
> It would be nice if Cisco/Juniper had a command like:
> 
> Router bgp 19029
> Bgp priority-bit dscp EF
> !
> 
> There may be a way to set QOS bits on the BGP traffic as it passes
> through the interface between your AS and upstream provider. The easiest
> I can imagine is to ensure your BGP session is not via a direct
> interface to interface connection, but configured eBGP-multihop and
> passes through a router in the middle that could be matching and
> flagging BGP traffic, so the routers with the direct connections would
> QOS enforce based upon these flags.
> 
> This would allow BGP traffic flagged with EF to process through the
> queue first, and avoid BGP session drop due to keepalive failures.
> 
> 
> Ron Johnson
> New Edge Networks
> 
> 
> -----Original Message-----
> From: nsp-security-bounces at puck.nether.net
> [mailto:nsp-security-bounces at puck.nether.net] On Behalf Of David
> Freedman
> Sent: Wednesday, March 26, 2008 12:42 PM
> To: Jason Gardiner; nsp-security at puck.nether.net
> Subject: Re: [nsp-sec] DDoS Chicken and Egg Problem
> 
> ----------- nsp-security Confidential --------
> 
> I see only three options really:
> 
> 1. Getting assured delivery of BGP packets during congestion (no shaping
> for BGP)
> 2. Seperate out-of-band connection for BGP blackhole (get them to run
> you a FastE connection for BGP only)
> 3. Get another provider
> 
> 
> 
> ------------------------------------------------
> David Freedman
> Group Network Engineering 
> Claranet Limited
> http://www.clara.net
> 
> 
> 
> -----Original Message-----
> From: nsp-security-bounces at puck.nether.net on behalf of Jason Gardiner
> Sent: Wed 3/26/2008 19:40
> To: Nsp-Security
> Subject: [nsp-sec] DDoS Chicken and Egg Problem
>  
> ----------- nsp-security Confidential --------
> 
> Hey,
> 
> So we have some GigE feeds with an InterNAP that are rate limited.  A 
> while back, we had a DoS attack that filled the pipe.  Unfortunately the
> 
> provider is doing simple rate limiting, so BGP was caught up in the 
> policing and the sessions dropped.
> 
> We are running remote triggered blackhole with the provider, but the 
> whole exercise raised a very interesting question.  How does one send 
> the BGP community trigger to the provider if the provider isn't doing 
> anything to assure that the BGP session remains stable during an 
> attack?  I suggested exempting BGP from policing to avoid the catch-22, 
> but they didn't see value in doing so.
> 
> Any thoughts or recommendations would be appreciated.
> 
> -- 
> Thanks,
> 
> Jason Gardiner
> $company_name Engineering
> 

On Junipers, network protocol packets are placed in the reserved
"network control" queue which normally has top priority and has reserved
bandwidth on the Ethernet between the RE and the forwarding plane.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751