IDR Working Group S. Hares
Internet-Draft Huawei
Intended status: Standards Track June 25, 2016
Expires: December 27, 2016

BGP Flow Specification Version 2
draft-hares-idr-flowspec-v2-00.txt

Abstract

BGP flow specification version 1 (RFC5575) describes the distribution of traffic filter policy (traffic filters and actions) which are distributed via BGP to BGP peers. Three applications utilize this traffic filter policy: (1) mitigation of Denial of Service (DoS), (2) enabling of traffic filtering in BGP/MPLS VPNS, and (3)centralized traffic control for networks with SDN or NFV controllers. Application of centralized traffic utilizing BGP Flow Specification traffic filters may need user-ordered filters rather than RFC5575's strict ordering of filters and defined ordering of actions.

This document proposes a new BGP Flow specification version 2 that supports user-order of filters and actions plus allowing more actions

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on December 27, 2016.

Copyright Notice

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Introduction

BGP flow specification [RFC5575] describes the distribution of filters and actions that apply when packets are received on a router with the flow specification function turned on. 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 were 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 Communiites values [RFC4360].

The initial set of policy [RFC5575] and [RFC7674] for this policy includes 12 types of match filters encoded in two application specific AFI/SAFIs for the IPv4 AFI.

The popularity of these flow specification filters in deployment for DoS and SDN/NFV has led to the requirement for more BGP flow specification match filters in the NLRI and more BGP flow specification actions.

This document describes distribution of two new BGP Flow Specification NLRI (2 AFI/SAFI pairs) that allow user-ordered list of traffic match filters, and user-ordered traffic match actions encoded in BGP Wide Communities.

The rest of this section provides background on BGP Flow Specification filters interaction with I2RS Filter-Based RIBs carried by NETCONF/RESTCONF protocol. Figure 1 below is a logial description of BGP Flow Specification rules that combine filters in BGP NLRI with actions in BGP Extended communities.

 
     +-----------------------------+
     | Flow Specification (FS)     | 
     |  Policy                     | 
     +-----------------------------+	
       	 ^                  ^  
         |                  | 
         |                  |              
+--------^-------+   +-------^-------+     
|   FS Rule      |   |   FS Rule     | 
+----------------+   +---------------+     
                       :          :        
                       :          :        
                 ......:          :.....   
                 :                     :
       +---------V---------+      +----V-------------+
       |  Rule Condition   |      |   Rule Action    |
       |  in BGP NLRIs     |      | in BGP extended  |
       | SAFI 133, 134     |      | Communities      | 
       +-------------------+      +------------------+
           :     :    :                 :      :    :
      .....:     .    :.....       .....:      .    :.....
      :          :         :       :           :         :
 +----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 

BGP Flow Specification (BGP-FS) ([RFC5575] and [I-D.raszuk-idr-rfc5575bis]) describes how to distribute the BGP Flow Specification policy as BGP routes which are locally configured on the originating BGP peer. Like BGP routes, if the BGP peer session drops then BGP Flow Specification routes are dropped. [RFC5575] and [I-D.raszuk-idr-rfc5575bis] do not indicate how the BGP Flow Specification policy is installed in the kernel.

1.1. RFC5575 vs. NETCONF/RESTCONF/I2RS Flow Filters

[RFC5575] describes the dissemination of flow specification rules policy is similar to the the statically configured Filter-Based RIB described in [I-D.ietf-i2rs-fb-rib-data-model], and the I2RS Filter-Based RIB ([I-D.ietf-i2rs-fb-rib-info-model], [I-D.ietf-i2rs-fb-rib-data-model], [I-D.ietf-i2rs-pkt-eca-data-model]). These FB-RIBs start on the reception of a packet using match filters to match frames (L2) or packet data (L3/L4/Application), and perform actions as shown in figure 2.

 
    +-----------+     +------------+		
    |Rule Group |     | Rule Group |
    +-----------+     +------------+					
       	 ^                   ^  
		 |                   | 
         |                   |              
