idnits 2.17.1 draft-xia-i2nsf-security-policy-object-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 : ---------------------------------------------------------------------------- ** There are 32 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (July 2, 2017) is 2490 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-01 == Outdated reference: A later version (-10) exists of draft-ietf-i2nsf-framework-05 == Outdated reference: A later version (-08) exists of draft-ietf-i2nsf-terminology-03 Summary: 1 error (**), 0 flaws (~~), 6 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: January 3, 2018 July 2, 2017 7 Policy Object for Interface to Network Security Functions (I2NSF) 8 draft-xia-i2nsf-security-policy-object-01 10 Abstract 12 This document describes policy object used in the Interface to 13 Network Security Functions (I2NSF) policy rules to provide re- 14 usability and defines essential attributes for 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 January 3, 2018. 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. Service Object . . . . . . . . . . . . . . . . . . . . . 7 62 4.3.1. The serviceName Attribute . . . . . . . . . . . . . . 7 63 4.3.2. The serviceList Attribute . . . . . . . . . . . . . . 7 64 4.3.2.1. The serviceProtocol Attribute . . . . . . . . . . 7 65 4.3.2.2. The serviceProtocolNumber Attribute . . . . . . . 8 66 4.3.2.3. The serviceICMPType Attribute . . . . . . . . . . 8 67 4.3.2.4. The serviceICMPCode Attribute . . . . . . . . . . 8 68 4.3.2.5. The serviceSourcePort Attribute . . . . . . . . . 8 69 4.3.2.6. The serviceDestinationPort Attribute . . . . . . 8 70 4.4. Service Group Object . . . . . . . . . . . . . . . . . . 8 71 4.4.1. The serviceGroupName Attribute . . . . . . . . . . . 9 72 4.4.2. The serviceReference Attribute . . . . . . . . . . . 9 73 4.5. Application Object . . . . . . . . . . . . . . . . . . . 9 74 4.5.1. The applicationName Attribute . . . . . . . . . . . . 9 75 4.5.2. The applicationCategory Attribute . . . . . . . . . . 9 76 4.5.3. The applicationSubCategory Attribute . . . . . . . . 9 77 4.5.4. The applicationTransmissionModel Attribute . . . . . 10 78 4.5.5. The applicationVulnerability Attribute . . . . . . . 10 79 4.5.6. The applicationRiskLevel Attribute . . . . . . . . . 10 80 4.6. Application Group Object . . . . . . . . . . . . . . . . 10 81 4.6.1. The applicationGroupName Attribute . . . . . . . . . 10 82 4.6.2. The applicationReference Attribute . . . . . . . . . 10 83 4.7. Schedule Object . . . . . . . . . . . . . . . . . . . . . 10 84 4.7.1. The scheduleName Attribute . . . . . . . . . . . . . 11 85 4.7.2. The scheduleList Attribute . . . . . . . . . . . . . 11 86 4.7.2.1. The scheduleType Attribute . . . . . . . . . . . 11 87 4.7.2.2. The scheduleStartTime Attribute . . . . . . . . . 11 88 4.7.2.3. The scheduleEndTime Attribute . . . . . . . . . . 11 89 4.7.2.4. The scheduleWeekDay Attribute . . . . . . . . . . 11 90 4.8. User Object . . . . . . . . . . . . . . . . . . . . . . . 11 91 4.8.1. The userName Attribute . . . . . . . . . . . . . . . 12 92 4.8.2. The userParentGroup Attribute . . . . . . . . . . . . 12 93 4.8.3. The userSecurityGroup Attribute . . . . . . . . . . . 12 94 4.8.4. The userDomain Attribute . . . . . . . . . . . . . . 12 95 4.8.5. The userPassword Attribute . . . . . . . . . . . . . 13 96 4.8.6. The userExpirationTime Attribute . . . . . . . . . . 13 97 4.9. User Group Object . . . . . . . . . . . . . . . . . . . . 13 98 4.9.1. The userGroupName Attribute . . . . . . . . . . . . . 13 99 4.9.2. The userGroupParentGroup Attribute . . . . . . . . . 13 100 4.9.3. The userGroupDomain Attribute . . . . . . . . . . . . 13 101 4.9.4. The userGroupReference Attribute . . . . . . . . . . 13 102 4.10. Security Group Object . . . . . . . . . . . . . . . . . . 13 103 4.10.1. The securityGroupName Attribute . . . . . . . . . . 14 104 4.10.2. The securityGroupParentGroup Attribute . . . . . . . 14 105 4.10.3. The securityGroupDomain Attribute . . . . . . . . . 14 106 4.10.4. The securityGroupType Attribute . . . . . . . . . . 14 107 4.10.5. The securityGroupReference Attribute . . . . . . . . 14 108 4.10.6. The securityGroupFilters Attribute . . . . . . . . . 14 109 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 110 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 111 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 112 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 113 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 114 8.2. Informative References . . . . . . . . . . . . . . . . . 15 115 Appendix A. Application Attributes . . . . . . . . . . . . . . . 15 116 A.1. Category and Subcategory . . . . . . . . . . . . . . . . 15 117 A.2. Data Transmission Model . . . . . . . . . . . . . . . . . 16 118 A.3. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 17 119 Appendix B. Example of Application Scenario for Policy Object . 17 120 B.1. Security Policy Control for Marketing Departments . . . . 20 121 B.2. Security Policy Control for R&D Departments . . . . . . . 20 122 B.3. Security Policy Control for Server Access of Internet 123 Users . . . . . . . . . . . . . . . . . . . . . . . . . . 21 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 126 1. Introduction 128 I2NSF policy consists of policy rules that are used to provision NSF 129 instances. The I2NSF policy rule is defined by using "Event- 130 Condition-Action" (ECA) model described in I2NSF framework draft 131 [I-D.ietf-i2nsf-framework]. In the ECA model, a condition is used to 132 determine whether or not the predefined actions should be executed. 133 A condition usually consists of several attributes. Information 134 Model of NSFs Capabilities [I-D.ietf-i2nsf-capability] describes 135 attributes of different condition subclasses. When configuring 136 policy rules by attributes, it is common to see that the same 137 attribute or the same set of several attributes are configured for 138 several times or more. And modifications of the policy rules are 139 also very tedious and time-consuming. 141 To facilitate the provisioning of NSF instances, this document 142 describes a set of policy objects which are reusable and can be 143 referenced by variable I2NSF policy rules. A policy object consists 144 of a name attribute that identifies itself and one or several 145 attributes that are typically used together to represent a certain 146 condition. For example, protocol type and port number are usually 147 used together to represent a certain service. Each policy object is 148 predefined and named in order to be used in I2NSF policy rules. By 149 defining policy objects, the creation and maintenance of policy rules 150 are greatly simplified. 152 o A policy object can be referenced in different policy rules as 153 required to provide re-usability. And a policy rule can reference 154 several policy objects. 156 o The modification of a policy object will be propagated to the 157 I2NSF policy rules that reference this object. No modification 158 should be made to the related policy rules. 160 In this document, a set of policy objects are described, and for each 161 policy object, several essential attributes are defined. 163 2. Requirements Language 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in RFC 2119 [RFC2119]. 169 3. Terminology 171 This document uses the terminology described in Interface to Network 172 Security Functions (I2NSF) Terminology [I-D.ietf-i2nsf-terminology]. 174 4. Policy Object 176 IP addresses, port numbers, protocol types, services, applications, 177 user accounts are commonly used attributes to determine whether a 178 certain condition occurs. In real-world deployment, these attributes 179 are often configured for many times. The definition of policy 180 objects could help to minimize the configuration effort and provide 181 simplicity. 183 Figure 1 shows the policy objects defined in this document and their 184 relationships. 186 +-----------------------------------------------------------------+ 187 | Policy Object | 188 +-----------------------------------------------------------------+ 189 | | | | | | 190 | | | | | | 191 +-------+ +-------+ +-----------+ +-----+ +--------+ | 192 |Address| |Service| |Application| |User | |Security| | 193 |Group | |Group | |Group | |Group| |Group | | 194 +-------+ +-------+ +-----------+ +-----+ +--------+ | 195 | | | | | | 196 | | | +---------+ | 197 | | | | | 198 +-------+ +-------+ +-----------+ +------+ +--------+ 199 |Address| |Service| |Application| |User | |Schedule| 200 |Object | |Object | |Object | |Object| |Object | 201 +-------+ +-------+ +-----------+ +------+ +--------+ 203 Figure 1: The Policy Objects Overview 205 4.1. Address Object 207 A of IPv4/IPv6 addresses or MAC addresses can be defined as an 208 address object, which may belongs to an address group object. An 209 address object consists of the following attributes: 211 4.1.1. The addressName Attribute 213 This attribute defines a unique name for the address object. 215 4.1.2. The addressRange Attribute 217 This attribute defines a set of IPv4/IPv6 addresses or MAC addresses, 218 or a range of contiguous IPv4/IPv6 addresses. 220 An IPv4 address range can be defined by one of the following 221 representations: 223 o IPv4 address with wildcard mask, e.g., 10.10.1.2\0.0.0.255. 225 o IPv4 address with subnet mask (subnet mask address or length of 226 the subnet mask), e.g., 10.10.1.2/255.255.255.0 or 10.10.1.2/32. 228 o Start address and end address of the IPv4 address range, e.g., 229 10.10.1.2-10.10.1.254. 231 An IPv6 address range can be defined by one of the following 232 representations: 234 o IPv6 address with length of the prefix, e.g., a234::120/120. 236 o Start address and end address of the IPv6 address range, e.g., 237 a231::a237-b231::b237. 239 4.2. Address Group Object 241 An address group object is comprised of several address items that 242 require the same policy enforcement. An address item can be an IPv4/ 243 IPv6 address, or a MAC address, or a range of contiguous IPv4/IPv6 244 addresses, or existing address object, or existing address group 245 object. An address group object consists of the following 246 attributes: 248 4.2.1. The addressGroupName Attribute 250 This attribute defines a unique name for the address group object. 252 4.2.2. The addressReference Attribute 254 This attribute refers to the existing address objects or existing 255 address group objects identified by their unique names. 257 4.2.3. The addressRange Attribute 259 This attribute is the same as the addressRange attribute of address 260 object. It can define a set of IPv4/IPv6 addresses or MAC addresses, 261 or a range of contiguous IPv4/IPv6 addresses. 263 An IPv4 address range can be defined by one of the following 264 representations: 266 o IPv4 address with wildcard mask, e.g., 10.10.1.2\0.0.0.255. 268 o IPv4 address with subnet mask (subnet mask address or length of 269 the subnet mask), e.g., 10.10.1.2/255.255.255.0 or 10.10.1.2/32. 271 o Start address and end address of the IPv4 address range, e.g., 272 10.10.1.2-10.10.1.254. 274 An IPv6 address range can be defined by one of the following 275 representations: 277 o IPv6 address with length of the prefix, e.g., a234::120/120. 279 o Start address and end address of the IPv6 address range, e.g., 280 a231::a237-b231::b237. 282 4.3. Service Object 284 A service object can be a single service based on IP, or ICMP, or 285 UDP, or TCP, or SCTP and it can also contain a set of services. To 286 identify services based on different protocols, different attributes 287 should be specified (see Section 4.3.2 The serviceList Attribute). 289 o IP based service is recognized by the value of the protocol field 290 in IP packet header. 292 o ICMP or ICMPv6 based service is recognized by two header fields in 293 the ICMP or ICMPv6 packets: type field and code field. 295 o UDP, TCP, or SCTP based service is recognized by port number. The 296 source port number and destination port number are used to 297 identify the sending and receiving service respectively. 299 A set of well-known services should be predefined by NSFs as service 300 objects to support direct reference. A service object consists of 301 the following attributes: 303 4.3.1. The serviceName Attribute 305 This attribute defines a unique name for the service object. 307 4.3.2. The serviceList Attribute 309 This attribute defined a set of services. Each service can be 310 defined by a subset of the following sub-attributes, according to the 311 protocol on which the service is based. 313 o For IP based service, the serviceProtocolNumber attribute should 314 be specified. 316 o For ICMP or ICMPv6 based service, the serviceICMPType attribute 317 and serviceICMPCode attribute should be specified. 319 o For UDP, TCP, or SCTP based service, the serviceSourcePort 320 attribute and serviceDestinationPort attribute should be 321 specified. 323 4.3.2.1. The serviceProtocol Attribute 325 This attribute defines the protocol type on which the service is 326 based, IP, ICMP, ICMPv6, TCP, UDP, or SCTP. 328 4.3.2.2. The serviceProtocolNumber Attribute 330 This attribute defines the protocol number for IP based service. The 331 protocol number is the value of protocol field in IP packet header 332 which identifies the corresponding upper layer protocol. For 333 example, to define a service object for IPsec Encapsulating Security 334 Payload, this attribute should be set to 50. 336 4.3.2.3. The serviceICMPType Attribute 338 This attribute defines the ICMP/ICMPv6 type number for ICMP/ICMPv6 339 based service. This attribute shall be used together with 340 serviceICMPCode attribute. For example, to define a service object 341 for IPv4 ping request, this attribute should be set to 8 and 342 serviceICMPCode attribute should be set to 0. 344 4.3.2.4. The serviceICMPCode Attribute 346 This attribute defines the ICMP/ICMPv6 message code for ICMP/ICMPv6 347 based service. This attribute shall be used together with 348 serviceICMPType attribute. For example, to define a service object 349 for IPv6 ping request, this attribute should be set to 0 and 350 serviceICMPCode should be set to 128. 352 4.3.2.5. The serviceSourcePort Attribute 354 This attribute defines the source port number for service based on 355 TCP, UDP or SCTP. The value could be a single port number which 356 identifies a single service, or a range of port numbers which 357 identify a family of services or several services in consecutive port 358 numbers. For example, to define a service object using port number 359 greater or equal to 1024 and enforce security policy on the traffic 360 that this object sends out, this attribute should be set as a port 361 range, 1024-65535. 363 4.3.2.6. The serviceDestinationPort Attribute 365 This attribute defines the destination port number for service based 366 on TCP, UDP or SCTP. The value could be a single port number or a 367 range of port numbers. For example, to define a service object for 368 HTTP and enforce security policy on the traffic that communicates 369 with this service object, this attribute should be set to 80. 371 4.4. Service Group Object 373 A service group object is a collection of service objects that 374 require the same policy enforcement. It consists of the following 375 attributes: 377 4.4.1. The serviceGroupName Attribute 379 This attribute defines a unique name for the service group object. 381 4.4.2. The serviceReference Attribute 383 This attribute refers to the existing service objects or service 384 group objects identified by their unique names. 386 4.5. Application Object 388 Due to the diversity and large amount of applications, it is not able 389 to identify a certain application based on protocol type and port 390 number. For example, there are many web applications with different 391 risk levels run on ports 80 and 443 using HTTP and HTTPS, such as web 392 gaming application and web chat application. Protocol type and port 393 number could not distinguish applications using the same application 394 protocol. In this document, category, subcategory, data transmission 395 model, vulnerability, and risk level are used to describe an 396 application. A set of well-known application objects should be 397 predefined in NSFs to support direct reference. For a newly created 398 application object, the rules for NSFs to identify this application 399 in the traffic should be configured. In this document, the 400 configuration of these rules is out of scope. An application object 401 consists of the following attributes: 403 4.5.1. The applicationName Attribute 405 This attribute defines a unique name for the application object. 407 4.5.2. The applicationCategory Attribute 409 This attribute defines the category for the application. The value 410 of this attribute is selected from a predefined set of categories, 411 e.g., general category, network category. Values of this attribute 412 are defined in Appendix A.1. Each category is broken down into 413 several subcategories. 415 4.5.3. The applicationSubCategory Attribute 417 This attribute defines the subcategory for the application. The 418 value of this attribute is selected from the predefined subcategories 419 of a category. For example, the entertainment category has seven 420 subcategories, and Facebook application belongs to social networking 421 subcategory. (See Appendix A.1 for details about subcategory and 422 examples of applications belong to each subcategory.) 424 4.5.4. The applicationTransmissionModel Attribute 426 This attribute defines the data transmission model of the 427 application. Four types of data transmission model are defined in 428 this document: client/server, browser-based, network protocol, peer- 429 to-peer. (See Appendix A.2 for more details.) 431 4.5.5. The applicationVulnerability Attribute 433 This attribute describes a set of possible threats for the 434 application. The values of this attribute are selected from a 435 predefined set of vulnerabilities, e.g., exploitable, bandwidth 436 consuming. (See Appendix A.3 for more details.) 438 4.5.6. The applicationRiskLevel Attribute 440 This attribute defines a risk level for the application. The value 441 of this attribute is selected from a predefined number of risk 442 levels, e.g., 5 risk levels. The risk level is determined by the 443 vulnerabilities of this application object. 445 4.6. Application Group Object 447 An application group object is a collection of application objects 448 that will be processed according to the same security policy. It 449 consists of the following attributes: 451 4.6.1. The applicationGroupName Attribute 453 This attribute defines a unique name for the application group 454 object. 456 4.6.2. The applicationReference Attribute 458 This attribute refers to the existing application objects or 459 application group objects identified by their unique names. 461 4.7. Schedule Object 463 A schedule object is a set of time ranges. There are two kinds of 464 time ranges: periodic time range and absolute time range. A periodic 465 time range occurs every week. An absolute time range occurs only 466 once. A schedule object consists of the following attributes: 468 4.7.1. The scheduleName Attribute 470 This attribute defines a unique name for the schedule object. 472 4.7.2. The scheduleList Attribute 474 This attribute defines a set of time ranges. A time range can be 475 defined by the following sub-attributes. 477 o For a periodic time range, the start and end time in a day, and 478 the days in a week that it takes effect, should be specified. 480 o For an absolute time range, the start time and date, and the end 481 time and date, should be specified. 483 4.7.2.1. The scheduleType Attribute 485 This attribute defines the type of a time range, periodic, absolute. 487 4.7.2.2. The scheduleStartTime Attribute 489 For a periodic time range, this attribute defines the start time in a 490 week day, such as 9:00 am. For an absolute time range, this 491 attribute defines the start time and start date, such as 00:00 am 492 2017-07-03. 494 4.7.2.3. The scheduleEndTime Attribute 496 For a periodic time range, this attribute defines the end time in a 497 week day, such as 18:00 pm. For an absolute time range, this 498 attribute defines the end time and end date, such as 23:59 pm 499 2017-07-03. 501 4.7.2.4. The scheduleWeekDay Attribute 503 This attribute defines the days in a week that the periodic time 504 range takes effect. For example, to define working hours in a week, 505 the scheduleStartTime can be set to 9:00 am, the scheduleEndTime can 506 be set to 18:00 pm, and this attribute should contain fives days, 507 from Monday to Friday. 509 4.8. User Object 511 A user object identifies a person who may access network resources. 512 It is the basis of implementing user-based policy control. The user 513 objects may be created locally on the NSFs, or be imported from third 514 parties, such as authentication servers. User objects that require 515 the same policy enforcement are grouped as user group objects or 516 security group objects. The user group objects are organized as a 517 hierarchical structure, See Figure 2. A security group object 518 consists of user objects from different user group objects that 519 require the same policy enforcement. 521 +---------------------------+ 522 | UserGroup_3 | 523 +---------------------------+ 524 | | 525 | | 526 +--------------+ +--------------+ 527 | UserGroup_1 | | UserGroup_2 | 528 +--------------+ +--------------+ 529 | | | | 530 | | | | 531 +--------+ +--------+ +--------+ +--------+ 532 | User_1 | | User_2 | | User_a | | User_b | 533 +--------+ +--------+ +--------+ +--------+ 535 Figure 2: Hierarchical Structure of User Group 537 A user object consists of the following attributes: 539 4.8.1. The userName Attribute 541 This attribute refers to the user name that used for user 542 authentication. 544 4.8.2. The userParentGroup Attribute 546 This attribute refers to the existing parent user group object to 547 which this user object belongs. The parent user group object is 548 identified by its unique name. A user object can only belong to one 549 user group object. 551 4.8.3. The userSecurityGroup Attribute 553 This attribute refers to the existing security group object to which 554 this user object belongs. The security user group object is 555 identified by its unique name. A user object can belong to several 556 security group objects. 558 4.8.4. The userDomain Attribute 560 This attribute refers to the authentication domain to which this user 561 object belongs. 563 4.8.5. The userPassword Attribute 565 If user is authenticated locally on the NSF, this attribute is 566 mandatory. It defines the password corresponding to the user name. 568 4.8.6. The userExpirationTime Attribute 570 This attribute defines when will this user object expire. 572 4.9. User Group Object 574 A user object group is a collection of user objects that require the 575 same policy enforcement and it usually corresponds to a physical 576 entity such as a department. The user group objects are organized as 577 a hierarchical structure. A user group object may belong to another 578 user group object. The user group objects may be created locally on 579 the NSFs, or be imported from third parties, such as authentication 580 servers. It consists of the following attributes: 582 4.9.1. The userGroupName Attribute 584 This attribute defines a unique name for the user group object. 586 4.9.2. The userGroupParentGroup Attribute 588 This attribute refers to the existing parent user group object to 589 which this user group object belongs. The parent user group object 590 is identified by its unique name. A user group object can only 591 belong to one parent user group object. 593 4.9.3. The userGroupDomain Attribute 595 This attribute refers to the authentication domain to which this user 596 group object belongs. 598 4.9.4. The userGroupReference Attribute 600 This attribute refers to the existing user objects or user group 601 objects which belong to this user group object. 603 4.10. Security Group Object 605 A security group object consists of user objects from different user 606 group objects that require the same policy enforcement. The security 607 group objects may be created locally on the NSFs, or be imported from 608 third parties, such as authentication servers. This attribute 609 consists of the following attributes: 611 4.10.1. The securityGroupName Attribute 613 This attribute defines a unique name for the security group object. 615 4.10.2. The securityGroupParentGroup Attribute 617 This attribute refers to the existing parent security group objects 618 to which this security group object belongs. The parent security 619 group objects are identified by their unique names. 621 4.10.3. The securityGroupDomain Attribute 623 This attribute refers to the authentication domain to which this 624 security group object belongs. 626 4.10.4. The securityGroupType Attribute 628 This attribute defines the type of the security group object. There 629 are two types: static and dynamic. For static security group, the 630 member objects are fixed and added as required. For dynamic security 631 group, the member objects are dynamically generated by setting 632 filtering rules. 634 4.10.5. The securityGroupReference Attribute 636 This attribute defines the member objects for static security group 637 object. It refers to the existing user objects or security group 638 objects which belong to this security group object. 640 4.10.6. The securityGroupFilters Attribute 642 This attribute defines the filtering rules for dynamic security group 643 object. 645 5. Acknowledgements 647 6. IANA Considerations 649 This document requires no IANA actions. 651 7. Security Considerations 653 When the policy objects are transmitted, the integrity of these 654 policy objects should be guaranteed. NSFs should verify that the 655 modifications of policy objects come from the authenticated security 656 controller. And NSF should protect the stored policy objects from 657 being tampered. 659 8. References 661 8.1. Normative References 663 [I-D.ietf-i2nsf-capability] 664 Xia, L., Strassner, J., Basile, C., and D. Lopez, 665 "Information Model of NSFs Capabilities", 2017, 666 . 669 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 670 Requirement Levels", BCP 14, RFC 2119, 671 DOI 10.17487/RFC2119, March 1997, 672 . 674 8.2. Informative References 676 [I-D.ietf-i2nsf-framework] 677 Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 678 Kumar, "Framework for Interface to Network Security 679 Functions", 2017, . 682 [I-D.ietf-i2nsf-terminology] 683 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 684 Birkholz, "Interface to Network Security Functions (I2NSF) 685 Terminology", 2017, . 688 Appendix A. Application Attributes 690 An application object is described by five items, category, 691 subcategory, data transmission model, vulnerability and risk level. 692 This appendix illustrates the possible values of applicationCategory 693 attribute, applicationSubCategory attribute, 694 applicationTransmissionModel attribute and applicationVulnerability 695 attribute. 697 A.1. Category and Subcategory 699 This section lists the possible values for applicationCategory 700 attribute and applicationSubCategory attribute. 702 +-------------------+------------------------+------------------------+ 703 | Category | Subcategory | Example | 704 +-------------------+------------------------+------------------------+ 705 | General | General_TCP | TCP-based applications | 706 | | General_UDP | UDP-based applications | 707 | | Other | Error_Packets | 708 +-------------------+------------------------+------------------------+ 709 | Network | IP_Protocol | ICMP, IGMP, OSPF | 710 | | Encrypted_Tunnel | GRE, L2TP, IKEv2 | 711 | | Infrastructure | FTP, HTTP, DNS | 712 | | Proxy | HTTP_Proxy | 713 | | Network_Admin | Syslog | 714 +-------------------+------------------------+------------------------+ 715 | General_Internet | Search_Engine | www.google.com | 716 | | Web_Content_Aggregate | FeedReader | 717 | | Utility | Google Earth | 718 | | Web_Desktop | Zimbra Desktop | 719 | | Browser_Plugin | Adobe | 720 | | File_Sharing | XDCC | 721 | | FileShare_P2P | BT, Thunder | 722 | | Network_Storage | DBank | 723 | | App_Download | AndroidMarket | 724 | | Software_Update | WindowsUpdate | 725 | | Web_Browsing | OperaMobile | 726 +-------------------+------------------------+------------------------+ 727 | Entertainment | Social_Networking | Facebook, Twitter | 728 | | Instant_Messaging | QQ, MSN | 729 | | Media_Sharing | RayV | 730 | | Peer_Casting | QQLive | 731 | | Web_Video | YouKu, YouTube | 732 | | Game | QQGame | 733 | | VoIP | Skype | 734 +-------------------+------------------------+------------------------+ 735 | Business_Systems | Electronic_Business | Taobao | 736 | | Remote_Access | Radmin | 737 | | Database | Oracle | 738 | | Finance | DaZhiHui, Fix | 739 | | Enterprise_Application | LotusNotes | 740 | | Internet_Conferencing | NetMeeting | 741 | | Data_Backup | Rsync | 742 | | Email | GMail | 743 +-------------------+------------------------+------------------------+ 745 A.2. Data Transmission Model 747 This section lists four types of models for 748 applicationTransmissionModel attribute. 750 +------------------+----------------------------------------------------+ 751 | Model | Description | 752 +------------------+----------------------------------------------------+ 753 | Client/Server | One or more client applications communicate with a | 754 | | communicate with a sever | 755 +------------------+----------------------------------------------------+ 756 | Browser-Based | Applications run on web browser | 757 +------------------+----------------------------------------------------+ 758 | Network Protocol | Applications that is used for system-to-system | 759 | | communication | 760 +------------------+----------------------------------------------------+ 761 | Peer-to-Peer | Applications directly communicate with each other | 762 +------------------+----------------------------------------------------+ 764 A.3. Vulnerability 766 This section lists five types of possible risks for 767 applicationVulnerabiltiy attribute. 769 +---------------------+-------------------------------------------------+ 770 | Vulnerability | Description | 771 +---------------------+-------------------------------------------------+ 772 | Exploitable | Has known vulnerabilities | 773 +---------------------+-------------------------------------------------+ 774 | Evasive | Used to evade the original purpose and traverse | 775 | | the firewall, for example, a proxy software | 776 +---------------------+-------------------------------------------------+ 777 | Data Loss | Used for transferring files or uploading texts, | 778 | | may cause information leaks | 779 +---------------------+-------------------------------------------------+ 780 | Used by Malware | Used by malware for propagation, attack, or | 781 | | data theft, or distributed with malware | 782 +---------------------+-------------------------------------------------+ 783 | Bandwidth Consuming | Consume large bandwidths | 784 +---------------------+-------------------------------------------------+ 786 Appendix B. Example of Application Scenario for Policy Object 788 This appendix describes the utilization of policy objects in policy 789 rules for enterprise scenario. 791 NSFs are key components to protect security in enterprise network. 792 For the typical architecture of an enterprise network, NSFs are 793 deployed on-premise at network perimeter. The inbound and outbound 794 traffic of the enterprise network are processed according to the 795 predefined security policies rules. 797 Figure 3 demonstrates an example of enterprise network topology. 798 Firewall is a typical NSF that used at the network perimeter to 799 protect enterprise intranet. Assuming that the firewall should be 800 provisioned to provide different network access controls for 801 marketing departments and R&D departments. 803 o Marketing departments are allowed to access the Internet website 804 but could not use entertainment applications such as online games, 805 instant messaging software, in work day. 807 o R&D departments are not allowed to access the Internet. But 808 managers of R&D departments have Internet access. 810 For Internet users who want to access the public website of this 811 enterprise, they are only allowed to access the servers deployed in 812 DMZ. 814 +----------+ 815 | Internet | 816 +----------+ 817 | 818 +--------+ 819 | Router | 820 +--------+ 821 | 822 +-----------------------------------+ 823 | Firewall | 824 +-----------------------------------+ 825 | 826 +-----------------------------------+ +--------+ +-----+ 827 | Core Layer Switch |---| Switch |---| DMZ | 828 +-----------------------------------+ +--------+ +-----+ 829 / \ 830 +-----------------+ +-----------------+ 831 | Aggregation | | Aggregation | 832 | Layer Switch | | Layer Switch | 833 +-----------------+ +-----------------+ 834 / \ / \ 835 +--------------+ +--------------+ +--------------+ +--------------+ 836 | Access Layer | | Access Layer | | Access Layer | | Access Layer | 837 | Switch | | Switch | | Switch | | Switch | 838 +--------------+ +--------------+ +--------------+ +--------------+ 839 | | | | 840 +--------------+ +--------------+ +--------------+ +--------------+ 841 | Marketing | | Marketing | | R&D | | R&D | 842 | Department A | | Department B | | Department A | | Department B | 843 +--------------+ +--------------+ +--------------+ +--------------+ 845 Figure 3: A Typical Architecture of Enterprise Network 847 To set security policy rules for this scenario, the following policy 848 objects should be created. 850 +--------------------+----------------------------------------------+ 851 | Policy Object Name | Description | 852 +--------------------+----------------------------------------------+ 853 | Marketing_A | User group object for Marketing Department A | 854 +--------------------+----------------------------------------------+ 855 | Marketing_B | User group object for Marketing Department B | 856 +--------------------+----------------------------------------------+ 857 | R&D_A | User group object for R&D Department A | 858 +--------------------+----------------------------------------------+ 859 | R&D_B | User group object for R&D Department B | 860 +--------------------+----------------------------------------------+ 861 | R&D_Manager | Security group object for managers of R&D | 862 | | Department A and R&D Department B | 863 +--------------------+----------------------------------------------+ 864 | Entertainment_App | Application group object for all recognized | 865 | | entertainment applications | 866 +--------------------+----------------------------------------------+ 867 | Server_Address | Address object for servers in DMZ | 868 +--------------------+----------------------------------------------+ 869 | Web_Service | Service object for HTTP, HTTPS protocols | 870 +--------------------+----------------------------------------------+ 871 | Work_Day | Schedule object for five week days | 872 +--------------------+----------------------------------------------+ 874 B.1. Security Policy Control for Marketing Departments 876 For traffic from marketing departments to Internet, the following 877 policy objects can be used as conditions to filter traffic. 879 +--------------------------------------+--------+ 880 | Policy Objects used in Condition | Action | 881 +--------------------------------------+--------+ 882 | User Group: Marketing_A, Marketing_B | Deny | 883 | Application Group: Entertainment_App | | 884 | Schedule: Work_Day | | 885 +--------------------------------------+--------+ 886 | User Group: Marketing_A, Marketing_B | Permit | 887 | Service: Web_Service | | 888 +--------------------------------------+--------+ 890 B.2. Security Policy Control for R&D Departments 892 For traffic from R&D departments to Internet, the following policy 893 objects can be used as conditions to filter traffic. 895 +--------------------------------------+--------+ 896 | Policy Objects used in Condition | Action | 897 +--------------------------------------+--------+ 898 | Security Group: R&D_Manager | Permit | 899 +--------------------------------------+--------+ 900 | User Group: R&D_A, R&D_B | Deny | 901 +--------------------------------------+--------+ 903 B.3. Security Policy Control for Server Access of Internet Users 905 For traffic from Internet to web servers deployed in DMZ, the 906 following policy objects can be used as conditions to filter traffic. 908 +--------------------------------------+--------+ 909 | Policy Objects used in Condition | Action | 910 +--------------------------------------+--------+ 911 | Address: Server_Address | Permit | 912 +--------------------------------------+--------+ 914 Authors' Addresses 916 Liang Xia 917 Huawei 918 101 Software Avenue, Yuhuatai District 919 Nanjing, Jiangsu 210012 920 China 922 Email: Frank.xialiang@huawei.com 924 Qiushi Lin 925 Huawei 926 Huawei Industrial Base 927 Shenzhen, Guangdong 518129 928 China 930 Email: linqiushi@huawei.com