idnits 2.17.1 draft-ietf-idr-rfc5575bis-18.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 has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? -- The draft header indicates that this document obsoletes RFC7674, but the abstract doesn't seem to directly say this. It does mention RFC7674 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC5575, but the abstract doesn't seem to directly say this. It does mention RFC5575 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 4, 2019) is 1633 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) -- Looks like a reference, but probably isn't: '137' on line 642 -- Looks like a reference, but probably isn't: '139' on line 642 -- Looks like a reference, but probably isn't: '1' on line 1558 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754.1985' ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-22) exists of draft-ietf-idr-flow-spec-v6-09 -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) -- Obsolete informational reference (is this intentional?): RFC 7674 (Obsoleted by RFC 8955) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group C. Loibl 3 Internet-Draft Next Layer Communications 4 Obsoletes: 5575,7674 (if approved) S. Hares 5 Intended status: Standards Track Huawei 6 Expires: May 7, 2020 R. Raszuk 7 Bloomberg LP 8 D. McPherson 9 Verisign 10 M. Bacher 11 T-Mobile Austria 12 November 4, 2019 14 Dissemination of Flow Specification Rules 15 draft-ietf-idr-rfc5575bis-18 17 Abstract 19 This document obsoletes both RFC5575 and RFC7674. 21 This document defines a Border Gateway Protocol Network Layer 22 Reachability Information (BGP NLRI) encoding format, that can be used 23 to distribute traffic Flow Specifications. This allows the routing 24 system to propagate information regarding more specific components of 25 the traffic aggregate defined by an IP destination prefix. 27 It also specifies BGP Extended Community encoding formats, that can 28 be used to propagate Traffic Filtering Actions along with the Flow 29 Specification NLRI. Those Traffic Filtering Actions encode actions a 30 routing system can take if the packet matches the Flow Specification. 32 Additionally, it defines two applications of that encoding format: 33 one that can be used to automate inter-domain coordination of traffic 34 filtering, such as what is required in order to mitigate 35 (distributed) denial-of-service attacks, and a second application to 36 provide traffic filtering in the context of a BGP/MPLS VPN service. 37 Other applications (ie. centralized control of traffic in a SDN or 38 NFV context) are also possible. Other drafts specify IPv6, MPLS 39 addresses, L2VPN addresses, and NV03 encapsulation of IP addresses as 40 Flow Specification extensions. 42 The information is carried via the BGP, thereby reusing protocol 43 algorithms, operational experience, and administrative processes such 44 as inter-provider peering agreements. 46 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at https://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on May 7, 2020. 63 Copyright Notice 65 Copyright (c) 2019 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (https://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 81 2. Definitions of Terms Used in This Memo . . . . . . . . . . . 5 82 3. Flow Specifications . . . . . . . . . . . . . . . . . . . . . 5 83 4. Dissemination of IPv4 FLow Specification Information . . . . 6 84 4.1. Length Encoding . . . . . . . . . . . . . . . . . . . . . 7 85 4.2. NLRI Value Encoding . . . . . . . . . . . . . . . . . . . 7 86 4.2.1. Operators . . . . . . . . . . . . . . . . . . . . . . 7 87 4.2.2. Components . . . . . . . . . . . . . . . . . . . . . 9 88 4.3. Examples of Encodings . . . . . . . . . . . . . . . . . . 13 89 5. Traffic Filtering . . . . . . . . . . . . . . . . . . . . . . 16 90 5.1. Ordering of Flow Specifications . . . . . . . . . . . . . 17 91 6. Validation Procedure . . . . . . . . . . . . . . . . . . . . 18 92 7. Traffic Filtering Actions . . . . . . . . . . . . . . . . . . 19 93 7.1. Traffic Rate in Bytes (traffic-rate-bytes) sub-type 0x06 20 94 7.2. Traffic Rate in Packets (traffic-rate-packets) sub-type 95 TBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 96 7.3. Traffic-action (traffic-action) sub-type 0x07 . . . . . . 21 97 7.4. RT Redirect (rt-redirect) sub-type 0x08 . . . . . . . . . 22 98 7.5. Traffic Marking (traffic-marking) sub-type 0x09 . . . . . 22 99 7.6. Interaction with other Filtering Mechanisms in Routers . 23 100 7.7. Considerations on Traffic Filtering Action Interference . 23 101 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks . 24 102 9. Traffic Monitoring . . . . . . . . . . . . . . . . . . . . . 25 103 10. Error-Handling . . . . . . . . . . . . . . . . . . . . . . . 25 104 11. Future NLRI Extensions . . . . . . . . . . . . . . . . . . . 25 105 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 106 12.1. AFI/SAFI Definitions . . . . . . . . . . . . . . . . . . 26 107 12.2. Flow Component Definitions . . . . . . . . . . . . . . . 26 108 12.3. Extended Community Flow Specification Actions . . . . . 27 109 13. Security Considerations . . . . . . . . . . . . . . . . . . . 30 110 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 111 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 112 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 113 16.1. Normative References . . . . . . . . . . . . . . . . . . 32 114 16.2. Informative References . . . . . . . . . . . . . . . . . 33 115 16.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 34 116 Appendix A. Python code: flow_rule_cmp . . . . . . . . . . . . . 34 117 Appendix B. Comparison with RFC 5575 . . . . . . . . . . . . . . 36 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 120 1. Introduction 122 This document obsoletes both 123 "Dissemination of Flow Specification Rules" [RFC5575] and 124 "Clarification of the Flowspec Redirect Extended Community"[RFC7674]. 126 Modern IP routers contain both the capability to forward traffic 127 according to IP prefixes as well as to classify, shape, rate limit, 128 filter, or redirect packets based on administratively defined 129 policies. These traffic policy mechanisms allow the operator to 130 define match rules that operate on multiple fields of the packet 131 header. Actions such as the ones described above can be associated 132 with each rule. 134 The n-tuple consisting of the matching criteria defines an aggregate 135 traffic Flow Specification. The matching criteria can include 136 elements such as source and destination address prefixes, IP 137 protocol, and transport protocol port numbers. 139 Section 4 of this document defines a general procedure to encode Flow 140 Specification for aggregated traffic flows so that they can be 141 distributed as a BGP [RFC4271] NLRI. Additionally, Section 7 of this 142 document defines the required Traffic Filtering Actions BGP Extended 143 Communities and mechanisms to use BGP for intra- and inter-provider 144 distribution of traffic filtering rules to filter (distributed) 145 denial-of-service (DoS) attacks. 147 By expanding routing information with Flow Specifications, the 148 routing system can take advantage of the ACL (Access Control List) or 149 firewall capabilities in the router's forwarding path. Flow 150 Specifications can be seen as more specific routing entries to a 151 unicast prefix and are expected to depend upon the existing unicast 152 data information. 154 A Flow Specification received from an external autonomous system will 155 need to be validated against unicast routing before being accepted 156 (Section 6). The flow specification received from an internal BGP 157 peer within the same autonomous system (per [RFC4271]) is assumed to 158 have been validated prior to transmission within the iBGP mesh of an 159 autonomous system. If the aggregate traffic flow defined by the 160 unicast destination prefix is forwarded to a given BGP peer, then the 161 local system can install more specific Flow Specifications that may 162 result in different forwarding behavior, as requested by this system. 164 From an operational perspective, the utilization of BGP as the 165 carrier for this information allows a network service provider to 166 reuse both internal route distribution infrastructure (e.g., route 167 reflector or confederation design) and existing external 168 relationships (e.g., inter-domain BGP sessions to a customer 169 network). 171 While it is certainly possible to address this problem using other 172 mechanisms, this solution has been utilized in deployments because of 173 the substantial advantage of being an incremental addition to already 174 deployed mechanisms. 176 In current deployments, the information distributed by this extension 177 is originated both manually as well as automatically. The latter by 178 systems that are able to detect malicious traffic flows. When 179 automated systems are used, care should be taken to ensure their 180 correctness as well as the limitations of the systems that receive 181 and process the advertised Flow Specifications (see also Section 13). 183 This specification defines required protocol extensions to address 184 most common applications of IPv4 unicast and VPNv4 unicast filtering. 185 The same mechanism can be reused and new match criteria added to 186 address similar filtering needs for other BGP address families such 187 as IPv6 families [I-D.ietf-idr-flow-spec-v6]. 189 2. Definitions of Terms Used in This Memo 191 AFI - Address Family Identifier. 193 AS - Autonomous System. 195 Loc-RIB - The Loc-RIB contains the routes that have been selected 196 by the local BGP speaker's Decision Process. 198 NLRI - Network Layer Reachability Information. 200 PE - Provider Edge router. 202 RIB - Routing Information Base. 204 SAFI - Subsequent Address Family Identifier. 206 VRF - Virtual Routing and Forwarding instance. 208 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 209 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 210 "OPTIONAL" in this document are to be interpreted as described in BCP 211 14 [RFC2119] [RFC8174] when, and only when, they appear in all 212 capitals, as shown here. 214 3. Flow Specifications 216 A Flow Specification is an n-tuple consisting of several matching 217 criteria that can be applied to IP traffic. A given IP packet is 218 said to match the defined Flow Specification if it matches all the 219 specified criteria. This n-tuple is encoded into a BGP NLRI defined 220 below. 222 A given Flow Specification may be associated with a set of 223 attributes, depending on the particular application; such attributes 224 may or may not include reachability information (i.e., NEXT_HOP). 225 Well-known or AS-specific community attributes can be used to encode 226 a set of predetermined actions. 228 A particular application is identified by a specific (Address Family 229 Identifier, Subsequent Address Family Identifier (AFI, SAFI)) pair 230 [RFC4760] and corresponds to a distinct set of RIBs. Those RIBs 231 should be treated independently from each other in order to assure 232 non-interference between distinct applications. 234 BGP itself treats the NLRI as a key to an entry in its databases. 235 Entries that are placed in the Loc-RIB are then associated with a 236 given set of semantics, which is application dependent. This is 237 consistent with existing BGP applications. For instance, IP unicast 238 routing (AFI=1, SAFI=1) and IP multicast reverse-path information 239 (AFI=1, SAFI=2) are handled by BGP without any particular semantics 240 being associated with them until installed in the Loc-RIB. 242 Standard BGP policy mechanisms, such as UPDATE filtering by NLRI 243 prefix as well as community matching and manipulation, must apply to 244 the Flow Specification defined NLRI-type, especially in an inter- 245 domain environment. Network operators can also control propagation 246 of such routing updates by enabling or disabling the exchange of a 247 particular (AFI, SAFI) pair on a given BGP peering session. 249 4. Dissemination of IPv4 FLow Specification Information 251 This document defines a Flow Specification NLRI type (Figure 1) that 252 may include several components such as destination prefix, source 253 prefix, protocol, ports, and others (see Section 4.2 below). 255 This NLRI information is encoded using MP_REACH_NLRI and 256 MP_UNREACH_NLRI attributes as defined in [RFC4760]. Whenever the 257 corresponding application does not require Next Hop information, this 258 shall be encoded as a 0-octet length Next Hop in the MP_REACH_NLRI 259 attribute (if a non 0-octet Next Hop is present it should be ignored 260 on receipt). 262 The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as 263 a 1- or 2-octet NLRI length field followed by a variable-length NLRI 264 value. The NLRI length is expressed in octets. 266 +-------------------------------+ 267 | length (0xnn or 0xfnnn) | 268 +-------------------------------+ 269 | NLRI value (variable) | 270 +-------------------------------+ 272 Figure 1: Flow Specification NLRI for IPv4 274 Implementations wishing to exchange Flow Specification MUST use BGP's 275 Capability Advertisement facility to exchange the Multiprotocol 276 Extension Capability Code (Code 1) as defined in [RFC4760]. The 277 (AFI, SAFI) pair carried in the Multiprotocol Extension Capability 278 MUST be (AFI=1, SAFI=133) for IPv4 Flow Specification, and (AFI=1, 279 SAFI=134) for VPNv4 Flow Specification. 281 4.1. Length Encoding 283 o If the NLRI length is smaller than 240 (0xf0 hex) octets, the 284 length field can be encoded as a single octet. 286 o Otherwise, it is encoded as an extended-length 2-octet value in 287 which the most significant nibble of the first byte is all ones. 289 In Figure 1 above, values less-than 240 are encoded using two hex 290 digits (0xnn). Values above 239 are encoded using 3 hex digits 291 (0xfnnn). The highest value that can be represented with this 292 encoding is 4095. For example the length value of 239 is encoded as 293 0xef (single octet) while 240 is encoded as 0xf0f0 (2-octet). 295 4.2. NLRI Value Encoding 297 The Flow Specification NLRI value consists of a list of optional 298 components and is encoded as follows: 300 Encoding: <[component]+> 302 A specific packet is considered to match the Flow Specification when 303 it matches the intersection (AND) of all the components present in 304 the Flow Specification. 306 Components must follow strict type ordering by increasing numerical 307 order. A given component type may (exactly once) or may not be 308 present in the Flow Specification. If present, it MUST precede any 309 component of higher numeric type value. 311 All combinations of components within a single Flow Specification are 312 allowed. However, some combinations cannot match any packets (ie. 313 "ICMP Type AND Port" will never match any packets), and thus SHOULD 314 NOT be propagated by BGP. 316 4.2.1. Operators 318 Most of the components described below make use of comparison 319 operators. Which of the two operators is used is defined by the 320 components in Section 4.2.2. The operators are encoded as a single 321 octet. 323 4.2.1.1. Numeric Operator (numeric_op) 325 This operator is encoded as shown in Figure 2. 327 0 1 2 3 4 5 6 7 328 +---+---+---+---+---+---+---+---+ 329 | e | a | len | 0 |lt |gt |eq | 330 +---+---+---+---+---+---+---+---+ 332 Figure 2: Numeric Operator (numeric_op) 334 e - end-of-list bit: Set in the last {op, value} pair in the list. 336 a - AND bit: If unset, the previous term is logically ORed with the 337 current one. If set, the operation is a logical AND. In the 338 first operator byte of a sequence it SHOULD be encoded as unset 339 and and MUST be treated as always unset on decoding. The AND 340 operator has higher priority than OR for the purposes of 341 evaluating logical expressions. 343 len - length: The length of the value field for this operator given 344 as (1 << len). This encodes 1 (len=00), 2 (len=01), 4 (len=10), 8 345 (len=11) bytes. 347 0 - SHOULD be set to 0 on NLRI encoding, and MUST be ignored during 348 decoding 350 lt - less than comparison between data and value. 352 gt - greater than comparison between data and value. 354 eq - equality between data and value. 356 The bits lt, gt, and eq can be combined to produce common relational 357 operators such as "less or equal", "greater or equal", and "not equal 358 to" as shown in Table 1. 360 +----+----+----+----------------------------------+ 361 | lt | gt | eq | Resulting operation | 362 +----+----+----+----------------------------------+ 363 | 0 | 0 | 0 | false (independent of the value) | 364 | 0 | 0 | 1 | == (equal) | 365 | 0 | 1 | 0 | > (greater than) | 366 | 0 | 1 | 1 | >= (greater than or equal) | 367 | 1 | 0 | 0 | < (less than) | 368 | 1 | 0 | 1 | <= (less than or equal) | 369 | 1 | 1 | 0 | != (not equal value) | 370 | 1 | 1 | 1 | true (independent of the value) | 371 +----+----+----+----------------------------------+ 373 Table 1: Comparison operation combinations 375 4.2.1.2. Bitmask Operator (bitmask_op) 377 This operator is encoded as shown in Figure 3. 379 0 1 2 3 4 5 6 7 380 +---+---+---+---+---+---+---+---+ 381 | e | a | len | 0 | 0 |not| m | 382 +---+---+---+---+---+---+---+---+ 384 Figure 3: Bitmask Operator (bitmask_op) 386 e, a, len - Most significant nibble: (end-of-list bit, AND bit, and 387 length field), as defined in the Numeric Operator format in 388 Section 4.2.1.1. 390 not - NOT bit: If set, logical negation of operation. 392 m - Match bit: If set, this is a bitwise match operation defined as 393 "(data AND value) == value"; if unset, (data AND value) evaluates 394 to TRUE if any of the bits in the value mask are set in the data 396 0 - all 0 bits: SHOULD be set to 0 on NLRI encoding, and MUST be 397 ignored during decoding 399 4.2.2. Components 401 The encoding of each of the components begins with a type field (1 402 octet) followed by a variable length parameter. The following 403 sections define component types and parameter encodings for the IPv4 404 IP layer and transport layer headers. IPv6 NLRI component types are 405 described in [I-D.ietf-idr-flow-spec-v6]. 407 4.2.2.1. Type 1 - Destination Prefix 409 Encoding: 411 Defines the destination prefix to match. The length and prefix 412 fields are encoded as in BGP UPDATE messages [RFC4271] 414 4.2.2.2. Type 2 - Source Prefix 416 Encoding: 418 Defines the source prefix to match. The length and prefix fields are 419 encoded as in BGP UPDATE messages [RFC4271] 421 4.2.2.3. Type 3 - IP Protocol 423 Encoding: 425 Contains a list of {numeric_op, value} pairs that are used to match 426 the IP protocol value byte in IP packet header (see [RFC0791] 427 Section 3.1). 429 This component uses the Numeric Operator (numeric_op) described in 430 Section 4.2.1.1. Type 3 component values SHOULD be encoded as single 431 byte (numeric_op len=00). 433 4.2.2.4. Type 4 - Port 435 Encoding: 437 Defines a list of {numeric_op, value} pairs that matches source OR 438 destination TCP/UDP ports (see [RFC0793] Section 3.1 and [RFC0768] 439 Section "Format"). This component matches if either the destination 440 port OR the source port of a IP packet matches the value. 442 This component uses the Numeric Operator (numeric_op) described in 443 Section 4.2.1.1. Type 4 component values SHOULD be encoded as 1- or 444 2-byte quantities (numeric_op len=00 or len=01). 446 In case of the presence of the port (destination-port, source-port) 447 component only TCP or UDP packets can match the entire Flow 448 Specification. The port component, if present, never matches when 449 the packet's IP protocol value is not 6 (TCP) or 17 (UDP), if the 450 packet is fragmented and this is not the first fragment, or if the 451 system is unable to locate the transport header. Different 452 implementations may or may not be able to decode the transport header 453 in the presence of IP options or Encapsulating Security Payload (ESP) 454 NULL [RFC4303] encryption. 456 4.2.2.5. Type 5 - Destination Port 458 Encoding: 460 Defines a list of {numeric_op, value} pairs used to match the 461 destination port of a TCP or UDP packet (see also [RFC0793] 462 Section 3.1 and [RFC0768] Section "Format"). 464 This component uses the Numeric Operator (numeric_op) described in 465 Section 4.2.1.1. Type 5 component values SHOULD be encoded as 1- or 466 2-byte quantities (numeric_op len=00 or len=01). 468 The last paragraph of Section 4.2.2.4 also applies to this component. 470 4.2.2.6. Type 6 - Source Port 472 Encoding: 474 Defines a list of {numeric_op, value} pairs used to match the source 475 port of a TCP or UDP packet (see also [RFC0793] Section 3.1 and 476 [RFC0768] Section "Format"). 478 This component uses the Numeric Operator (numeric_op) described in 479 Section 4.2.1.1. Type 6 component values SHOULD be encoded as 1- or 480 2-byte quantities (numeric_op len=00 or len=01). 482 The last paragraph of Section 4.2.2.4 also applies to this component. 484 4.2.2.7. Type 7 - ICMP type 486 Encoding: 488 Defines a list of {numeric_op, value} pairs used to match the type 489 field of an ICMP packet (see also [RFC0792] Section "Message 490 Formats"). 492 This component uses the Numeric Operator (numeric_op) described in 493 Section 4.2.1.1. Type 7 component values SHOULD be encoded as single 494 byte (numeric_op len=00). 496 In case of the presence of the ICMP type (code) component only ICMP 497 packets can match the entire Flow Specification. The ICMP type 498 (code) component, if present, never matches when the packet's IP 499 protocol value is not 1 (ICMP), if the packet is fragmented and this 500 is not the first fragment, or if the system is unable to locate the 501 transport header. Different implementations may or may not be able 502 to decode the transport header in the presence of IP options or 503 Encapsulating Security Payload (ESP) NULL [RFC4303] encryption. 505 4.2.2.8. Type 8 - ICMP code 507 Encoding: 509 Defines a list of {numeric_op, value} pairs used to match the code 510 field of an ICMP packet (see also [RFC0792] Section "Message 511 Formats"). 513 This component uses the Numeric Operator (numeric_op) described in 514 Section 4.2.1.1. Type 8 component values SHOULD be encoded as single 515 byte (numeric_op len=00). 517 The last paragraph of Section 4.2.2.7 also applies to this component. 519 4.2.2.9. Type 9 - TCP flags 521 Encoding: 523 Defines a list of {bitmask_op, bitmask} pairs used to match TCP 524 Control Bits (see also [RFC0793] Section 3.1). 526 This component uses the Bitmask Operator (bitmask_op) described in 527 Section 4.2.1.2. Type 9 component bitmasks MUST be encoded as 1- or 528 2-byte bitmask (bitmask_op len=00 or len=01). 530 When a single byte (bitmask_op len=00) is specified, it matches byte 531 14 of the TCP header (see also [RFC0793] Section 3.1), which contains 532 the TCP Control Bits. When a 2-byte (bitmask_op len=01) encoding is 533 used, it matches bytes 13 and 14 of the TCP header with the data 534 offset (leftmost 4 bits) always treated as 0. 536 In case of the presence of the TCP flags component only TCP packets 537 can match the entire Flow Specification. The TCP flags component, if 538 present, never matches when the packet's IP protocol value is not 6 539 (TCP), if the packet is fragmented and this is not the first 540 fragment, or if the system is unable to locate the transport header. 541 Different implementations may or may not be able to decode the 542 transport header in the presence of IP options or Encapsulating 543 Security Payload (ESP) NULL [RFC4303] encryption. 545 4.2.2.10. Type 10 - Packet length 547 Encoding: 549 Defines a list of {numeric_op, value} pairs used to match on the 550 total IP packet length (excluding Layer 2 but including IP header). 552 This component uses the Numeric Operator (numeric_op) described in 553 Section 4.2.1.1. Type 10 component values SHOULD be encoded as 1- or 554 2-byte quantities (numeric_op len=00 or len=01). 556 4.2.2.11. Type 11 - DSCP (Diffserv Code Point) 558 Encoding: 560 Defines a list of {numeric_op, value} pairs used to match the 6-bit 561 DSCP field (see also [RFC2474]). 563 This component uses the Numeric Operator (numeric_op) described in 564 Section 4.2.1.1. Type 11 component values MUST be encoded as single 565 byte (numeric_op len=00). 567 The six least significant bits contain the DSCP value. All other 568 bits SHOULD be treated as 0. 570 4.2.2.12. Type 12 - Fragment 572 Encoding: 574 Defines a list of {bitmask_op, bitmask} pairs used to match specific 575 IP fragments. 577 This component uses the Bitmask Operator (bitmask_op) described in 578 Section 4.2.1.2. The Type 12 component bitmask MUST be encoded as 579 single byte bitmask (bitmask_op len=00). 581 0 1 2 3 4 5 6 7 582 +---+---+---+---+---+---+---+---+ 583 | 0 | 0 | 0 | 0 |LF |FF |IsF|DF | 584 +---+---+---+---+---+---+---+---+ 586 Figure 4: Fragment Bitmask Operand 588 Bitmask values: 590 DF - Don't fragment - match if [RFC0791] IP Header Flags Bit-1 (DF) 591 is 1 593 IsF - Is a fragment - match if [RFC0791] IP Header Fragment Offset 594 is not 0 596 FF - First fragment - match if [RFC0791] IP Header Fragment Offset 597 is 0 AND Flags Bit-2 (MF) is 1 599 LF - Last fragment - match if [RFC0791] IP Header Fragment Offset is 600 not 0 AND Flags Bit-2 (MF) is 0 602 0 - SHOULD be set to 0 on NLRI encoding, and MUST be ignored during 603 decoding 605 4.3. Examples of Encodings 607 4.3.1. Example 1 609 An example of a Flow Specification NLRI encoding for: "all packets to 610 192.0.2.0/24 and TCP port 25". 612 +--------+----------------+----------+----------+ 613 | length | destination | protocol | port | 614 +--------+----------------+----------+----------+ 615 | 0x0b | 01 18 c0 00 02 | 03 81 06 | 04 81 19 | 616 +--------+----------------+----------+----------+ 618 Decoded: 620 +-------+------------+------------------------------+ 621 | Value | | | 622 +-------+------------+------------------------------+ 623 | 0x0b | length | 11 octets (len<240 1-octet) | 624 | 0x01 | type | Type 1 - Destination Prefix | 625 | 0x18 | length | 24 bit | 626 | 0xc0 | prefix | 192 | 627 | 0x00 | prefix | 0 | 628 | 0x02 | prefix | 2 | 629 | 0x03 | type | Type 3 - IP Protocol | 630 | 0x81 | numeric_op | end-of-list, value size=1, = | 631 | 0x06 | value | IP Protocol 6 = TCP | 632 | 0x04 | type | Type 4 - Port | 633 | 0x81 | numeric_op | end-of-list, value size=1, = | 634 | 0x19 | value | 25 | 635 +-------+------------+------------------------------+ 637 This constitutes a NLRI with a NLRI length of 11 octets. 639 4.3.2. Example 2 641 An example of a Flow Specification NLRI encoding for: "all packets to 642 192.0.2.0/24 from 203.0.113.0/24 and port {range [137, 139] or 643 8080}". 645 +--------+----------------+----------------+-------------------------+ 646 | length | destination | source | port | 647 +--------+----------------+----------------+-------------------------+ 648 | 0x12 | 01 18 c0 00 02 | 02 18 cb 00 71 | 04 03 89 45 8b 91 1f 90 | 649 +--------+----------------+----------------+-------------------------+ 651 Decoded: 653 +--------+------------+------------------------------+ 654 | Value | | | 655 +--------+------------+------------------------------+ 656 | 0x12 | length | 18 octets (len<240 1-octet) | 657 | 0x01 | type | Type 1 - Destination Prefix | 658 | 0x18 | length | 24 bit | 659 | 0xc0 | prefix | 192 | 660 | 0x00 | prefix | 0 | 661 | 0x02 | prefix | 2 | 662 | 0x02 | type | Type 2 - Source Prefix | 663 | 0x18 | length | 24 bit | 664 | 0xcb | prefix | 203 | 665 | 0x00 | prefix | 0 | 666 | 0x71 | prefix | 113 | 667 | 0x04 | type | Type 4 - Port | 668 | 0x03 | numeric_op | value size=1, >= | 669 | 0x89 | value | 137 | 670 | 0x45 | numeric_op | "AND", value size=1, <= | 671 | 0x8b | value | 139 | 672 | 0x91 | numeric_op | end-of-list, value size=2, = | 673 | 0x1f90 | value | 8080 | 674 +--------+------------+------------------------------+ 676 This constitutes a NLRI with a NLRI length of 18 octets. 678 4.3.3. Example 3 680 An example of a Flow Specification NLRI encoding for: "all packets to 681 192.0.2.1/32 and fragment { DF or FF } (matching packet with DF bit 682 set or First Fragments) 684 +--------+-------------------+----------+ 685 | length | destination | fragment | 686 +--------+-------------------+----------+ 687 | 0x09 | 01 20 c0 00 02 01 | 0c 80 05 | 688 +--------+-------------------+----------+ 690 Decoded: 692 +-------+------------+------------------------------+ 693 | Value | | | 694 +-------+------------+------------------------------+ 695 | 0x09 | length | 9 octets (len<240 1-octet) | 696 | 0x01 | type | Type 1 - Destination Prefix | 697 | 0x20 | length | 32 bit | 698 | 0xc0 | prefix | 192 | 699 | 0x00 | prefix | 0 | 700 | 0x02 | prefix | 2 | 701 | 0x01 | prefix | 1 | 702 | 0x0c | type | Type 12 - Fragment | 703 | 0x80 | bitmask_op | end-of-list, value size=1 | 704 | 0x05 | bitmask | DF=1, FF=1 | 705 +-------+------------+------------------------------+ 707 This constitutes a NLRI with a NLRI length of 9 octets. 709 5. Traffic Filtering 711 Traffic filtering policies have been traditionally considered to be 712 relatively static. Limitations of these static mechanisms caused 713 this new dynamic mechanism to be designed for the three new 714 applications of traffic filtering: 716 o Prevention of traffic-based, denial-of-service (DOS) attacks. 718 o Traffic filtering in the context of BGP/MPLS VPN service. 720 o Centralized traffic control for SDN/NFV networks. 722 These applications require coordination among service providers and/ 723 or coordination among the AS within a service provider. 725 The Flow Specification NLRI defined in Section 4 conveys information 726 about traffic filtering rules for traffic that should be discarded or 727 handled in a manner specified by a set of pre-defined actions (which 728 are defined in BGP Extended Communities). This mechanism is 729 primarily designed to allow an upstream autonomous system to perform 730 inbound filtering in their ingress routers of traffic that a given 731 downstream AS wishes to drop. 733 In order to achieve this goal, this draft specifies two application 734 specific NLRI identifiers that provide traffic filters, and a set of 735 actions encoding in BGP Extended Communities. The two application 736 specific NLRI identifiers are: 738 o IPv4 Flow Specification identifier (AFI=1, SAFI=133) along with 739 specific semantic rules for IPv4 routes, and 741 o VPNv4 Flow Specification identifier (AFI=1, SAFI=134) value, which 742 can be used to propagate traffic filtering information in a BGP/ 743 MPLS VPN environment. 745 Encoding of the NLRI is described in Section 4 for IPv4 Flow 746 Specification and in Section 8 for VPNv4 Flow Specification. The 747 filtering actions are described in Section 7. 749 5.1. Ordering of Flow Specifications 751 More than one Flow Specification may match a particular traffic flow. 752 Thus, it is necessary to define the order in which Flow 753 Specifications get matched and actions being applied to a particular 754 traffic flow. This ordering function is such that it does not depend 755 on the arrival order of the Flow Specification via BGP and thus is 756 consistent in the network. 758 The relative order of two Flow Specifications is determined by 759 comparing their respective components. The algorithm starts by 760 comparing the left-most components (lowest component type value) of 761 the Flow Specifications. If the types differ, the Flow Specification 762 with lowest numeric type value has higher precedence (and thus will 763 match before) than the Flow Specification that doesn't contain that 764 component type. If the component types are the same, then a type- 765 specific comparison is performed (see below) if the types are equal 766 the algorithm continues with the next component. 768 For IP prefix values (IP destination or source prefix): If one of the 769 two prefixes to compare is a more specific prefix of the other, the 770 more specific prefix has higher precedence. Otherwise the one with 771 the lowest IP value has higher precedence. 773 For all other component types, unless otherwise specified, the 774 comparison is performed by comparing the component data as a binary 775 string using the memcmp() function as defined by [ISO_IEC_9899]. For 776 strings with equal lengths the lowest string (memcmp) has higher 777 precedence. For strings of different lengths, the common prefix is 778 compared. If the common prefix is not equal the string with the 779 lowest prefix has higher precedence. If the common prefix is equal, 780 the longest string is considered to have higher precedence than the 781 shorter one. 783 The code in Appendix A shows a Python3 implementation of the 784 comparison algorithm. The full code was tested with Python 3.6.3 and 785 can be obtained at https://github.com/stoffi92/flowspec-cmp [1]. 787 6. Validation Procedure 789 Flow Specifications received from a BGP peer that are accepted in the 790 respective Adj-RIB-In are used as input to the route selection 791 process. Although the forwarding attributes of two routes for the 792 same Flow Specification prefix may be the same, BGP is still required 793 to perform its path selection algorithm in order to select the 794 correct set of attributes to advertise. 796 The first step of the BGP Route Selection procedure (Section 9.1.2 of 797 [RFC4271] is to exclude from the selection procedure routes that are 798 considered non-feasible. In the context of IP routing information, 799 this step is used to validate that the NEXT_HOP attribute of a given 800 route is resolvable. 802 The concept can be extended, in the case of the Flow Specification 803 NLRI, to allow other validation procedures. 805 The validation process described below validates Flow Specifications 806 against unicast routes received over the same AFI but the associated 807 unicast routing information SAFI: 809 Flow specification received over SAFI=133 will be validated 810 against routes received over SAFI=1 812 Flow specification received over SAFI=134 will be validated 813 against routes received over SAFI=128 815 By default a Flow Specification NLRI MUST be validated such that it 816 is considered feasible if and only if all of the below is true: 818 a) A destination prefix component is embedded in the Flow 819 Specification. 821 b) The originator of the Flow Specification matches the originator 822 of the best-match unicast route for the destination prefix 823 embedded in the Flow Specification (this is the unicast route with 824 the longest possible prefix length covering the destination prefix 825 embedded in the Flow Specification). 827 c) There are no more specific unicast routes, when compared with 828 the flow destination prefix, that have been received from a 829 different neighboring AS than the best-match unicast route, which 830 has been determined in rule b). 832 However, rule a) MAY be relaxed by explicit configuration, permitting 833 Flow Specifications that include no destination prefix component. If 834 such is the case, rules b) and c) are moot and MUST be disregarded. 836 By originator of a BGP route, we mean either the address of the 837 originator in the ORIGINATOR_ID Attribute [RFC4456], or the source IP 838 address of the BGP peer, if this path attribute is not present. 840 BGP implementations MUST also enforce that the AS_PATH attribute of a 841 route received via the External Border Gateway Protocol (eBGP) 842 contains the neighboring AS in the left-most position of the AS_PATH 843 attribute. While this rule is optional in the BGP specification, it 844 becomes necessary to enforce it for security reasons. 846 The best-match unicast route may change over the time independently 847 of the Flow Specification NLRI. Therefore, a revalidation of the 848 Flow Specification NLRI MUST be performed whenever unicast routes 849 change. Revalidation is defined as retesting that clause a and 850 clause b above are true. 852 Explanation: 854 The underlying concept is that the neighboring AS that advertises the 855 best unicast route for a destination is allowed to advertise Flow 856 Specification information that conveys a more or equally specific 857 destination prefix. Thus, as long as there are no more specific 858 unicast routes, received from a different neighboring AS, which would 859 be affected by that Flow Specification. 861 The neighboring AS is the immediate destination of the traffic 862 described by the Flow Specification. If it requests these flows to 863 be dropped, that request can be honored without concern that it 864 represents a denial of service in itself. Supposedly, the traffic is 865 being dropped by the downstream autonomous system, and there is no 866 added value in carrying the traffic to it. 868 7. Traffic Filtering Actions 870 This document defines a minimum set of Traffic Filtering Actions that 871 it standardizes as BGP extended community values [RFC4360]. This is 872 not meant to be an inclusive list of all the possible actions, but 873 only a subset that can be interpreted consistently across the 874 network. Additional actions can be defined as either requiring 875 standards or as vendor specific. 877 The default action for a matching Flow Specification is to accept the 878 packet (treat the packet according to the normal forwarding behaviour 879 of the system). 881 This document defines the following extended communities values shown 882 in Table 2 in the form 0xttss where tt indicates the type and ss 883 indicates the sub-type of the extended community. Encodings for 884 these extended communities are described below. 886 +--------------+--------------------------+-------------------------+ 887 | community | action | encoding | 888 | 0xttss | | | 889 +--------------+--------------------------+-------------------------+ 890 | 0x8006 | traffic-rate-bytes | 2-byte ASN, 4-byte | 891 | | (Section 7.1) | float | 892 | TBD | traffic-rate-packets | 2-byte ASN, 4-byte | 893 | | (Section 7.1) | float | 894 | 0x8007 | traffic-action (Section | bitmask | 895 | | 7.3) | | 896 | 0x8008 | rt-redirect AS-2byte | 2-octet AS, 4-octet | 897 | | (Section 7.4) | value | 898 | 0x8108 | rt-redirect IPv4 | 4-octet IPv4 address, | 899 | | (Section 7.4) | 2-octet value | 900 | 0x8208 | rt-redirect AS-4byte | 4-octet AS, 2-octet | 901 | | (Section 7.4) | value | 902 | 0x8009 | traffic-marking (Section | DSCP value | 903 | | 7.5) | | 904 +--------------+--------------------------+-------------------------+ 906 Table 2: Traffic Filtering Action Extended Communities 908 Multiple Traffic Filtering Actions defined in this document may be 909 present for a single Flow Specification and SHOULD be applied to the 910 traffic flow (for example traffic-rate-bytes and rt-redirect can be 911 applied to packets at the same time). If not all of the Traffic 912 Filtering Actions can be applied to a traffic flow they should be 913 treated as interfering Traffic filtering actions (see below). 915 Some Traffic Filtering Actions may interfere with each other even 916 contradict. Section 7.7 of this document provides general 917 considerations on such Traffic Filtering Action interference. Any 918 additional definition of Traffic Filtering Actions SHOULD specify the 919 action to take if those Traffic Filtering Actions interfere (also 920 with existing Traffic Filtering Actions). 922 All Traffic Filtering Actions are specified as transitive BGP 923 Extended Communities. 925 7.1. Traffic Rate in Bytes (traffic-rate-bytes) sub-type 0x06 927 The traffic-rate-bytes extended community uses the following extended 928 community encoding: 930 The first two octets carry the 2-octet id, which can be assigned from 931 a 2-byte AS number. When a 4-byte AS number is locally present, the 932 2 least significant bytes of such an AS number can be used. This 933 value is purely informational and SHOULD NOT be interpreted by the 934 implementation. 936 The remaining 4 octets carry the maximum rate information in IEEE 937 floating point [IEEE.754.1985] format, units being bytes per second. 938 A traffic-rate of 0 should result on all traffic for the particular 939 flow to be discarded. On encoding the traffic-rate MUST NOT be 940 negative. On decoding negative values MUST be treated as zero 941 (discard all traffic). 943 Interferes with: No other BGP Flow Specification Traffic Filtering 944 Action in this document. 946 7.2. Traffic Rate in Packets (traffic-rate-packets) sub-type TBD 948 The traffic-rate-packets extended community uses the same encoding as 949 the traffic-rate-bytes extended community. The floating point value 950 carries the maximum packet rate in packets per second. A traffic- 951 rate-packets of 0 should result in all traffic for the particular 952 flow to be discarded. On encoding the traffic-rate-packets MUST NOT 953 be negative. On decoding negative values MUST be treated as zero 954 (discard all traffic). 956 Interferes with: No other BGP Flow Specification Traffic Filtering 957 Action in this document. 959 7.3. Traffic-action (traffic-action) sub-type 0x07 961 The traffic-action extended community consists of 6 bytes of which 962 only the 2 least significant bits of the 6th byte (from left to 963 right) are defined by this document as shown in Figure 5. 965 0 1 2 3 966 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 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 | Traffic Action Field | 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 | Tr. Action Field (cont.) |S|T| 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 Figure 5: Traffic-action Extended Community Encoding 975 where S and T are defined as: 977 o T: Terminal Action (bit 47): When this bit is set, the traffic 978 filtering engine will evaluate any subsequent Flow Specifications 979 (as defined by the ordering procedure). If not set, the 980 evaluation of the traffic filters stops when this Flow 981 Specification is evaluated. 983 o S: Sample (bit 46): Enables traffic sampling and logging for this 984 Flow Specification (only effective when set). 986 o Traffic Action Field: Other Traffic Action Field (see Section 12) 987 bits unused in this specification. 989 The use of the Terminal Action (bit 47) may result in more than one 990 Flow Specification matching a particular traffic flow. All the 991 Traffic Filtering Actions from these Flow Specifications shall be 992 collected and applied. In case of interfering Traffic Filtering 993 Actions it is an implementation decision which Traffic Filtering 994 Actions are selected. See also Section 7.7. 996 Interferes with: No other BGP Flow Specification Traffic Filtering 997 Action in this document. 999 7.4. RT Redirect (rt-redirect) sub-type 0x08 1001 The redirect extended community allows the traffic to be redirected 1002 to a VRF routing instance that lists the specified route-target in 1003 its import policy. If several local instances match this criteria, 1004 the choice between them is a local matter (for example, the instance 1005 with the lowest Route Distinguisher value can be elected). 1007 This Extended Community allows 3 different encodings formats for the 1008 route-target (type 0x80, 0x81, 0x82). It uses the same encoding as 1009 the Route Target Extended Community in Sections 3.1 (type 0x80: 1010 2-octet AS, 4-octet value), 3.2 (type 0x81: 4-octet IPv4 address, 1011 2-octet value) and 4 of [RFC4360] and Section 2 (type 0x82: 4-octet 1012 AS, 2-octet value) of [RFC5668] with the high-order octet of the Type 1013 field 0x80, 0x81, 0x82 respectively and the low-order of the Type 1014 field (Sub-Type) always 0x08. 1016 Interferes with: No other BGP Flow Specification Traffic Filtering 1017 Action in this document. 1019 7.5. Traffic Marking (traffic-marking) sub-type 0x09 1021 The traffic marking extended community instructs a system to modify 1022 the DSCP bits in the IP header ([RFC2474] Section 3) of a transiting 1023 IP packet to the corresponding value encoded in the 6 least 1024 significant bits of the extended community value as shown in 1025 Figure 6. 1027 The extended is encoded as follows: 1029 0 1 2 3 1030 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 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 | reserved | reserved | reserved | reserved | 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 | reserved | r.| DSCP | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 Figure 6: Traffic Marking Extended Community Encoding 1039 o DSCP: new DSCP value for the transiting IP packet. 1041 o reserved, r.: SHOULD be set to 0 on encoding, and MUST be ignored 1042 during decoding. 1044 Interferes with: No other BGP Flow Specification Traffic Filtering 1045 Action in this document. 1047 7.6. Interaction with other Filtering Mechanisms in Routers 1049 Implementations SHOULD provide mechanisms that map an arbitrary BGP 1050 community value (normal or extended) to Traffic Filtering Actions 1051 that require different mappings in different systems in the network. 1052 For instance, providing packets with a worse-than-best-effort, per- 1053 hop behavior is a functionality that is likely to be implemented 1054 differently in different systems and for which no standard behavior 1055 is currently known. Rather than attempting to define it here, this 1056 can be accomplished by mapping a user-defined community value to 1057 platform-/network-specific behavior via user configuration. 1059 7.7. Considerations on Traffic Filtering Action Interference 1061 Since Traffic Filtering Actions are represented as BGP extended 1062 community values, Traffic Filtering Actions may interfere with each 1063 other (e.g. there may be more than one conflicting traffic-rate-bytes 1064 Traffic Filtering Action associated with a single Flow 1065 Specification). Traffic Filtering Action interference has no impact 1066 on BGP propagation of Flow Specifications (all communities are 1067 propagated according to policies). 1069 If a Flow Specification associated with interfering Traffic Filtering 1070 Actions is selected for packet forwarding, it is an implementation 1071 decision which of the interfering Traffic Filtering Actions are 1072 selected. Implementors of this specification SHOULD document the 1073 behaviour of their implementation in such cases. 1075 Operators are encouraged to make use of the BGP policy framework 1076 supported by their implementation in order to achieve a predictable 1077 behaviour (ie. match - replace - delete communities on administrative 1078 boundaries). See also Section 13. 1080 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks 1082 Provider-based Layer 3 VPN networks, such as the ones using a BGP/ 1083 MPLS IP VPN [RFC4364] control plane, may have different traffic 1084 filtering requirements than Internet service providers. But also 1085 Internet service providers may use those VPNs for scenarios like 1086 having the Internet routing table in a VRF, resulting in the same 1087 traffic filtering requirements as defined for the global routing 1088 table environment within this document. This document defines an 1089 additional BGP NLRI type (AFI=1, SAFI=134) value, which can be used 1090 to propagate Flow Specification in a BGP/MPLS VPN environment. 1092 The NLRI format for this address family consists of a fixed-length 1093 Route Distinguisher field (8 bytes) followed by the Flow 1094 Specification NLRI value Section 4.2. The NLRI length field shall 1095 include both the 8 bytes of the Route Distinguisher as well as the 1096 subsequent Flow Specification NLRI value. The resulting encoding is 1097 shown in Figure 7. 1099 +------------------------------+ 1100 | length (0xnn or 0xfn nn) | 1101 +------------------------------+ 1102 | Route Distinguisher (8 bytes)| 1103 +------------------------------+ 1104 | NLRI value (variable) | 1105 +------------------------------+ 1107 Figure 7: Flow Specification NLRI for MPLS 1109 Propagation of this NLRI is controlled by matching Route Target 1110 extended communities associated with the BGP path advertisement with 1111 the VRF import policy, using the same mechanism as described in BGP/ 1112 MPLS IP VPNs [RFC4364]. 1114 Flow Specifications received via this NLRI apply only to traffic that 1115 belongs to the VRF(s) in which it is imported. By default, traffic 1116 received from a remote PE is switched via an MPLS forwarding decision 1117 and is not subject to filtering. 1119 Contrary to the behavior specified for the non-VPN NLRI, Flow 1120 Specifications are accepted by default, when received from remote PE 1121 routers. 1123 The validation procedure (Section 6) and Traffic Filtering Actions 1124 (Section 7) are the same as for IPv4. 1126 9. Traffic Monitoring 1128 Traffic filtering applications require monitoring and traffic 1129 statistics facilities. While this is an implementation specific 1130 choice, implementations SHOULD provide: 1132 o A mechanism to log the packet header of filtered traffic. 1134 o A mechanism to count the number of matches for a given Flow 1135 Specification. 1137 10. Error-Handling 1139 Error handling according to [RFC7606] SHOULD apply to this 1140 specification. 1142 This document introduces Traffic Filtering Action Extended 1143 Communities. Malformed Traffic Filtering Action Extended Communities 1144 in the sense of [RFC7606] Section 7.14. are Extended Community values 1145 that cannot be decoded according to Section 7 of this document. 1147 11. Future NLRI Extensions 1149 Future Flow Specification extensions may introduce new Flow 1150 Specification components. In order to facilitate such extensions of 1151 the Flow Specification NLRI, in addition to the cases described in 1152 [RFC7606], if BGP encounters an unknown Flow Specification component 1153 in an UPDATE message, it SHOULD also treat this message as Treat-as- 1154 withdraw as specified in [RFC7606] Section 2. 1156 The specification of a new Flow Specification Component Type SHOULD 1157 clearly identify what the criteria used to match packets forwarded by 1158 the router is. This criteria should be meaningful across router hops 1159 and not depend on values that change hop-by-hop such as TTL or Layer 1160 2 encapsulation. 1162 Such extensions SHOULD also specify a way to encode an "always-match" 1163 match condition within the newly introduced components (this is a 1164 match condition, encoded with the newly introduced components: If 1165 present on its own, matches all flows). This match condition can be 1166 used to propagate (and apply) certain Flow Specifications only if a 1167 specific extension is known to the implementation. 1169 12. IANA Considerations 1171 This section complies with [RFC7153]. 1173 12.1. AFI/SAFI Definitions 1175 IANA maintains a registry entitled "SAFI Values". For the purpose of 1176 this work, IANA is requested to update the following SAFIs to read 1177 according to the table below (Note: This document obsoletes both 1178 RFC7674 and RFC5575 and all references to those documents should be 1179 deleted from the registry below): 1181 +-------+------------------------------------------+----------------+ 1182 | Value | Name | Reference | 1183 +-------+------------------------------------------+----------------+ 1184 | 133 | Dissemination of Flow Specification | [this | 1185 | | rules | document] | 1186 | 134 | L3VPN Dissemination of Flow | [this | 1187 | | Specification rules | document] | 1188 +-------+------------------------------------------+----------------+ 1190 Table 3: Registry: SAFI Values 1192 12.2. Flow Component Definitions 1194 A Flow Specification consists of a sequence of flow components, which 1195 are identified by a an 8-bit component type. IANA has created and 1196 maintains a registry entitled "Flow Spec Component Types". IANA is 1197 requested to update the reference for this registry to [this 1198 document]. Furthermore the references to the values should be 1199 updated according to the table below (Note: This document obsoletes 1200 both RFC7674 and RFC5575 and all references to those documents should 1201 be deleted from the registry below). 1203 +-------+--------------------+-----------------+ 1204 | Value | Name | Reference | 1205 +-------+--------------------+-----------------+ 1206 | 1 | Destination Prefix | [this document] | 1207 | 2 | Source Prefix | [this document] | 1208 | 3 | IP Protocol | [this document] | 1209 | 4 | Port | [this document] | 1210 | 5 | Destination port | [this document] | 1211 | 6 | Source port | [this document] | 1212 | 7 | ICMP type | [this document] | 1213 | 8 | ICMP code | [this document] | 1214 | 9 | TCP flags | [this document] | 1215 | 10 | Packet length | [this document] | 1216 | 11 | DSCP | [this document] | 1217 | 12 | Fragment | [this document] | 1218 +-------+--------------------+-----------------+ 1220 Table 4: Registry: Flow Spec Component Types 1222 In order to manage the limited number space and accommodate several 1223 usages, the following policies defined by [RFC8126] are used: 1225 +--------------+-------------------------------+ 1226 | Type Values | Policy | 1227 +--------------+-------------------------------+ 1228 | 0 | Specification required | 1229 | [1 .. 12] | Defined by this specification | 1230 | [13 .. 127] | Specification required | 1231 | [128 .. 255] | First Come First Served | 1232 +--------------+-------------------------------+ 1234 Table 5: Flow Spec Component Types Policies 1236 12.3. Extended Community Flow Specification Actions 1238 The Extended Community Flow Specification Action types defined in 1239 this document consist of two parts: 1241 Type (BGP Transitive Extended Community Type) 1243 Sub-Type 1245 For the type-part, IANA maintains a registry entitled "BGP Transitive 1246 Extended Community Types". For the purpose of this work (Section 7), 1247 IANA is requested to update the references to the following entries 1248 according to the table below (Note: This document obsoletes both 1249 RFC7674 and RFC5575 and all references to those documents should be 1250 deleted in the registry below): 1252 +-------+-----------------------------------------------+-----------+ 1253 | Type | Name | Reference | 1254 | Value | | | 1255 +-------+-----------------------------------------------+-----------+ 1256 | 0x81 | Generic Transitive Experimental Use Extended | [this | 1257 | | Community Part 2 (Sub-Types are defined in | document] | 1258 | | the "Generic Transitive Experimental Use | | 1259 | | Extended Community Part 2 Sub-Types" | | 1260 | | Registry) | | 1261 | 0x82 | Generic Transitive Experimental Use Extended | [this | 1262 | | Community Part 3 (Sub-Types are defined in | document] | 1263 | | the "Generic Transitive Experimental Use | | 1264 | | Extended Community Part 3 Sub-Types" | | 1265 | | Registry) | | 1266 +-------+-----------------------------------------------+-----------+ 1268 Table 6: Registry: BGP Transitive Extended Community Types 1270 For the sub-type part of the extended community Traffic Filtering 1271 Actions IANA maintains the following registries. IANA is requested 1272 to update all names and references according to the tables below and 1273 assign a new value for the "Flow spec traffic-rate-packets" Sub-Type 1274 (Note: This document obsoletes both RFC7674 and RFC5575 and all 1275 references to those documents should be deleted from the registries 1276 below). 1278 +----------+--------------------------------------------+-----------+ 1279 | Sub-Type | Name | Reference | 1280 | Value | | | 1281 +----------+--------------------------------------------+-----------+ 1282 | 0x06 | Flow spec traffic-rate-bytes | [this | 1283 | | | document] | 1284 | TBD | Flow spec traffic-rate-packets | [this | 1285 | | | document] | 1286 | 0x07 | Flow spec traffic-action (Use of the | [this | 1287 | | "Value" field is defined in the "Traffic | document] | 1288 | | Action Fields" registry) | | 1289 | 0x08 | Flow spec rt-redirect AS-2byte format | [this | 1290 | | | document] | 1291 | 0x09 | Flow spec traffic-remarking | [this | 1292 | | | document] | 1293 +----------+--------------------------------------------+-----------+ 1295 Table 7: Registry: Generic Transitive Experimental Use Extended 1296 Community Sub-Types 1298 +----------------+--------------------------------+-----------------+ 1299 | Sub-Type Value | Name | Reference | 1300 +----------------+--------------------------------+-----------------+ 1301 | 0x08 | Flow spec rt-redirect IPv4 | [this document] | 1302 | | format | | 1303 +----------------+--------------------------------+-----------------+ 1305 Table 8: Registry: Generic Transitive Experimental Use Extended 1306 Community Part 2 Sub-Types 1308 +---------------+----------------------------------+----------------+ 1309 | Sub-Type | Name | Reference | 1310 | Value | | | 1311 +---------------+----------------------------------+----------------+ 1312 | 0x08 | Flow spec rt-redirect AS-4byte | [this | 1313 | | format | document] | 1314 +---------------+----------------------------------+----------------+ 1316 Table 9: Registry: Generic Transitive Experimental Use Extended 1317 Community Part 3 Sub-Types 1319 Furthermore IANA is requested to update the reference for the 1320 registries "Generic Transitive Experimental Use Extended Community 1321 Part 2 Sub-Types" and "Generic Transitive Experimental Use Extended 1322 Community Part 3 Sub-Types" to [this document]. 1324 The "traffic-action" extended community (Section 7.3) defined in this 1325 document has 46 unused bits, which can be used to convey additional 1326 meaning. IANA created and maintains a registry entitled: "Traffic 1327 Action Fields". IANA is requested to update the reference for this 1328 registry to [this document]. Furthermore IANA is requested to update 1329 the references according to the table below. These values should be 1330 assigned via IETF Review rules only (Note: This document obsoletes 1331 both RFC7674 and RFC5575 and all references to those documents should 1332 be deleted from the registry below). 1334 +-----+-----------------+-----------------+ 1335 | Bit | Name | Reference | 1336 +-----+-----------------+-----------------+ 1337 | 47 | Terminal Action | [this document] | 1338 | 46 | Sample | [this document] | 1339 +-----+-----------------+-----------------+ 1341 Table 10: Registry: Traffic Action Fields 1343 13. Security Considerations 1345 As long as Flow Specifications are restricted to match the 1346 corresponding unicast routing paths for the relevant prefixes 1347 (Section 6), the security characteristics of this proposal are 1348 equivalent to the existing security properties of BGP unicast 1349 routing. Any relaxation of the validation procedure described in 1350 Section 6 may allow unwanted Flow Specifications to be propagated and 1351 thus unwanted Traffic Filtering Actions may be applied to flows. 1353 Where the above mechanisms are not in place, this could open the door 1354 to further denial-of-service attacks such as unwanted traffic 1355 filtering, remarking or redirection. 1357 Deployment of specific relaxations of the validation within an 1358 administrative boundary of a network, defined by an AS or an AS- 1359 Confederation boundary, may be useful in some networks for quickly 1360 distributing filters to prevent denial-of-service attacks. For a 1361 network to utilize this relaxation, the BGP policies must support 1362 additional filtering since the origin AS field is empty. 1363 Specifications relaxing the validation restrictions SHOULD contain 1364 security considerations that provide details on the required 1365 additional filtering. For example, the use of [RFC6811] to enhance 1366 filtering within an AS confederation. 1368 Inter-provider routing is based on a web of trust. Neighboring 1369 autonomous systems are trusted to advertise valid reachability 1370 information. If this trust model is violated, a neighboring 1371 autonomous system may cause a denial-of-service attack by advertising 1372 reachability information for a given prefix for which it does not 1373 provide service (unfiltered address space hijack). Since validation 1374 of the Flow Specification is tied to the announcement of the best 1375 unicast route, this may also cause this validation to fail and 1376 consequently prevent Flow Specifications from being accepted by a 1377 peer. Possible mitigations are [RFC6811] and [RFC8205]. 1379 Enabling firewall-like capabilities in routers without centralized 1380 management could make certain failures harder to diagnose. For 1381 example, it is possible to allow TCP packets to pass between a pair 1382 of addresses but not ICMP packets. It is also possible to permit 1383 packets smaller than 900 or greater than 1000 bytes to pass between a 1384 pair of addresses, but not packets whose length is in the range 900- 1385 1000. Such behavior may be confusing and these capabilities should 1386 be used with care whether manually configured or coordinated through 1387 the protocol extensions described in this document. 1389 Flow Specification BGP speakers (e.g. automated DDoS controllers) not 1390 properly programmed, algorithms that are not performing as expected, 1391 or simply rogue systems may announce unintended Flow Specifications, 1392 send updates at a high rate or generate a high number of Flow 1393 Specifications. This may stress the receiving systems, exceed their 1394 maximum capacity or may lead to unwanted Traffic Filtering Actions 1395 being applied to flows. 1397 While the general verification of the Flow Specification NLRI is 1398 specified in this document (Section 6) the Traffic Filtering Actions 1399 received by a third party may need custom verification or filtering. 1400 In particular all non traffic-rate actions may allow a third party to 1401 modify packet forwarding properties and potentially gain access to 1402 other routing-tables/VPNs or undesired queues. This can be avoided 1403 by proper filtering/screening of the Traffic Filtering Action 1404 communities at network borders and only exposing a predefined subset 1405 of Traffic Filtering Actions (see Section 7) to third parties. One 1406 way to achieve this is by mapping user-defined communities, that can 1407 be set by the third party, to Traffic Filtering Actions and not 1408 accepting Traffic Filtering Action extended communities from third 1409 parties. 1411 This extension adds additional information to Internet routers. 1412 These are limited in terms of the maximum number of data elements 1413 they can hold as well as the number of events they are able to 1414 process in a given unit of time. Service providers need to consider 1415 the maximum capacity of their devices and may need to limit the 1416 number of Flow Specifications accepted and processed. 1418 14. Contributors 1420 Barry Greene, Pedro Marques, Jared Mauch, Danny McPherson, and 1421 Nischal Sheth were authors on [RFC5575], and therefore are 1422 contributing authors on this document. 1424 15. Acknowledgements 1426 The authors would like to thank Yakov Rekhter, Dennis Ferguson, Chris 1427 Morrow, Charlie Kaufman, and David Smith for their comments for the 1428 comments on the original [RFC5575]. Chaitanya Kodeboyina helped 1429 design the flow validation procedure; and Steven Lin and Jim Washburn 1430 ironed out all the details necessary to produce a working 1431 implementation in the original [RFC5575]. 1433 A packet rate Traffic Filtering Action was also described in a Flow 1434 Specification extension draft and the authors like to thank Wesley 1435 Eddy, Justin Dailey and Gilbert Clark for their work. 1437 Additionally, the authors would like to thank Alexander Mayrhofer, 1438 Nicolas Fevrier, Job Snijders, Jeffrey Haas and Adam Chappell for 1439 their comments and review. 1441 16. References 1443 16.1. Normative References 1445 [IEEE.754.1985] 1446 IEEE, "Standard for Binary Floating-Point Arithmetic", 1447 IEEE 754-1985, August 1985. 1449 [ISO_IEC_9899] 1450 ISO, "Information technology -- Programming languages -- 1451 C", ISO/IEC 9899:2018, June 2018. 1453 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1454 DOI 10.17487/RFC0768, August 1980, 1455 . 1457 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1458 DOI 10.17487/RFC0791, September 1981, 1459 . 1461 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1462 RFC 792, DOI 10.17487/RFC0792, September 1981, 1463 . 1465 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1466 RFC 793, DOI 10.17487/RFC0793, September 1981, 1467 . 1469 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1470 Requirement Levels", BCP 14, RFC 2119, 1471 DOI 10.17487/RFC2119, March 1997, 1472 . 1474 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1475 "Definition of the Differentiated Services Field (DS 1476 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1477 DOI 10.17487/RFC2474, December 1998, 1478 . 1480 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1481 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1482 DOI 10.17487/RFC4271, January 2006, 1483 . 1485 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1486 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 1487 February 2006, . 1489 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1490 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1491 2006, . 1493 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 1494 Reflection: An Alternative to Full Mesh Internal BGP 1495 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 1496 . 1498 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1499 "Multiprotocol Extensions for BGP-4", RFC 4760, 1500 DOI 10.17487/RFC4760, January 2007, 1501 . 1503 [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS 1504 Specific BGP Extended Community", RFC 5668, 1505 DOI 10.17487/RFC5668, October 2009, 1506 . 1508 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 1509 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 1510 March 2014, . 1512 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1513 Patel, "Revised Error Handling for BGP UPDATE Messages", 1514 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1515 . 1517 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1518 Writing an IANA Considerations Section in RFCs", BCP 26, 1519 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1520 . 1522 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1523 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1524 May 2017, . 1526 16.2. Informative References 1528 [I-D.ietf-idr-flow-spec-v6] 1529 McPherson, D., Raszuk, R., Pithawala, B., 1530 akarch@cisco.com, a., and S. Hares, "Dissemination of Flow 1531 Specification Rules for IPv6", draft-ietf-idr-flow-spec- 1532 v6-09 (work in progress), November 2017. 1534 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1535 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1536 . 1538 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1539 and D. McPherson, "Dissemination of Flow Specification 1540 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1541 . 1543 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 1544 Austein, "BGP Prefix Origin Validation", RFC 6811, 1545 DOI 10.17487/RFC6811, January 2013, 1546 . 1548 [RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect 1549 Extended Community", RFC 7674, DOI 10.17487/RFC7674, 1550 October 2015, . 1552 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 1553 Specification", RFC 8205, DOI 10.17487/RFC8205, September 1554 2017, . 1556 16.3. URIs 1558 [1] https://github.com/stoffi92/flowspec-cmp 1560 Appendix A. Python code: flow_rule_cmp 1562 1563 """ 1564 Copyright (c) 2019 IETF Trust and the persons identified as authors of 1565 the code. All rights reserved. 1567 Redistribution and use in source and binary forms, with or without 1568 modification, is permitted pursuant to, and subject to the license 1569 terms contained in, the Simplified BSD License set forth in Section 1570 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 1571 (http://trustee.ietf.org/license-info). 1572 """ 1574 import itertools 1575 import ipaddress 1577 def flow_rule_cmp(a, b): 1578 for comp_a, comp_b in itertools.zip_longest(a.components, 1579 b.components): 1580 # If a component type does not exist in one rule 1581 # this rule has lower precedence 1582 if not comp_a: 1583 return B_HAS_PRECEDENCE 1584 if not comp_b: 1585 return A_HAS_PRECEDENCE 1586 # higher precedence for lower component type 1587 if comp_a.component_type < comp_b.component_type: 1588 return A_HAS_PRECEDENCE 1589 if comp_a.component_type > comp_b.component_type: 1590 return B_HAS_PRECEDENCE 1591 # component types are equal -> type specific comparison 1592 if comp_a.component_type in (IP_DESTINATION, IP_SOURCE): 1593 # assuming comp_a.value, comp_b.value of type 1594 # ipaddress.IPv4Network 1595 if comp_a.value.overlaps(comp_b.value): 1596 # longest prefixlen has precedence 1597 if comp_a.value.prefixlen > comp_b.value.prefixlen: 1598 return A_HAS_PRECEDENCE 1599 if comp_a.value.prefixlen < comp_b.value.prefixlen: 1600 return B_HAS_PRECEDENCE 1601 # components equal -> continue with next component 1602 elif comp_a.value > comp_b.value: 1603 return B_HAS_PRECEDENCE 1604 elif comp_a.value < comp_b.value: 1605 return A_HAS_PRECEDENCE 1606 else: 1607 # assuming comp_a.value, comp_b.value of type bytearray 1608 if len(comp_a.value) == len(comp_b.value): 1609 if comp_a.value > comp_b.value: 1610 return B_HAS_PRECEDENCE 1611 if comp_a.value < comp_b.value: 1612 return A_HAS_PRECEDENCE 1613 # components equal -> continue with next component 1614 else: 1615 common = min(len(comp_a.value), len(comp_b.value)) 1616 if comp_a.value[:common] > comp_b.value[:common]: 1617 return B_HAS_PRECEDENCE 1618 elif comp_a.value[:common] < comp_b.value[:common]: 1619 return A_HAS_PRECEDENCE 1620 # the first common bytes match 1621 elif len(comp_a.value) > len(comp_b.value): 1622 return A_HAS_PRECEDENCE 1623 else: 1624 return B_HAS_PRECEDENCE 1625 return EQUAL 1626 1628 Appendix B. Comparison with RFC 5575 1630 This document includes numerous editorial changes to [RFC5575]. It 1631 also completely incorporates the redirect action clarification 1632 document [RFC7674]. It is recommended to read the entire document. 1633 The authors, however want to point out the following technical 1634 changes to [RFC5575]: 1636 Section 1 introduces the Flow Specification NLRI. In [RFC5575] 1637 this NLRI was defined as an opaque-key in BGPs database. This 1638 specification has removed all references to a opaque-key property. 1639 BGP is able to understand the NLRI encoding. This change also 1640 resulted in a new section regarding error-handling and 1641 extensibility (Section 10 and Section 11). 1643 Section 4.2.2.3 defines a numeric operator and comparison bit 1644 combinations. In [RFC5575] the meaning of those bit combination 1645 was not explicitly defined and left open to the reader. 1647 Section 4.2.2.3 - Section 4.2.2.8, Section 4.2.2.10, 1648 Section 4.2.2.11 make use of the above numeric operator. The 1649 allowed length of the comparison value was not consistently 1650 defined in [RFC5575]. 1652 Section 7 defines all Traffic Filtering Action Extended 1653 communities as transitive extended communities. [RFC5575] defined 1654 the traffic-rate action to be non-transitive and did not define 1655 the transitivity of the other Traffic Filtering Action communities 1656 at all. 1658 Section 7.2 introduces a new Traffic Filtering Action (traffic- 1659 rate-packets). This action did not exist in [RFC5575]. 1661 Section 7.4 contains the same redirect actions already defined in 1662 [RFC5575] however, these actions have been renamed to "rt- 1663 redirect" to make it clearer that the redirection is based on 1664 route-target. This section also completely incorporates the 1665 [RFC7674] clarifications of the Flowspec Redirect Extended 1666 Community. 1668 Section 7.7 contains general considerations on interfering traffic 1669 actions. Section 7.3 also cross-references this section. 1670 [RFC5575] did not mention this. 1672 Section 10 contains new error handling. 1674 Section 11 describes graceful handling of unknown Flow 1675 Specification components to allow future extensions. 1677 Authors' Addresses 1679 Christoph Loibl 1680 Next Layer Communications 1681 Mariahilfer Guertel 37/7 1682 Vienna 1150 1683 AT 1685 Phone: +43 664 1176414 1686 Email: cl@tix.at 1688 Susan Hares 1689 Huawei 1690 7453 Hickory Hill 1691 Saline, MI 48176 1692 USA 1694 Email: shares@ndzh.com 1696 Robert Raszuk 1697 Bloomberg LP 1698 731 Lexington Ave 1699 New York City, NY 10022 1700 USA 1702 Email: robert@raszuk.net 1704 Danny McPherson 1705 Verisign 1706 USA 1708 Email: dmcpherson@verisign.com 1710 Martin Bacher 1711 T-Mobile Austria 1712 Rennweg 97-99 1713 Vienna 1030 1714 AT 1716 Email: mb.ietf@gmail.com