+--------^-------+   +-------^-----------+     
|      Rule      |   |     Rule          | 
+----------------+   +-------------------+     
                      :  :   :    :     
    :.................:  :   :    :
    :	       |.........:   :    :
 +--V--+    +--V--+          :    :        
 | name|    |order| .........:    :.....   
 +-----+    +-----+ :                  :
                    :                  :
     +--------------V-------+       +--V------------+
	 | Rule Match condition |       | Rule Action   |
     +----------------------+       +---------------+
           :     :    :                 :     :    :
      .....:     .    :.....       .....:     .    :.....
      :          :         :       :          :         :
 +----V---+  +---V----+ +--V---+ +-V------++--V-----++--V---+
 |  Match |  | match  | |match | | Action || action ||action|
 |Operator|  |variable| |Value | |Operator||Variable|| Value|
 +--------+  +--------+ +------+ +--------++--------++------+

   Figure 2: I2RS Filter-Based RIB Policy 

[I-D.ietf-i2rs-fb-rib-data-model] suggests that the storage of BGP Flow Specification routes in the kernel should utilize the same format as the statically configured FB-RIB and the I2RS ephemeral FB-RIB so that these traffic filters may be compared. This draft also proposes that precedence between these three sources of filters in the kernel (statically configured, I2RS ephemeral, and BGP ephemeral routes) can either set by local policy or defaults. If it is set by defaults [I-D.ietf-i2rs-fb-rib-data-model] suggests the default precedence between static, I2RS, and BGP-FS installed filters is:

2. Definitions

2.1. Definitions and Acronyms

2.2. RFC 2119 language

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 [RFC2119].

3. Dissemination of BGP Flow Specification version 2 NLRI and Wide Communities

The BGP Flow Specification version 2 (BGP-FS v2) uses an NRLI with the format for AFI/SAFI (SAFI = TBD) for IP flow, and AFI/SAFI for BGP/MPLS (SAFI = TBD). This NLRI information is encoded using MP_READ_NRI and MP_UNREACH_NLRI attributes defined in [RFC4760]. 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.

Implementatinos wishing to exchange flow specificastion rules MUST use BGP's Capability Advertisement facility to exchange the Multiprotocol Extension Capability Code (Code 1) as defined in [RFC4760].

3.1. Encoding of BGP-FS v2 Filters

 +------------------------+
 |length (2 octets)       |
 +------------------------+
 | Sub-TLVs (variable)    |
 | +====================+ |
 | | order (2 octets)   | |
 | +--------------------+ |
 | | type (2 octets)    | |
 | +--------------------+ |
 | | length (2 octets)  | |
 | +--------------------+ |
 | | value (variable)   | |
 | |[multiples of       | | 
 | | 2 octets]          | |
 | +====================+ |
 +------------------------+
 
 Figure 16 - NRLI revision 
  

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

where:

Filters are process in the order specified by the user. If multiple filters exist for the same order, the strict filter ordering defined in [RFC5575] and [I-D.raszuk-idr-rfc5575bis] will be used for the filters with the same value for user order.

3.2. Encoding of BGP-FS v2 Actions

The BGP-FS version 2 actions are passed in a Wide Community [I-D.ietf-idr-wide-bgp-communities] atom with the following format.


+--------------------------+
| order (2 octets)         |
+--------------------------+
| Action type (2 octets)   |
+--------------------------+
| Action length (2 octets) |
+--------------------------+
| Action Values (variable) |
| (multiples of 2 octets)  | 
+--------------------------+

Wide Community Atom 
figure 17

where:

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

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:

3.3. Required NLRI Validation

Same as [RFC5575] and [I-D.raszuk-idr-rfc5575bis].

4. Optional Security Additions

This section discusses the optional BGP Security additions for BGP-FS v2: BGPSEC [I-D.ietf-sidr-bgpsec-protocol], ROA [RFC6482] and revised security for flow specification distributed from a centralized server within an AS [I-D.ietf-idr-bgp-flowspec-oid]. These optional security parameters can be applied per BGP peer.

4.1. BGP FS v2 and BGPSEC

[RFC5575] does not require BGP Flow specifications to be passed BGPSEC [I-D.ietf-sidr-bgpsec-protocol]. BGP FS v2 can be passed in BGPSEC, but it is not required.

4.2. BGP FS v2 with with ROA

BGP-FS v2 can utilize ROAs in the validation. If BGP-FS v2 is used with BGPSEC and ROA, the first thing is to vaildate 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:

The best match is defined to be the longest-match NLRI with the highest preference.

4.3. Revise Flow Specification Security for centralized Server

The distribution of Flow Specifications from a centralized server supports mitigation of DoS attacks. [I-D.ietf-idr-bgp-flowspec-oid] suggests the following redefined procedure for validation for this case:

A route is valid if the following conditions holds true:

This reduced validation mechanism can be used for BGP-FS v2 within a single domain.

