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,
<http://www.rfc-editor.org/info/rfc2119>.
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,
<http://www.rfc-editor.org/info/rfc4271>.
[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,
<http://www.rfc-editor.org/info/rfc5575>.
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]
