idnits 2.17.1 draft-ietf-idr-flowspec-mpls-match-01.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (December 6, 2016) is 2691 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: 'RFC2119' is defined on line 250, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) == Outdated reference: A later version (-05) exists of draft-hares-idr-flowspec-v2-00 == Outdated reference: A later version (-03) exists of draft-hr-idr-rfc5575bis-02 == Outdated reference: A later version (-02) exists of draft-ietf-idr-bgp-flowspec-label-00 == Outdated reference: A later version (-15) exists of draft-ietf-idr-bgp-flowspec-oid-03 == Outdated reference: A later version (-22) exists of draft-ietf-idr-flow-spec-v6-07 == Outdated reference: A later version (-23) exists of draft-ietf-idr-flowspec-l2vpn-04 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group L. Yong 3 Internet-Draft S. Hares 4 Intended status: Standards Track Q. Liang 5 Expires: June 9, 2017 J. You 6 Huawei 7 December 6, 2016 9 BGP Flow Specification Filter for MPLS Label 10 draft-ietf-idr-flowspec-mpls-match-01.txt 12 Abstract 14 This draft proposes BGP flow specification rules that are used to 15 filter MPLS labeled packets. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 9, 2017. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. The Flow Specification Encoding for MPLS Match . . . . . . . 3 53 3. Deployment Example: DDoS Traffic . . . . . . . . . . . . . . 4 54 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 56 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 58 6.2. Informative References . . . . . . . . . . . . . . . . . 6 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 61 1. Introduction 63 BGP Flow Specification (BGP-FS) [RFC5575] is an extension to that 64 allows for the dissemination of traffic flow specification rules via 65 BGP ([RFC4271]). BGP-FS policies have a match condition that may be 66 n-tuple match in a policy, and an action that modifies the packet and 67 forwards/drops the packet. Via BGP, new filter rules can be sent to 68 all BGP peers simultaneously without changing router configuration, 69 and the BGP peer can install these routes in the forwarding table. 70 The typical application of BGP-FS is to automate the distribution of 71 traffic filter lists to routers for DDOS mitigation. 73 [RFC5575] defines a new BGP Network Layer Reachability Information 74 (NLRI) format used to distribute traffic flow specification rules. 75 NLRI (AFI=1, SAFI=133) is for IPv4 unicast filtering. NLRI (AFI=1, 76 SAFI=134)is for BGP/MPLS VPN filtering. [I-D.ietf-idr-flow-spec-v6] 77 defines flow-spec extension for IPv6 data packets. 78 [I-D.ietf-idr-flowspec-l2vpn] extends the flow-spec rules for layer 2 79 Ethernet packets (AFI=25, SAFI=133, SAFI=134). All these flow 80 specifications match parts only reflect single layer IP (source/ 81 destination IP prefix, protocol type, ports, etc.) and Ethernet 82 information with matches for source/destination MAC 84 [I-D.hr-idr-rfc5575bis] provides updates to [RFC5575] to resolve 85 unclear sections in text and conflicts with interactions of filtering 86 actions. 88 MPLS technologies [RFC3031] have been widely deployed in WAN 89 networks. MPLS label stack [RFC3032] is the foundation for label 90 switched data plane. A label on a label stack may represent a label 91 switch path (LSP), application identification such as Pseudo Wire 92 (PW), a reserved label that triggers a specific data plane action, or 93 etc. The data plane label switching operations includes pop, push, 94 or swap label on the label stack. 96 For value added services, it is valuable for a MPLS network to have 97 BGP-FS policy filter that matches on the MPLS portion of a packet and 98 an action to modify the MPLS packet header and/or monitor the packets 99 that match the policy. This document specifies an MPLS match filter. 100 [I-D.ietf-idr-bgp-flowspec-label] specifies a BGP action to modify 101 the MPLS label. 103 [I-D.hares-idr-flowspec-v2] describes the following two options for 104 extending [RFC5575]: creating a version 2 of BGP Flow Specification 105 which can run in parallel to the original BGP Flow specification. 106 Version 2 may also include improved security features (ROAs or 107 [I-D.ietf-idr-bgp-flowspec-oid]) 109 This MPLS match option can be used for RFC5575 ([RFC5575], 110 [I-D.hr-idr-rfc5575bis]) or version 2 of the flow specification. 112 2. The Flow Specification Encoding for MPLS Match 114 This document proposes new flow specifications rules that is encoded 115 in NLRI. 117 Type TBD1- MPLS Match1 119 Function: The match1 applies to MPLS Label field on the label 120 stack. 122 Encoding: . 124 It contains a set of {operator, value} pairs that are used for 125 matching filter. 127 The operator byte is encoded as: 129 0 1 2 3 4 5 6 7 130 +---+---+---+---+---+---+---+---+ 131 | e | a | i | pos | Resv | 132 +---+---+---+---+---+---+---+---+ 134 where: 136 e - end of list bit: Set in the last {op, value} pair in the 137 list. 139 a - AND bit: If unset, the previous term is logically ORed 140 with the current one. If set, the operation is a logical 141 AND. It should be unset in the first operator byte of a 142 sequence. The AND operator has higher priority than OR for 143 the purposes of evaluating logical expressions. 145 i - before bit: If unset, apply matching filter before MPLS 146 label data plane action; if set, apply matching filter after 147 MPLS label data plane action. 149 pos - the label position indication bits: where: 151 00:any position on the label stack - the presented label 152 value is used to match any label on the label stack. 153 When apply it, at least one label on the stack match the 154 value 156 01:top label indication- the presented label value MUST be 157 used to match the top label on the label stack. 159 10: bottom label indication- If it is set, the presented 160 label value MUST match the bottom label on the label 161 stack. When it is clear, the present label value can 162 match to any label on the label stack 164 11: (for reserved labels) 166 The value field is encoded as: 168 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Label | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 Type TBD2 - MPLS Match2 175 Function: MPLS Match2 applies to MPLS Label experiment bits 176 (EXP) on the top label in the label stack. 178 Encoding: 180 [op,value] - Defines a list of {operation, value} pairs used 181 to match 3-bit exp field on the top label of packets 182 [RFC3032]. 184 Values are encoded using a single byte, where the five most 185 significant bits are zero and the three least significant 186 bits contain the exp value. 188 3. Deployment Example: DDoS Traffic 190 In this example, 5 local policy rules in the filter-based RIBs (FB- 191 RB, aka Policy Routing) will match n-tuples (destination IP address, 192 Destination Port, source IP address, Source IP Address, protocols 193 (ICMP and STCP). These policy rules can be created by standard yang 194 modules for filter-based RIBS (configuration, and ephemeral 195 configuration) or ACLs, or vendor based policy. These policies will 196 put the DDoS attack data onto one LSP (LSP1) in order to send the 197 DDoS traffic to the IDS/IPS processing attached to PE2. 199 The MPLS Filter allows the BGP Flow specification to match on the LSP 200 label rather than the IP address so that PE2 (with the FB-RIBs on 201 PE2) can forward the traffic to a set of IDS/IPS machines. The BGP 202 Flow Specification (BGP-FS) can forward this simple match policy 203 along with an action policy that constraints the traffic on this Flow 204 to a certain rate (bytes/second). 206 |<---------------- AS1 ----------------->| 207 +---------+ +-----+ +-----+ +-----+ 208 ===| PE1 |---|IBGP |----|IBGP |----| PE2 |--IDS-1/IPS 209 | Filters | | | | | | |--IDS-2/IPS 210 +---------+ +-----+ +-----+ +-----+ 211 |-------------------------------| 212 MPLS travel on LSP-1 with label-1 214 BGP Flow Specification Filter 1 216 BGP Flow Specification 217 Match Policy 218 Destination IP address (0/0) [Required by RFC5575] 219 MPLS Label match (label-1) 220 Action Policy 221 Traffic-rate (n bytes) 223 4. Security Considerations 225 The validation of BGP Flow Specification policy relies on the 226 security of the BGP protocol and RFC 5575 checks ([RFC5575], 227 [I-D.hr-idr-rfc5575bis]) for BGP Flow specification version 1 and BGP 228 Flow specification version 2 ([I-D.hares-idr-flowspec-v2]). For 229 Option 1, the MPLS Match can be one of the match filtes, and and the 230 final match is an "AND" of all the filters. Match filters are tested 231 in the order specified in [I-D.hares-idr-flowspec-v2] and/or an 232 RFC5575bis document. 234 5. IANA Considerations 236 This section complies with [RFC7153] 238 IANA is requested to a new entry in "Flow Spec component types 239 registry" with the following values: 241 Value Name: Value Reference 242 =========== ===== ========= 243 MPLS-Match1 TBD1 [This Document] 244 MPLS-Match2 TBD2 [This Document] 246 6. References 248 6.1. Normative References 250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 251 Requirement Levels", BCP 14, RFC 2119, 252 DOI 10.17487/RFC2119, March 1997, 253 . 255 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 256 Label Switching Architecture", RFC 3031, 257 DOI 10.17487/RFC3031, January 2001, 258 . 260 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 261 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 262 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 263 . 265 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 266 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 267 DOI 10.17487/RFC4271, January 2006, 268 . 270 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 271 and D. McPherson, "Dissemination of Flow Specification 272 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 273 . 275 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 276 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 277 March 2014, . 279 6.2. Informative References 281 [I-D.hares-idr-flowspec-v2] 282 Hares, S., "BGP Flow Specification Version 2", draft- 283 hares-idr-flowspec-v2-00 (work in progress), June 2016. 285 [I-D.hr-idr-rfc5575bis] 286 Hares, S., Raszuk, R., McPherson, D., Loibl, C., and M. 287 Bacher, "Dissemination of Flow Specification Rules", 288 draft-hr-idr-rfc5575bis-02 (work in progress), November 289 2016. 291 [I-D.ietf-idr-bgp-flowspec-label] 292 liangqiandeng, l., Hares, S., You, J., Raszuk, R., and d. 293 danma@cisco.com, "Carrying Label Information for BGP 294 FlowSpec", draft-ietf-idr-bgp-flowspec-label-00 (work in 295 progress), June 2016. 297 [I-D.ietf-idr-bgp-flowspec-oid] 298 Uttaro, J., Filsfils, C., Smith, D., Alcaide, J., and P. 299 Mohapatra, "Revised Validation Procedure for BGP Flow 300 Specifications", draft-ietf-idr-bgp-flowspec-oid-03 (work 301 in progress), March 2016. 303 [I-D.ietf-idr-flow-spec-v6] 304 McPherson, D., Raszuk, R., Pithawala, B., 305 akarch@cisco.com, a., and S. Hares, "Dissemination of Flow 306 Specification Rules for IPv6", draft-ietf-idr-flow-spec- 307 v6-07 (work in progress), March 2016. 309 [I-D.ietf-idr-flowspec-l2vpn] 310 Weiguo, H., liangqiandeng, l., Litkowski, S., and S. 311 Zhuang, "Dissemination of Flow Specification Rules for L2 312 VPN", draft-ietf-idr-flowspec-l2vpn-04 (work in progress), 313 May 2016. 315 Authors' Addresses 317 Lucy Yong 318 Huawei 320 Email: lucy.yong@huawei.com 322 Susan Hares 323 Huawei 324 7453 Hickory Hill 325 Saline, MI 48176 326 USA 328 Email: shares@ndzh.com 329 Qiandeng Liang 330 Huawei 331 101 Software Avenue, Yuhuatai District 332 Nanjing 210012 333 China 335 Email: liangqiandeng@huawei.com 337 Jianjie You 338 Huawei 339 101 Software Avenue, Yuhuatai District 340 Nanjing 210012 341 China 343 Email: youjianjie@huawei.com