5. IANA Considerations

This section complies with [RFC7153]

This document requests:

Registry be created for BGP-FS V2 filter component types with the following ranges:

Registry be created for BGP-FS v2 action types with the following ranges:

6. Security Considerations

The use of ROA improves on [RFC5575] to check the route orgination is valid can improve the validation sequence for a multiple-AS environment. The use of BGPSEC [I-D.ietf-sidr-bgpsec-protocol] 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 [I-D.ietf-idr-bgp-flowspec-oid] 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.

7. References

7.1. Normative References

[I-D.ietf-idr-bgp-flowspec-oid] Uttaro, J., Filsfils, C., Smith, D., Alcaide, J. and P. Mohapatra, "Revised Validation Procedure for BGP Flow Specifications", Internet-Draft draft-ietf-idr-bgp-flowspec-oid-03, March 2016.
[I-D.ietf-idr-wide-bgp-communities] Raszuk, R., Haas, J., Lange, A., Amante, S., Decraene, B., Jakma, P. and R. Steenbergen, "Wide BGP Communities Attribute", Internet-Draft draft-ietf-idr-wide-bgp-communities-02, May 2016.
[I-D.ietf-sidr-bgpsec-protocol] Lepinski, M. and K. Sriram, "BGPsec Protocol Specification", Internet-Draft draft-ietf-sidr-bgpsec-protocol-17, June 2016.
[I-D.raszuk-idr-rfc5575bis] Raszuk, R., McPherson, D., Mauch, J., Greene, B. and S. Hares, "Dissemination of Flow Specification Rules", Internet-Draft draft-raszuk-idr-rfc5575bis-00, June 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC4271] Rekhter, Y., Li, T. and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006.
[RFC4360] Sangli, S., Tappan, D. and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007.
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007.
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J. and D. McPherson, "Dissemination of Flow Specification Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J. and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011.
[RFC6482] Lepinski, M., Kent, S. and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012.
[RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP Extended Communities", RFC 7153, DOI 10.17487/RFC7153, March 2014.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 7223, DOI 10.17487/RFC7223, May 2014.
[RFC7674] Haas, J., "Clarification of the Flowspec Redirect Extended Community", RFC 7674, DOI 10.17487/RFC7674, October 2015.

7.2. Informative References

[I-D.ietf-i2rs-architecture] Atlas, A., Halpern, J., Hares, S., Ward, D. and T. Nadeau, "An Architecture for the Interface to the Routing System", Internet-Draft draft-ietf-i2rs-architecture-15, April 2016.
[I-D.ietf-i2rs-ephemeral-state] Haas, J. and S. Hares, "I2RS Ephemeral State Requirements", Internet-Draft draft-ietf-i2rs-ephemeral-state-09, May 2016.
[I-D.ietf-i2rs-fb-rib-data-model] Hares, S., Kini, S., Dunbar, L., Krishnan, R., Bogdanovic, D. and R. White, "Filter-Based RIB Data Model", Internet-Draft draft-ietf-i2rs-fb-rib-data-model-00, June 2016.
[I-D.ietf-i2rs-fb-rib-info-model] Kini, S., Hares, S., Dunbar, L., Ghanwani, A., Krishnan, R., Bogdanovic, D. and R. White, "Filter-Based RIB Information Model", Internet-Draft draft-ietf-i2rs-fb-rib-info-model-00, June 2016.
[I-D.ietf-i2rs-pkt-eca-data-model] Hares, S., Wu, Q. and R. White, "Filter-Based Packet Forwarding ECA Policy", Internet-Draft draft-ietf-i2rs-pkt-eca-data-model-00, June 2016.
[I-D.ietf-netconf-restconf] Bierman, A., Bjorklund, M. and K. Watsen, "RESTCONF Protocol", Internet-Draft draft-ietf-netconf-restconf-13, April 2016.
[I-D.ietf-netmod-acl-model] Bogdanovic, D., Koushik, K., Huang, L. and D. Blair, "Network Access Control List (ACL) YANG Data Model", Internet-Draft draft-ietf-netmod-acl-model-07, March 2016.
[RFC6074] Rosen, E., Davie, B., Radoaca, V. and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 10.17487/RFC6074, January 2011.
[RFC6483] Huston, G. and G. Michaelson, "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012.

Author's Address

Susan Hares Huawei 7453 Hickory Hill Saline, MI 48176 USA EMail: shares@ndzh.com