idnits 2.17.1 draft-you-i2nsf-user-group-based-policy-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 (July 8, 2016) is 2848 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 7297 == Outdated reference: A later version (-10) exists of draft-ietf-i2nsf-framework-02 == Outdated reference: A later version (-16) exists of draft-ietf-i2nsf-problem-and-use-cases-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2nsf Working Group J. You 3 Internet-Draft Huawei 4 Intended status: Standards Track M. Zarny 5 Expires: January 9, 2017 Goldman Sachs 6 C. Jacquenet 7 M. Boucadair 8 France Telecom 9 Y. Li 10 J. Strassner 11 Huawei 12 S. Majee 13 F5 Networks 14 July 8, 2016 16 User-group-based Security Policy for Service Layer 17 draft-you-i2nsf-user-group-based-policy-02 19 Abstract 21 This draft defines the User-group Aware Policy Control (UAPC) 22 framework, which facilitates consistent enforcement of security 23 policies based on user group identity. Policies are used to control 24 security policy enforcement using a policy server and a security 25 controller. Northbound APIs are also discussed. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 9, 2017. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.1. Abbreviations and acronyms . . . . . . . . . . . . . . . 4 70 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Use Cases for User-group Aware Policy Control . . . . . . . . 5 72 4. User-group Aware Policy Control . . . . . . . . . . . . . . . 6 73 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 74 4.2. Functional Entities . . . . . . . . . . . . . . . . . . . 7 75 4.3. User Group . . . . . . . . . . . . . . . . . . . . . . . 9 76 4.4. Inter-group Policy Enforcement . . . . . . . . . . . . . 10 77 4.5. UAPC Implementation . . . . . . . . . . . . . . . . . . . 12 78 5. Requirements for I2NSF . . . . . . . . . . . . . . . . . . . 13 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 84 9.2. Informative References . . . . . . . . . . . . . . . . . 14 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 87 1. Introduction 89 In traditional networks, network access is typically controlled 90 through a combination of mechanisms such as maintaining separate 91 static VLAN/IP subnet assignments per organization, applying Access 92 Control Lists (ACLs) on VLANs and/or IP subnets, leveraging Network 93 Access Control (NAC). Common side effects are: 95 o Network administrators typically assume that users access the 96 network from their own static location--from their assigned 97 switch, VLAN, IP subnet, etc. 99 o MAC or IP address of the users' device is often used as a proxy 100 for the user's identity. As such, filtering (e.g., via ACLs) of 101 the user is usually based on IP or MAC addresses. 103 o Authentication of the user by the network, if it exists at all, 104 typically takes place only at the access switch in conjunction 105 with an AAA (Authentication, Authorization, Accounting) server. 106 Different authentication mechanisms could be used - from machine- 107 based certificates to username/password challenges, to just 108 "authenticating" on MAC addresses, etc. 110 o Network security functions such as firewalls often act only on 111 IP addresses and ports - not on the user's identity. 113 These are all symptoms of a system not using actual user 114 identification information, but rather, one or more attributes that 115 attempt to represent a user identity. 117 Traditional network access control mechanisms 118 [I-D.ietf-i2nsf-problem-and-use-cases] do not work well in newer 119 network paradigms. 121 o First, both clients and servers can move and change their IP 122 addresses on a regular basis. For example, Wi-Fi and VPN clients, 123 as well as back-end Virtual Machine (VM)-based servers, can move; 124 their IP addresses could change as a result. This means relying 125 on well-known network fields (e.g., the 5-tuple) is increasingly 126 inadequate to ensure consistent security policy enforcement. 128 o Secondly, with more people working from non-traditional office 129 setups like "working from home", there is now a need to be able to 130 apply different security policies to the same set of users under 131 different circumstances. Network access needs to be granted based 132 on such criteria as users' location, time-of-day, type of network 133 device used (e.g., corporate issued device versus personal 134 device), device's security posture, etc. This means the network 135 needs to recognize the users' identity and their current context, 136 and map the users to their correct access entitlement to the 137 network. 139 o Moreover, implementation of coherent security policy across 140 several network and network security devices is almost impossible. 141 NSFs in operation could be sourced from different vendors, or 142 could be different hardware models/software versions by the same 143 vendor. As a result, the capabilities as well as APIs of the NSFs 144 may not be the same throughout the environment. Finally, few 145 enterprises, if any, have a complete view of all the application 146 flows. It is not uncommon for administrators to update a policy 147 on a firewall, only to later find out that related ACLs, firewall 148 policies, and other related mechanisms were not updated. 150 Today, addressing the above issues takes considerable time and 151 effort. Most network administrators have to manually plan and 152 implement necessary changes as little automation, if any, exists 153 across diverse sets of network security platforms. In line with the 154 I2NSF effort to standardize APIs so as to facilitate automation, this 155 draft defines User-group Aware Policy Control (UAPC), which 156 facilitates consistent enforcement of policies based on user-group 157 identity, and discusses how it operates in the I2NSF Service Layer 158 [I-D.ietf-i2nsf-framework]. 160 2. Terminology 162 2.1. Abbreviations and acronyms 164 AAA: Authentication, Authorization, and Accounting 166 ACL: Access Control List 168 ADSL: Asymmetric Digital Subscriber Line 170 AP: Access Point 172 LTE: Long Term Evolution 174 NAC: Network Admission Control 176 NBI: Northbound Interface 178 NSF: Network Security Function 180 UAPC: User-group Aware Policy Control 182 VLAN: Virtual Local Area Network 184 2.2. Definitions 186 User: An individual or a group of individuals that act as a single 187 entity. 189 User-group: A group of users that share one or more 190 characteristics and/or behaviors in common, which allows each user 191 in the user-group to be assigned the same access control 192 permissions. For example, sales employees are treated with 193 equivalent service policy rules when accessing the network. 195 Profile: A set of capabilities, in terms of functions and 196 behaviors, for a given entity or set of entities. 198 Role: A role defines a set of responsibilities of an object that 199 it is attached to. This enables the functions and behavior of a 200 complex object to be abstracted into just those that are required 201 by a client in a particular context. 203 User-group Identifier (User-group ID): An identifier that 204 represents the collective identity of a group of users, and is 205 determined by a set of one or more matching criteria (e.g., roles, 206 4-, 5-, and 6-tuples, VLAN ID, etc.) that disambiguates this user- 207 group entity from other entities. 209 3. Use Cases for User-group Aware Policy Control 211 With the increased popularity of enterprise wireless networks and 212 remote access technologies such as Virtual Private Networks (VPN), 213 enterprise networks have become borderless, and employees' locations 214 can be anywhere. Enabling large-scale employee mobility across many 215 access locations improves enterprise production efficiency but also 216 introduces challenges related to enterprise network management and 217 security. The IP address of the user can change frequently when the 218 user is in motion. Consequently, IP address-based policies (such as 219 forwarding, routing, QoS and security policies) may not be flexible 220 enough to accommodate users in motion. 222 The User-group Aware Policy Control (UAPC) approach is intended to 223 facilitate the consistent enforcement of policies. As shown in 224 Figure 1, a multi-technology network (e.g., Wi-Fi, 3G/LTE, ADSL and 225 fiber infrastructures) can connect different types of terminal 226 devices (e.g., Smartphone, tablet, and laptop) which should be able 227 to access networks in a secure manner. Security policies should be 228 consistently enforced based on their user-group identities, 229 regardless of whether these terminal devices connect to a wired or a 230 wireless infrastructure. 232 +--------------------+ 233 | PDP | 234 | (policy, security, | 235 | management) | 236 +---+--------------+-+ 237 | | 238 | | 239 | UAPC | 240 | | 241 | | 242 +--------------+ +----------+---+ +---+----------+ 243 |+------------+| | | | | 244 ||smartphone || | | | | 245 |+------------+| | 3G/LTE | | | 246 |+------------+| | | | Data | 247 || tablet || | Pulic WiFi | | | 248 |+------------+| | | | Center | 249 |+------------++-------+ ADSL +------+ | 250 || laptop || | | | | 251 |+------------+| | AP | | | 252 |+------------+| | | | | 253 || PC || | ... | | | 254 |+------------+| | | | | 255 | | | Access | | Enterprise | 256 | Devices | | Networks | | HQ | 257 +--------------+ +--------------+ +--------------+ 259 Figure 1: UAPC Framework Example 261 4. User-group Aware Policy Control 263 4.1. Overview 265 The UAPC framework is as follows enables users to be authenticated 266 and classified into different user-groups at the network ingress by 267 the Security Controller; this may require obtaining information from 268 the Policy Server and an AAA server. The user-group is an identifier 269 that represents the collective identity of a group of users, and is 270 determined by a set of pre-defined policy criteria (e.g., source IP 271 address, geo-location data, time of day, or device certificate). 272 Users may be moved to different user-groups if their composite 273 security context and/or environment change. 275 The Security Controller, if necessary, pushes the required user-group 276 policies to all Network Security Functions (NSFs) that need them. 277 The policies are expressed as user-group (not IP or MAC address) IDs 278 so as to decouple the user identity from the network addresses of the 279 user's device. 281 (Note that User-group IDs may be implemented in at least two ways: 282 (1) the ingress switch inserts the user-group ID into the packets, 283 and downstream NSFs match and act on the user-group ID, or (2) the 284 Security Controller updates each NSF with the mapping between the 285 user-group IDs and the packet tuples; NSFs map incoming packets to 286 their rightful user-group IDs, and act on the user-group IDs. These 287 and other implementation methodologies are out of scope of this 288 document.) 290 The security policy provisioning information can be derived from the 291 user's profile and credentials, as well as the group to which the 292 user belongs; such information can also be derived from the outcomes 293 of the dynamic security service parameter negotiation that could 294 possibly take place between the user and the service provider or the 295 network administrator (e.g., parameters like whether the user is 296 entitled to access the enterprise network while in motion or not, the 297 lease time associated to an IP address, whether the user can access 298 the Internet or not, and whether traffic needs to be encrypted or 299 not). This information is transferred to the Network Security 300 Functions (NSF) from the controller. Once an incoming packet matches 301 a certain user group on the NSF, the corresponding security policy 302 will be enforced on that packet. 304 4.2. Functional Entities 306 The UAPC framework consists of four main components: (1) Policy 307 Server, (2) Authentication Server, (3) Security Controller, (4) 308 Network Security Functions: 310 o Policy Server 312 The Policy Server houses two policy databases: (1) the user-group 313 criteria, which assigns users to their user-group, and (2) the rule 314 base of what each user group has access to. 316 - Contains (G)UI and/or APIs to enable policies to be created, 317 modified, and deleted using command line, graphical tools, and/or 318 programming logic 320 - Contains logic to create, read, update, and delete policies and 321 policy components, and apply policies to user-groups from one or 322 more policy repositories 324 - Contains logic to detect conflicts between policies 326 - Contains logic to resolve conflicts between policies 327 - Contains logic to broker and/or federate policies between 328 domains 330 The above subjects are beyond the scope of this document. 332 o AAA Server 334 The AAA Server authenticates users, and then performs associated 335 authorization and accounting functions. The AAA server classifies 336 users into different user-groups at the network ingress. AAA server 337 implementation details are out of scope for this document. 339 o Security Controller 341 The Security Controller coordinates various network security-related 342 tasks on a set of NSFs under its administration. In general, there 343 may be multiple security domains, where each domain has its own 344 security controller. The detailed architecture is beyond the scope 345 of this document. 347 - Authenticates the user at the ingress using an authentication 348 service. While the authentication functionality is an integral 349 part of the framework, the topics of defining and managing 350 authentication rules are out of scope of this document. 352 - Asks policy server for decisions to security-related requests; 353 takes these decisions and invokes the set of NSFs that are 354 required to implement security for that particular packet. The 355 security controller may cache policies. 357 - May perform additional actions as specified by the metadata 358 associated with a policy rule (e.g., the "function(s)" to be 359 executed after the actions in a policy rule are executed) 361 - Has an authoritative database of NSFs under its administration 363 - Determines on which NSFs a given policy needs to be enforced 365 - Presents a set of NBIs for applications, orchestration engines, 366 etc. 368 - Interfaces with NSFs via (to-be-developed) I2NSF Capability 369 Layer APIs. 371 o Network Security Functions 373 - Packet classification: Depending on the implementation model, 374 the NSF may match on User-group IDs in the packets; or it may 375 match on common packet header fields such as the 5-tuple, and map 376 the n-tuple to the appropriate User-group ID supplied out-of-band 377 by the Security Controller. 379 - Policy enforcement: Enforce the corresponding policy (or set of 380 policies) if the packet matches a specified User-group ID or set 381 of User-group IDs 383 - Presents I2NSF Capability Layer APIs 385 4.3. User Group 387 The user-group is an identifier that represents the collective 388 identity of a group of users, whose definition is controlled by one 389 or more policy rules (e.g., source IP, geo-location, time of day, and 390 device certificate). 392 A given user is authenticated, and classified at the network ingress, 393 and assigned to a user-group. (The term "user" refers to any user of 394 the network. As such, servers, terminals and other devices are also 395 classified and assigned to their respective user-groups.) A user's 396 group membership may change as aspects of the user change. For 397 example, if the user-group membership is determined solely by the 398 source IP address, then a given user's user-group ID will change when 399 the user moves to a new IP address that falls outside of the range of 400 addresses of the previous user-group. 402 Table 1 shows an example of how user-group definitions may be 403 constructed. User-groups may share several common criteria. That 404 is, user-group criteria are not mutually exclusive. For example, the 405 policy criteria of user-groups R&D Regular and R&D-BYOD may share the 406 same set of users that belong to the R&D organization, and differ 407 only in the type of client (firm-issued clients versus users' 408 personal clients); likewise, the same user may be assigned to 409 different user-groups depending on the time of day or the type of day 410 (e.g., weekdays versus weekends); and so on. 412 Table 1: User-Group Example 413 +--------------+------------+--------------------------------+ 414 | Group Name | Group ID | Group Definition | 415 +--------------+------------+--------------------------------+ 416 | R&D | 10 | R&D employees | 417 +--------------+------------+--------------------------------+ 418 | R&D BYOD | 11 | Personal devices of R&D | 419 | | | employees | 420 +--------------+------------+--------------------------------+ 421 | Sales | 20 | Sales employees | 422 +--------------+------------+--------------------------------+ 423 | VIP | 30 | VIP employees | 424 +--------------+------------+--------------------------------+ 425 | Workflow | 40 | IP addresses of Workflow | 426 | | | resource servers | 427 +--------------+------------+--------------------------------+ 428 | R&D Resource | 50 | IP addresses of R&D resource | 429 | | | servers | 430 +--------------+------------+--------------------------------+ 431 |Sales Resource| 54 | IP addresses of Sales resource | 432 | | | servers | 433 +--------------+------------+--------------------------------+ 435 4.4. Inter-group Policy Enforcement 437 Within the UAPC framework, inter-group policy enforcement requires 438 two key components: (1) user-group-to-user-group access policies, and 439 (2) sets of NSFs that are managed by sets of policies. 441 First, the framework calls for an authoritative rule-base that lists 442 all the destination user-groups to which all the source user-groups 443 are entitled to access. The rule-base, hosted on the Policy Server, 444 enables administrators to construct authorized inter-group access 445 relationships. The simple example in Table 2 shows a policy matrix 446 in which the row represents source user-groups and the column 447 represents destination ones. The inter-group rule-base is similar to 448 firewall rule-bases, which are mostly made up of 5-tuples. (Firewall 449 rule-bases could and do include criteria other than the standard 450 5-tuple. Also, the user-group rule-base could consist of other 451 criteria. Actual implementation details are out of scope of this 452 document.) 454 The responsibility of implementing and managing the inter-group 455 policies falls to the Security Controller. The controller first 456 needs to determine, (or is told) the specific NSFs on which a given 457 policy is to be implemented. The controller then communicates with 458 each NSF via the I2NSF APIs to execute the required tasks. 460 Table 2: Inter-group Policy Example 461 +-----------------+----------------------------------------------+ 462 | | Destination Group | 463 | +-------------+----------------+---------------+ 464 | | Workflow | R&D Resource | Sales Resource| 465 |Source Group | Group | Group | Group | 466 +-----------------+-------------+----------------+---------------+ 467 | R&D group | Permit | Permit | Deny | 468 +-----------------+-------------+----------------+---------------+ 469 | R&D BYOD group |Traffic-rate | Deny | Deny | 470 +-----------------+-------------+----------------+---------------+ 471 | Sales group | Permit | Deny | Permit | 472 +-----------------+-------------+----------------+---------------+ 473 | VIP user group |Traffic-mark | Traffic-mark | Traffic-mark | 474 +-----------------+-------------+----------------+---------------+ 476 Inter-user-group rules are configurable. Figure 2 illustrates how 477 various user-groups and their entitlements may be structured. The 478 example shows a "north-south" model that shows how users may access 479 internal network resources. Similar models can be developed for 480 "east-west" intra-data center traffic flows. 482 +---------------------------------+ 483 | Authentication Domain | 484 |+------------------------------+ | 485 || DemilitarizedZone | | 486 ||+---------------------------+ | | 487 ||| General Service | | | 488 Common BYOD |||+------------------------+ | | | 489 User --------++++ Common Service | | | | 490 ||||+---------------------+ | | | | 491 Guest--------++|||Limited Service | | | | | 492 |||||+------------------+ | | | | | 493 Insecure ||||||Important Service +-+-+-+-+-+-- Partner 494 User -----+||||| +------------+ | | | | | | 495 |||||| |Core Service+-+-+-+-+-+-+-- Executive 496 User at ---+++++| +------------+ +-+-+-+-+-+-- User at office 497 non-office |||||+------------------+ | | | | | hours 498 hours ||||+---------------------+ | | | | 499 |||+------------------------+ | | | 500 ||+---------------------------+ | | 501 |+------------------------------+ | 502 +---------------------------------+ 504 Unauthorized user (X) 505 User using an unregistered device (X) 507 Figure 2: Sample Authorization Rules for User-group Aware Policy Control 508 4.5. UAPC Implementation 510 The security policies are instantiated and maintained by the policy 511 server. The associated computation logic (to instantiate such 512 policies) may be dynamically fed with instructions coming from the 513 application. The policy decisions could also be from the outcomes of 514 dynamic security service parameter negotiations that typically take 515 place at the management plane between the user and the service 516 provider [RFC7297]. 518 The NSFs receive group-based policy provisioning information from the 519 security controller. The security policies will be enforced so that 520 participating NSFs can process traffic accordingly. There are five 521 steps for implementing the UAPC framework, which are shown in 522 Figure 3. 524 +-----------------+ 525 | Orchestrator | 526 +-+-------------+-+ 527 | | 528 ======================|=============|============== 529 +----+---+ ++---------+ 530 | Policy +--------+Security | 531 (Step 1)| Server | +----+Controller| 532 +----+---+ | +-+---+----+ 533 | | | | 534 +----+-------+-+ | | 535 | AAA | | | 536 | Server | | | 537 +--------------+ | | 538 | | (Step 2) 539 | | 540 (Step 4) +------+-+ | 541 ---------------- 542 (Step 3) ///// | | | \\\\\ 543 +-------------+ /// | | | \\\ 544 Site1|Wireless User+-------- | | | \\ 545 +-------------+ || +--+-+ +--+-+ +-+--+ || 546 +-------------+ | | | | | | | | 547 Site2|Wired User +--+ |NSFs| |NSFs| |NSFs| | 548 +-------------+ | | | | | | | | 549 +-------------+ || +----+ +----+ +----+ || 550 Site3|Remoter User +------- (Step 5) // 551 +-------------+ \\\ /// 552 \\\\\ ///// 553 ---------------- 555 Figure 3: Unified Policy Procedures 557 1. User-group identification policies and inter-user-group access 558 polices on the Policy Server are managed by authorized user(s) 559 and/or team(s). 561 2. The user-group-based policies are implemented on the NSFs 562 under the Security Controller's management. 564 3. When a given user first comes logs onto the network, the user 565 is authenticated at the ingress switch. 567 4. If the authentication is successful, the user is placed in a 568 user-group, as determined by the Policy Server. If the 569 authentication is not successful, then the user is not assigned a 570 user-group, which means that the user has no access permissions 571 for the network. 573 5. The user's subsequent traffic is allowed or permitted based on 574 the user-group ID by the NSFs per the inter-user-group access 575 policies. (It is beyond the scope of this document as to how 576 user-group IDs may be delivered to non-ingress NSFs. See 577 Section 4.1 for a brief overview of possible implementation 578 methods.) 580 5. Requirements for I2NSF 582 Key aspects of the UAPC framework fall within the Service Layer of 583 the I2NSF charter. If the community adopts the approach as one 584 possible framework for the Service Layer, the I2NSF Service Layer 585 MUST support at least the following northbound APIs (NBIs): 587 o The user-group classification policy database on the Policy 588 Server 590 o The inter-user-group access policy rule-base on the Policy 591 Server 593 o The inventory of NSFs under management by the Security 594 Controller 596 o The list of NSFs on which a given inter-user-group policy is to 597 be implemented by the Security Controller. 599 The framework also assumes that the I2NSF Capability Layer APIs will 600 be there for the NSFs. 602 6. Security Considerations 604 This document provides the UAPC framework, and discusses how it 605 operates in the I2NSF Service Layer. It is not intended to represent 606 any particular system design or implementation, nor does it define a 607 protocol, and as such it does not have any specific security 608 requirements. 610 7. IANA Considerations 612 This document has no actions for IANA. 614 8. Acknowledgements 616 The editors would like to thank Linda Dunbar for a thorough review 617 and useful comments. 619 9. References 621 9.1. Normative References 623 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 624 Requirement Levels", BCP 14, RFC 2119, 625 DOI 10.17487/RFC2119, March 1997, 626 . 628 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 629 Connectivity Provisioning Profile (CPP)", RFC 7297, 630 DOI 10.17487/RFC7297, July 2014, 631 . 633 9.2. Informative References 635 [I-D.ietf-i2nsf-framework] 636 elopez@fortinet.com, e., Lopez, D., Dunbar, L., Strassner, 637 J., Zhuang, X., Parrott, J., Krishnan, R., and S. Durbha, 638 "Framework for Interface to Network Security Functions", 639 draft-ietf-i2nsf-framework-02 (work in progress), July 640 2016. 642 [I-D.ietf-i2nsf-problem-and-use-cases] 643 Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C. 644 Jacquenet, "I2NSF Problem Statement and Use cases", draft- 645 ietf-i2nsf-problem-and-use-cases-00 (work in progress), 646 February 2016. 648 Authors' Addresses 650 Jianjie You 651 Huawei 652 101 Software Avenue, Yuhuatai District 653 Nanjing, 210012 654 China 656 Email: youjianjie@huawei.com 658 Myo Zarny 659 Goldman Sachs 660 30 Hudson Street 661 Jersey City, NJ 07302 662 USA 664 Email: myo.zarny@gs.com 666 Christian Jacquenet 667 France Telecom 668 Rennes 35000 669 France 671 Email: christian.jacquenet@orange.com 673 Mohamed Boucadair 674 France Telecom 675 Rennes 35000 676 France 678 Email: mohamed.boucadair@orange.com 680 Yizhou Li 681 Huawei 682 101 Software Avenue, Yuhuatai District 683 Nanjing, 210012 684 China 686 Email: liyizhou@huawei.com 687 John Strassner 688 Huawei 689 2330 Central Expressway 690 San Jose, CA 691 USA 693 Email: john.sc.strassner@huawei.com 695 Sumandra Majee 696 F5 Networks 697 3545 N 1st St 698 San Jose, CA 95134 700 Email: S.Majee@f5.com