[nsp-sec] DDoS Chicken and Egg Problem

[Dave Mitchell]

But if they have a normal policer on the interface, all the packets
coming in regardless of which queue they will be in will be limited,
unless you create a separate term or bucket for network control traffic, no?

They'd probably need something simple like this to make sure to not drop the
BGP sessions:

filter HOSE_CUSTOMER_LESS {
 term PERMIT_BGP {
    from {
        protocol tcp;
	destination-port 179;
    }
    then {
        accept
    }
 }    
 term POLICE_CUST {
    then {
        policer PERMIT_1G;
    }
 }   
}

There may be something you can do with the queue in the actual policer
defs, but I'd have to go find some old configs and find out. 


-dave

On Wed, Mar 26, 2008 at 02:07:18PM -0700, Kevin Oberman wrote:
> ----------- nsp-security Confidential --------
> 

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



> 
> 
> _______________________________________________
> 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.
> _______________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://puck.nether.net/mailman/private/nsp-security/attachments/20080326/2ec06714/attachment-0001.sig>