idnits 2.17.1 draft-yizhou-anima-ip-to-access-control-groups-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 20, 2021) is 890 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) ** Downref: Normative reference to an Informational RFC: RFC 7575 == Outdated reference: A later version (-11) exists of draft-ietf-anima-grasp-distribution-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-anima-grasp-distribution (ref. 'I-D.ietf-anima-grasp-distribution') == Outdated reference: A later version (-13) exists of draft-ietf-cbor-network-addresses-11 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 anima Y. Li 3 Internet-Draft L. Shen 4 Intended status: Standards Track Y. Zhou 5 Expires: April 23, 2022 Huawei Technologies 6 October 20, 2021 8 Autonomic IP Address To Access Control Groups Mapping 9 draft-yizhou-anima-ip-to-access-control-groups-01 11 Abstract 13 This document defines the autonomic technical objectives for IP 14 address/prefix to access control groups mapping. The objectives 15 defined can be used in Generic Autonomic Signaling Protocol (GRASP) 16 to make the policy enforcement point receive IP address and its tied 17 access control groups information directly from the access 18 authentication points and then execute the group based policies. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 23, 2022. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Autonomic IP Address to Access Control Groups Mapping 58 Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4.1. Behaviours of IP Address to Access Control Groups Mapping 60 Requesting Nodes . . . . . . . . . . . . . . . . . . . . 6 61 4.2. Behaviours of IP Address to Access Control Groups Mapping 62 Providing Nodes . . . . . . . . . . . . . . . . . . . . . 7 63 5. Autonomic IP Address to Access Control Groups Objectives . . 8 64 5.1. IPAddressToAccessControlGroups Objective Option . . . . . 8 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 70 9.2. Informative References . . . . . . . . . . . . . . . . . 10 71 Appendix A. Objective Examples . . . . . . . . . . . . . . . . . 12 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 74 1. Introduction 76 Ubiquitous group based policy management makes sure that the users 77 can obtain the same network access permission and QoS assurance 78 wherever they access the campus network. That is, the permission and 79 QoS assurance are tied to user role, rather than access points and/or 80 IP address assigned. 82 Group means a number of endpoints connecting to the network that 83 share common network policies. It facilitates the easy design and 84 provision of policy. A user's role is usually a group indicated by a 85 group ID. Group based policy management has been replacing the 86 traditional IP address and/or port number based policy widely. 88 The policy enforcement point (PEP) requires the IP address/prefix and 89 access control group mapping information of user in order to execute 90 the group based policy. This mapping information is usually first 91 available at the access authentication point (AAP) during the 92 procedures of user access and authentication/authorization. However 93 PEP may not be the access authentication point. Therefore IP and 94 group mappings has to be passed to PEP. 96 This document defines the autonomic technical objectives for IP 97 address/prefix and access control group mapping. In this document, 98 group is also used for short to refer to the access control group. 99 The Generic Autonomic Signaling Protocol (GRASP) [RFC8990] can make 100 use of these technical objectives as the basic building blocks of a 101 ubiquitous group based policy management solution, especially for a 102 campus network. 104 Autonomic Networking Infrastructure (ANI) is designed to provide the 105 elementary functions and services to be further integrated and used 106 by Autonomic Service Agents (ASA) on nodes. A campus policy 107 management system can integrate the function introduced in this 108 document when necessary. Such an Autonomic Service Agent (ASA) 109 performing the function of IP address/prefix to access control groups 110 mapping is called IPAddressToAccessControlGroups ASA in this 111 document. 113 2. Terminologies 115 This document uses terminology defined in [RFC7575]. 117 PEP: Policy Enforcement Point. A logical entity that enforces 118 policy decisions [RFC3198]. The policy decisions are group based 119 policies in this document. 121 AAP: Access Authentication Point. A logical entity that obtains the 122 information of the attaching clients' assigned IP address/prefix 123 and their access control groups. AAP may get the information from 124 one or different resources, for example, DHCP [RFC2131] [RFC8415] 125 server and/or RADIUS [RFC3198] server. 127 3. Problems 129 The traditional policy in a campus network is normally presented as 130 IP prefix/address based, for example, "Deny the traffic from IP 131 prefix X to IP prefix Y". Each of the access port of the switches is 132 assigned a subnet prefix and each subnet implies a group. It works 133 well when the end hosts are static. With the increasing deployment 134 of wireless accessed users and more complicated and dynamic 135 requirements of campus network policy, such an assumption no longer 136 hold. For instance, a user from the engineering department may bring 137 the laptop to access the campus network via a WiFi access point. 138 Then it will be assigned an IP address from a different subnet prefix 139 from the other fixed end hosts in the same engineering department. 140 It is hard and tedious to provision the consistent policy with the 141 other hosts in the same group for this specific IP address. Another 142 example is a user can belong to more than one group, say group of 143 department A and also VIP group. Group assignment is much more 144 flexible than subnet defined IP address assignment. 146 Therefore group based policy is used in such cases. No matter what 147 IP address is assigned to the user, its belonging access control 148 groups have no change and the group based policies has no change too. 149 For example, the policy can be "Allow the traffic from group 150 engineering to group testing, and assign the traffic destined to VIP 151 group the highest priority". In order to make group based policy 152 work, the IP address and its group mapping information has to be 153 stored on PEP so that IP addresses carried in data packet can be 154 mapped to the group ID first and then the policy can be enforced. 156 IP and group mapping information is usually first available at the 157 access authentication point (AAP). Figure 1 show a typical campus 158 network. The policy enforcement point (PEP) can be core switches, 159 while the access authentication point (AAP) is the access switch in 160 the figure. AAP serves as the DHCP relay which remembers the IP 161 address assigned to the client and/or at the same time it talks to 162 AAA server to get the client's group information based on client's 163 identity. The problem to be solved by Autonomic Networking 164 Infrastructure(ANI) here is how to make IP address/prefix and access 165 control group mapping information available at PEP from AAP and/or 166 other PEPs using IPAddressToAccessControlGroups ASA. 168 +-------+ +-------+ 169 | core1 | --- | core2 | core switches (PEP) 170 +-------+ /+-------+ 171 | \ / | \ 172 | \ / | \ 173 | \ / | \ 174 | \ / | \ 175 | \ | \ 176 +-------+ / \ +-------+ +-------+ 177 | acc1 |/ \| acc2 | | acc3 | access switches 178 +-------+ +-------+ +-------+ (AAP) 179 | 180 | 181 | 182 | 183 +-------+ 184 | WiFi | 185 | AP1 | wifi access point 186 +-------+ 188 Figure 1: Hierarchical Campus Network 190 A more complex campus network is shown in Figure 2. There are 4 PEPs 191 are deployed at the key positions for different types of traffic. 192 The AAPs obtaining a user's IP and group ID mapping information are 193 access switches which are the access nodes for the attaching clients. 195 via VPN tunnel ----- 196 +--------+ / \ 197 | user2 |-----------+Internet | 198 |(group1)| | | 199 +--------+ \-------/ 200 | 201 | 202 | 203 +---------------------|--------+ 204 ----- | | | 205 / \ | +--------+ +--------+ | 206 | WAN | --------------| WAN | | VPN | | 207 | | | | border | |Internet| | 208 \-------/ | |firewall| |gateway | | 209 | | +--------+ +--------+ | 210 | | |PEP3 | PEP2 | 211 | | | +----+ | 212 +------|---------+ | | | | 213 | | | | +--------+ | +--------+ | 214 | +--------+ | | | core |---+ | | | 215 | | core | | | | switch |-----|firewall| | 216 | | switch | | | +--------+ +--------+ | 217 | +--------+ | | | PEP1 | 218 | |PEP4 | | | | 219 | | | | | | 220 | | | | +--------+ +--------+ | 221 | +--------+ | | | switch | --- | switch | | 222 | | switch | | | +--------+ +--------+ | 223 | +--------+ | | | AAP2 | AAP1 | 224 | | AAP3 | | | | | 225 | | | | +--------+ +--------+ | 226 | +--------+ | | | user1 | | user3 | | 227 | | user4 | | | |(group1)| |(group2)| | 228 | |(group2)| | | +--------+ +--------+ | 229 | +--------+ | | | 230 | | | | 231 | | | | 232 |Branch | | Headquarter | 233 +----------------+ +------------------------------+ 235 Figure 2: Campus Networks with remote access 237 Some deployment uses a centralized controller to distribute IP and 238 group ID mapping information. Every single AAP reports its IP and 239 group ID mapping information to the controller. When a PEP receives 240 a data packet, it queries the controller for the group IDs of the 241 source and/or destination IP addresses and then enforce the group 242 based policy. This approach requires an explicit controller able to 243 talk to each and every AAP and PEP. In the deployment where the 244 headquarter and branch campus networks are far apart, it will require 245 controllers for each site to exchange information or have another 246 super-controller to help exchange the information among sites. It 247 introduces the complexity and interoperability issues. 249 Autonomic Networking (AN) puts the intelligence at the node level, to 250 minimize dependency on human administrators and central management 251 such as a controller. The Autonomic Networking approach discussed in 252 this document is based on the assumption that there is a generic 253 discovery and negotiation protocol that enables direct negotiation 254 between the routers or switches. GRASP [RFC8990] is intended to be 255 such a protocol which can make use of the technical objectives 256 defined in the following sections as the basic building blocks of a 257 ubiquitous group based policy management solution, especially for a 258 campus network. The ultimate goal is self-management of campus 259 networks which can expand over multiple sites and share the same set 260 of policies, including self-configuration, self-optimization, self- 261 healing and self-protection (sometimes collectively called self-X). 263 4. Autonomic IP Address to Access Control Groups Mapping Procedures 265 IPAddressToAccessControlGroups ASA carries out the the function of IP 266 address/prefix to access control groups mapping in this document. 267 The procedures is illustrated below. 269 4.1. Behaviours of IP Address to Access Control Groups Mapping 270 Requesting Nodes 272 IPAddressToAccessControlGroups requesting node is usually a PEP in a 273 domain which executes the group based policy. So it needs to map an 274 IP address/prefix to one or more group IDs first. Such mapping 275 information will be stored locally until either timeout or withdrawn. 277 The request can be triggered by a data packet. Group based policy 278 requires both the source and destination group IDs which are normally 279 mapped from source and destination IP addresses. If any of such 280 mapping is not locally available, the requesting node needs to ask 281 for it. In some implementation, data packet encapsulation includes 282 the source group ID directly such as in the reserved field in VXLAN 283 [RFC7348]. Therefore it is up to the requesting node to determine if 284 both source and destination groups or only one of them to be queried. 286 In some cases that the requesting node is a tunnel endpoint, it 287 should be noted that usually the inner rather than outer IP addresses 288 are to be used to query for the corresponding group id. 290 The request can also be sent periodically or voluntarily. It can 291 happen when a newly booted requesting node wants to get the whole 292 batch of IP address and access control group mapping information or 293 when a requesting node would like have an explicit refreshment on the 294 information. 296 The IPAddressToAccessControlGroups ASA should send out a GRASP 297 Discovery message that contains a IPAddressToAccessControlGroups 298 Objective option in order to discover peers supporting this option. 299 The requesting ASA acts as a GRASP synchronization initiator by 300 sending a GRASP Request message with a IPAddressToAccessControlGroups 301 Objective option. The ASA indicates an IP prefix or address in this 302 option. This starts a GRASP synchronization process. 304 4.2. Behaviours of IP Address to Access Control Groups Mapping 305 Providing Nodes 307 IPAddressToAccessControlGroups providing node can be the AAP of a 308 user or PEP with the specific mapping information stored in a domain. 309 It obtains the mapping of IP address and group IDs of an endpoint in 310 various ways. For instance, use RADIUS [RFC2865] or CAPWAP [RFC5415] 311 to get the user's access control group IDs during authentication 312 phase and/or use DHCP snooping to get the user's assigned IP address. 313 Sometimes such mapping information can be statically provisioned 314 based on port or VLAN. Mapping information obtained in such ways is 315 usually stored locally on AAP. In some cases, a PEP previously aware 316 of the specific mapping information can be a providing node to other 317 PEPs as well. 319 A device that receives a Discovery message with a 320 IPAddressToAccessControlGroups Objective option should respond with a 321 GRASP Response message if it contains a 322 IPAddressToAccessControlGroups ASA. When this ASA receives a 323 subsequent Request message, it should reply with a GRASP 324 Synchronization messages. The Synchronization messages carry a 325 IPAddressToAccessControlGroups Objective option, which will indicate 326 the mappings between the IP address/prefix and group IDs. Optionally 327 the expiration time can be tied to each mapping. 329 The IP address to access control groups mapping providing node can 330 send the Flood Synchronization message if it has any update or 331 withdraw regarding its providing mapping information. 333 The providing nodes of address to access control groups mapping 334 information are usually at the edges and can be added or replaced 335 with the expansion of the network. The requesting nodes are normally 336 aggregation or core nodes with more storage and capability to enforce 337 the policy. Therefore the number of mapping information providing 338 nodes is usually more than the number of requesting nodes. The 339 providing node can be the one initiating the GRASP Discovery message 340 as well and/or send the unsolicited Synchronization message 341 [I-D.ietf-anima-grasp-distribution]. 343 5. Autonomic IP Address to Access Control Groups Objectives 345 This section defines the GRASP technical objective options that are 346 used to support autonomic IP address/prefix to access control groups 347 mapping. 349 5.1. IPAddressToAccessControlGroups Objective Option 351 The IPAddressToAccessControlGroups Objective option is a GRASP 352 objective option conforming to [RFC8990]. The name of this option is 353 "IPAddressToAccessControlGroups". It carries the IP prefix/address 354 and its mapping access control group id. The format of 355 IPAddressToAccessControlGroups Objective option in CBOR (Concise 356 Binary Object Representation [RFC8949]) is show in Concise data 357 definition language (CDDL) [RFC8610] as follows. Tags for general 358 IPv4 and IPv6 addresses and prefixes defined in 359 [I-D.ietf-cbor-network-addresses] are used. 361 objective = ["IPAddressToAccessControlGroups", 362 objective-flags, loop-count, 363 [ip-address-or-prefix, *group-id]] 365 group-id = uint 367 ; copied from draft-ietf-cbor-network-addresses, RFC YYYY TBD: 369 ip-address-or-prefix = ipv6-address-or-prefix/ipv4-address-or-prefix 371 ipv6-address-or-prefix = #6.54(ipv6-address / ipv6-prefix) 372 ipv4-address-or-prefix = #6.52(ipv4-address / ipv4-prefix) 374 ipv6-prefix = [ipv6-prefix-length, ipv6-prefix-bytes] 375 ipv4-prefix = [ipv4-prefix-length, ipv4-prefix-bytes] 377 ipv6-prefix-length = 0..128 378 ipv4-prefix-length = 0..32 380 ipv6-prefix-bytes = bytes .size (uint .le 16) 381 ipv4-prefix-bytes = bytes .size (uint .le 4) 383 ipv6-address = bytes .size 16 384 ipv4-address = bytes .size 4 386 ; copied from the GRASP specification, RFC 8990: 388 objective-flags = uint .bits objective-flag 390 objective-flag = &( 391 F_DISC: 0 ; valid for discovery 392 F_NEG: 1 ; valid for negotiation 393 F_SYNCH: 2 ; valid for synchronization 394 F_NEG_DRY: 3 ; negotiation is a dry run 395 ) 396 loop-count = 0..255 398 A common practice currently usually uses 16 bits to present a group 399 ID. But the representation does not limit that. Zero group ID would 400 be used for full retraction of a prefix or address. 402 6. Security Considerations 404 Security consideration for GRASP [RFC8990] applies in this document. 405 The preferred security model is that devices are trusted following 406 the secure bootstrap procedure [RFC8995] and that a secure Autonomic 407 Control Plane (ACP) [RFC8994] is in place. 409 7. IANA Considerations 411 This document defines a new GRASP Objective option name: 412 "IPAddressToAccessControlGroups". The IANA is requested to added it 413 to the "GRASP Objective Names" subregistry defined by [RFC8990]. 415 8. Acknowledgements 417 Thanks to Carsten Bormann, Brian Carpenter and Michael Richardson for 418 useful suggestions and revising CDDL representations. 420 9. References 422 9.1. Normative References 424 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 425 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 426 Networking: Definitions and Design Goals", RFC 7575, 427 DOI 10.17487/RFC7575, June 2015, 428 . 430 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 431 Definition Language (CDDL): A Notational Convention to 432 Express Concise Binary Object Representation (CBOR) and 433 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 434 June 2019, . 436 [RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic 437 Autonomic Signaling Protocol (GRASP)", RFC 8990, 438 DOI 10.17487/RFC8990, May 2021, 439 . 441 [I-D.ietf-anima-grasp-distribution] 442 Xiao, X., Liu, B., Hecker, A., Jiang, S., and Brian, 443 "Information Distribution over GRASP", draft-ietf-anima- 444 grasp-distribution-03 (work in progress), July 2021. 446 [I-D.ietf-cbor-network-addresses] 447 Richardson, M. and C. Bormann, "CBOR tags for IPv4 and 448 IPv6 addresses and prefixes", draft-ietf-cbor-network- 449 addresses-11 (work in progress), October 2021. 451 9.2. Informative References 453 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 454 RFC 2131, DOI 10.17487/RFC2131, March 1997, 455 . 457 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 458 "Remote Authentication Dial In User Service (RADIUS)", 459 RFC 2865, DOI 10.17487/RFC2865, June 2000, 460 . 462 [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, 463 M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, 464 J., and S. Waldbusser, "Terminology for Policy-Based 465 Management", RFC 3198, DOI 10.17487/RFC3198, November 466 2001, . 468 [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, 469 Ed., "Control And Provisioning of Wireless Access Points 470 (CAPWAP) Protocol Specification", RFC 5415, 471 DOI 10.17487/RFC5415, March 2009, 472 . 474 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 475 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 476 eXtensible Local Area Network (VXLAN): A Framework for 477 Overlaying Virtualized Layer 2 Networks over Layer 3 478 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 479 . 481 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 482 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 483 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 484 RFC 8415, DOI 10.17487/RFC8415, November 2018, 485 . 487 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 488 Representation (CBOR)", STD 94, RFC 8949, 489 DOI 10.17487/RFC8949, December 2020, 490 . 492 [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An 493 Autonomic Control Plane (ACP)", RFC 8994, 494 DOI 10.17487/RFC8994, May 2021, 495 . 497 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 498 and K. Watsen, "Bootstrapping Remote Secure Key 499 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 500 May 2021, . 502 Appendix A. Objective Examples 504 This appendix shows a number of examples of objective defined in this 505 document conforming to the CDDL syntax given in Section 5.1. 507 ["IPAddressToAccessControlGroups", 15, 101, 508 [54([4, h'A50386A78BA56FA4BBC734281C51']), 3506, 2698, 4562]] 510 ["IPAddressToAccessControlGroups", 5, 73, [52(h'9946B8A3'), 2881, 511 2265, 1720, 2450]] 513 ["IPAddressToAccessControlGroups", 15, 161, 514 [54(h'39F3045B641AD291B057CD1857A7314A')]] 516 ["IPAddressToAccessControlGroups", 15, 2, [52(h'98A1CE4F')]] 518 ["IPAddressToAccessControlGroups", 15, 66, [52(h'69A16BFE'), 2601, 519 1851, 3876, 1405]] 521 ["IPAddressToAccessControlGroups", 15, 254, 522 [54(h'38AB303B8895DC95068CE00248D2FE91'), 4019, 1166, 3113]] 524 ["IPAddressToAccessControlGroups", 15, 63, [52([4, h'0B48']), 3035, 525 1181]] 527 ["IPAddressToAccessControlGroups", 15, 44, [52(h'01F1D8FF'), 3099, 528 1577, 1138, 1670]] 530 ["IPAddressToAccessControlGroups", 15, 181, 531 [54(h'2C74719F9355BA4E3BDE5689D1FE4CB0')]] 533 ["IPAddressToAccessControlGroups", 15, 129, [52(h'A2EF97C7'), 3149, 534 2728]] 536 ["IPAddressToAccessControlGroups", 15, 18, 537 [54(h'CD3868615B00D72A61A028822FEE6407'), 1832, 4605, 360, 3030]] 539 ["IPAddressToAccessControlGroups", 15, 171, 540 [54(h'46929AE1103FDF6407A239323F71C234')]] 542 ["IPAddressToAccessControlGroups", 15, 42, [52([7, h'8E05'])]] 544 ["IPAddressToAccessControlGroups", 15, 180, 545 [54([41, h'2D85855FA9C3772AAB2F']), 672, 1205]] 547 Authors' Addresses 549 Yizhou Li 550 Huawei Technologies 552 Email: liyizhou@huawei.com 554 Li Shen 555 Huawei Technologies 557 Email: kevin.shenli@huawei.com 559 Yujing Zhou 560 Huawei Technologies 562 Email: zhouyujing3@huawei.com