idnits 2.17.1 draft-loibl-bacher-idr-flowspec-clarification-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 (Using the creation date from RFC5575, updated by this document, for RFC5378 checks: 2007-08-15) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 22, 2016) is 2797 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) == Unused Reference: 'RFC4271' is defined on line 279, but no explicit reference was found in the text == Unused Reference: 'RFC4760' is defined on line 288, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 300, but no explicit reference was found in the text == Unused Reference: 'RFC4364' is defined on line 306, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Loibl 3 Internet-Draft Next Layer Communications 4 Updates: 5575 (if approved) M. Bacher 5 Intended status: Standards Track T-Mobile Austria 6 Expires: February 23, 2017 August 22, 2016 8 Flowspec Clarification 9 draft-loibl-bacher-idr-flowspec-clarification-00 11 Abstract 13 This document clarifies multiple aspects of Flowspec (RFC 5575) to 14 allow a consistent and robust implementation in an multi vendor / 15 inter provider environment. 17 This document updates RFC 5575. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on February 23, 2017. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Clarification of the Comparison Operator . . . . . . . . . . 3 56 4. Clarification of the Component Type Length . . . . . . . . . 3 57 5. (Re-)Validation of the Flow Specification NLRI . . . . . . . 4 58 6. Transitivity of Traffic Filtering Actions . . . . . . . . . . 5 59 7. Clarification of Flowspec NLRI Parsing and Validation . . . . 5 60 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 10. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 11.1. Normative References . . . . . . . . . . . . . . . . . . 6 65 11.2. Informative References . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 This document clarifies multiple aspects of Flowspec (RFC 5575) to 71 allow a consistent and robust implementation in a multi vendor / 72 inter autonomous system environment. It describes only minimal 73 changes in the behaviour defined by RFC 5575 [RFC5575] but clarifies 74 many of the unclear sections of RFC 5575. 76 During a large interoperability lab session involving multiple 77 routing equipment vendors (Alcatel, Cisco, Huawei, Juniper) we 78 identified many incompatibilities in their Flowspec implementations. 79 The identified incompatibilities range from valid Flowspec network 80 layer reachability information (NLRI) updates being ignored by BGP 81 speakers (and not forwarded according to the normal BGP update 82 mechanisms) to the inability to parse valid Flowspec NLRIs causing 83 BGP notifications sent to neighbors and sessions being closed, thus 84 leading to partial or complete network outages. Most of the 85 incompatibilities found during those tests were results of unclear or 86 missing definitions in the flowspec RFC 5575. 88 2. Terminology 90 AS - Autonomous System 92 BGP - Border Gateway Protocol 94 DSCP - Diffserv Code Point 95 ICMP - Internet Control Messaging Protocol 97 NLRI - Network Layer Reachability Information 99 VPN - Virtual Private Network 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 3. Clarification of the Comparison Operator 107 RFC 5575 section 4 under Type 3 defines the encoding of {operator, 108 value} pairs where the operator bits 5-7 contain comparison flags (<, 109 >, =). The following table obsoletes the last paragraph of RFC 5575 110 section 4 Type 3 ("The bits lt, gt, and eq can be combined to produce 111 "less or equal", "greater or equal", and inequality values."). 112 Combinations of the bits MUST be interpreted as follows: 114 +---+---+---+----------------------------------+ 115 | < | > | = | Resulting operation | 116 +---+---+---+----------------------------------+ 117 | 0 | 0 | 0 | true (independent of the value) | 118 | 0 | 0 | 1 | == (equal) | 119 | 0 | 1 | 0 | > (greater than) | 120 | 0 | 1 | 1 | >= (greater than or equal) | 121 | 1 | 0 | 0 | < (less than) | 122 | 1 | 0 | 1 | <= (less than or equal) | 123 | 1 | 1 | 0 | != (not equal value) | 124 | 1 | 1 | 1 | false (independent of the value) | 125 +---+---+---+----------------------------------+ 127 Table 1: Comparison operation combinations 129 3.1. Changes to RFC5575 131 The behaviour of the bit-combinations is not explicitly defined. 132 Especially the three combinations (0,0,0), (1,1,0), (1,1,1) are 133 subject to misinterpretation. 135 4. Clarification of the Component Type Length 137 RFC 5575 section 4 under Type 3 defines the encoding of {operator, 138 value} pairs. The operator component contains a 2 bit length field 139 (bit 2 and 3) representing the length of the value field. This 140 length field allows to encode a 1-4 byte long value. This {operator, 141 value} pairs are used as a match criteria for the flow component type 142 3, 4, 5, 6, 7, 8, 10, 11. The allowed length for these components is 143 as following: 145 +------+--------------+------------------+ 146 | Type | Length | Name | 147 +------+--------------+------------------+ 148 | 3 | 1-byte | IP protocol | 149 | 4 | 1- or 2-byte | Port | 150 | 5 | 1- or 2-byte | Destination port | 151 | 6 | 1- or 2-byte | Source port | 152 | 7 | 1-byte | ICMP type | 153 | 8 | 1-byte | ICMP code | 154 | 10 | 1- or 2-byte | Packet length | 155 | 11 | 1-byte | DSCP | 156 +------+--------------+------------------+ 158 Table 2: Allowed value lengths 160 4.1. Changes to RFC5575 162 The allowed length of the value for a type 3 component (IP protocol) 163 was not explicitly defined. This is inconsistent with all other 164 types where the allowed length is explicitly specified. 166 5. (Re-)Validation of the Flow Specification NLRI 168 RFC 5575 section 6 defines a validation procedure for the flow 169 specification NLRI. The outcome of the defined validation procedure 170 is depending on the best-match unicast route for the destination 171 prefix embedded in the flow specification. 173 Since the best-match unicast route may change over the time 174 independently of the flow specification NLRI, revalidation of the 175 flow specification NLRI MUST be performed whenever unicast routes 176 change. Thus changes in the best-match unicast route can effect the 177 validation-state of a flow specification NLRI. 179 5.1. Changes to RFC5575 181 Explicit definition of the requirement of revalidation. Revalidation 182 of flow specification NLRI is not explicitly described in RFC5575, 183 however it is compared with the "validation" of the reachability of 184 the NEXT_HOP in the context of IP routing information. A unicast 185 route becomes unfeasible if the NEXT_HOP for that particular route 186 becomes unreachable. 188 6. Transitivity of Traffic Filtering Actions 190 RFC 5575 section 7 defines a minimum set of filtering actions. The 191 predefined traffic filtering actions are standardized as BGP extended 192 community values [RFC4360]. All predefined filtering action 193 communities SHALL be treated as transitive BGP extended communities. 195 6.1. Changes to RFC5575 197 The transitivity of the traffic filtering action extended community 198 was only defined for the "traffic-rate" action (defined as non- 199 transitive). Since all filtering communities were assigned from an 200 transitive pool by IANA, for consistency with RFC4360 section 2 this 201 document explicitly redefines the "traffic-rate" action as 202 transitive. It also defines the transitivity of all other traffic 203 filtering actions as transitive (this definition is missing in 204 RFC5575). This redefinition also reflects the behaviour of many of 205 the current implementations. 207 7. Clarification of Flowspec NLRI Parsing and Validation 209 A flow specification NLRI is syntactically correct if it is encoded 210 according to RFC 5575 section 4. The semantic of the NLRI is opaque 211 to BGP. As a result of this statement the following behaviour is 212 expected: 214 Flow specification NLRI propagation through the network is following 215 the BGP propagation mechanisms independent of the semantic of the 216 particular NLRI itself. The inability of the particular 217 implementation to actually make use of a given flow specification 218 SHOULD NOT affect the BGP NLRI propagation. Nor SHOULD a semantical 219 incorrect NLRI affect the propagation of the NLRI (the NLRI, even if 220 semantically incorrect should be propergated according to BGP 221 propagation mechanisms). 223 Invalid NLRI semantics SHOULD NOT trigger BGP failures (ie BGP 224 notifications). 226 An example of a syntactically correct, but semantically incorrect 227 NLRI match criteria may be the following: 229 IP Protocol == 1, Port == 2 231 Since IP protocol 1 (ICMP) packets do not contain a port information 232 the NLRI is incorrect from the semantical perspective and may not be 233 applied to the forwarding plane in the network. However it is still 234 syntactically correct and thus subject to BGP propagation. 236 7.1. Changes to RFC5575 238 None. See RFC5575 section 3 last 2 paragraphs. 240 8. Acknowledgements 242 The authors would like to thank Alexander Mayrhofer and Nicolas 243 Fevrier for their comments and support. 245 9. IANA Considerations 247 This document has no IANA actions. 249 10. Security Considerations 251 The required filtering action for a specific NLRI may vary throughout 252 the network. Extensive modification and filtering of filter actions 253 is needed in an inter AS setting. Therefore implementations SHALL 254 provide a policy framework to allow modification (add, modify, 255 delete) of the filtering actions. 257 Especially in an inter-AS-setting unverified filtering actions like 258 "redirect" (0x8008) or "traffic-marking" (0x8009) may potentially be 259 harmful ("redirect" may allow any Flowspec-peer to redirect any 260 traffic into arbitrary VPNs; "traffic-marking" allows any malicious 261 Flowspec-peer to assign different forwarding classes to arbitrary 262 traffic). 264 Inbound and outbound Flowspec route filters may also be necessary in 265 order to match and filter specific filtering actions and flow 266 component types from being accepted or sent by the local BGP daemon. 267 The implementations SHALL therefore also provide a policy framework 268 which provides the described functionality. 270 11. References 272 11.1. Normative References 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", BCP 14, RFC 2119, 276 DOI 10.17487/RFC2119, March 1997, 277 . 279 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 280 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 281 DOI 10.17487/RFC4271, January 2006, 282 . 284 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 285 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 286 February 2006, . 288 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 289 "Multiprotocol Extensions for BGP-4", RFC 4760, 290 DOI 10.17487/RFC4760, January 2007, 291 . 293 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 294 and D. McPherson, "Dissemination of Flow Specification 295 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 296 . 298 11.2. Informative References 300 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 301 "Definition of the Differentiated Services Field (DS 302 Field) in the IPv4 and IPv6 Headers", RFC 2474, 303 DOI 10.17487/RFC2474, December 1998, 304 . 306 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 307 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 308 2006, . 310 Authors' Addresses 312 Christoph Loibl 313 Next Layer Communications 314 Mariahilfer Guertel 37/7 315 Vienna 1150 316 AT 318 Phone: +43 664 1176414 319 Email: cl@tix.at 321 Martin Bacher 322 T-Mobile Austria 323 Rennweg 97-99 324 Vienna 1030 325 AT 327 Phone: +43 676 8200 5143 328 Email: martin.bacher@t-mobile.at