Idr Working Group Q. Liang Internet-Draft W. Hao Intended status: Standards Track J. You Huawei Expires: September 26, 2015 March 26, 2015 BGP FlowSpec Outbound Route Filter draft-liang-ospf-flowspec-orf-00 Abstract This document defines a new ORF-type, called the "FlowSpec-ORF". FlowSpec-ORF is applicable in the networks supporting flow specifications (FlowSpec) [RFC5575]. It can be used to filter the FlowSpec rules on demand. Requirements 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]. 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 September 2, 2015. Copyright Notice Copyright (c) 2014 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 Liang, et al. Expires September 26, 2015 [Page 1] Internet-Draft OSPF FlowSpec 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases for FlowSpec-ORF . . . . . . . . . . . . . . . . . 3 3.1. Network Security . . . . . . . . . . . . . . . . . . . . 3 3.2. FlowSpec Capability Negotiation . . . . . . . . . . . 4 4. FlowSpec-ORF Encoding . . . . . . . . . . . . . . . . . . . . 5 4.1. Filters . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. FlowSpec-ORF Capability . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Security considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction The Outbound Route Filtering Capability defined in [RFC5291] provides a mechanism for a BGP speaker to send to its BGP peer a set of Outbound Route Filters (ORFs) that can be used by its peer to filter its outbound routing updates to the speaker. [RFC5292] defines Address Prefix ORF type which can be used to perform address-prefix-based route filtering. This ORF-type supports prefix-length- or range-based matching, wild-card-based address prefix matching, as well as the exact address prefix matching for address families. [I-D.ietf-bess-orf-covering-prefixes] defines Covering Prefixes ORF (CP-ORF) which is applicable in Virtual Hub-and-Spoke VPNs and BGP/ MPLS Ethernet VPN (EVPN) networks. In order to filter the FlowSpec rules [RFC5575], this document defines a new ORF-type, called the "FlowSpec-ORF". FlowSpec-ORF is applicable in the networks supporting flow specifications (FlowSpec) [RFC5575]. It can be used to filter the FlowSpec rules on demand. Liang, et al. Expires September 26, 2015 [Page 2] Internet-Draft OSPF FlowSpec 2014 2. Terminology This section contains definitions for terms used frequently throughout this document. However, many additional definitions can be found in [RFC5291] and [RFC5575]. Flow Specification (FlowSpec): A flow specification is an n-tuple consisting of several matching criteria that can be applied to IP traffic, including filters and actions. Each FlowSpec consists of a set of filters and a set of actions. 3. Use Cases for FlowSpec-ORF 3.1. Network Security Normally each AS corresponds to a management domain. ASs have different security policies. FlowSpec rule dissemination also needs the security consideration. We take FlowSpec Anti-DOS application in L3VPN scenario as an example. In provider-based L3VPN networks, the VPN customer network needs traffic filtering capabilities towards their external network connections (e.g., firewall facing public network connection). As shown in Figure 1, traffic analyzer is deployed in the customer network VPN1 AS1; while attacker is in the VPN1 AS3. When ASBR1 (AS Boundary Router) receives flow specification policies from the traffic analyzer, it will generate and distribute the flow specification rules to ASBR4 through provider network via MP-EBGP. Once ASBR4 receives the flow specification rules, it can block the attack traffic closer to the source of the attacker. +----------------+ +-------+ | FlowSpec Policy| |Target | | Server | +---------+ +----\--+ +---/------------+ |Attacker | \ / +---/-----+ \ / / \ / / \ / / /------\ \ / /------\ / /------\ // \\+\--/-+ +-----+/ \\+-----+ +--/--+/ \\ | VPN1 Site |ASBR | |ASBR | |ASBR | |ASBR | VPN1 Site | \\ AS1 //| 1 +----+ 2 |\ AS2 //| 3 +----+ 4 |\ AS3 // \------/ +-----+ +-----+ \------/ +-----+ +-----+ \------/ Customer Network Provider Network Customer Network Figure 1: Scenario 1 - Anti-DOS based on FlowSpec Liang, et al. Expires September 26, 2015 [Page 3] Internet-Draft OSPF FlowSpec 2014 In this use case, the provider network needs to deploy security policies to filter the FlowSpec rules from the customer network, i.e. only accepts the authorized or secure FlowSpec rules which can be supported. Therefore, ASBR2 can send to ASBR1 a set of FlowSpec-ORF that can be used by ASBR1 to filter its outbound FlowSpec rules to ASBR2. If the traffic analyzer is deployed in the provider network AS2, while attacker is in the VPN1 AS3, as shown in Figure 2; RR will generate and then distribute FlowSpec rules to ASBR2 and ASBR3 when it receives the FlowSpec policies from the traffic analyzer. Furthermore, ASBR2 and ASBR3 will distribute the FlowSpec rules to ASBR1 and ASBR4 respectively. Once ASBR4 receives the flow specification rules, it can block the attack traffic closer to the source of the attacker. +----------------+ +-------+ | FlowSpec Policy| |Target | | Server | +---------+ +----\--+ +---------+------+ |Attacker | \ | +---/-----+ \ | / \ +-+--+ / \ |RR | / /------\ \ /+----+\ / /------\ // \\+\----+ +-----+/ \\+-----+ +--/--+/ \\ | VPN1 Site |ASBR | |ASBR | |ASBR | |ASBR | VPN1 Site | \\ AS1 //| 1 +----+ 2 |\ AS2 //| 3 +----+ 4 |\ AS3 // \------/ +-----+ +-----+ \------/ +-----+ +-----+ \------/ Customer Network Provider Network Customer Network Figure 2: Scenario 2 - Anti-DOS based on FlowSpec In this use case, the customer network also needs to deploy security policies to filter the FlowSpec rules from the provider network, i.e. only accepts the authorized or secure FlowSpec rules which can be supported. Therefore, ASBR4 can send to ASBR3 a set of FlowSpec-ORF that can be used by ASBR4 to filter its outbound FlowSpec rules to ASBR4. 3.2 FlowSpec Capability Negotiation FlowSpec [RFC5575] is an n-tuple consisting of several matching criteria that can be applied to IP traffic. The matching criteria can include elements such as source and destination address prefixes, IP protocol, and transport protocol port numbers. Traditional routers or L3 switches use special FIB hardware, such as TCAM, AISC. Liang, et al. Expires September 26, 2015 [Page 4] Internet-Draft OSPF FlowSpec 2014 The forwarding plane usually doesn't support Type, Code fields matching for ICMP packet. However, some modern forwarding devices such as vRouter can support FlowSpec matching with more elements. So even though different BGP speakers have the FlowSpec capability, their filters and action types of FlowSpec may be different. Therefore, BGP speaker should send its FlowSpec capability to BGP peers with the format of FlowSpec-ORF, then it can only receive the FlowSpec rules on demand; those that cannot be supported or are not required will be denied. 4. FlowSpec-ORF Encoding FlowSpec-ORF (ORF-type: TBD,First Come First Served) entries can be carried in the BGP ROUTE-REFRESH [RFC5291] message. The types of FlowSpec-ORF are identified by (Address Family Identifier, Subsequent Address Family Identifier (AFI, SAFI)) pairs [RFC4760]. They are aligned with the values for (AFI, SAFI) used in BGP UPDATE message, as shown in the following table: Liang, et al. Expires September 26, 2015 [Page 5] Internet-Draft OSPF FlowSpec 2014 +----------------+------------------------+---------------------------+ | AFI/SAFI Value | Description | RFC/Draft | +----------------+------------------------+---------------------------+ | AFI=1,SAFI=133 | IPv4 FlowSpec rule/orf | RFC5575 | +----------------+------------------------+---------------------------+ | AFI=1,SAFI=134 | VPNv4 FlowSpec rule/orf| RFC5575 | +----------------+------------------------+---------------------------+ | AFI=2,SAFI=133 | IPv6 FlowSpec rule/orf |draft-ietf-idr-flow-spec | +----------------+------------------------+---------------------------+ | AFI=2,SAFI=134 | VPNv6 FlowSpec rule/orf|draft-ietf-idr-flow-spec | +----------------+------------------------+---------------------------+ | AFI=25,SAFI=134| L2 VPN FlowSpec rule/or|draft-hao-idr-flowspec-evpn| +----------------+------------------------+---------------------------+ The format of FlowSpec-ORF entry is aligned with ORF entry encoding defined in [RFC5291]. Therein, the "Type specific part" is extended as shown in Figure 3: +---------------------------+ |Sequence (32 bits) | +---------------------------+ |Filter Number (8 bits) | +---------------------------+ |RD Number (8 bits) | +---------------------------+ |RD Equal Flag (1 bits) | +---------------------------+ |Reserved (15 bits) | +---------------------------+ |Action Matching (32 bits) | +---------------------------+ |RD 1 (64 bits) | +---------------------------+ |...... | +---------------------------+ |RD n (64 bits) | +---------------------------+ |Filters (variable, RFC5575)| +---------------------------+ Figure 3: FlowSpec-ORF "Type specific part" Encoding Sequence: the relative ordering of the entry among all the FlowSpec-ORF entries. Filter Number: the number of the filters of a FlowSpec-ORF entry. Liang, et al. Expires September 26, 2015 [Page 6] Internet-Draft OSPF FlowSpec 2014 RD Number: the number of the RD items. When SAFI=133, RD Number=0; When SAFI=134, RD number must be no less than 1. RD Equal Flag: matching mode for RD. If set, the operation is equality between data and value. If unset, the operation is inequality between data and value. Reserved: it is set to 0 on transmit and ignored on receipt. RD: An 8-byte Route Distinguisher (RD), present when SAFI=134. Action Matching: each bit corresponds to a particular FlowSpec action [RFC5575]. If set, match the action; If unset, not match the action. If Filter Number=0, Action Matching=0, RD Number!=0, then this FlowSpec-ORF is used to match the "RD" field. When SAFI=134, the BGP speaker (e.g. PE or ASBR) will distribute this FlowSpec-ORF, i.e. deny those VPN instances which are not configured locally. When BGP Speaker distributes FlowSpec rules to the BGP peers, it will first check the FlowSpec-ORF. When more than one FlowSpec-ORF entry matches the NLRI of the FlowSpec rule, the "first-match" rule applies. That is, the ORF entry with the smallest sequence number (among all the matching ORF entries) is considered as the sole match, and it would determine whether the FlowSpec rule should be advertised. 4.1. Filters The filters in FlowSpec-ORF are aligned with the filters defined in [RFC5575] except the following four types: +---------------------------------------+--------------------------------+ | Filter Type | RFC/Draft | +---------------------------------------+--------------------------------+ |Type 1: Destination Prefix IPv4 or IPv6|RFC5575, | | |draft-ietf-idr-flow-spce-v6 | +---------------------------------------+--------------------------------+ |Type 2: Source Prefix IPv4 or IPv6 |RFC5575, | | |draft-ietf-idr-flow-spce-v6 | +---------------------------------------+--------------------------------+ |Type 14: Destination MAC Prefix |draft-hao-idr-flowspec-evpn | +---------------------------------------+--------------------------------+ |Type 15: Source MAC Prefix |draft-hao-idr-flowspec-evpn | +---------------------------------------+--------------------------------+ Liang, et al. Expires September 26, 2015 [Page 7] Internet-Draft OSPF FlowSpec 2014 These four types are encoded as follows: +--------------------------------+ | Type(8 bits) | +--------------------------------+ | MaxLen (8 bits) | +--------------------------------+ | MinLen (8 bits) | +--------------------------------+ | Length (8 bits) | +--------------------------------+ | Prefix (32/48/128 bits) | +--------------------------------+ Therein, MaxLen, MinLen, Length, Prefix are the same as defined in [RFC5292]. 4.2. Actions The "Action Matching" field indicates a particular FlowSpec action [RFC5575] that needs to match or not. When some bit of Action Matching is set, the corresponding FlowSpec action of the FlowSpec rule should be matched. Otherwise, this FlowSpec rule is not matched. +-----------------------+----------------------+------------+ | FlowSpec Action Type | Action Matching bit | RFC/Draft | +-----------------------+----------------------+------------+ | traffic-rate | 0 | RFC5575 | | traffic-action | 1 | RFC5575 | | redirect | 2 | RFC5575 | | traffic-marking | 3 | RFC5575 | +-----------------------+----------------------+------------+ 4.3. FlowSpec-ORF Capability Section 5 of RFC 5291 describes how BGP speakers use the Outbound Route Filtering Capability to advertise their intention to send FlowSpec-ORFs and their willingness to accept FlowSpec-ORFs. 5. IANA Considerations This document defines a new ORF, i.e. FlowSpec-ORF (Type Code: TBD1), which is used to to filter the FlowSpec rules on demand. Liang, et al. Expires September 26, 2015 [Page 8] Internet-Draft OSPF FlowSpec 2014 6. Security considerations Each FlowSpec-ORF consumes memory and compute resources on the device that supports it. Therefore, a device supporting FlowSpec-ORF takes the following steps to protect itself from oversubscription: (1) When negotiating the ORF capability, advertise willingness to receive the FlowSpec-ORF only to known, trusted BGP peers. (2) Enforce a per-peer limit on the number of FlowSpec-ORFs that can be installed at any given time. Ignore all requests to add FlowSpec- ORFs beyond that limit and/or reply a BGP notification message to indicate "ROUTE-REFRESH Message Error" (Error Code: 7)/"FlowSpec-ORF overfilling Error" (Subcode: TBD2). (3) When BGP speaker receives unknown FlowSpec-ORF, it will send to the BGP peer the Notification message carrying Error Code/Subcode, e.g. "ROUTE-REFRESH Message Error" (Error Code: 7) / "FlowSpec-ORF Attribute Error" (Subcode: TBD3). Security considerations for BGP are presented in [RFC4271] while further security analysis of BGP is found in [RFC6952]. 7. Acknowledgement TBD. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering Capability for BGP-4", RFC 5291, August 2008. [RFC5292] Chen, E. and S. Sangli, "Address-Prefix-Based Outbound Route Filter for BGP-4", RFC 5292, August 2008. Liang, et al. Expires September 26, 2015 [Page 9] Internet-Draft OSPF FlowSpec 2014 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., and D. McPherson, "Dissemination of Flow Specification Rules", RFC 5575, August 2009. [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, May 2013. 8.2. Informative References [I-D.hao-idr-flowspec-evpn] Weiguo, H., Zhuang, S., and S. Litkowski, "Dissemination of Flow Specification Rules for L2 VPN", draft-hao-idr- flowspec-evpn-02 (work in progress), January 2015. [I-D.ietf-bess-orf-covering-prefixes] Jeng, H., Jalil, L., Bonica, R., Patel, K., and L. Yong, "Covering Prefixes Outbound Route Filter for BGP-4", draft-ietf-bess-orf-covering-prefixes-04 (work in progress), February 2015. [I-D.ietf-idr-flow-spec-v6] Raszuk, R., Pithawala, B., McPherson, D., and A. Andy, "Dissemination of Flow Specification Rules for IPv6", draft-ietf-idr-flow-spec-v6-06 (work in progress), November 2014. Authors' Addresses Qiandeng Liang Huawei 101 Software Avenue, Yuhuatai District Nanjing, 210012 China Email: liuweihang@huawei.com Weiguo Hao Huawei 101 Software Avenue, Yuhuatai District Nanjing, 210012 China Email: haoweiguo@huawei.com Liang, et al. Expires September 26, 2015 [Page 10] Internet-Draft OSPF FlowSpec 2014 Jianjie You Huawei 101 Software Avenue, Yuhuatai District Nanjing, 210012 China Email: youjianjie@huawei.com Liang, et al. Expires September 26, 2015 [Page 11]