Community FlowSpec

Last updated: $Date: 2011/01/10 17:55:51 $
Updates to:


Distributing accurate and reliable firewall filter rules has largely been relegated to custom or proprietary solutions. With the publication of IETF RFC 5575 - Dissemination of Flow Specification Rules, there is now a standards-based approach to just that sort of thing. A flow specification rule or simply flowspec for short, leverages the concept of a "flow", a common concept used in modern IP traffic forwarding devices, particularly routers. A flow is a n-tuple set of IP traffic charactistics. It is inherently defined as being one-way, since the set of attributes include both a source and destination IP address or prefix. Other attributes may also include IP protocol (e.g. ICMP, TCP or UDP) and applicable protocol characteristics such as protocol port, ICMP type, ICMP code, TCP flags, packet length, differentiated services code point (DSCP) and so on. A flow specification rule thus consists of one or more combinations of these attributes and associated actions to be applied to flows matching these rules. While not a complete distributed firewall filter rule system, flowspec can provide that sort of functionality.

Team Cymru is implementing a community-based flowspec system that builds on our past experience and expertise to leverage a technology that can widely benefit the Internet community. We are well known for providing a bogon route service over BGP. However, for a variety of reasons, some networks cannot make use of that service to due to inherent network design issues. Furthermore, that service does not fully guard against more specific route announcements. Using the power of flowspec, we can provide a flowspec-based bogon feed that addresses some of the limitations of a traditional remote triggered black hole (RTBH) service.

If you would like to participate in this new flowspec based bogon service, please review the technical details in the remainder of this document and contact John Kristoff <> for a peering session. Please note, at this time, Team Cymru Community FlowSpec is NOT a production service. It is being offered on a trial basis only with absolutely no guarantee of future support or reliability. Plan accordingly if we wish to participate in the trial. That said, if the trial proves successful we do hope to offer his as a production service in the near future.

Getting Started

To receive a Community FlowSpec feed you need a BGP-speaking device that understands flowspec as specified in IEF RFC 5575. As of this writing, only a handful of solutions exist, but most notably are Juniper Networks routers. This is the platform we know well and can provide some configuration and management assistance with. If you have knowledge of another platform, can help us test it and can provide configuration examples to include here we would greatly appreciate it.

Before starting you need to determine a BGP IP peering address and an autonomous system number (ASN). Ideally we would like to exchange peering information with you using PGP-encrypted email. Please use John Kristoff's PGP key for this trial service. Send us the above information and we will in return send you our BGP peering address, ASN and any pertinent information not included on this page. Below is a generic template for setting up peering and the reception of flowspec rules using Juniper JUNOS routers in the protocols->bgp configuration scope:

group community-fs {
    type external;
    multihop;                    /* required */
    local-address;     /* TODO: change to your local address */
    local-as 65001;              /* TODO: change to your local ASN */
    export no-routes;            /* we don't want any routes back */
    peer-as 65000;               /* TODO: to be provided by Team Cymru */
    passive;                     /* we'll open the connection */
    neighbor {         /* TODO: to be provided by Team Cymru */
        traceoptions {           /* TODO: optional, for debugging */
            file community-fs;
            flag all;
        family inet {
            flow {
                prefix-limit {   /* TODO: optional, route defensively */
                    maximum 100;
                    teardown 80 idle-timeout forever;
                no-validate all-routes;  /* required */
Under the policy-options configuration scope here example policies referenced in the template above:
policy-statement all-routes {
    then accept;
policy-statement no-routes {
    then reject;

Frequently Asked Questions (FAQ)

Why not just use remote triggered black holes (RTBHs)?

BGP RTBH work very well in certain circumstances. You may wish to still use it as a technique in various cases. However, there are three areas where such an approach may be inadequate. First, a RTBH will affect all traffic to the black hole route, indiscriminate of protocol, application or intent. Second, more specific route announcements made either inadvertently or surrepitiously may bypass the black hole. Third, in some circumstances, particularly when using unicast reverse path forwarding (uRPF) checks for source address spoofing prevention, the technology and the network infrastructure are incompatible.

What is the exact flowspec rule we get for each bogon?

The initial trial feed is a set of flow specification discard rules for any packet with a bogon source address.

What about packets to bogon destination addresses?

We could add this if warranted, but the rules would change slightly to accommodate IP multicast ( and the limited local broadcast address (, which are legitimate destinations for many networks. If this would be a useful feed to you, please let us know so we can make plans to make it available if there is demand.

Is discard the only flowspec rule action choice?

At this time yes.

Can you provide a full IPv4 bogon feed?

Not at this time. The Team Cymru full bogons list is of significant length (over 6000 routes as of this writing). In our experience, on some gear we have tested this on, it will not work reliably. We will revisit larger feeds if demand dictates it.

Can we peer using IPv6 connectivity?

There is no technical restriction preventing us from doing so, but we have not enabled IPv6 connectivity at this time. Let us know if IPv6 connectivity is important to you. If we have demand we can justify setting it up.

Can you provide a IPv6 bogon feed?

At this time it is IPv4 only. We are still investigating the feasibility of supporting a IPv6 bogon flowspec service. The primary constraint may likely be the sheer number of flowspec rules. See the FAQ entry regarding a full IPv4 bogon feed.

Can we use a private ASN for peering?

Yes and in fact it might not be a bad idea to do so since it may help to keep Community FlowSpec rules from propagating further than they ought to through widely deployed and easy to configure private ASN export policies.

How will the feed be keep up to date?

This service will track the Team Cymru Aggregated bogon list and sync with it approximately once a day. Your BGP session therefore may be refreshed daily to reflect any bogon listing changes.

Can we use a Cisco router for this service?

No. Cisco does not currently support flowspec.

What other implementations can we use with this service?

We are not aware of any other implementation of IETF RFC 5575 besides the one from Juniper Networks that will usefully interoperate with our service. If you know of one, please let us know!

Can we peer using TCP MD5 authentication or IPsec?

At this time, no. If this is something you are interested, we'd like to know. This is currently a limitation in our existing implementation, but please see the answer to the "How can I help..." question.

Why does the Team Cymru end do the active TCP open?

This is a limitation in our current implementation. We do realize this makes the session more prone to 3rd party tampering. We do hope to remove this limitation in the future.

How can we reject specific flowspec routes by policy?

We are not aware of any way to use policies to reject select flowspec routes. If you know of some ways to help limit specific flowspec routes, please let us know.

Do you tag your flowspec routes with any communities?

Not at this time. We do plan to tag them as NO_EXPORT in the future. We also would like to AS path prepend the flowspec routes by one to three AS hops in the future as a small, but additional safeguard.

How do we monitor flowspec routes and rules?

In JUNOS, show route table inetflow.0 extensive and show firewall filter __flowspec_default_inet__ can be helpful.

Can you provide a flowspec feed for ... ?

We have had a lot of questions about setting up a flowspec feed to help filter the latest Internet threats. There is at least one technical challenge and a host of practical issues in doing so. First, there are numerous potential threats. Trying to enumerate them all and distribute them in a timely fashion is not only a challenge in itself, but may prove burdensome on flowspec-capable devices. Many platforms that implement flowspec may not be able to store and process the number of flowspec rules it might require to provide a comprehensive service. Second, this service is not an "Internet firewall". We will focus on the flowspec rule sets that are, perhaps limited, easy for partners to implement, reliable and useful. If you have some ideas that fit neatly into our focus, please contact us with your suggestions and we will review and implement them if we can.

How can we help improve this service?

Thanks for asking! If you have any flowspec-cable gear that you can donate, we would love to hear from you. We would be especially interested in hearing about other flowspec implementations that we have not had a chance to work with. If you have any configuration or documentation enhancements that need to be made, please send them to us. If you have an idea for a set of flowspec rules we might want to incorporate, please send us your thoughts. If know of some other network operators who run flowspec-capable devices and could benefit from a service like this, please introduce them to us.

$Id: community-fs.html,v 1.8 2011/01/10 17:55:51 jtk Exp $