Internet2 Network Security SIG

["Garrett, Seth B" <>]

Michael,

 

We’ve been running the loopback BGP peer limit-tcp-syn policer on our campus network without any issues so far.  I think the concern of one policer over all BGP-Peers is valid though.  The introduction of the Junos DDoS subsystem could be a less risky method as you mentioned.  A prefix-action policer could help distribute the sources being policed too, but the DDoS subsystem is probably still superior to that for protecting the control plane since it can use PPS.  I want to check out some of the postings by Saku Ytti you mentioned.  I’ll probably reach out to you on that specifically with some questions.

 

Also, thanks for pointing out the 16.x release for the PPS firewall filter policers.  I am looking forward to the ability to do PPS filters in a Junos firewall filter.   That will simplify some unrelated PPS oriented DDOS policers.

 

Thanks,

 

Seth Garrett
Principal Network Engineer
Indiana University

 

 

From: [mailto:] On Behalf Of Michael Hare
Sent: Sunday, April 30, 2017 11:57 AM
To:
Subject: RE: [Security-WG] I2 - Rate Limiting BGP Draft

 

When the policer is activated a "legit" BGP session may have a hard time reestablishing (if required).  There is also no reason a determined attacker couldn’t slip a high PPS rate through simply by using the TCP flags you’ve excluded (including ACK).  If the policer is rarely activated and your BGP sessions are stable in general, it is a game of statistics and risk/reward. 

  

I personally haven’t tried the lo0 policer approach so I don’t have historical data on such an approach to make a recommendation for it.  I don’t have a copy handy but from what I recall the Hank Mills MX book doesn’t suggest a policer here.

 

My understanding is that this approach has worked well for I2, non the less I would yank 500k from your example and replace with $X to avoid copy/pasting without reading/understanding your disclaimers.  Being human I’m just as guilty for including the “5000” and “500” parameters in my original ddos-protection example..

 

-Michael

 

From: [] On Behalf Of gcbrowni
Sent: Friday, April 28, 2017 12:48 PM
To:
Subject: Re: [Security-WG] I2 - Rate Limiting BGP Draft

 

Brad & Michael:

 

Great comments. I’ll update the article.

 

 

Michael, is your worry 500k of BGP traffic of the 500k of SYN(&!ack), FIN, RST traffic that’s in the term?

 

 

I’m generally skeptical on the entire technique, especially with the other protections available. I’ve tried to walk a line between suggesting that  and still providing some examples. Should we just eliminate the examples and instead suggest that folks follow the other practices?

 

 

 

 

 

 

 

 

On Apr 27, 2017, at 11:33 AM, Michael Hare <> wrote:

 

If running JunOS I'd personally advise against the JunOS lo0 filter policer approach mentioned below [just the policer part, the prefix-list approach is spot on].  Using that approach a single looped peer will cause packet loss on your iBGP sessions.

 

In our small network (AS3128) our DFZ speakers commonly see bursts above 1Mbps.

 

graph:

https://stats.uwsys.net/cgi-bin/genstatspage.fcgi?end_time=4%2F27%2F2017&rrdfunc=MAX&rrdlist=b796b317137b5a50630bed554a333b70&stack=2&stack_by=Everything&start_time=1%2F1%2F2017&time=CUSTOM

 

Juniper's ddos-protection features are probably where best to focus efforts in that it has the ability to automatically police (or drop) effectively on an IFL basis.  The ddos-protection subsystem has the added benefit of supporting PPS whereas JunOS firewall filters do not support PPS filtering until 16.X.

 

In addition to looking at the O Reilly Juniper MX Series v2 book I recommend Saku Ytti's many public postings on this topic with the following being a good (technical) entry.  He explains well the problem/limitations of the ddos-protection subsystem including it's flow based tracking.

 

http://blog.ip.fi/2014/03/quick-look-at-trio-ddos-protection-with.html

 

I took Saku's approach to heart, stored "show ddos-protection protocols statistics" max arrival, drop pps and current pps into RRD file and set values on our systems after collecting data for a few months.  I'd be happy to share our settings but they cannot be deployed blindly on any other production network.

 

In short I have many stanzas hand tuned, and they look like this.

 

m7h@r-uwmadison-hub-re0# show groups sync_ddos-protection-mx2010 system ddos-protection protocols bgp            

aggregate {

    bandwidth 5000;

    burst 500;

    flow-level-bandwidth {

        logical-interface XXXX;

    }

    flow-level-detection {

        subscriber off;

        logical-interface on;

    }

}

 

-Michael

 

