An overview of BGP Flow Specification Rules and its applicability for Traffic Filtering Applications

1. BGP Flow Spec
Using BGP to Disseminate Flow Specification Rules
for Traffic Filtering Applications
Stefan Fouant
ShortestPathFirst Consulting Services
www.shortestpathfirst.com

2. BGP Flow Specification Overview
• Recently standardized in RFC 5575, entitled “Dissemination of Flow
Specification Rules”
» http://tools.ietf.org/html/rfc5575
• Defines a method for the originator of a BGP NLRI to define and
advertise a flow filter to its upstream BGP peers via BGP
• Multi vendor support
» Supported code on Juniper, Arbor, and others
• Authors:
» Danny McPherson (Arbor)
» Pedro Marques (Juniper)
» Nischal Sheth (Juniper)
» Robert Raszuk (Juniper)
» Barry Greene (Juniper)
» Jared Mauch (NTT/Verio)
ShortestPathFirst Consulting Services
www.shortestpathfirst.net

3. What is Flow Specification
• Flow Specification defines a method and apparatus whereby traffic flow
specifications can be distributed using a new BGP NLRI encoding format
• Primary and immediate motivation is to provide intra and inter provider
distribution of traffic filtering rules to filter DoS and DDoS attacks
• Requires a new address family for BGP
» NLRI type (AFI=1, SAFI=133) for Unicast traffic filtering applications
» NLRI type (AFI=1, SAFI=134) for BGP/MPLS VPN environments
» This also means that routers MUST use BGP’s Capability Advertisement
facility in order to exchange the Multiprotocol Extension Capability Code
as defined in RFC4760 “Multiprotocol Extensions for BGP-4”
• A flow specification is a set of data (represented in an n-tuple) consisting of
several matching criteria that can be applied to IP packet data
• A flow specification received from an peer will need to be validated against
the unicast routing before being accepted
ShortestPathFirst Consulting Services
www.shortestpathfirst.net

4. Flow Specification Motivations
• Question: What is the primary tool used today in
Service Provider networks to deal with DoS and DDoS
attacks?
• Question: Are there any drawbacks to this approach?
ShortestPathFirst Consulting Services
www.shortestpathfirst.net

5. Flow Specification Motivations
• The most commonly used Service Provider security tool used today in order to deal
with DDoS attack is to use BGP to redirect traffic to a discard interface (otherwise
known as Remote Triggered Black Hole (RTBF))
• As such, using BGP to trigger security policy has been the de facto standard for some
time
» The drawback to this approach is that only destination prefixes may be specified
» Furthermore, filtering information is intermingled with routing information
• Flow spec addresses these limitations by allowing for specific NLRI to be defined
which may convey additional information about traffic filtering rules for traffic that
should be discarded
• Since a new address family is defined, filtering information is now separated from the
routing information (and in fact this information is kept in a separate RIB)
• Provides a tool for Network Operators to quickly react to DDOS attacks, saving
valuable time between identification of attack and implementation of various
remediation schemes
ShortestPathFirst Consulting Services
www.shortestpathfirst.net

6. Flow Specification NLRI
• A Flow Specification NLRI is defined which may include several components in order to identify particular
flows
• The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as a 1 or 2 octet NLRI length field
followed by a variable length NLRI value. The NLRI length is expressed in octets
+------------------------------+
| length (0xnn or 0xfn nn) |
+------------------------------+
| NLRI value (variable) |
+------------------------------+
• Type 1 - Destination Prefix • Type 7 - ICMP Type
» Match on Destination IP Prefix » Match on type fields of an ICMP packet
• Type 2 - Source Prefix • Type 8 – ICMP Code
» Match on Source IP Prefix » Match on code fields of an ICMP packet
• Type 3 - IP Protocol • Type 9 - TCP flags
» Match on IP protocol value in IP packets » Match on various TCP flags
• Type 4 – Port • Type 10 - Packet length
» Match on source OR destination TCP/UDP ports » Match on IP Packet length, excluding the L2
• Type 5 – Destination Port headers
» Match on destination TCP/UDP ports • Type 11 - DSCP
• Type 6 - Source Port » Match IP TOS octet
» Match on source TCP/UDP ports • Type 12 - Fragment Encoding
» Match DF bit, First Fragment, Last Fragment,
etc.
ShortestPathFirst Consulting Services
www.shortestpathfirst.net

7. Validation Procedure
• Need to validate the NLRI received in order to prevent spoofing and to eliminate any
concern that the mechanism represents a Denial of Service in and of itself
• A flow specification NLRI must be validated such that it is considered feasible if and
only if:
» a) The "originator" of the flow specification matches the "originator" of the best
match unicast route for the destination prefix embedded in the flow specification
» b) There are no more-specific unicast routes, when compared with the flow
destination prefix, that have been received from a different neighboring AS than
the best-match unicast route, which has been determined in step a)
• The underlying concept is that the neighboring AS that advertise the best unicast
route for a destination is allowed to advertise flow-spec information that conveys a
more or equally specific destination prefix
• As long as traffic filtering rules are restricted to match the corresponding unicast
routing paths for the relevant prefixes, the security characteristics of this proposal are
equivalent to the existing security properties of BGP unicast routing
ShortestPathFirst Consulting Services
www.shortestpathfirst.net

8. Traffic Filtering Actions
• Several BGP extended community values have been standardized to
define the minimum set of filtering actions required in a typical flow-
spec application:
» Traffic-Rate extended community – most likely used for policing
applications, units expressed in bytes per second
» Traffic-Action extended community
− Terminal action (bit 0) – indicate that subsequent filtering rules be applied,
or not
− Sampling (bit 1) – enable traffic sampling and logging for this flow
» Redirect extended community – allows for the traffic to be
redirected to a VRF routing instance for further processing
• Although these extended communities have been defined, it is
expected that each unique implementation will utilize arbitrary
community values for various filtering actions, as heterogeneous
networks and disparate vendors make it difficult to standardize on
such behavior
ShortestPathFirst Consulting Services
www.shortestpathfirst.net

9. Open Forum Discussion
• Future and evolution of BGP Flow Spec
• Applicability to the the current network infrastructure
» Use internally to control internal routers
» Use externally to control upstream ISP routers
• Which ISPs are currently supporting BGP Flow Spec or are
currently beginning technology rollouts?
• Gaining widespread acceptance within the community and
engaging ISPs to begin implementation
• Other areas of concern
» TIDP vs. BGP Flow Spec
− Flow Spec for Inter-AS and TIDP for Intra-AS?
» IPFIX, Netflow v9, Flexible Netflow
− How will these developments change the state of the art in networks?
ShortestPathFirst Consulting Services
www.shortestpathfirst.net

10. Questions?
ShortestPathFirst Consulting Services
www.shortestpathfirst.net