idnits 2.17.1 draft-yizhou-anima-ip-to-access-control-groups-02.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 (November 15, 2021) is 864 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 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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: May 19, 2022 Huawei Technologies 6 November 15, 2021 8 Autonomic IP Address To Access Control Group ID Mapping 9 draft-yizhou-anima-ip-to-access-control-groups-02 11 Abstract 13 This document defines the autonomic technical Objectives for IP 14 address/prefix to access control group IDs mapping information. The 15 Objectives defined can be used in Generic Autonomic Signaling 16 Protocol (GRASP) to make the policy enforcement point receive IP 17 address and its tied access control groups information directly from 18 the access authentication points and facilitate the group based 19 policy enforcement. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 19, 2022. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Autonomic IP Address to Access Control Groups ID Mapping 59 Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 4.1. Behaviours of IP to Group Mapping Information Providing 61 Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 4.2. Behaviours of IP to Group Mapping Information Receiving 63 or Requesting Nodes . . . . . . . . . . . . . . . . . . . 8 64 5. Autonomic IP Address to Access Control Groups Objectives . . 10 65 5.1. IpToGroupId.AAP and IpToGroupId.PEP Objective Option . . 10 66 5.2. Example of Using the Defined Objective Options . . . . . 12 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 72 9.2. Informative References . . . . . . . . . . . . . . . . . 15 73 Appendix A. Objective Examples . . . . . . . . . . . . . . . . . 16 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 76 1. Introduction 78 Ubiquitous group based policy management makes sure that the users 79 can obtain the same network access permission and QoS assurance 80 wherever they access the campus network. That is, the permission and 81 QoS assurance are tied to user role, rather than access points and/or 82 IP address assigned. 84 Group means a number of endpoints connecting to the network that 85 share common network policies. It facilitates the easy design and 86 provision of policy. A user's role is usually a group indicated by a 87 group ID. Group based policy management has been replacing the 88 traditional IP address and/or port number based policy widely. 90 The policy enforcement point (PEP) requires the IP address/prefix and 91 access control group ID mapping information of user in order to 92 execute the group based policy. This mapping information is usually 93 available at the access authentication point (AAP) during the 94 procedures of user access and authentication/authorization. However 95 PEP may not be the access authentication point. Therefore IP and 96 access control group ID mappings has to be passed to PEP. 98 This document defines the autonomic technical Objectives for IP 99 address/prefix and access control group ID mapping. In this 100 document, group is also used for short to refer to the access control 101 group. The Generic Autonomic Signaling Protocol (GRASP) [RFC8990] 102 can make use of these technical Objectives as the basic building 103 blocks of a ubiquitous group based policy management solution, 104 especially for a campus network. 106 Autonomic Networking Infrastructure (ANI) is designed to provide the 107 elementary functions and services to be further integrated and used 108 by Autonomic Service Agents (ASA) on nodes. A campus policy 109 management system can integrate the function introduced in this 110 document when necessary. Such an Autonomic Service Agent (ASA) 111 performing the function of IP address/prefix to access control group 112 ID mapping is called IPAddressToAccessControlGroups ASA in this 113 document. 115 2. Terminologies 117 This document uses terminology defined in [RFC7575]. 119 PEP: Policy Enforcement Point. A logical entity that enforces 120 policy decisions [RFC3198]. The policy decisions are group based 121 policies in this document. 123 AAP: Access Authentication Point. A logical entity that obtains the 124 information of the attaching clients' assigned IP address/prefix 125 and their access control group IDs. AAP may get the information 126 from one or different resources, for example, DHCP [RFC2131] 127 [RFC8415] server and/or RADIUS [RFC2865] server. 129 3. Problems 131 The traditional policy in a campus network is normally presented as 132 IP prefix/address based, for example, "Deny the traffic from IP 133 prefix X to IP prefix Y". Each of the access port of the switches is 134 assigned a subnet prefix and each subnet implies a group. It works 135 well when the end hosts are static. With the increasing deployment 136 of wireless accessed users and more complicated and dynamic 137 requirements of campus network policy, such an assumption no longer 138 holds. For instance, a user from the engineering department may 139 bring the laptop to access the campus network via a WiFi access 140 point. Then it will be assigned an IP address from a different 141 subnet prefix from the other fixed end hosts in the same engineering 142 department. It is hard and tedious to provision the consistent 143 policy with the other hosts in the same group for this specific IP 144 address. Another example is a user can belong to more than one 145 group, say group of department A and also VIP group. Group 146 assignment is much more flexible than subnet defined IP address 147 assignment. 149 Therefore group based policy is used in such cases. No matter what 150 IP address is assigned to the user, its belonging access control 151 groups have no change and the group based policies have no change 152 either. For example, the policy can be "Allow the traffic from group 153 engineering whose group ID is 3 to group testing whose group ID is 154 15", or "assign the traffic destined to VIP group whose group ID is 1 155 the highest priority". In order to make group based policy work, the 156 IP address and its group mapping information has to be stored on PEP 157 so that IP addresses carried in data packet can be extracted and then 158 mapped to the group ID. For instance, when a packet with source 159 address X and destination address Y is received by PEP, PEP checks 160 its mapping table to get that source address X maps to group ID 3 and 161 destination address Y maps to group ID 15. It checks its policy 162 table to see what kind of policy, such as "allow" or "drop", should 163 be enforced on packet from group ID 3 to group ID 15. Then PEP 164 executes the group based policy. The mapping table is short for IP 165 address to access control group ID mapping table. For the 166 information in the mapping table, we call it IP and group mapping 167 information in this document. 169 IP and group mapping information is usually first available at the 170 access authentication point (AAP). AAP may serve as the DHCP relay 171 which remembers the IP address assigned to the client during DHCP 172 address assignment and at the same time it talks to AAA server to get 173 the client's group ID information based on client's identity using 174 AAA protocol such as RADIUS [RFC2865]. AAP then obtains the IP and 175 group mapping information. Figure 1 show a typical campus network. 176 The policy enforcement point (PEP) can be core switches, while the 177 access authentication point (AAP) is the access switch in the figure. 178 The problem to be solved by Autonomic Networking Infrastructure(ANI) 179 here is how to make IP address and access control group ID mapping 180 information passing from AAP to PEPs using 181 IPAddressToAccessControlGroups ASA. 183 +-------+ +-------+ 184 | core1 | --- | core2 | core switches (PEP) 185 +-------+ /+-------+ 186 | \ / | \ 187 | \ / | \ 188 | \ / | \ 189 | \ / | \ 190 | \ | \ 191 +-------+ / \ +-------+ +-------+ 192 | acc1 |/ \| acc2 | | acc3 | access switches 193 +-------+ +-------+ +-------+ (AAP) 194 | 195 | 196 | 197 | 198 +-------+ 199 | WiFi | 200 | AP1 | wifi access point 201 +-------+ 203 Figure 1: Hierarchical Campus Network 205 A more complex campus network is shown in Figure 2. There are 4 PEPs 206 are deployed at the key positions for different types of traffic. 207 The AAPs obtaining a user's IP and group ID mapping information are 208 access switches which are the access nodes for the attaching clients. 210 via VPN tunnel ----- 211 +--------+ / \ 212 | user2 |-----------+Internet | 213 |(group1)| | | 214 +--------+ \-------/ 215 | 216 | 217 | 218 +---------------------|--------+ 219 ----- | | | 220 / \ | +--------+ +--------+ | 221 | WAN | --------------| WAN | | VPN | | 222 | | | | border | |Internet| | 223 \-------/ | |firewall| |gateway | | 224 | | +--------+ +--------+ | 225 | | |PEP3 | PEP2 | 226 | | | +----+ | 227 +------|---------+ | | | | 228 | | | | +--------+ | +--------+ | 229 | +--------+ | | | core |---+ | | | 230 | | core | | | | switch |-----|firewall| | 231 | | switch | | | +--------+ +--------+ | 232 | +--------+ | | | PEP1 | 233 | |PEP4 | | | | 234 | | | | | | 235 | | | | +--------+ +--------+ | 236 | +--------+ | | | switch | --- | switch | | 237 | | switch | | | +--------+ +--------+ | 238 | +--------+ | | | AAP2 | AAP1 | 239 | | AAP3 | | | | | 240 | | | | +--------+ +--------+ | 241 | +--------+ | | | user1 | | user3 | | 242 | | user4 | | | |(group1)| |(group2)| | 243 | |(group2)| | | +--------+ +--------+ | 244 | +--------+ | | | 245 | | | | 246 | | | | 247 |Branch | | Headquarter | 248 +----------------+ +------------------------------+ 250 Figure 2: Campus Networks with remote access 252 Some deployment uses a centralized controller to distribute IP and 253 group ID mapping information. Every single AAP reports its IP and 254 group ID mapping information to the controller. Controller pushes 255 the information regularly to all the PEPs. In addition, when a PEP 256 receives a data packet without pre-stored mapped group ID information 257 of the corresponding IP addresses, it queries the controller for the 258 group IDs of the source and/or destination IP addresses and then 259 enforce the group based policy. This approach requires an explicit 260 controller able to talk to each and every AAP and PEP. In the 261 deployment where the headquarter and branch campus networks are far 262 apart, it will require controllers for each site to exchange 263 information or have another super-controller to help exchange the 264 information among sites. It introduces the complexity and 265 interoperability issues. 267 Autonomic Networking (AN) puts the intelligence at the node level, to 268 minimize dependency on human administrators and central management 269 such as a controller. The Autonomic Networking approach discussed in 270 this document is based on the assumption that there is a generic 271 discovery and negotiation protocol that enables direct negotiation 272 and/or synchronization between the routers or switches. GRASP 273 [RFC8990] is intended to be such a protocol which can make use of the 274 technical Objectives defined in the following sections as the basic 275 building blocks of a ubiquitous group based policy management 276 solution, especially for a campus network. The ultimate goal is 277 self-management of campus networks which can expand over multiple 278 sites and share the same set of policies, including self- 279 configuration, self-optimization, self-healing and self-protection 280 (sometimes collectively called self-X). 282 4. Autonomic IP Address to Access Control Groups ID Mapping Procedures 284 IPAddressToAccessControlGroups ASA carries out the the function of IP 285 address/prefix to access control groups ID mapping in this document. 286 The procedures is illustrated below. As noted in Section 3, a 287 network node with IPAddressToAccessControlGroups ASA deployed usually 288 has a role of either AAP or PEP. Therefore two new GRASP Objectives 289 are defined and used for Objective name based multiplexing. They are 290 IpToGroupId.PEP and IpToGroupId.AAP respectively. Section 5 gives 291 more details of the format of them. 293 The basic procedures are AAP provides the mapping information to PEPs 294 whenever it obtains new or updated or withdrawn mapping information. 295 PEPs will then store the information for future policy enforcement 296 usage. A rare case is that a PEP requests the group ID for a 297 specific IP address when it finds that information is required but 298 not locally stored. AAP possessing such mapping information will 299 reply to this request. 301 4.1. Behaviours of IP to Group Mapping Information Providing Nodes 303 IPAddressToAccessControlGroups ASA with mapping information providing 304 feature is usually an AAP supporting IpToGroupId.AAP Objective 305 option. If a PEP would like to provide mapping information as well 306 to the other PEPs, it is logically an AAP in that procedure. Then 307 such PEPs should support both IpToGroupId.PEP and IpToGroupId.AAP 308 Objective options in its IPAddressToAccessControlGroups ASA. 310 AAP obtains the mapping of IP address and group IDs of a user in 311 various ways. For instance, use RADIUS [RFC2865] or CAPWAP [RFC5415] 312 to get the user's access control group IDs during authentication 313 phase and use DHCP snooping to get the user's assigned IP address. 314 Therefore the IP and group ID mapping information of a user can be 315 obtained by AAP at the very early stage when the user connects to the 316 network. Sometimes such mapping information can be statically 317 provisioned based on port or VLAN. Mapping information obtained in 318 such ways is stored locally on AAP. AAP discovers the 319 IPAddressToAccessControlGroups ASA supporting IpToGroupId.PEP first. 320 Then AAP sends Request Negotiation message to those PEPs with the 321 mapping information it has. Whenever there is a change or withdrawn 322 of the mapping information, AAP has to send Request Negotiation again 323 to PEPs for updating. 325 The providing nodes of mapping information are usually at the network 326 edges. The requesting or receiving nodes of the mapping information 327 are normally aggregation or core nodes with more storage and 328 capability to enforce the policy. There are normally only a few of 329 them, for instance two in a campus network. Therefore the number of 330 mapping information receiving nodes is usually much less than the 331 number of providing nodes. Hence it is quite efficient that the 332 information providing AAP nodes proactively send the mapping 333 information to the receiving PEP nodes. It is the most common case 334 how the mapping information is distributed. 336 In some rare cases that an AAP receives the Request Synchronization 337 with specific IP address and NULL (represented by zero) group ID, it 338 should reply with Synchronization message with the mapped group ID of 339 the specific IP address. If an AAP has no such mapped information 340 available locally, it can reply with an Invalid message. 342 4.2. Behaviours of IP to Group Mapping Information Receiving or 343 Requesting Nodes 345 IPAddressToAccessControlGroups ASA with mapping information 346 requesting or receiving feature is usually a PEP supporting 347 IpToGroupId.PEP Objective option. PEPs need to map the IP address/ 348 prefix of the received data packets to one or more group IDs in order 349 to enforce the group based policy. 351 PEPs deployed IPAddressToAccessControlGroups ASA supporting 352 IpToGroupId.PEP Objective option will receive the Request Negotiation 353 GRASP message with the mapping information from the information 354 providing AAP nodes as shown in Section 4.1. It should save the 355 mapping information locally. And reply with an Negotiation End GRASP 356 message with an Accept option. 358 It makes the mapping information of the specific IP addresses 359 received and pre-stored in most cases by PEP before the data packet 360 with those addresses as source or destination is received. 362 However there are cases that the mapped group ID information of the 363 IP address is not pre-stored when a data packet with that IP address 364 arrives, for example due to timeout or unintentional withdrawn of the 365 mapping information. Then PEPs will send the Request Synchronization 366 with the specific IP address and NULL group ID to ask AAPs for the 367 mapping information. 369 The request can be triggered by the first data packet of a flow. 370 Group based policy requires both the source and destination group IDs 371 which are mapped from source and destination IP addresses 372 respectively. If any of such mapping is not locally available, the 373 requesting node needs to ask for it. In some implementation, data 374 packet encapsulation includes the source group ID directly such as in 375 the reserved field in VXLAN [RFC7348]. Therefore it is up to the 376 requesting node to determine if both source and destination group IDs 377 or only one of them should be requested. If the requesting node is a 378 tunnel endpoint, usually the inner rather than outer IP addresses 379 should be used to request for the corresponding group id. 381 The request can also be sent periodically or voluntarily. It can be 382 sent when a newly booted requesting node wants to get the whole set 383 of mapping information or when a requesting node would like have an 384 explicit refreshment on some specific information. 386 The requesting PEP should send out a GRASP Discovery message 387 containing IpToGroupId.AAP Objective option in order to discover 388 AAPs. It then acts as a GRASP synchronization initiator by sending 389 the Request Synchronization with IP address and NULL group ID as the 390 Objective values to ask for the mapping information. This starts a 391 GRASP synchronization process. 393 5. Autonomic IP Address to Access Control Groups Objectives 395 This section defines two GRASP technical Objective options 396 IpToGroupId.AAP and IpToGroupId.PEP that can be used by 397 IPAddressToAccessControlGroups ASA to support autonomic IP address/ 398 prefix to access control group ID mapping information distribution. 400 5.1. IpToGroupId.AAP and IpToGroupId.PEP Objective Option 402 Both IpToGroupId.AAP and IpToGroupId.PEP Objective option are GRASP 403 Objective options conforming to [RFC8990]. They share the same 404 Objective option value format defined in this section. Normally 405 IpToGroupId.AAP Objective option should be supported by 406 IPAddressToAccessControlGroups ASA deployed on AAP nodes to provide 407 the mapping information and IpToGroupId.PEP Objective option should 408 be supported by IPAddressToAccessControlGroups ASA deployed on PEP 409 nodes to request or receive the mapping information . 411 The Objective carries the IP prefix/address and its mapping access 412 control group IDs. The format of them in CBOR (Concise Binary Object 413 Representation [RFC8949]) is show in Concise data definition language 414 (CDDL) [RFC8610] as follows. Tags for general IPv4 and IPv6 415 addresses and prefixes defined in [I-D.ietf-cbor-network-addresses] 416 are used. 418 objective = ["IpToGroupId.AAP", 419 objective-flags, loop-count, 420 [ip-address-or-prefix, *group-id]] 422 objective = ["IpToGroupId.PEP", 423 objective-flags, loop-count, 424 [ip-address-or-prefix, *group-id]] 426 group-id = uint 428 ; copied from draft-ietf-cbor-network-addresses, RFC YYYY TBD: 430 ip-address-or-prefix = ipv6-address-or-prefix/ipv4-address-or-prefix 432 ipv6-address-or-prefix = #6.54(ipv6-address / ipv6-prefix) 433 ipv4-address-or-prefix = #6.52(ipv4-address / ipv4-prefix) 435 ipv6-prefix = [ipv6-prefix-length, ipv6-prefix-bytes] 436 ipv4-prefix = [ipv4-prefix-length, ipv4-prefix-bytes] 438 ipv6-prefix-length = 0..128 439 ipv4-prefix-length = 0..32 441 ipv6-prefix-bytes = bytes .size (uint .le 16) 442 ipv4-prefix-bytes = bytes .size (uint .le 4) 444 ipv6-address = bytes .size 16 445 ipv4-address = bytes .size 4 447 ; copied from the GRASP specification, RFC 8990: 449 objective-flags = uint .bits objective-flag 451 objective-flag = &( 452 F_DISC: 0 ; valid for discovery 453 F_NEG: 1 ; valid for negotiation 454 F_SYNCH: 2 ; valid for synchronization 455 F_NEG_DRY: 3 ; negotiation is a dry run 456 ) 457 loop-count = 0..255 459 A common practice usually uses 16 bits to present a group ID. But 460 the representation does not limit that. Zero group ID represents a 461 NULL group value and is used for full retraction of a prefix or 462 address. 464 5.2. Example of Using the Defined Objective Options 466 Figure 1 shows a typical campus network of with three access switches 467 which are AAPs and two core switches which are PEPs. We assume that 468 the policy in this campus is outsource_group (which has group ID 5) 469 is not allowed to access accounting_group (which has group ID 10). 470 The policy (5, 10, drop) expressed in the form of (source group ID, 471 destination group ID, action) is provisioned on the PEPs which are 472 core switches in the figure. 474 When a user gets connected, the access switch which is an AAP snoops 475 the DHCP address assignment exchange to obtain the IP address IP_A. 476 The user provides a user ID to get authenticated via 802.1x and 477 RADIUS protocol. Thus the access switch obtains the user's group ID 478 which is 5 in this example in authentication procedures. So the 479 access switch has the mapping information (IP_A, 5) in the form of 480 (IP address, access control group ID). The mapping information is 481 then passed from the access switch to the core switches which are 482 PEPs using GRASP Objective defined in this document. Figure 3 shows 483 an example of the procedures. Only the key values of the Objective 484 is shown for simplicity. 486 +-------------+ +-------------+ +-------------+ 487 |access switch| | core switch | | core switch | 488 | (AAP) | | (PEP1) | | (PEP2) | 489 +-------------+ +-------------+ +-------------+ 490 | 491 | | 492 | | | 493 | Discovery (IpToGroupId.PEP) | 494 | | | 495 |------------------------>-------------------->| 496 | | | 497 | Discovery Response | | 498 |<----------------------- | | 499 | Discovery Response | 500 |<---------------------------------------------| 501 | | | 502 | | | 503 | | | 504 |Request Negotiation ( | | 505 |IpToGroupId.PEP,(IP_A,5))| | 506 |------------------------>| save (IP_A,5) | 507 | | | 508 | Negotiation End (ACCEPT)| | 509 |<----------------------- | | 510 | | | 511 | Request Negotiation ( | 512 | IpToGroupId.PEP,(IP_A,5)) | 513 |--------------------------------------------->|save (IP_A,5) 514 | | | 515 | | | 516 | | | 517 | Negotiation End (ACCEPT) | 518 |<---------------------------------------------| 519 | | | 520 | | | 521 | | | 523 Figure 3: Example of AAP pushing mapping information to PEPs 525 After the core switches get this mapping information, they save it 526 for future policy enforcement. For example, when a data packet with 527 source IP address IP_A and destination IP address IP_B is received, 528 the PEP checks its mapping table to get the group ID 5 for IP_A and 529 group ID 10 for IP_B. Then the policy provisioned as (5, 10, drop) 530 is enforcement. So the data packet will be dropped. It facilitates 531 the group based policy execution. 533 6. Security Considerations 535 Security consideration for GRASP [RFC8990] applies in this document. 536 The preferred security model is that devices are trusted following 537 the secure bootstrap procedure [RFC8995] and that a secure Autonomic 538 Control Plane (ACP) [RFC8994] is in place. 540 7. IANA Considerations 542 This document defines two new GRASP Objective option names: 543 "IpToGroupId.AAP" and "IpToGroupId.PEP". The IANA is requested to 544 added them to the "GRASP Objective Names" subregistry defined by 545 [RFC8990]. 547 8. Acknowledgements 549 Thanks to Carsten Bormann, Brian Carpenter and Michael Richardson for 550 useful suggestions and revising CDDL representations. 552 9. References 554 9.1. Normative References 556 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 557 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 558 Networking: Definitions and Design Goals", RFC 7575, 559 DOI 10.17487/RFC7575, June 2015, 560 . 562 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 563 Definition Language (CDDL): A Notational Convention to 564 Express Concise Binary Object Representation (CBOR) and 565 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 566 June 2019, . 568 [RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic 569 Autonomic Signaling Protocol (GRASP)", RFC 8990, 570 DOI 10.17487/RFC8990, May 2021, 571 . 573 [I-D.ietf-cbor-network-addresses] 574 Richardson, M. and C. Bormann, "CBOR tags for IPv4 and 575 IPv6 addresses and prefixes", draft-ietf-cbor-network- 576 addresses-13 (work in progress), October 2021. 578 9.2. Informative References 580 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 581 RFC 2131, DOI 10.17487/RFC2131, March 1997, 582 . 584 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 585 "Remote Authentication Dial In User Service (RADIUS)", 586 RFC 2865, DOI 10.17487/RFC2865, June 2000, 587 . 589 [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, 590 M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, 591 J., and S. Waldbusser, "Terminology for Policy-Based 592 Management", RFC 3198, DOI 10.17487/RFC3198, November 593 2001, . 595 [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, 596 Ed., "Control And Provisioning of Wireless Access Points 597 (CAPWAP) Protocol Specification", RFC 5415, 598 DOI 10.17487/RFC5415, March 2009, 599 . 601 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 602 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 603 eXtensible Local Area Network (VXLAN): A Framework for 604 Overlaying Virtualized Layer 2 Networks over Layer 3 605 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 606 . 608 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 609 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 610 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 611 RFC 8415, DOI 10.17487/RFC8415, November 2018, 612 . 614 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 615 Representation (CBOR)", STD 94, RFC 8949, 616 DOI 10.17487/RFC8949, December 2020, 617 . 619 [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An 620 Autonomic Control Plane (ACP)", RFC 8994, 621 DOI 10.17487/RFC8994, May 2021, 622 . 624 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 625 and K. Watsen, "Bootstrapping Remote Secure Key 626 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 627 May 2021, . 629 Appendix A. Objective Examples 631 This appendix shows a number of examples of Objective defined in this 632 document conforming to the CDDL syntax given in Section 5.1. 634 ["IpToGroupId.PEP", 15, 101, 635 [54([4, h'A50386A78BA56FA4BBC734281C51']), 3506, 2698, 4562]] 637 ["IpToGroupId.PEP", 5, 73, [52(h'9946B8A3'), 2881, 638 2265, 1720, 2450]] 640 ["IpToGroupId.PEP", 15, 161, 641 [54(h'39F3045B641AD291B057CD1857A7314A')]] 643 ["IpToGroupId.PEP", 15, 2, [52(h'98A1CE4F')]] 645 ["IpToGroupId.PEP", 15, 66, [52(h'69A16BFE'), 2601, 646 1851, 3876, 1405]] 648 ["IpToGroupId.AAP", 15, 254, 649 [54(h'38AB303B8895DC95068CE00248D2FE91'), 4019, 1166, 3113]] 651 ["IpToGroupId.AAP", 15, 63, [52([4, h'0B48']), 3035, 652 1181]] 654 ["IpToGroupId.AAP", 15, 44, [52(h'01F1D8FF'), 3099, 655 1577, 1138, 1670]] 657 ["IpToGroupId.AAP", 15, 181, 658 [54(h'2C74719F9355BA4E3BDE5689D1FE4CB0')]] 660 ["IpToGroupId.PEP", 15, 129, [52(h'A2EF97C7'), 3149, 661 2728]] 663 Authors' Addresses 665 Yizhou Li 666 Huawei Technologies 668 Email: liyizhou@huawei.com 669 Li Shen 670 Huawei Technologies 672 Email: kevin.shenli@huawei.com 674 Yujing Zhou 675 Huawei Technologies 677 Email: zhouyujing3@huawei.com