idnits 2.17.00 (12 Aug 2021) /tmp/idnits41991/draft-dbb-netmod-acl-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 333 has weird spacing: '...rw name str...' == 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 (18 October 2021) is 208 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) == Missing Reference: 'RFC9132' is mentioned on line 162, but not defined == Missing Reference: 'RFC8955' is mentioned on line 118, but not defined == Missing Reference: 'RFC8956' is mentioned on line 119, but not defined == Missing Reference: 'RFC7950' is mentioned on line 129, but not defined == Missing Reference: 'RFC8340' is mentioned on line 131, but not defined Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Netmod WG O. Gonzalez de Dios 3 Internet-Draft S. Barguil 4 Intended status: Standards Track Telefonica 5 Expires: 21 April 2022 M. Boucadair 6 Orange 7 18 October 2021 9 Extensions to the Access Control Lists (ACLs) YANG Model 10 draft-dbb-netmod-acl-00 12 Abstract 14 RFC 8519 defines a YANG data model for Access Control Lists (ACLs). 15 This document discusses a set of extensions that fix many of the 16 limitations of the ACL model as initially defined in RFC 8519. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 21 April 2022. 35 Copyright Notice 37 Copyright (c) 2021 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Problem Statement & Gap Analysis . . . . . . . . . . . . . . 4 55 3.1. Suboptimal Configuration: Lack of Manipulating Lists of 56 Prefixes . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.2. Manageability: Impossibility to Use Aliases or Defined 58 Sets . . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 3.3. Bind ACLs to Devices, Not Only Interfaces . . . . . . . . 9 60 3.4. Partial or Lack of IPv4/IPv6 Fragment Handling . . . . . 9 61 3.5. Suboptimal TCP Flags Handling . . . . . . . . . . . . . . 13 62 3.6. Rate-Limit Action . . . . . . . . . . . . . . . . . . . . 13 63 3.7. Payload-based Filtering . . . . . . . . . . . . . . . . . 14 64 3.8. Reuse the ACLs Content Across Several Devices . . . . . . 15 65 4. Overall Module Structure (TBC) . . . . . . . . . . . . . . . 15 66 5. YANG Module (TBC) . . . . . . . . . . . . . . . . . . . . . . 15 67 6. Security Considerations (TBC) . . . . . . . . . . . . . . . . 15 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 69 7.1. URI Registration (TBC) . . . . . . . . . . . . . . . . . 16 70 7.2. YANG Module Name Registration (TBC) . . . . . . . . . . . 16 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 72 9. Normative References . . . . . . . . . . . . . . . . . . . . 16 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 75 1. Introduction 77 [RFC8519] defines Acces control lists (ACLs) as a user-ordered set of 78 filtering rules. The model targets the configuration of the 79 filtering behaviour of a device. However, the model structure, as 80 defined in [RFC8519], suffers from a set of limitations. This 81 document describes these limitations and proposes an enhanced ACL 82 structure. 84 The motivation of such enhanced ACL structure is discussed in detail 85 in Section 3. 87 When managing ACLs, it is common for network operators to group 88 matching elements in pre-defined sets. The consolidation into 89 matches allows reducing the number of rules, especially in large 90 scale networks. If it is needed, for example, to find a match 91 against 100 IP addresses (or prefixes), a single rule will suffice 92 rather than creating individual Access Control Entries (ACEs) for 93 each IP address (or prefix). In doing so, implementations would 94 optimize the performance of matching lists vs multiple rules 95 matching. 97 The enhanced ACL structure is also meant to facilitate the management 98 of network operators. Instead of entering the IP address or port 99 number literals, using user-named lists decouples the creation of the 100 rule from the management of the sets. Hence, it is possible to 101 remove/add entries to the list without redefining the (parent) ACL 102 rule. 104 In addition, the notion of Access Control List (ACL) and defined sets 105 is generalized so that it is not device-specific as per [RFC8519]. 106 ACLs and defined sets may be defined at network / administrative 107 domain level and associated to devices. This approach facilitates 108 the reusability across multiple network elements. For example, 109 managing the IP prefix sets from a network level makes it easier to 110 maintain by the security groups. 112 Network operators maintain sets of IP prefixes that are related to 113 each other, e.g., deny-lists or accept-lists that are associated with 114 those provided by a VPN customer. These lists are maintained and 115 manipulated by security expert teams. 117 Note that ACLs are used locally in devices but are triggered by other 118 tools such as DDoS mitigation [RFC9132] or BGP Flow Spec [RFC8955] 119 [RFC8956]. Therefore, supporting means to easily map to the 120 filtering rules conveyed in messages triggered by hese tools is 121 valuable from a network operation standpoint. 123 1.1. Terminology 125 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 126 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 127 document, are to be interpreted as described in [RFC2119]. 129 The terminology for describing YANG modules is defined in [RFC7950]. 130 The meaning of the symbols in the tree diagrams is defined in 131 [RFC8340]. 133 In adition to the terms defined in [RFC8519], this document makes use 134 of the following terms: 136 * Defined set: Refers to reusable description of one or multiple 137 information elements (e.g., IP address, IP prefix, port number, 138 ICMP type). 140 2. Approach 142 This first version of the document does not include on purpose any 143 YANG module. This is because the authors are seeking a work 144 direction from the netmod WG whether the missing features can be 145 accomplished by means of augmentations or whether an ACL-bis document 146 is more appropriate. 148 Future versions of the document will include a YANG module that will 149 reflect the WG feedback. A network wide module, in adition to the 150 device module, might be required. The decision on whether a single 151 module is sufficient to handle both device and network levels or two 152 separate ones will be based on WG feedback. 154 3. Problem Statement & Gap Analysis 156 3.1. Suboptimal Configuration: Lack of Manipulating Lists of Prefixes 158 IP prefix related data nodes, e.g., "destination-ipv4-network" or 159 "destination-ipv6-network", do not allow manipulating a list of IP 160 prefixes, which may lead to manipulating large files. The same issue 161 is encountered when ACLs have to be in place to mitigate DDoS attacks 162 (e.g., [RFC9132]) when a set of sources are involved in such an 163 attack. The situation is even worse when both a list of sources and 164 destination prefixes are involved. 166 Figure 1 shows an example of the required ACL configuration for 167 filtering traffic from two prefixes. 169 { 170 "ietf-access-control-list:acls": { 171 "acl": [ 172 { 173 "name": "first-prefix", 174 "type": "ipv6-acl-type", 175 "aces": { 176 "ace": [ 177 { 178 "name": "my-test-ace", 179 "matches": { 180 "ipv6": { 181 "destination-ipv6-network": 182 "2001:db8:6401:1::/64", 183 "source-ipv6-network": 184 "2001:db8:1234::/96", 185 "protocol": 17, 186 "flow-label": 10000 187 }, 188 "udp": { 189 "source-port": { 190 "operator": "lte", 191 "port": 80 192 }, 193 "destination-port": { 194 "operator": "neq", 195 "port": 1010 196 } 197 } 198 }, 199 "actions": { 200 "forwarding": "accept" 201 } 202 } 203 ] 204 } 205 }, 206 { 207 "name": "second-prefix", 208 "type": "ipv6-acl-type", 209 "aces": { 210 "ace": [ 211 { 212 "name": "my-test-ace", 213 "matches": { 214 "ipv6": { 215 "destination-ipv6-network": 216 "2001:db8:6401:c::/64", 217 "source-ipv6-network": 218 "2001:db8:1234::/96", 219 "protocol": 17, 220 "flow-label": 10000 221 }, 222 "udp": { 223 "source-port": { 224 "operator": "lte", 225 "port": 80 226 }, 227 "destination-port": { 228 "operator": "neq", 229 "port": 1010 230 } 231 } 232 }, 233 "actions": { 234 "forwarding": "accept" 235 } 237 } 238 ] 239 } 240 } 241 ] 242 } 243 } 245 Figure 1: Example Illustrating Sub-optimal Use of the ACL Model 246 with a Prefix List. 248 Such configuration is suboptimal for both: - Network controllers that 249 need to manipulate large files. All or a subset fo this 250 configuration will need to be passed to the undelrying network 251 devices. - Devices may receive such confirguration and thus will need 252 to maintain it locally. 254 Figure 2 depicts an example of an optimized strcuture: 256 { 257 "ietf-access-control-list:acls": { 258 "acl": [ 259 { 260 "name": "prefix-list-support", 261 "type": "ipv6-acl-type", 262 "aces": { 263 "ace": [ 264 { 265 "name": "my-test-ace", 266 "matches": { 267 "ipv6": { 268 "destination-ipv6-network": [ 269 "2001:db8:6401:1::/64", 270 "2001:db8:6401:c::/64" 271 ], 272 "source-ipv6-network": 273 "2001:db8:1234::/96", 274 "protocol": 17, 275 "flow-label": 10000 276 }, 277 "udp": { 278 "source-port": { 279 "operator": "lte", 280 "port": 80 281 }, 282 "destination-port": { 283 "operator": "neq", 284 "port": 1010 285 } 286 } 287 }, 288 "actions": { 289 "forwarding": "accept" 290 } 291 } 292 ] 293 } 294 } 295 ] 296 } 297 } 299 Figure 2: Example Illustrating Optimal Use of the ACL Model in a 300 Network Context. 302 3.2. Manageability: Impossibility to Use Aliases or Defined Sets 304 The same approach as the one discussed for IP prefixes can be 305 generalized by introduing the concept of "aliases" or "defined sets". 307 The defined sets are reusable definitions across several ACLs. Each 308 category is modelled in YANG as a list of parameters related to the 309 class it represents. The following sets can be considered: 311 * Prefix sets: Used to create lists of IPv4 or IPv6 prefixes. 313 * Protocol sets: Used to create a list of protocols. 315 * Port number sets: Used to create lists of TCP or UDP port values 316 (or any other transport protocol that makes uses of port numbers). 317 The identity of the protcols is identified by the protocol set, if 318 present. Otherwise, a set apply to any protocol. 320 * ICMP sets: Uses to create lists of ICMP-based filters. This 321 applies only when the protocol is set to ICMP or ICMPv6. 323 A candidate structure is shown in #example_sets: 325 +--rw defined-sets 326 | +--rw prefix-sets 327 | | +--rw prefix-set* [name mode] 328 | | +--rw name string 329 | | +--rw mode enumeration 330 | | +--rw ip-prefix* inet:ip-prefix 331 | +--rw port-sets 332 | | +--rw port-set* [name] 333 | | +--rw name string 334 | | +--rw port* inet:port-number 335 | +--rw protocol-sets 336 | | +--rw protocol-set* [name] 337 | | +--rw name string 338 | | +--rw protocol-name* identityref 339 | +--rw icmp-type-sets 340 | +--rw icmp-type-set* [name] 341 | +--rw name string 342 | +--rw types* [type] 343 | +--rw type uint8 344 | +--rw code? uint8 345 | +--rw rest-of-header? binary 347 Figure 3: Examples of Defined Sets. 349 3.3. Bind ACLs to Devices, Not Only Interfaces 351 In the context of network management, an ACL may be enforced in many 352 network locations. As such, the ACL module should allow binding an 353 ACL to multiple devices, not only (abstract) interfaces. 355 The ACL name must, thus, be unique at the scale of the network, but 356 still the same name may be used in many devices when enforcing node- 357 specific ACLs. 359 3.4. Partial or Lack of IPv4/IPv6 Fragment Handling 361 [RFC8519] does not support fragment handling capability for IPv6 but 362 offers a partial support for IPv4 by means of 'flags'. Nevertheless, 363 the use of 'flags' is problematic since it does not allow a bitmask 364 to be defined. For example, setting other bits not covered by the 365 'flags' filtering clause in a packet will allow that packet to get 366 through (because it won't match the ACE). 368 Defining a new IPv4/IPv6 matching field called 'fragment' is thus 369 required to efficiently handle fragment-related filtering rules. 370 Some examples to illustrate how 'fragment' can be used are provided 371 below. 373 Figure 4 shows the content of a candidate POST request to allow the 374 traffic destined to 198.51.100.0/24 and UDP port number 53, but to 375 drop all fragmented packets. The following ACEs are defined (in this 376 order): 378 * "drop-all-fragments" ACE: discards all fragments. 380 * "allow-dns-packets" ACE: accepts DNS packets destined to 381 198.51.100.0/24. 383 { 384 "ietf-access-control-list:acls": { 385 "acl": [ 386 { 387 "name": "dns-fragments", 388 "type": "ipv4-acl-type", 389 "aces": { 390 "ace": [ 391 { 392 "name": "drop-all-fragments", 393 "matches": { 394 "ipv4": { 395 "fragment": { 396 "operator": "match", 397 "type": "isf" 398 } 399 } 400 }, 401 "actions": { 402 "forwarding": "drop" 403 } 404 }, 405 { 406 "name": "allow-dns-packets", 407 "matches": { 408 "ipv4": { 409 "destination-ipv4-network": "198.51.100.0/24" 410 }, 411 "udp": { 412 "destination-port": { 413 "operator": "eq", 414 "port": 53 415 } 416 }, 417 "actions": { 418 "forwarding": "accept" 419 } 420 } 421 } 422 ] 423 } 424 } 425 ] 426 } 427 } 429 Figure 4: Example Illustrating Canddiate Filtering of IPv4 430 Fragmented Packets. 432 Figure 5 shows an example of the body of a candidate POST request to 433 allow the traffic destined to 2001:db8::/32 and UDP port number 53, 434 but to drop all fragmented packets. The following ACEs are defined 435 (in this order): 437 * "drop-all-fragments" ACE: discards all fragments (including atomic 438 fragments). That is, IPv6 packets that include a Fragment header 439 (44) are dropped. 441 * "allow-dns-packets" ACE: accepts DNS packets destined to 442 2001:db8::/32. 444 { 445 "ietf-access-control-list:acls": { 446 "acl": [ 447 { 448 "name": "dns-fragments", 449 "type": "ipv6-acl-type", 450 "aces": { 451 "ace": [ 452 { 453 "name": "drop-all-fragments", 454 "matches": { 455 "ipv6": { 456 "fragment": { 457 "operator": "match", 458 "type": "isf" 459 } 460 } 461 }, 462 "actions": { 463 "forwarding": "drop" 464 } 465 }, 466 { 467 "name": "allow-dns-packets", 468 "matches": { 469 "ipv6": { 470 "destination-ipv6-network": "2001:db8::/32" 471 }, 472 "udp": { 473 "destination-port": { 474 "operator": "eq", 475 "port": 53 476 } 477 } 478 }, 479 "actions": { 480 "forwarding": "accept" 481 } 482 } 483 ] 484 } 485 } 486 ] 487 } 488 } 490 Figure 5: Example Illustrating Canddiate Filtering of IPv6 491 Fragmented Packets. 493 3.5. Suboptimal TCP Flags Handling 495 [RFC8519] allows including flags in the TCP match fields, however 496 that strcuture does not support matching operations as those 497 supported in BGP Flow Spec. Definig this field to be defined as a 498 flag bitmask together with a set of operations is meant to 499 efficiently handle TCP flags filtering rules. Some examples to 500 illustrate the use of such field are discussed below. 502 Figure 6 shows an example of a candidate request to install a filter 503 to discard incoming TCP messages having all flags unset. 505 { 506 "ietf-access-control-list:acls": { 507 "acl": [{ 508 "name": "tcp-flags-example", 509 "aces": { 510 "ace": [{ 511 "name": "null-attack", 512 "matches": { 513 "tcp": { 514 "flags-bitmask": { 515 "operator": "not any", 516 "bitmask": 4095 517 } 518 } 519 }, 520 "actions": { 521 "forwarding": "drop" 522 } 523 }] 524 } 525 }] 526 } 527 } 529 Figure 6: Example to Deny TCP Null Attack Messages 531 3.6. Rate-Limit Action 533 [RFC8519] specifies that forwarding actions can be 'accept' (i.e., 534 accept matching traffic), 'drop' (i.e., drop matching traffic without 535 sending any ICMP error message), or 'reejct' (i.e., drop matching 536 traffic and send an ICMP error message to the source). Howover, 537 there are situations where the matching traffic can be accepted, but 538 with a rate-limit policy. Such capability is not currently supported 539 by the ACL model. 541 Figure 7 shows a candidate ACL example to rate-limit incoming SYNs 542 during a SYN flood attack. 544 { 545 "ietf-access-control-list:acls": { 546 "acl": [{ 547 "name": "tcp-flags-example-with-rate-limit", 548 "aces": { 549 "ace": [{ 550 "name": "rate-limit-syn", 551 "matches": { 552 "tcp": { 553 "flags-bitmask": { 554 "operator": "match", 555 "bitmask": 2 556 } 557 } 558 }, 559 "actions": { 560 "forwarding": "accept", 561 "rate-limit": "20.00" 562 } 563 }] 564 } 565 }] 566 } 567 } 569 Figure 7: Example Rate-Limit Incoming TCP SYNs 571 3.7. Payload-based Filtering 573 Some transport protocols use existing protocols (e.g., TCP or UDP) as 574 substrate. The match criteria for such protocols may rely upon the 575 'protocol' under 'l3', TCP/UDP match criteria, part of the TCP/UDP 576 payload, or a combination thereof. [RFC8519] does not support 577 matching based on the payload. 579 Likewise, the current version of the ACL model does not support 580 filetering of encapsulated traffic. 582 3.8. Reuse the ACLs Content Across Several Devices 584 Having a global network view of the ACLs is highly valuable for 585 service providers. An ACL could be defined and applied following the 586 hierarchy of the network topology. So, an ACL can be defined at the 587 network level and, then, that same ACL can be used (or referenced to) 588 in several devices (including termination points) within the same 589 network. 591 This network/device ACLs differentiation introduces several new 592 requirements, e.g.: 594 * An ACL name can be used at both network and device levels. 596 * An ACL content updated at the network level should imply a 597 transaction that updates the relevant content in all the nodes 598 using this ACL. 600 * ACLs defined at the device level have a local meaning for the 601 specific node. 603 * A device can be associated with a router, a VRF, a logical system, 604 or a virtual node. ACLs can be applied in physical and logical 605 infrastructure. 607 4. Overall Module Structure (TBC) 609 To be completed. 611 5. YANG Module (TBC) 613 To be completed. 615 6. Security Considerations (TBC) 617 The YANG modules specified in this document define a schema for data 618 that is designed to be accessed via network management protocol such 619 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 620 is the secure transport layer, and the mandatory-to-implement secure 621 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 622 is HTTPS, and the mandatory-to-implement secure transport is TLS 623 [RFC8446]. 625 The Network Configuration Access Control Model (NACM) [RFC8341] 626 provides the means to restrict access for particular NETCONF or 627 RESTCONF users to a preconfigured subset of all available NETCONF or 628 RESTCONF protocol operations and content. 630 There are a number of data nodes defined in this YANG module that are 631 writable/creatable/deletable (i.e., config true, which is the 632 default). These data nodes may be considered sensitive or vulnerable 633 in some network environments. Write operations (e.g., edit-config) 634 to these data nodes without proper protection can have a negative 635 effect on network operations. These are the subtrees and data nodes 636 and their sensitivity/vulnerability: 638 * TBC 640 Some of the readable data nodes in this YANG module may be considered 641 sensitive or vulnerable in some network environments. It is thus 642 important to control read access (e.g., via get, get-config, or 643 notification) to these data nodes. These are the subtrees and data 644 nodes and their sensitivity/vulnerability: 646 * TBC 648 7. IANA Considerations 650 7.1. URI Registration (TBC) 652 This document requests IANA to register the following URI in the "ns" 653 subregistry within the "IETF XML Registry" [RFC3688]: 655 URI: urn:ietf:params:xml:ns:yang:xxx 656 Registrant Contact: The IESG. 657 XML: N/A; the requested URI is an XML namespace. 659 7.2. YANG Module Name Registration (TBC) 661 This document requests IANA to register the following YANG module in 662 the "YANG Module Names" subregistry [RFC6020] within the "YANG 663 Parameters" registry. 665 name: xxxx 666 namespace: urn:ietf:params:xml:ns:yang:ietf-xxx 667 maintained by IANA: N 668 prefix: xxxx 669 reference: RFC XXXX 671 8. Acknowledgements 673 Many thanks to Jon Shallow and Miguel Cros for the discussion when 674 preparing this draft. 676 9. Normative References 678 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 679 Requirement Levels", BCP 14, RFC 2119, 680 DOI 10.17487/RFC2119, March 1997, 681 . 683 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 684 DOI 10.17487/RFC3688, January 2004, 685 . 687 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 688 the Network Configuration Protocol (NETCONF)", RFC 6020, 689 DOI 10.17487/RFC6020, October 2010, 690 . 692 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 693 and A. Bierman, Ed., "Network Configuration Protocol 694 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 695 . 697 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 698 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 699 . 701 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 702 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 703 . 705 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 706 Access Control Model", STD 91, RFC 8341, 707 DOI 10.17487/RFC8341, March 2018, 708 . 710 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 711 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 712 . 714 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 715 "YANG Data Model for Network Access Control Lists (ACLs)", 716 RFC 8519, DOI 10.17487/RFC8519, March 2019, 717 . 719 Authors' Addresses 721 Oscar Gonzalez de Dios 722 Telefonica 723 Distrito T 724 Madrid 725 Email: oscar.gonzalezdedios@telefonica.com 727 Samier Barguil 728 Telefonica 729 Distrito T 730 Madrid 732 Email: samier.barguilgiraldo.ext@telefonica.com 734 Mohamed Boucadair 735 Orange 736 Rennes 738 Email: mohamed.boucadair@orange.com