BGP Flow Specification Version 2

BGP () flow specification (see and ) describes the distribution of traffic filter policy (traffic filters and actions) which are distributed via BGP to BGP peers. The traffic filter policy is applied when packets are received on a router with the flow specification function turned on. Multiple applications utilize the BGP distributed traffic filter policy. These applications include: (1) mitigation of Denial of Service (DoS), (2) enabling of traffic filtering in BGP/MPLS VPNS, and (3)centralized traffic control for networks utilizing either SDN control of router firewall functions. During the deployment of BGP flow specification v1, the following issues were detected: problems due to the lack of clear TLV encoding, desire to order filtering rules, and desire to order actions to provide deterministic interactions of actions. Version 2 of the BGP flow specification protocol addresses these features. This document describes distribution of three new BGP Flow Specification NLRI (3 AFIs (1, 2, and 6) with SAFI (TBD) that allow user-ordered list of traffic match filters, and user-ordered traffic match actions encoded in BGP Wide Communities. This document contains a overview in this section and the following other sections: section 2 - Definitions, section 3 - Rules for dissemination of Flow Specification v2, section 4 - Optional Security, section 5 - IANA considerations, section 6 - security considerations. This section reviews the existing flow specification and provides a logical description of ordered flow specification.

If one considers the reception of the packet as an event, then BGP flow specification describes a set of minimalistic Event-MatchCondition-Action (ECA) policies where the match-condition is defined in the BGP NLRI, and the action is defined either by the default condition (accept traffic) or actions defined in Extended BGP Community values . The initial set of policy and for this policy includes 13 types of match filters encoded the following: specific AFI/SAFIs for the IPv4 and IPv6 AFIs: IPv4 traffic: AFI:1, SAFI:133; IPv6 Traffic: AFI:2 SAFI:133 BGP/MPLS IPv4 VPN: AFI:1, SAFI: 134 BGP/MPLS IPv6 VPN: AFI:2, SAFI: 134 The 13 types of filters are the following: Type 1: Destination Prefix Type 2: Source Prefix Type 3: IP Protocol (v4, ) or Upper Layer Protocol (v6, ) Type 4: Port Type 5: Destination Port Type 6: Source Port Type 7: ICMPv4 Type (v4, ) or ICMPv6 Type (v6, ) Type 8: ICMPv4 Code (v4, ) or ICMPv6 code(v6, ) Type 9: TCP flags (v4, ) Type 10: Packet length Type 11: DSCP marking Type 12: Fragment Type 13: Flow Label (v6, ) The actions proposed in and for exclusion on Extended Community (0xttss) are the following: Traffic rate limited by bytes (0x8006) [2 byte AS, 4 byte float] Traffic action (set by bitmask, bits 47 and 46 defined) (0x8007) rt-redirect IPv4 (0x8008) [2 byte AS, 4 octet value] rt-redirect IPv4 (0x8108) [4 byte IPv4 address, 2 octet value] rt-redirect IPv4 (0x8108) [4 byte AS, 2 octet value] traffic marking (0x8009) (DSCP value) Traffic rate limited by packets (0x800C) [2 byte AS, 4 byte float] rt-redirect IPv6 (0x820D) [2 byte AS, 4 octet value] rt-redirect IPv6 (0x810D) [4 byte IPv4 address, 2 octet value] rt-redirect IPv6 (0x820D) [4 byte AS, 2 octet value] The flow specification filers and actions combine to make up flow specification rules associated with an NRLI. The Extended Communities for actions can be attached to a single rule or multiple rules. Figure 1 shows a diagram of the flow specification data structures.

+--------------------------------------+ | Flow Specification (FS) | | Policy | +--------------------------------------+ ^ ^ ^ | | | | | | +--------^----+ +-------^-------+ +-------------+ | FS Rule1 | | FS Rule | ... | FS rule | +-------------+ +---------------+ +-------------+ : : : : ...: :........ : : +---------V---------+ +----V-------------+ | Rule Condition | | Rule Action | | in BGP NLRIs | | in BGP extended | | AFIs: 1 and 2 | | Communities | | SAFI 133, 134 | | | +-------------------+ +------------------+ : : : : : : .....: . :..... .....: . :..... : : : : : : +----V---+ +---V----+ +--V---+ +-V------+ +--V-----++--V---+ | Match | | match | |match | | Action | | action ||action| |Operator| |Variable| |Value | |Operator| |variable|| Value| |*1 | | | | | |(subtype| | || | +--------+ +--------+ +------+ +--------+ +--------++------+ *1 match operator may be complex. Figure 1: BGP Flow Specification Policy

An minimal ordered specification of the rules would include an order indicator per rule. The inclusion of names for each rule, match condition and action allows for logical indirection. The existing extended community which tags multiple NLRIs could be saved as an indirect reference by name. For Flow specification v1 actions, the Extended actions could be assigned default names. The actions could be linked to many NLRIs. Figure 2 below provides a logical diagram of the ordering of rules and the association of names per rule, rule match action, and rule action. Since many policies also group data flow specifications under rule groups, many implementations may order set of rules under a particular group policy. Network Management display of BGP filers may use the Rule Grouping mechanism to display the filters.

+--------------------------------+ | Rule Group | +------------------------------ -+ ^ ^ ^ | ---------- | | | ------ | | | +--------^-------+ +-------^-----+ +---^-----+ | Rule1 | | Rule2 | ... | Rule-n | +----------------+ +-------------+ +---------+ : : : : :.................: : : : : |.........: : : +--V--+ +--V--+ : : | name| |order| .........: :..... +-----+ +-----+ : : : : +----------------V----+ +-----V------- --+ |Rule Match condition | | Rule Action | +---------------------+ +-----------------+ : : : : : : : : +--V--+ : : : +--V--+ : : : | name| : : : |name | : : : +-----+ : : : +-----+ : : : : : : : : :........... : : : : : : .....: . :..... ..: :..... : : : : : : : +----V---+ +---V----+ +--V---+ +-V------++--V-----++--V---+ | Match | | match | |match | | Action || action ||action| |Operator| |variable| |Value | |Operator||Variable|| Value| +--------+ +--------+ +------+ +--------++--------++------+ Figure 2: Order Flow Specification Data storage

NETCONF: The Network Configuration Protocol . RESTCONF: The RESTCONF configuration Protocol BGPSEC - secure BGP updated by BGP Session ephemeral state - state which does not survive the loss of BGP peer, Ephemeral state - state which does not survive the reboot of a software module, or a hardware reboot. Ephemeral state can be ephemeral configuration state or operational state. configuration state - state which persist across a reboot of software module within a routing system or a reboot of a hardware routing device.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

The BGP Flow Specification version 2 (BGP-FS v2) uses an NRLI with the format for AFIs for IPv4 (AFI = 1), IPv6 (AFI = 2), and L2VPN (L2VPN = 6) with a SAFI of (TBD=xx). This NLRI information is encoded using MP_READ_NRI and MP_UNREACH_NLRI attributes defined in . Whenever the corresponding application does not require Next-HOP information, this shall be encoded as zero-octet length Next Hop in the MP_REAC_NLRI and ignored upon receipt. Implementations wishing to exchange flow specification rules MUST use BGP's Capability Advertisement facility to exchange the Multiprotocol Extension Capability Code (Code 1) as defined in , and indicate a capability for flow specification v2 (TBD).

The AFI/SAFI NLRI for BGP Flow Specification has the format:

+------------------------+ |length (2 octets) | +------------------------+ | Sub-TLVs (variable) | | +====================+ | | | order (2 octets) | | | +--------------------+ | | | type (2 octets) | | | +--------------------+ | | | length (2 octets) | | | +--------------------+ | | | value (variable) | | | +====================+ | +------------------------+ Figure 3 -Flow Specification v2 format where: order - is 2 octet field indicating the flow-specification global rule order type - is one of the following types identifier (value = 00) match rule (value = 01) with default action of block traffic match rule (value = 02) with default action of permit traffic match rule (value = 03) with action TLVs match rule (value = 04) with Wide Communities Action TLVS match rule (value = 05) with tunnel matching from (draft-ietf-idr-flowspec-nv03-13.txt) length - is the length of the NLRI, value is a series of sub-TLVs fields (TLV) depended on the type value defined in the sections below. Filters are processed in the order specified by the user.

The BGP flow specification V2 identifier sub-TLVs use the following format:

+--------------------------+ |length (2 octets) | +--------------------------+ | Sub-TLVs (variable) | | +======================+ | | | order (2 octets) | | | +----------------------+ | | | type = 01 | | | +----------------------+ | | | length (variable) | | | +----------------------+ | | | value field | | | | AFI/SAFI field (4) | | | | components (variable | | | +======================+ | +--------------------------+ Figure 5 - Flow specification v2 with default Block traffic flow Flow Specification v2 with a default Action of block traffic has the following sub-TLVs in the value field: a value of an AFI/SAFI field with 4 bytes [AFI 2 Bytes, SAFI 1 byte, 1 Byte reserved] Component fields as defined in the following documents: , , draft-ietf-idr-flowspec-l2vpn

The BGP flow specification V2 identifier sub-TLVs use the following format:

+--------------------------+ |length (2 octets) | +--------------------------+ | Sub-TLVs (variable) | | +======================+ | | | order (2 octets) | | | +----------------------+ | | | type = 01 | | | +----------------------+ | | | length (variable) | | | +----------------------+ | | | value field | | | | AFI/SAFI field (4) | | | | components (variable | | | +======================+ | +--------------------------+ Figure 6 - Flow specification v2 with default permit traffic flow Flow Specification v2 with Filters and Default action of block traffic has the following sub-TLVs in the value field: a value of an AFI/SAFI field with 4 bytes [AFI 2 Bytes, SAFI 1 byte, 1 Byte reserved] Component fields as defined in the following documents: , , draft-ietf-idr-flowspec-l2vpn

The BGP flow specification V2 identifier sub-TLVs use the following format:

[Type (2 bytes)][Extended-Community-type (2 bytes)][6 bytes] Figure 8 - Extended Community action type encoding The Extended community types are the following: Type 1: Traffic rate limited by bytes (0x8006) [2 byte AS, 4 byte float] Type 2: Traffic action (set by bitmask, bits 47 and 46 defined) (0x8007) Type 3: rt-redirect IPv4 (0x8008) [2 byte AS, 4 octet value] Type 4: rt-redirect IPv4 (0x8108) [4 byte IPv4 address, 2 octet value] Type 5: rt-redirect IPv4 (0x8108) [4 byte AS, 2 octet value] Type 6: traffic marking (0x8009) (DSCP value) Type 7: Traffic rate limited by packets (0x800C) [2 byte AS, 4 byte float] Type 8: rt-redirect IPv6 (0x820D) [2 byte AS, 4 octet value] Type 9: rt-redirect IPv6 (0x810D) [4 byte IPv4 address, 2 octet value] Type 10: rt-redirect IPv6 (0x820D) [4 byte AS, 2 octet value] Component fields as defined in the following documents: , , draft-ietf-idr-flowspec-l2vpn The BGP-FS version 2 actions are passed in a Wide Community atom with the following format.

The BGP-FS version 2 actions are passed in a Wide Community atom with the following format:

+--------------------------+ | Atom ID (4 octets) | +--------------------------+ | order (2 octets) | +--------------------------+ | Action type (2 octets) | +--------------------------+ | Action length (2 octets) | +--------------------------+ | Action Values (variable) | | (multiples of 2 octets) | +--------------------------+ Figure 10 Wide Community Atom where: Action type (2 octets) - is the type of action. These actions can be standardized (0x0001 - 0x3ffff), vendor specific (0x40000-0x7FFFF), or reserved (0x0, 0x80000-0xFFFFFFFF). Action length - length of actions including variable field, Action values - value of actions (variable) defined in individual definitions. The BGP Flow Specification (BGP-FS) atom can be part of the Wide Community container (type 1) or the BGP Flow Specification Atom can be part of the BGP Flow Specification container (type 2) which will have:

+-----------------------------+ | Source AS Number (4 octets)| +-----------------------------+ | list of atoms (variable) | +-----------------------------+ figure 11

This section needs to be discussed with the authors of draft-ietf-idr-flowspec-nv03.

This section discusses the optional BGP Security additions for BGP-FS v2 relating to BGPSEC and ROA.

Flow specification v1 ( and ) do not BGP Flow specifications to be passed BGPSEC BGP Flow Specification v2 can be passed in BGPSEC, but it is not required.

BGP Flow Specification v2 can utilize ROAs in the validation. If BGP-FS v2 is used with BGPSEC and ROA, the first thing is to validate the route within BGPSEC and second to utilize BGP ROA to validate the route origin. The BGP-FS peers using both ROA and BGP-FS validation determine that a BGP Flow specification is valid if and only if one of the following cases: If the BGP Flow Specification NLRI has a IPv4 or IPv6 address in destination address match filter and the following is true: A BGP ROA has been received to validate the originator, and the route is the best-match unicast route for the destination prefix embedded in the match filter; or If a BGP ROA has not been received that matches the IPv4 or IPv6 destination address in the destination filter, the match filter must abide by the and validation rules of: The originator match of the flow specification matches the originator of the best-match unicast route for the destination prefix filter embedded in the flow specification", and No more specific unicast routes exist 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 best match is defined to be the longest-match NLRI with the highest preference.

The distribution of Flow Specifications from a centralized server supports mitigation of DoS attacks. suggests the following redefined procedure for validation for this case: A route is valid if the following conditions holds true: The originator of the flow specification matches the originator of the best-match unicast route for the destination prefix embedded in the flow specification. The AS_PATH and AS4_PATH attribute of the flow specification are empty (on originating AS) The AS_PATH and AS4_PATH attribute of the flow specification does not contain AS_SET and AS_SEQUENCE segments (on originating AS with AS Confederation) This reduced validation mechanism can be used for BGP-FS v2 within a single domain.

This section complies with This document requests: SAFI be defined for IPv4 (AFI = 1), IPv6 (AFI=2), L2VPN (AFI=25) for BGP-FS SAFI be defined for BGP/MPLS IPv4 (AFI = 1), IPv6 (AFI=2), L2VPN (AFI=25) for BGP-FS Registry be created for BGP-FS V2 filter component types with the following ranges: 0x00 - reserved 0x01 - 0x3FFFF - standards action 0x40000- 0x7FFFF - vendor specific filters 0x80000 -0xFFFFFFFF - reserved 0x80000 -0xFFFFFFFF - reserved Registry be created for BGP-FS v2 action types with the following ranges: 0x0 - reserved 0x01 - 0x3ffff - standards action 0x40000 - 0x7ffff - vendor actions 0x80000 - 0xFFFFFFF - reserved

The use of ROA improves on to check the route orgination is valid can improve the validation sequence for a multiple-AS environment. The use of BGPSEC to secure the packet can increase security of BGP flow specification information sent in the packet. The use of the reduced validation within an AS can provide adequate validation for distribution of flow specification within an single autonomous system for prevention of DDOS. Distribution of flow filters may provide insight into traffic being sent within an AS, but this information should be composite information that does not reveal the traffic patterns of individuals.