IDR Working Group Q. Liang Internet-Draft J. You Intended status: Standards Track S. Zhuang Expires: April 20, 2016 Huawei Technologies October 18, 2015 BGP FlowSpec with Time Constraints draft-liang-idr-bgp-flowspec-time-00 Abstract The BGP flow specification (FlowSpec) is an additional tool to mitigate the effects of Distributed Denial of Service (DDoS) attacks. Since DDoS attacks are dynamic, filtering of a flow may only be necessary for some specified time, and be undesirable at other times. This document proposes a new BGP path attribute called "Flow Extended Attribute", which carries expected valid period information for a FlowSpec rule. So network administrators can control certain types of traffic in a specified period. 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 RFC 2119 [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 April 20, 2016. Liang, et al. Expires April 20, 2016 [Page 1] Internet-Draft FlowSpec with Time Constraints October 2015 Copyright Notice Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 3 3.1. Flow Description sub-TLV . . . . . . . . . . . . . . . . 4 3.2. Flow Validity Period sub-TLV . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction The BGP flow specification (FlowSpec) defined in [RFC5575] is an n-tuple consisting of several matching criteria, which gives network operators an additional tool to mitigate the effects of Distributed Denial of Service (DDoS) attacks on their networks. The matching criteria can include elements such as source and destination address prefixes, IP protocol, and transport protocol port numbers. A given IP packet is said to match the defined flow if it matches all the specified criteria.[RFC5575] also defines flow actions, such as rate limit, redirect, and marking, associated with each flow specification rule. A Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) (AFI/SAFI: 1/133 for IPv4, AFI/SAFI: 1/134 for VPNv4) encoding format is used to distribute traffic flow specification rules. Since DDoS attacks are dynamic, redirection or filtering of a flow may only be necessary for some specified time, and be undesirable at Liang, et al. Expires April 20, 2016 [Page 2] Internet-Draft FlowSpec with Time Constraints October 2015 other times [I-D.eddy-idr-flowspec-exp]. Thus, network administrators may only need to control certain types of traffic in a specified period; they can configure or inject a FlowSpec rule with a valid period, which determines when the said FlowSpec rule is effective. There's another use case for this usage, for example, the network administrator may need to ensure reliable transmission for high priority services (e.g. video traffic) for VIP and limit the bandwidth for low priority services (e.g. web browsing) for common users during peak network utilization periods. The current BGP FlowSpec protocol cannot support to control the valid period of a FlowSpec rule precisely in the network. For example, the network administrator may want to validate a FlowSpec rule on different BGP routers simultaneously; firstly the rule should be disseminated to those BGP routers. But since those BGP routers would receive this FlowSpec rule with different delay, the FlowSpec rule may be valid at different time slightly. Therefore the BGP router can specify a time parameter as the valid period when installing a FlowSpec rule. This document proposes a new BGP path attribute called "Flow Extended Attribute", which carries expected valid period information for a FlowSpec rule. Besides, in order to make the FlowSpec rule more readable in diagnosing and logging, the "Flow Extended Attribute" can also carry the flow description information for the FlowSpec rule. 2. Terminology This section contains definitions of terms used in this document. Specification (FlowSpec): A flow specification is an n-tuple consisting of several matching criteria that can be applied to IP traffic. Each FlowSpec consists of a set of filters and a set of actions. 3. Protocol Extensions In this document, BGP is used to distribute FlowSpec rules bound with a "Flow Extended Attribute". This "Flow Extended Attribute" is an optional transitive attribute that is composed of a set of Type- Length-Value (TLV) encodings, including Flow Description sub-TLV and Flow Validation Period sub-TLV. Liang, et al. Expires April 20, 2016 [Page 3] Internet-Draft FlowSpec with Time Constraints October 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (2 Octets) | Length (2 Octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Value | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1:TLV Format 3.1. Flow Description sub-TLV The Flow Description sub-TLV is encoded as below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 (Flow Description) | Length (2 Octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Flow Description (variable Octets) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2:Flow Description sub-TLV Format Type: Flow Description (Type Code: 1) Length: the size of the value field (typically in bytes) Flow Description: This field is an ASCII string, padded on the right with null bytes (\0). It is usually used as a flow name or flow function description. The length of this field SHOULD be no more than 256 octets. 3.2. Flow Validity Period sub-TLV The Flow Validity Period sub-TLV is encoded as below: Liang, et al. Expires April 20, 2016 [Page 4] Internet-Draft FlowSpec with Time Constraints October 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 (Flow Validity Period) | Length (2 Octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Starting Time Type (2 Octets) | Duration Type (2 Octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Starting Time (seconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Starting Time (microseconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duration (seconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duration (microseconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delay Time (seconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delay Time (microseconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Periodic Time (seconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Periodic Time (microseconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3:Flow Validity Period sub-TLV Format Type:Flow Validity Period (Type Code: 2) Length: the size of the value field (typically in bytes) Starting Time Type: +-------------------+-----------------------------------------------+ | Type Code | Function Description | +-------------------+-----------------------------------------------+ | 0 | Immediate validation | +-------------------+-----------------------------------------------+ | 1 | Delayed validation | +-------------------+-----------------------------------------------+ | 2 | Timing validation | +-------------------+-----------------------------------------------+ | else codes | Reserved | +-------------------+-----------------------------------------------+ When the "Starting Time Type" is set to 2, the BGP Speaker should be clock synchronized [I-D.litkowski-idr-bgp-timestamp]. Duration Type: Liang, et al. Expires April 20, 2016 [Page 5] Internet-Draft FlowSpec with Time Constraints October 2015 +-------------------+-----------------------------------------------+ | Type Code | Function Description | +-------------------+-----------------------------------------------+ | 0 | Permanent validation | +-------------------+-----------------------------------------------+ | 1 | Hard invalidation | +-------------------+-----------------------------------------------+ | 2 | Idle invalidation | +-------------------+-----------------------------------------------+ | else codes | Reserved | +-------------------+-----------------------------------------------+ When the "Duration Type" is set to 0, the corresponding FlowSpec rule is always valid until it is withdrawn by BGP signaling. When the "Duration Type" is set to 1, the corresponding FlowSpec rule is only valid in a specified duration defined by the "Duration" field. When the "Duration Type" is set to 2, the corresponding FlowSpec rule is valid until no traffic has matched it for a duration defined by the "Duration" field. Starting Time: Expressed in seconds and microseconds since midnight (zero hour), January 1, 1970 (UTC). Precision of the "Starting Time" is implementation-dependent. If the "Starting Time Type" is set to 0, this field is invalid. Duration: if the "Duration Type" is set to 0, this field is invalid. Delay Time: Only when the "Starting Time Type" is set to 1, this field is valid. If the "Starting Time" is set to a valid value,the first valid period of the FlowSpec rule bound with this "Flow Extended Attribute" is [Starting Time + Delay, Starting Time + Delay + Duration]; if not, and assuming that the current time of the BGP router is T1, then the first valid period of the FlowSpec rule bound with this "Flow Extended Attribute" is [T1 + Delay, T1 + Delay + Duration]. Periodic Time: If zero, the value is unavailable. The FlowSpec rule bound with this "Flow Extended Attribute" would be valid periodically. The "Periodic Time" MUST be not less than the "Duration", otherwise this sub-TLV is invalid. The BGP router may not actively withdraw a FlowSpec rule, which has been invalid. However, it should withdraw a FlowSpec rule according to the BGP signaling normally. Liang, et al. Expires April 20, 2016 [Page 6] Internet-Draft FlowSpec with Time Constraints October 2015 4. IANA Considerations For the purpose of this work, IANA should allocate a new code from the "BGP Path Attributes" Registry to "BGP Flow Extended Attribute". IANA is requested to change the registration policy of the "BGP Flow Extended Attribute Sub-TLVs" registry to the following: o The values 0 and 255 are reserved. o The values in the range 1-127 are to be allocated using the "Standards Action" registration procedure. o The values in the range 128-251 are to be allocated using the "First Come, First Served" registration procedure. o The values in the range 252-254 are reserved for experimental use; IANA shall not allocate values from this range. IANA is requested to assign a code point from the "BGP Flow Extended Attribute Sub-TLVs" registry for "Flow Description", with this document being the reference. IANA is requested to assign a code point from the "BGP Flow Extended Attribute Sub-TLVs" registry for "Flow Validity Period", with this document being the reference. 5. Security Considerations This extension to BGP does not change the underlying security issues inherent in the existing BGP. 6. Acknowledgements The authors would like to thank Zhenbin Li and Weiguo Hao for their comments. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Liang, et al. Expires April 20, 2016 [Page 7] Internet-Draft FlowSpec with Time Constraints October 2015 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [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, . 7.2. Informative References [I-D.eddy-idr-flowspec-exp] Eddy, W., Dailey, J., and G. Clark, "Experimental BGP Flow Specification Extensions", draft-eddy-idr-flowspec-exp-00 (work in progress), August 2015. [I-D.ietf-idr-tunnel-encaps] Rosen, E., Patel, K., and G. Velde, "Using the BGP Tunnel Encapsulation Attribute without the BGP Encapsulation SAFI", draft-ietf-idr-tunnel-encaps-00 (work in progress), August 2015. [I-D.litkowski-idr-bgp-timestamp] Litkowski, S., Patel, K., and J. Haas, "Timestamp support for BGP paths", draft-litkowski-idr-bgp-timestamp-02 (work in progress), March 2015. Authors' Addresses Qiandeng Liang Huawei Technologies 101 Software Avenue, Yuhuatai District Nanjing 210012 China Email: liangqiandeng@huawei.com Jianjie You Huawei Technologies 101 Software Avenue, Yuhuatai District Nanjing 210012 China Email: youjianjie@huawei.com Liang, et al. Expires April 20, 2016 [Page 8] Internet-Draft FlowSpec with Time Constraints October 2015 Shunwan Zhuang Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: zhuangshunwan@huawei.com Liang, et al. Expires April 20, 2016 [Page 9]