idnits 2.17.1 draft-ietf-idr-flowspec-packet-rate-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 6, 2016) is 2875 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing (IDR) W. Eddy 3 Internet-Draft J. Dailey 4 Intended status: Standards Track G. Clark 5 Expires: December 8, 2016 MTI Systems 6 June 6, 2016 8 BGP Flow Specification Packet-Rate Action 9 draft-ietf-idr-flowspec-packet-rate-00 11 Abstract 13 This document defines a new type of traffic filtering action for the 14 BGP flow specification. The new packet-rate action allows specifying 15 a rate-limit in number of packets per second. This is intended to be 16 used in combatting some types of denial of service attacks where the 17 packet rate is more important than the raw bitrate of the attack 18 traffic. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 8, 2016. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 56 2. Packet Rate Action . . . . . . . . . . . . . . . . . . . . . 2 57 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 63 7.2. Informative References . . . . . . . . . . . . . . . . . 5 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 The existing BGP flow specification [RFC5575] standard supports 69 traffic-rate limits conveyed in bytes per second. In some cases, it 70 may be easier, faster, or more relevant to perform accounting and 71 decision-making based on quantities of packets per second. It is 72 desirable to specify rate limits in terms of the number of packets 73 per second, and not just the number of bytes per second. 75 As an example use case, there are several types of denial of service 76 attacks that do not require large amounts of bandwidth, but operate 77 based on a cadence of packets over time. TCP SYN flooding attacks 78 are one well-known example [RFC4987], along with common packet-rate 79 limits applied to ICMP messages and packets to unknown UDP ports. 81 1.1. Requirements Language 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC 2119 [RFC2119]. 87 2. Packet Rate Action 89 The traffic filtering actions pertaining to a matched flow 90 specification are indicated using BGP extended communities [RFC7153]. 91 Particular extended community values are defined in RFC 5575 for a 92 number of possible actions. New types of actions can be defined 93 using additional extended community values. The value 0x8006 has 94 been defined as the "traffic-rate" action, and specifies a rate-limit 95 in a quantity of bytes per second. The new packet-rate extended 96 community described in this draft is similar, except the quantity is 97 interpreted as packets per second. 99 +------+--------------------+-------------------------------------+ 100 | type | extended community | encoding | 101 +------+--------------------+-------------------------------------+ 102 | TBD | packet-rate | 2-byte ASN, 4-byte unsigned integer | 103 +------+--------------------+-------------------------------------+ 105 Table 1 107 Packet-rate: The packet-rate extended community is a transitive 108 extended community across the autonomous-system boundary and uses 109 following extended community encoding: 111 The first two octets carry the 2-octet id, which can be 112 assigned from a 2-byte AS number. When a 4-byte AS number is 113 locally present, the 2 least significant bytes of such an AS 114 number can be used. This value is purely informational and 115 should not be interpreted by the implementation. 117 The remaining 4 octets carry the rate information as an 118 unsigned integer in network byte order, with packets per second 119 as the unit represented. A packet-rate of 0 should result on 120 all traffic for the particular flow to be discarded. 122 Note that this is a transitive community type, as explained in RFC 123 7153 and not a non-transitive type as mentioned narratively in the 124 RFC 5575 description of the traffic-rate action. 126 The packet-rate action SHOULD NOT be used together with a traffic- 127 rate action within the same flow specification, due to unclear 128 semantics. Implementations MUST be robust to receiving both actions 129 and may choose to honor either one or the other, or the combination 130 of both, depending on local implementation capabilities. 132 3. Discussion 134 Interaction between multiple actions in a flow specification is a 135 matter of ongoing work in the IETF. There are potential semantic 136 conflicts when a traffic-rate action is combined with a packet-rate 137 action. This is legal syntactically, but devices are not universally 138 capable of honoring both a packet per second and a bit per second 139 rate limit, resulting in inability to meet the operator intention if 140 both are used within a flow specification. Resolving this is 141 potential future work, however, the present guidance is for 142 implementations to avoid sending such flow specifications, while 143 still behaving in some reasonable manner when receiving them (e.g. 144 honoring one or the other limit if it is not possible to honor both). 146 The traffic-rate action is specified as a floating point value. 147 There can be discrepancies between what is configured and what is 148 encoded, due to loss of precision in the floating point 149 representation, which would be annoying for operators. Based on 150 discussions in the IDR working group, for the packet-rate action, an 151 unsigned integer value is used, which allows unambiguous packet per 152 second rates to be specified. This limits rates represented to under 153 4.3 Gpps (4.3 billion packets per second), which is believed to be 154 sufficient for the present and foreseeable future networks. 156 4. Acknowledgements 158 The initial idea to add a packet rate action was encouraged by 159 comments from Donald Smith at a DHS meeting in 2015. The content of 160 this document was shaped by discussion on the IETF IDR mailing list, 161 including comments from Aseem Choudhary, Acee Lindem, Jeff Haas, John 162 Schiel, Robert Raszuk, Kirill Kasavchenko. Special thanks go to the 163 IDR chairs Sue Hares, and John Scudder for their leadership and 164 shepherding of the many other BGP enhancements concurrently underway. 166 5. IANA Considerations 168 If accepted for publication, IANA will need to allocate a BGP 169 extended community value for the "packet-rate" action from the 170 "Generic Transitive Experimental Use Extended Community Sub-Types" 171 registry. 173 6. Security Considerations 175 No security considerations are raised by this document. 177 7. References 179 7.1. Normative References 181 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 182 Requirement Levels", BCP 14, RFC 2119, 183 DOI 10.17487/RFC2119, March 1997, 184 . 186 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 187 and D. McPherson, "Dissemination of Flow Specification 188 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 189 . 191 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 192 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 193 March 2014, . 195 7.2. Informative References 197 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 198 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 199 . 201 Authors' Addresses 203 Wesley Eddy 204 MTI Systems 206 Email: wes@mti-systems.com 208 Justin Dailey 209 MTI Systems 211 Email: justin@mti-systems.com 213 Gilbert Clark 214 MTI Systems 216 Email: gclark@mti-systems.com