Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

An Introduction to BGP Flow Spec


Published on

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

  • The ISP that fully supports BGP FlowSpec for its customers (both by BGP address family flowspec or by manually setting in Customer Portal page) since April 2016 is RASCOM:
    Are you sure you want to  Yes  No
    Your message goes here

An Introduction to BGP Flow Spec

  1. 1. BGP Flow Spec Using BGP to Disseminate Flow Specification Rules for Traffic Filtering Applications Stefan Fouant ShortestPathFirst Consulting Services
  2. 2. BGP Flow Specification Overview • Recently standardized in RFC 5575, entitled “Dissemination of Flow Specification Rules” » • 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 10. Questions? ShortestPathFirst Consulting Services