idnits 2.17.1 draft-xia-i2nsf-security-policy-object-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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 12, 2017) is 2599 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) == Outdated reference: A later version (-02) exists of draft-xibassnez-i2nsf-capability-00 == Outdated reference: A later version (-10) exists of draft-ietf-i2nsf-framework-04 == Outdated reference: A later version (-08) exists of draft-ietf-i2nsf-terminology-03 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Interface to Network Security Functions (I2NSF) L. Xia 3 Internet-Draft Q. Lin 4 Intended status: Standards Track Huawei 5 Expires: September 13, 2017 March 12, 2017 7 Policy Object for Interface to Network Security Functions (I2NSF) 8 draft-xia-i2nsf-security-policy-object-00 10 Abstract 12 This document describes policy objects used in the Interface to 13 Network Security Functions (I2NSF) policy rules and defines the 14 attributes of each policy object. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 13, 2017. 33 Copyright Notice 35 Copyright (c) 2017 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 52 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 4. Policy Object . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4.1. Address Object . . . . . . . . . . . . . . . . . . . . . 5 55 4.1.1. The addressName Attribute . . . . . . . . . . . . . . 5 56 4.1.2. The addressRange Attribute . . . . . . . . . . . . . 5 57 4.2. Address Group Object . . . . . . . . . . . . . . . . . . 6 58 4.2.1. The addressGroupName Attribute . . . . . . . . . . . 6 59 4.2.2. The addressReference Attribute . . . . . . . . . . . 6 60 4.2.3. The addressRange Attribute . . . . . . . . . . . . . 6 61 4.3. Domain Group Object . . . . . . . . . . . . . . . . . . . 6 62 4.3.1. The domainGroupName Attribute . . . . . . . . . . . . 6 63 4.3.2. The domainNameList Attribute . . . . . . . . . . . . 7 64 4.4. Region Object . . . . . . . . . . . . . . . . . . . . . . 7 65 4.4.1. The regionName Attribute . . . . . . . . . . . . . . 7 66 4.4.2. The regionLocation Attribute . . . . . . . . . . . . 7 67 4.4.2.1. The regionLongitude Attribute . . . . . . . . . . 7 68 4.4.2.2. The regionLatitude Attribute . . . . . . . . . . 7 69 4.4.3. The regionIPAddress Attribute . . . . . . . . . . . . 7 70 4.5. Region Group Object . . . . . . . . . . . . . . . . . . . 8 71 4.5.1. The regionGroupName Attribute . . . . . . . . . . . . 8 72 4.5.2. The regionGroupReference Attribute . . . . . . . . . 8 73 4.6. Service Object . . . . . . . . . . . . . . . . . . . . . 8 74 4.6.1. The serviceName Attribute . . . . . . . . . . . . . . 8 75 4.6.2. The serviceList Attribute . . . . . . . . . . . . . . 8 76 4.6.2.1. The serviceProtocol Attribute . . . . . . . . . . 8 77 4.6.2.2. The serviceProtocolNumber Attribute . . . . . . . 8 78 4.6.2.3. The serviceSourcePort Attribute . . . . . . . . . 9 79 4.6.2.4. The serviceDestinationPort Attribute . . . . . . 9 80 4.6.2.5. The serviceICMPType Attribute . . . . . . . . . . 9 81 4.7. Service Group Object . . . . . . . . . . . . . . . . . . 9 82 4.7.1. The serviceGroupName Attribute . . . . . . . . . . . 9 83 4.7.2. The serviceReference Attribute . . . . . . . . . . . 9 84 4.8. Application Object . . . . . . . . . . . . . . . . . . . 10 85 4.8.1. The applicationName Attribute . . . . . . . . . . . . 10 86 4.8.2. The applicationCategory Attribute . . . . . . . . . . 10 87 4.8.3. The applicationSubCategory Attribute . . . . . . . . 10 88 4.8.4. The applicationTransmissionModel Attribute . . . . . 10 89 4.8.5. The applicationLabel Attribute . . . . . . . . . . . 10 90 4.8.6. The applicationRiskLevel Attribute . . . . . . . . . 10 91 4.9. Application Group Object . . . . . . . . . . . . . . . . 10 92 4.9.1. The applicationGroupName Attribute . . . . . . . . . 11 93 4.9.2. The applicationReference Attribute . . . . . . . . . 11 94 4.10. Schedule Object . . . . . . . . . . . . . . . . . . . . . 11 95 4.10.1. The scheduleName Attribute . . . . . . . . . . . . . 11 96 4.10.2. The scheduleList Attribute . . . . . . . . . . . . . 11 97 4.10.2.1. The scheduleType Attribute . . . . . . . . . . . 11 98 4.10.2.2. The scheduleStartTime Attribute . . . . . . . . 11 99 4.10.2.3. The scheduleEndTime Attribute . . . . . . . . . 11 100 4.10.2.4. The scheduleWeekDay Attribute . . . . . . . . . 11 101 4.11. User Object . . . . . . . . . . . . . . . . . . . . . . . 12 102 4.11.1. The userName Attribute . . . . . . . . . . . . . . . 12 103 4.11.2. The userParentGroup Attribute . . . . . . . . . . . 12 104 4.11.3. The userSecurityGroup Attribute . . . . . . . . . . 12 105 4.11.4. The userDomain Attribute . . . . . . . . . . . . . . 12 106 4.11.5. The userPassword Attribute . . . . . . . . . . . . . 12 107 4.11.6. The userExpirationTime Attribute . . . . . . . . . . 12 108 4.11.7. The userAllowSharing Attribute . . . . . . . . . . . 13 109 4.11.8. The userBindingStatus Attribute . . . . . . . . . . 13 110 4.11.9. The userBindingAddress Attribute . . . . . . . . . . 13 111 4.12. User Group Object . . . . . . . . . . . . . . . . . . . . 13 112 4.12.1. The userGroupName Attribute . . . . . . . . . . . . 13 113 4.12.2. The userGroupParentGroup Attribute . . . . . . . . . 13 114 4.12.3. The userGroupDomain Attribute . . . . . . . . . . . 14 115 4.12.4. The userGroupReference Attribute . . . . . . . . . . 14 116 4.12.5. The userGroupAllowSharing Attribute . . . . . . . . 14 117 4.13. Security Group Object . . . . . . . . . . . . . . . . . . 14 118 4.13.1. The securityGroupName Attribute . . . . . . . . . . 14 119 4.13.2. The securityGroupParentGroup Attribute . . . . . . . 14 120 4.13.3. The securityGroupDomain Attribute . . . . . . . . . 14 121 4.13.4. The securityGroupType Attribute . . . . . . . . . . 14 122 4.13.5. The securityGroupReference Attribute . . . . . . . . 15 123 4.13.6. The securityGroupFilters Attribute . . . . . . . . . 15 124 4.13.7. The securityGroupAllowSharing Attribute . . . . . . 15 125 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 126 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 127 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 128 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 129 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 130 8.2. Informative References . . . . . . . . . . . . . . . . . 16 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 133 1. Introduction 135 I2NSF policy consists of policy rules that are used to provision NSF 136 instances. The I2NSF policy rule is defined by using "Event- 137 Condition-Action" (ECA) model described in Framework for Interface to 138 Network Security Functions [I-D.ietf-i2nsf-framework]. In the ECA 139 model, a condition is used to determine whether or not the predefined 140 actions should be executed. A condition usually consists of several 141 attributes. Information Model of NSFs Capabilities 142 [I-D.ietf-i2nsf-capability] describes or illustrates attributes of 143 different Condition subclasses. When configuring policy rules by 144 using attributes, it is no surprise to see that the same value of an 145 attribute or the same value set of several attributes are configured 146 for several times or more. And modifications of the policy rules are 147 also very complex and time-consuming. 149 To facilitate the provisioning of NSF instances, this document 150 describes a set of policy objects which are reusable and can be 151 referenced by variable I2NSF policy rules. A policy object can be 152 identified by a set of data items, such as IP addresses, TCP/UDP 153 ports, and domain names. Each policy object is predefined and named 154 in order to be used in I2NSF policy rules. By defining policy 155 objects, the creation and maintenance of policy rules are greatly 156 simplified. 158 o A policy object can be referenced in different policy rules as 159 required to provide re-usability. And a policy rule can reference 160 several policy objects. 162 o The modification of a policy object will be propagated to the 163 I2NSF policy rules that reference this object. No modification 164 should be made to the related policy rules. 166 In this document, a set of policy objects are described, and for each 167 policy object, several related attributes are defined. 169 2. Requirements Language 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in RFC 2119 [RFC2119]. 175 3. Terminology 177 This document uses the terminology described in Interface to Network 178 Security Functions (I2NSF) Terminology [I-D.ietf-i2nsf-terminology]. 180 4. Policy Object 182 Policy objects are collections of commonly used condition attributes. 183 Different policy objects consist of different attributes. For each 184 policy object, a description of this policy object may be an optional 185 attribute. The following figure shows the policy objects defined in 186 this document. 188 Policy Object 189 | 190 +---Address Object 191 | 192 +---Address Group Object 193 | 194 +---Domain Group Object 195 | 196 +---Region Object 197 | 198 +---Region Group Object 199 | 200 +---Service Object 201 | 202 +---Service Group Object 203 | 204 +---Application Object 205 | 206 +---Application Group Object 207 | 208 +---Schedule Object 209 | 210 +---User Object 211 | 212 +---User Group Object 213 | 214 +---Security Group Object 216 Figure 1: The policy objects 218 4.1. Address Object 220 An address object is a collection of IPv4/IPv6 addresses or MAC 221 addresses. It consists of the following attributes: 223 4.1.1. The addressName Attribute 225 This attribute defines the unique name of the address object. 227 4.1.2. The addressRange Attribute 229 This attribute defines a set of IPv4/IPv6 addresses or MAC addresses, 230 or a range of contiguous IPv4/IPv6 addresses. 232 The IPv4 address range can be defined by IPv4 address with wildcard 233 mask, or IPv4 address with subnet mask (subnet mask address or length 234 of the subnet mask), or the start address and the end address of the 235 IPv4 address range. 237 The IPv6 address range can be defined by IPv6 address with length of 238 the prefix, or the start address and the end address of the IPv6 239 address range. 241 4.2. Address Group Object 243 An address group object is composed of several address items that 244 require the same policy enforcement. An address item can be an IPv4/ 245 IPv6 address, or a MAC address, or a range of contiguous IPv4/IPv6 246 addresses, or existing address object, or existing address group 247 object. An address group object consists of the following 248 attributes: 250 4.2.1. The addressGroupName Attribute 252 This attribute defines the unique name of the address group object. 254 4.2.2. The addressReference Attribute 256 This attribute refers to the existing address objects or existing 257 address group objects identified by their unique names. 259 4.2.3. The addressRange Attribute 261 This attribute is the same as the addressRange attribute of address 262 object. It can define a set of IPv4/IPv6 addresses or MAC addresses, 263 or a range of contiguous IPv4/IPv6 addresses. 265 The IPv4 address range can be defined by IPv4 address with wildcard 266 mask, or IPv4 address with subnet mask (subnet mask address or length 267 of the subnet mask), or the start address and the end address of the 268 IPv4 address range. 270 The IPv6 address range can be defined by IPv6 address with length of 271 the prefix, or the start address and the end address of the IPv6 272 address range. 274 4.3. Domain Group Object 276 A domain group object is a collection of domain names that require 277 the same policy enforcement. It consists of the following 278 attributes: 280 4.3.1. The domainGroupName Attribute 282 This attribute defines the unique name of the domain group object. 284 4.3.2. The domainNameList Attribute 286 This attribute defines a set of domain names. The domain name can be 287 matched in two modes: exact match and suffix match. Thus a domain 288 name can be added by using the full string of the domain name (e.g., 289 www.example.com) or a domain name begins with a wildcard (e.g., 290 *.example.com). 292 4.4. Region Object 294 A region object is an IPv4/IPv6 address of a geographical region or a 295 collection of IPv4/IPv6 addresses located in the same geographical 296 region. A set of region objects which can be referenced directly 297 should be predefined by NSFs. A region object consists of the 298 following attributes: 300 4.4.1. The regionName Attribute 302 This attribute defines the unique name of the region object. 304 4.4.2. The regionLocation Attribute 306 This attribute defines the longitude and latitude of the region. It 307 consists of two sub-attributes: 309 4.4.2.1. The regionLongitude Attribute 311 This attribute defines the longitude of the region. 313 4.4.2.2. The regionLatitude Attribute 315 This attribute defines the latitude of the region. 317 4.4.3. The regionIPAddress Attribute 319 This attribute defines a set of IPv4/IPv6 addresses or a range of 320 contiguous IPv4/IPv6 addresses. And an IP address can only belong to 321 one region object. 323 The IPv4 address range can be defined by IPv4 address with wildcard 324 mask, IPv4 address with subnet mask (subnet mask address or length of 325 the subnet mask), or the start address and the end address of the 326 IPv4 address range. 328 The IPv6 address range can be defined by IPv6 address with length of 329 the prefix, or the start address and the end address of the IPv6 330 address range. 332 4.5. Region Group Object 334 A region group object is a collection of region objects that require 335 the same policy enforcement. It consists of the following 336 attributes: 338 4.5.1. The regionGroupName Attribute 340 This attribute defines the unique name of the region group object. 342 4.5.2. The regionGroupReference Attribute 344 This attribute refers to the existing region objects or region group 345 objects identified by their unique names. 347 4.6. Service Object 349 A service object is one or more services that can be identified by 350 certain information, such as protocol type, source port number and 351 destination port number. A set of well-known services should be 352 predefined by NSFs as service objects to support direct reference. A 353 service object consists of the following attributes: 355 4.6.1. The serviceName Attribute 357 This attribute defines the unique name of the service object. 359 4.6.2. The serviceList Attribute 361 This attribute defined a set of services. A service can be defined 362 by the following sub-attributes. 364 4.6.2.1. The serviceProtocol Attribute 366 This attribute defines the protocol type of the service. The value 367 of this attribute is selected from six types of protocols: TCP, UDP, 368 SCTP, ICMP, ICMPv6 or IP. 370 4.6.2.2. The serviceProtocolNumber Attribute 372 This attribute defines the protocol number for IP protocol. The 373 protocol number is the protocol field value in IP packet which 374 identifies which kind of upper layer protocol is used. 376 4.6.2.3. The serviceSourcePort Attribute 378 This attribute defines the source port number range for TCP, UDP or 379 SCTP protocol. A single port number or a range of port numbers can 380 be set. 382 4.6.2.4. The serviceDestinationPort Attribute 384 This attribute defines the destination port number range for TCP, UDP 385 or SCTP protocol. A single port number or a range of port numbers 386 can be set. 388 4.6.2.5. The serviceICMPType Attribute 390 This attribute defines the ICMP/ICMPv6 type for ICMP or ICMPv6 391 protocol. The ICMP/ICMPv6 type can be identified by ICMP/ICMPv6 type 392 number and ICMP/ICMPv6 message code. Thus, this attribute has two 393 sub-attributes: serviceICMPTypeNumber and serviceICMPMessageCode. 395 The serviceICMPTypeNumber Attribute: It defines the ICMP/ICMPv6 type 396 number and shall be defined together with the serviceICMPMessageCode 397 attribute. For example, if the ICMP packet type is Echo, this 398 attribute shall be set to 8 and the serviceICMPMessageCode attribute 399 shall be set to 0. 401 The serviceICMPMessageCode Attribute: It defines the ICMP/ICMPv6 402 message code and shall be defined together with the 403 serviceICMPTypeNumber attribute. For example, if the ICMP packet 404 type is Echo, this attribute shall be set to 0 and the 405 serviceICMPTypeNumber attribute shall be set to 8. 407 4.7. Service Group Object 409 A service group object is a collection of service objects that 410 require the same policy enforcement. It consists of the following 411 attributes: 413 4.7.1. The serviceGroupName Attribute 415 This attribute defines the unique name of the service group object. 417 4.7.2. The serviceReference Attribute 419 This attribute refers to the existing service objects or service 420 group objects identified by their unique names. 422 4.8. Application Object 424 An application object is a kind of application that can be identified 425 by several features, such as category, subcategory or risk level. A 426 set of well-known application objects should be predefined by NSFs to 427 support direct reference. An application object consists of the 428 following attributes: 430 4.8.1. The applicationName Attribute 432 This attribute defines the unique name of the application object. 434 4.8.2. The applicationCategory Attribute 436 This attribute defines the category of the application. The value of 437 this attribute is selected from a predefined set of categories, e.g., 438 general category, network application category. 440 4.8.3. The applicationSubCategory Attribute 442 This attribute defines the subcategory of the application. The value 443 of this attribute is selected from a predefined set of subcategories, 444 e.g., search engine subcategory, electronic commerce subcategory. 446 4.8.4. The applicationTransmissionModel Attribute 448 This attribute defines the data transmission model of the 449 application. The value of this attribute is selected from a 450 predefined set of transmission models, e.g., client/server model, 451 peer-to-peer model. 453 4.8.5. The applicationLabel Attribute 455 This attribute defines a set of labels for the application. The 456 values of this attribute are selected from a predefined set of 457 labels, e.g., database, encrypted-communication. 459 4.8.6. The applicationRiskLevel Attribute 461 This attribute defines a risk level for the application. The value 462 of this attribute is selected from a predefined number of risk 463 levels. 465 4.9. Application Group Object 467 An application group object is a collection of application objects 468 that require the same policy enforcement. It consists of the 469 following attributes: 471 4.9.1. The applicationGroupName Attribute 473 This attribute defines the unique name of the application group 474 object. 476 4.9.2. The applicationReference Attribute 478 This attribute refers to the existing application objects or 479 application group objects identified by their unique names. 481 4.10. Schedule Object 483 A schedule object is a set of time ranges. There are two kinds of 484 time ranges: periodic time range and absolute time range. A periodic 485 time range occurs every week. An absolute time range occurs only 486 once. A schedule object consists of the following attributes: 488 4.10.1. The scheduleName Attribute 490 This attribute defines the unique name of the schedule object. 492 4.10.2. The scheduleList Attribute 494 This attribute defines a set of time ranges. A time range can be 495 defined by the following sub-attributes. 497 4.10.2.1. The scheduleType Attribute 499 This attribute defines the type of a time range. The value of this 500 attribute is selected from the two types: periodic, absolute. 502 4.10.2.2. The scheduleStartTime Attribute 504 For a periodic time range, this attribute defines the start time in a 505 day. For an absolute time range, this attribute defines the start 506 time and start date. 508 4.10.2.3. The scheduleEndTime Attribute 510 For a periodic time range, this attribute defines the end time in a 511 day. For an absolute time range, this attribute defines the end time 512 and end date. 514 4.10.2.4. The scheduleWeekDay Attribute 516 This attribute defines the days in a week that the periodic time 517 range takes effect. 519 4.11. User Object 521 A user object identifies a person who may access network resources. 522 It is the basis of implementing user-based I2NSF policy. The user 523 objects may be created locally on the NSFs, or be imported from third 524 parties, such as authentication servers. User objects that require 525 the same policy enforcement are grouped as user group objects or 526 security group objects. The user group objects are organized as a 527 hierarchical structure. A security group object consists of user 528 objects from different user group objects that require the same 529 policy enforcement. A user object consists of the following 530 attributes: 532 4.11.1. The userName Attribute 534 This attribute refers to the user name that used for user 535 authentication. 537 4.11.2. The userParentGroup Attribute 539 This attribute refers to the existing parent user group object to 540 which this user object belongs. The parent user group object is 541 identified by its unique name. A user object can only belong to one 542 user group object. 544 4.11.3. The userSecurityGroup Attribute 546 This attribute refers to the existing security group object to which 547 this user object belongs. The security user group object is 548 identified by its unique name. A user object can belong to several 549 security group objects. 551 4.11.4. The userDomain Attribute 553 This attribute refers to the authentication domain to which this user 554 object belongs. 556 4.11.5. The userPassword Attribute 558 If user is authenticated locally on the NSF, this attribute is 559 mandatory. It defines the password corresponding to the user name. 561 4.11.6. The userExpirationTime Attribute 563 This attribute defines when will this user object expire. 565 4.11.7. The userAllowSharing Attribute 567 This attribute defines whether this user account identified by the 568 userName and userPassword attribute is allowed to be shared by 569 different persons. If allowed, this user object can be logged on to 570 several devices simultaneously. 572 4.11.8. The userBindingStatus Attribute 574 This attribute defines whether the user object is bound to IP 575 addresses, or MAC addresses, or IP/MAC address pairs. It is selected 576 from three binding modes: no binding, unidirectional binding, and 577 bidirectional binding. For no binding mode, the user object is not 578 bound to any IP or MAC address or IP/MAC address pair. For 579 unidirectional binding mode, the addresses or address pairs bound to 580 this user object also can be bound to other users. For bidirectional 581 binding mode, the addresses or address pairs bound to this user 582 should not be bound to other bidirectional binding user object. 584 4.11.9. The userBindingAddress Attribute 586 This attribute defines the bound IP addresses, or MAC addresses, or 587 IP/MAC address pairs. If the userBindingStatus is unidirectional 588 binding or bidirectional binding, this attribute is mandatory. 590 4.12. User Group Object 592 A user object group is a collection of user objects that require the 593 same policy enforcement and it usually corresponds to a physical 594 entity such as a department. The user group objects are organized as 595 a hierarchical structure. A user group object may belong to another 596 user group object. The user group objects may be created locally on 597 the NSFs, or be imported from third parties, such as authentication 598 servers. It consists of the following attributes: 600 4.12.1. The userGroupName Attribute 602 This attribute defines the unique name of the user group object. 604 4.12.2. The userGroupParentGroup Attribute 606 This attribute refers to the existing parent user group object to 607 which this user group object belongs. The parent user group object 608 is identified by its unique name. A user group object can only 609 belong to one parent user group object. 611 4.12.3. The userGroupDomain Attribute 613 This attribute refers to the authentication domain to which this user 614 group object belongs. 616 4.12.4. The userGroupReference Attribute 618 This attribute refers to the existing user objects or user group 619 objects which belong to this user group object. 621 4.12.5. The userGroupAllowSharing Attribute 623 This attribute defines whether the user objects of this user group 624 object are allowed to be shared by different persons. If allowed, 625 all user objects of this user group object can be logged on to 626 several devices simultaneously. 628 4.13. Security Group Object 630 A security group object consists of user objects from different user 631 group objects that require the same policy enforcement. The security 632 group objects may be created locally on the NSFs, or be imported from 633 third parties, such as authentication servers. This attribute 634 consists of the following attributes: 636 4.13.1. The securityGroupName Attribute 638 This attribute defines the unique name of the security group object. 640 4.13.2. The securityGroupParentGroup Attribute 642 This attribute refers to the existing parent security group objects 643 to which this security group object belongs. The parent security 644 group objects are identified by their unique names. 646 4.13.3. The securityGroupDomain Attribute 648 This attribute refers to the authentication domain to which this 649 security group object belongs. 651 4.13.4. The securityGroupType Attribute 653 This attribute defines the type of the security group object. There 654 are two types: static and dynamic. For static security group, the 655 member objects are fixed and added as required. For dynamic security 656 group, the member objects are dynamically generated by setting 657 filtering rules. 659 4.13.5. The securityGroupReference Attribute 661 This attribute defines the member objects for static security group 662 object. It refers to the existing user objects or security group 663 objects which belong to this security group object. 665 4.13.6. The securityGroupFilters Attribute 667 This attribute defines the filtering rules for dynamic security group 668 object. 670 4.13.7. The securityGroupAllowSharing Attribute 672 This attribute defines whether the user objects of this security 673 group object are allowed to be shared by different persons. If 674 allowed, all user objects of this security group object can be logged 675 on to several devices simultaneously. 677 5. Acknowledgements 679 6. IANA Considerations 681 This document requires no IANA actions. 683 7. Security Considerations 685 When the policy objects are transmitted, the integrity of these 686 policy objects should be guaranteed. NSFs should verify that the 687 modifications of policy objects come from the authenticated security 688 controller. And NSF should protect the stored policy objects from 689 being tampered. 691 8. References 693 8.1. Normative References 695 [I-D.ietf-i2nsf-capability] 696 Xia, L., Strassner, J., Zhang, D., Li, K., Basile, C., 697 Lioy, A., Lopez, D., Lopez, E., BOUTHORS, N., and L. Fang, 698 "Information Model of NSFs Capabilities", 2016, 699 . 702 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 703 Requirement Levels", BCP 14, RFC 2119, 704 DOI 10.17487/RFC2119, March 1997, 705 . 707 8.2. Informative References 709 [I-D.ietf-i2nsf-framework] 710 Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 711 Kumar, "Framework for Interface to Network Security 712 Functions", 2016, . 715 [I-D.ietf-i2nsf-terminology] 716 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 717 Birkholz, "Interface to Network Security Functions (I2NSF) 718 Terminology", 2016, . 721 Authors' Addresses 723 Liang Xia 724 Huawei 725 101 Software Avenue, Yuhuatai District 726 Nanjing, Jiangsu 210012 727 China 729 Email: Frank.xialiang@huawei.com 731 Qiushi Lin 732 Huawei 733 Huawei Industrial Base 734 Shenzhen, Guangdong 518129 735 China 737 Email: linqiushi@huawei.com