idnits 2.17.1 draft-wang-idr-flowspec-dip-origin-as-filter-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([I-D.ietf-idr-RFC5575bis], [RFC5575]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 10, 2020) is 1323 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-23) exists of draft-ietf-idr-flowspec-l2vpn-15 == Outdated reference: A later version (-27) exists of draft-ietf-idr-rfc5575bis-26 ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Wang 3 Internet-Draft Huawei 4 Intended status: Standards Track A. Wang 5 Expires: March 14, 2021 China Telecom 6 S. Zhuang 7 Huawei 8 September 10, 2020 10 Destination-IP-Origin-AS Filter for BGP Flow Specification 11 draft-wang-idr-flowspec-dip-origin-as-filter-03 13 Abstract 15 BGP Flowspec mechanism [RFC5575] [I-D.ietf-idr-rfc5575bis] propogates 16 both traffic Flow Specifications and Traffic Filtering Actions by 17 making use of the BGP NLRI and the BGP Extended Community encoding 18 formats. This document specifies a new BGP-FS component type to 19 support AS-level filtering. The match field is the origin AS number 20 of the destination IP address that is encoded in the Flowspec NLRI. 21 This function is applied in a single administrative domain. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on March 14, 2021. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3 65 3. The Flow Specification Encoding for Destination-IP-Origin-AS 66 Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 4. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 6. IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 BGP Flow Specification (BGP-FS) [RFC5575] [I-D.ietf-idr-rfc5575bis] 78 defines a new BGP NLRI to distribute traffic flow specification rules 79 via BGP ([RFC4271]). BGP-FS policies have a match condition that may 80 be n-tuple match in a policy, and an action that modifies the packet 81 and forwards/drops the packet. Via BGP, new filter rules can be sent 82 to all BGP peers simultaneously without changing router 83 configuration, and the BGP peer can install these routes in the 84 forwarding table. BGP-FS defines Network Layer Reachability 85 Information (NLRI) format used to distribute traffic flow 86 specification rules. NLRI (AFI=1, SAFI=133) is for IPv4 unicast 87 filtering. NLRI (AFI=1, SAFI=134) is for BGP/MPLS VPN 88 filtering.[I-D.ietf-idr-flowspec-l2vpn][I-D.ietf-idr-flowspec-l2vpn] 89 extends the flow-spec rules for layer 2 Ethernet packets. 91 This document specifies a new BGP-FS component type to support AS- 92 level filtering. The match field is the origin AS number of the 93 destination IP address that is encoded in the Flowspec NLRI. This 94 function is applied in a single administrative domain. 96 2. Definitions and Acronyms 98 o FS: Flow Specification 100 o Destination-IP-Origin-AS: The origin AS number of the destination 101 IP address 103 3. The Flow Specification Encoding for Destination-IP-Origin-AS Filter 105 This document proposes a new flow specification component type that 106 is encoded in the BGP Flowspec NLRI. The following new component 107 type is defined. 109 o Destination-IP-Origin-AS 111 Type TBD1 - Destination-IP-Origin-AS 113 Encoding: 115 Contains a set of {operator, value} pairs that are used to match the 116 Destination-IP-Origin-AS (i.e. the origin AS number of the 117 destination IP address). 119 The operator byte is encoded as: 121 0 1 2 3 4 5 6 7 122 +---+---+---+---+---+---+---+---+ 123 | e | a | len | 0 |lt |gt |eq | 124 +---+---+---+---+---+---+---+---+ 126 Where: 128 e - end-of-list bit. Set in the last {op, value} pair in the list. 130 a - AND bit. If unset, the previous term is logically ORed with the 131 current one. If set, the operation is a logical AND. It MUST be 132 unset in the Destination-IP-Origin-AS filter. 134 lt - less than comparison between data and value. 136 gt - greater than comparison between data and value. 138 eq - equality between data and value. 140 The bits lt, gt, and eq can be combined to produce match the 141 Destination-IP-Origin-AS filter or a range of Destination-IP-Origin- 142 AS filter(e.g. less than AS1 and greater than AS2). 144 The value field is encoded as: 146 0 1 2 3 147 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 148 +---------------------------------------------------------------+ 149 ~ Destination-IP-Origin-AS (4 octets) ~ 150 +---------------------------------------------------------------+ 152 Per section 10 of [I-D.ietf-idr-rfc5575bis] , If a receiving BGP 153 speaker cannot support this new Flow Specification component type, it 154 MUST discard the NLRI value field that contains such unknown 155 components. Since the NLRI field encoding (Section 4 of 156 [I-D.ietf-idr-rfc5575bis]) is defined in the form of a 2-tuple 157 , message decoding can skip over the unknown NLRI 158 value and continue with subsequent remaining NLRI. 160 4. Use Case 162 This section describes how to use this function in a simple scenario. 163 Considering the topology shown in Figure 1. In AS64597's R1, if the 164 ISP AS64597 wants to redirect all packets from IP Prefix 61 to 165 AS64598, first goto to R3, then forward to AS64598", the ISP AS64597 166 can use the traditional method or the method defining in this draft. 168 +---------+ 169 | BGP FS | 170 | Server | 171 +----|----+ 172 | 173 | 174 / 175 / 176 ************/************ IP Prefix 81 177 * / * IP Prefix 82 178 IP Prefix 61 * / AS64597 * IP Prefix 83 179 * / * IP Prefix 84 180 +-------+ * +---+/ +---+ * +-------+ 181 +AS64596+-------+ R1+---------+ R2|------+AS64598+ 182 +-------+ * +-+-+\ +---+ */ +-------+ 183 * \ |\ / 184 * \ | \ /* IP Prefix 91 185 * \ | /\* IP Prefix 92 186 * \ | / \ IP Prefix 93 187 * \ |/ *\ IP Prefix 94 188 * \ +-+-+ * \ +-------+ 189 * \-+ R3+------+AS64599+ 190 * +---+ * +-------+ 191 * * 192 ************************* 193 Figure 1: Steering the Traffic Using Flowspec 195 Using the traditional method, the ISP AS64597 needs to setup multiple 196 "Destination Prefix + Source Prefix" rules in Router R1 as following: 198 +--------------+--------------+-------------------------+ 199 | Destination | Source Prefix| Redirect to IP Nexthop | 200 | Prefix | | | 201 +--------------+--------------+-------------------------+ 202 | IP Prefix 81 | IP Prefix 61 | R3 | 203 +--------------+--------------+-------------------------+ 204 | IP Prefix 82 | IP Prefix 61 | R3 | 205 +--------------+--------------+-------------------------+ 206 | IP Prefix 83 | IP Prefix 61 | R3 | 207 +--------------+--------------+-------------------------+ 208 | IP Prefix 84 | IP Prefix 61 | R3 | 209 +--------------+--------------+-------------------------+ 210 | More... | 211 +--------------+--------------+-------------------------+ 213 Figure 2: Steering the Traffic Using Destination Prefix and Source Prefix 214 Using the method defining in this draft, the ISP AS64597 needs to 215 setup only one "Destination Origin AS + Source Prefix" rule in Router 216 R1 as following: 218 +--------------+--------------+-------------------------+ 219 | Destination | Source Prefix| Redirect to IP Nexthop | 220 | IP Origin AS | | | 221 +--------------+--------------+-------------------------+ 222 | 64598 | IP Prefix 61 | R3 | 223 +--------------+--------------+-------------------------+ 225 Figure 3: Steering the Traffic Using Origin AS and Source Prefix 227 Obviously, the new method defining in this draft saves a lot of entry 228 spaces on the control plane and forwarding plane, and it would 229 greatly simplify the operation of the control plane, and the more 230 destination prefixes an AS has, the more obvious the benefit. 232 5. Security Considerations 234 No new security issues are introduced to the BGP protocol by this 235 specification. 237 6. IANA 239 IANA is requested to a new entry in "Flow Spec component types 240 registry" with the following values: 242 +----------------------------------------------------------+ 243 | Type | RFC or Draft | Description | 244 +----------------------------------------------------------+ 245 | TBD1 | This Draft | Destination-IP-Origin-AS | 246 +----------------------------------------------------------+ 248 7. Contributors 250 TBD 252 8. Acknowledgments 254 The authors would like to acknowledge the review and inputs from Gang 255 Yan, Zhenbin Li, Rainbow Wu, Jie Dong and Ziqing Cao. 257 9. References 259 [I-D.ietf-idr-flowspec-l2vpn] 260 Weiguo, H., Eastlake, D., Litkowski, S., and S. Zhuang, 261 "BGP Dissemination of L2 Flow Specification Rules", draft- 262 ietf-idr-flowspec-l2vpn-15 (work in progress), May 2020. 264 [I-D.ietf-idr-rfc5575bis] 265 Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 266 Bacher, "Dissemination of Flow Specification Rules", 267 draft-ietf-idr-rfc5575bis-26 (work in progress), August 268 2020. 270 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 271 Requirement Levels", BCP 14, RFC 2119, 272 DOI 10.17487/RFC2119, March 1997, 273 . 275 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 276 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 277 DOI 10.17487/RFC4271, January 2006, 278 . 280 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 281 and D. McPherson, "Dissemination of Flow Specification 282 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 283 . 285 Authors' Addresses 287 Haibo Wang 288 Huawei 289 156 Beiqing Road 290 Beijing 100095 291 P.R. China 293 Email: rainsword.wang@huawei.com 295 Aijun Wang 296 China Telecom 297 Beiqijia Town, Changping District 298 Beijing 102209 299 P.R. China 301 Email: wangaj3@chinatelecom.cn 302 Shunwan Zhuang 303 Huawei 304 156 Beiqing Road 305 Beijing 100095 306 P.R. China 308 Email: zhuangshunwan@huawei.com