From:  [] On Behalf Of gcbrowni
Sent: Thursday, April 27, 2017 9:51 AM
To: 
Subject: [Security-WG] I2 - Rate Limiting BGP Draft

 

Folks,

 

Here’s the latest draft, on Rate-Limiting BGP. I also included a little information on the DDOS protections the platforms have built in. 

 

The comments about it being more trouble than its worth, especially in light of targeted BGP-speaker ACL’s, border spoofing protections, and GTSM, resonated a lot as I wrote this.

 

As always, I appreciate you comments,

 

-G

 

 

 

 

 

 

 

 

https://spaces.internet2.edu/x/5ZCTBg

 

Rate-limiting, in the context RFC 7454, is discussed in the context of protecting the RE from BGP events received at a high rate. The goal being the protection of the control plane of the router and not letting "bad" control traffic impact your desired BGP updates. The RFC also points to RFC 6954 for more information on general control plane protections, but in the words of the RFC: 

In addition to strict filtering, rate-limiting MAY be configured for accepted BGP traffic. Rate-limiting BGP traffic consists in permitting only a certain quantity of bits per second (or packets per second) of BGP traffic to the control plane. This protects the BGP router control plane in case the amount of BGP traffic surpasses platform capabilities.

The topic contains significant complexity. Setting the limit too low may impact convergence and stability. Setting the limits too high can effectively eliminates the benefits. Complicating this is a lack of good material on what effective settings, or guidelines in general. In other words, while there is academic agreement that this should be an effective tool, pragmatically there is little advice available on what settings to use in which situations.

If a device is already blocking unauthorized BGP speakers, say through the use of a dynamic filter, in combination with other techniques such as GTSM and internal border spoofing protections, then the issue may be moot as the other techniques offer significantly more protections. Newer router code from vendors also includes some protection schemes, on by default, that help protect the control plane from becoming overloaded. 

 

Juniper Example

A Juniper example follows. A term is defined in the loopback ingress filter that allows specifies that only certain traffic types from BGP peers (and MSDP peers in this case) through at a 500k drop limit, which is defined in a separately configured policer policy. Note that the 500k limit is only a placeholder; there's no assertion that this is the correct setting.

 

term limit-tcp-syn {               

  from {                   

    source-prefix-list {                       

    BGP-PEERS;                       

    MSDP-PEERS;                    }                  

     protocol tcp;                   

     tcp-flags "(syn & !ack) | fin | rst";                }                  then {                   

    policer 500K-drop;                   

    next term;                }

 

 policer 500K-drop {       

  if-exceeding {           

    bandwidth-limit 500k;          

     burst-size-limit 62k;        }       

  then discard;    }

 

Juniper has an entire series of articles available that details the (default) internal DDOS protections for their RE's. It's worth becoming familiar with the default RE protections Juniper provides. It is at:

https://www.juniper.net/documentation/en_US/junos12.3/information-products/pathway-pages/config-guide-ddos/ddos-protection.html

 

 

Cisco Example

The Cisco example uses IOS-XR for Local Packet Transport Services. Hardware policers on the line cards limit traffic sent up the stack. Packets per second are defined for three types of BGP traffic. bgp-cfg-peer are new sessions and sessions that are not yet 'Established.' bgp-know are established sessions and bgp-default is the 'default' entry for bgp traffic; things not falling in to other buckets, etc. 

 

lpts pifib hardware police

  flow bgp-cfg-peer 2000

  flow bgp-default 2500

  flow bgp-known 1500

 

Cisco has a feature set called Control Plane Policing, or COPP, as well as Control Plane Protection, CPPr.

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/configuration/guide/book/copp.html

 

There are also articles about LPTS, such as:

http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r4-2/addr_serv/configuration/guide/b_ipaddr_cg42a9k/b_ipaddr_cg42a9k_chapter_0111.html

 

Cisco has several good summary article of DDOS that describes various DDOS and protection techniques.

http://www.cisco.com/c/en/us/about/security-center/guide-ddos-defense.html

http://www.cisco.com/c/en/us/about/security-center/copp-best-practices.html

 

Brocade Example

Brocade has a variety of solutions for filtering traffic via ACL's to the local CPU, as well as protecting the CPU from various Layer-2 events, but it has no specific abilities with regard to BGP rates. There are some built in protections against SMURF and TCP SYN attacks.

http://www.brocade.com/content/html/en/configuration-guide/NI_05800a_SECURITY/GUID-4DDF53B1-14EB-45AB-9B23-EA7E5A52C2CE.html

 

Attachment: smime.p7s
Description: S/MIME cryptographic signature