idnits 2.17.1 draft-ietf-i2nsf-terminology-06.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 2, 2018) is 2115 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-14 == Outdated reference: A later version (-16) exists of draft-ietf-sacm-terminology-14 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 I2NSF S. Hares 2 Internet-Draft J. Strassner 3 Intended status: Informational Huawei 4 Expires: July 06, 2018 D. Lopez 5 Telefonica I+D 6 L. Xia 7 Huawei 8 H. Birkholz 9 Fraunhofer SIT 10 July 2, 2018 12 Interface to Network Security Functions (I2NSF) Terminology 13 draft-ietf-i2nsf-terminology-06.txt 15 Abstract 17 This document defines a set of terms that are used for the Interface 18 to Network Security Functions (I2NSF) effort. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current 28 Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other 32 documents at any time. It is inappropriate to use Internet-Drafts 33 as reference material or to cite them other than as "work in 34 progress." 36 This Internet-Draft will expire on July 06, 2018. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided 51 without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 59 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 60 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 6.1. Informative References . . . . . . . . . . . . . . . . . 12 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 64 1. Introduction 66 This document defines the terminology for the Interface to Network 67 Security Functions (I2NSF) effort. This section provides some 68 background on I2NSF; a detailed problem statement can be found in 69 [RFC8192]. Motivation and comparison to previous work can be found 70 in [I-D.ietf-i2nsf-gap-analysis]. 72 Enterprises are now considering using network security functions 73 (NSFs) hosted by service providers due to the growing challenges and 74 complexity in maintaining an up-to-date secure infrastructure that 75 complies with regulatory requirements, while controlling costs. The 76 hosted security service is especially attractive to small- and 77 medium-size enterprises who suffer from a lack of security experts 78 to continuously monitor, acquire new skills and propose immediate 79 mitigations to ever increasing sets of security attacks. Small- and 80 medium-sized businesses (SMBs) are increasingly adopting cloud-based 81 security services to replace on-premises security tools, while larger 82 enterprises are deploying a mix of traditional (hosted) and cloud- 83 based security services. 85 To meet the demand, more and more service providers are providing 86 hosted security solutions to deliver cost-effective managed security 87 services to enterprise customers. The hosted security services are 88 primarily targeted at enterprises, but could also be provided to 89 mass-market customers as well. NSFs are provided and consumed in 90 increasingly diverse environments. Users of NSFs may consume 91 network security services hosted by one or more providers, which 92 may be their own enterprise, service providers, or a combination 93 of both. 95 It is out of scope in this document to define an exhaustive list of 96 terms that are used in the security field; the reader is referred to 97 other applicable documents, such as [RFC4949]. 99 2. Conventions Used in This Document 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 103 this document are to be interpreted as described in [RFC2119]. In 104 this document, these words will appear with that interpretation 105 only when in ALL CAPS. Lower case uses of these words are not to 106 be interpreted as carrying [RFC2119] significance. 108 3. Terminology 110 AAA: Authentication, Authorization, and Accounting. See individual 111 definitions. 113 Abstraction: The definition of the salient characteristics and 114 behavior of an object that distinguish it from all other types of 115 objects. It manages complexity by exposing common properties 116 between objects and processes while hiding detail that is not 117 relevant. 119 Access Control: Protection of system resources against unauthorized 120 access; a process by which use of system resources is regulated 121 according to a security policy, and is permitted by only 122 authorized entities (e.g., users, programs, processes, or other 123 systems) according to that policy [RFC4949]. 125 Access Control List (ACL): This is a mechanism that implements 126 access control for a system resource by enumerating the system 127 entities that are permitted to access the resource and stating, 128 either implicitly or explicitly, the access modes granted to each 129 entity [RFC4949]. A YANG description is defined in 130 [I-D.ietf-netmod-acl-model]. 132 Accounting: The act of collecting information on resource usage for 133 the purpose of trend analysis, auditing, billing, or cost 134 allocation ([RFC2975] [RFC3539]). 136 Assertion: Defined by the ITU in [X.1252] as "a statement made by 137 an entity without accompanying evidence of its validity". In the 138 context of I2NSF, an assertion may include metadata about all or 139 part of the assertion (e.g., context of the assertion, or about 140 timestamp indicating the point in time the assertion was 141 created). The validity of an assertion cannot be verified. 142 (from [I-D.ietf-sacm-terminology]). 144 Attestation: The process of validating the integrity of a computing 145 device. See also Direct Anonymous Attestation, Remote Attestation. 147 Authentication: Defined in [RFC4949] as "the process of verifying 148 a claim that a system entity or system resource has a certain 149 attribute value." (from [I-D.ietf-sacm-terminology]). 151 Authorization: Defined in [RFC4949] as "an approval that is granted 152 to a system entity to access a system resource." 153 (from [I-D.ietf-sacm-terminology]). 155 Business-to-Business (B2B). A type of transaction in which one 156 business makes a commercial transaction with another business. 158 Business-to-Consumer (B2C). A type of transaction in which a 159 business makes a commercial transaction with a Customer. 161 Bespoke: Something made to fit a particular person, customer, or 162 company. 164 Bespoke security management: Security management systems that are 165 made to fit a particular customer. 167 Boolean Clause: A logical statement that evaluates to either TRUE 168 or FALSE. Also called Boolean Expression. 170 Capability: A set of features that are available from an I2NSF 171 Component. These features may, but do not have to, be used. All 172 Capabilities are announced using the I2NSF Registration 173 Interface. Capabilities are a type of I2NSF Metadata. 175 Component: An encapsulation of software that communicates using 176 Interfaces. A Component may be implemented by hardware and/or 177 software, and be represented using a set of classes. In general, 178 a Component encapsulates a set of data structures and a set of 179 algorithms that implement the function(s) that it provides. 181 Constraint: A Constraint is a limitation or restriction. 182 Constraints may be associated with any type of object (e.g., 183 Events, Conditions, and Actions in Policy Rules). 185 Constraint Programming: A type of programming that uses constraints 186 to define relations between variables in order to find a 187 feasible (but not necessarily optimal) solution. 189 Context: The Context of an Entity is a collection of measured and/ 190 or inferred knowledge that describe the state and the environment 191 in which an Entity exists or has existed. (from 192 http://www.ietf.org/mail-archive/web/i2nsf/current/msg00762.html). 194 Controller: A Controller is a management Component that contains 195 control plane functions to manage and facilitate information 196 sharing. An I2NSF COntroller may also execute security functions. 197 This definition is based on that in [I-D.ietf-sacm-terminology]. 199 Control Plane: In the context of I2NSF, the Control Plane is an 200 architectural Component that provides common control functions 201 to all I2NSF Components, including some or all of the following: 202 authentication, authorization, accounting, auditing, and 203 Capability discovery and negotiation. The Control Plane 204 orchestrates the operation of the Data Plane according to 205 guidance and/or input from the Management Plane. I2NSF Components 206 with Interfaces to the Control Plane may have knowledge of the 207 Capabilities of other I2NSF Components within a particular I2NSF 208 administrative domain. This definition is based on that in 209 [I-D.ietf-sacm-terminology]. See also: Data Plane, Management 210 Plane. 212 Customer: A business role of an entity that is involved in the 213 definition and/or consumption of services, and the possible 214 negotiation of a contract to use services from a Provider. 216 Data Center (DC): A facility used to house data processing and 217 communication equipment. 219 Data Confidentiality: Defined in [RFC4949] as "the property that 220 data is not disclosed to system entities unless they have been 221 authorized to know the data." 223 Data Integrity: Defined in [RFC4949] as "the property that data has 224 not been changed, destroyed, or lost in an unauthorized or 225 accidental manner." 227 Data Model: A representation of concepts of interest to an 228 environment in a form that is dependent on data repository, data 229 definition language, query language, implementation language, and 230 protocol (typically one or more of these ). Note the difference 231 between a data **model** and a data **structure**. 232 See also: Information Model. 234 Data Plane: In the context of I2NSF, the Data Plane is an 235 architectural Component that provides operational functions to 236 enable an I2NSF Component to provide and consume packets and 237 flows. See also: Control Plane, Management Plane. 239 Data Provenance: A historical record of the sources, origins and 240 evolution of data that is influenced by inputs, entities, 241 functions and processes. 243 Data Structure: A low-level building block that is used in 244 programming to implement an algorithm. It defines how data is 245 organized. A data model typically contains multiple types of 246 data structures; however, a data structure does not contain a 247 data model. Note the difference between a data **model** and a 248 data **structure**. 250 Domain: A collection of Entities that share a common purpose. In 251 addition, each constituent Entity in a Domain is both uniquely 252 addressable and uniquely identifiable within that Domain. 254 Direct Anonymous Attestation (DAA): A cryptographic primitive that 255 enables remote authentication of a trusted computer without 256 compromising the privacy of that computer's user(s). See also 257 attestation, remote attestation. 259 Firewall (FW): A function that restricts data communication traffic 260 to and from one of the connected networks (the one said to be 261 'inside' the firewall), and thus protects that network's system 262 resources against threats from the other network (the one that 263 is said to be 'outside' the firewall) [RFC4949]. 264 [I-D.ietf-opsawg-firewalls] 266 Flow: A set of information (e.g., packets) that are related in a 267 fundamental manner (e.g., sent from the same source and sent to 268 the same destination). A common example is a sequence of packets. 269 It is the opposite of packet-based, which treats each packet 270 discretely (e.g., each packet is assessed individually to 271 determine the action(s) to be taken). 273 Flow-based NSF: A NSF that inspects network flows according to a 274 set of policies intended for enforcing security properties. Flow- 275 based security also means that packets are inspected in the order 276 they are received, and without modification to the packet due to 277 the inspection process. 279 I2NSF Action: An I2NSF Action is used to control and monitor 280 aspects of flow-based NSFs. An I2NSF Action, when used in the 281 context of an (imperative) I2NSF Policy Rule, may be executed 282 only when the Event and the Condition clauses of its owning 283 I2NSF Policy Rule evaluate to true. The execution of this I2NSF 284 Action may be influenced by applicable metadata. Examples of 285 I2NSF Actions include providing intrusion detection and/or 286 protection, web and flow filtering, and deep packet inspection 287 for packets and flows. 288 See also: I2NSF Condition, I2NSF Event, I2NSF Policy Rule. 290 I2NSF Agent: A software Component that implements an NSF. It 291 typically plays the roles of I2NSF Consumer and I2NSF Producer. 292 For example, it can receive provisioning information and requests 293 for operational and/or monitoring data from an I2NSF Component, 294 and can provide these and other data to I2NSF Consumers. It can 295 also receive I2NSF Policy Rules to change the configuration of 296 one or more network devices, optionally transform each I2NSF 297 Policy Rule into an alternate form (e.g., one that is directly 298 consummable by the network device), and then execute the I2NSF 299 Policy Rules. 301 I2NSF Component: A Component that provides one or more I2NSF 302 Services. I2NSF Components are managed and communicate with other 303 I2NSF Components using I2NSF Interfaces. 305 I2NSF Condition: An I2NSF Condition is defined as a set of 306 attributes, features, and/or values that are to be compared with 307 a set of known attributes, features, and/or values in order to 308 determine whether or not the set of Actions in that (imperative) 309 I2NSF Policy Rule can be executed or not. An I2NSF Condition, 310 when used in the context of an (imperative) I2NSF Policy Rule, 311 may be executed only when the Event clause of its owning 312 I2NSF Policy Rule evaluates to true. Examples of an I2NSF 313 Condition include matching attributes of a packet or flow, and 314 comparing the internal state of an NSF to a desired state. 315 See also: I2NSF Action, I2NSF Event, I2NSF Policy Rule. 317 I2NSF Consumer: A Consumer is a Role that is assigned to an I2NSF 318 Component that contains functions to request information from, 319 and/or use services provided by, other I2NSF Components. Examples 320 include requesting Capabilities and I2NSF Policy Rules from 321 another I2NSF Component. See also: I2NSF Consumer-Facing 322 Interface, I2NSF Producer, I2NSF Producer-Facing Interface, Role. 324 I2NSF Consumer-Facing Interface: An Interface dedicated to 325 requesting information from I2NSF Producers. This is typically 326 defined per I2NSF administrative domain. For example, this 327 Interface could be used to request a set of I2NSF Flow Security 328 Policy Rules from an I2NSF Controller, or from one or more 329 individual NSFs. See also: I2NSF Consumer, I2NSF Provider, 330 I2NSF NSF-Facing Interface, Interface. 332 I2NSF Directly Consummable Policy Rule: An I2NSF Policy Rule is 333 said to be directly consummable if a network device can execute 334 it without translating its content or structure. See also I2NSF 335 Indirectly Consummable Policy Rule, I2NSF Policy Rule. 337 I2NSF Indirectly Consummable Policy Rule: An I2NSF Policy Rule is 338 said to be indirectly consummable if a network device can NOT 339 execute it without first translating its content or structure. See 340 also I2NSF Directly Consummable Policy Rule, I2NSF Policy Rule. 342 I2NSF Event: An I2NSF Event is defined as any important occurrence 343 in time of a change in the system being managed, and/or in the 344 environment of the system being managed. An I2NSF Event, when used 345 in the context of an (imperative) I2NSF Policy Rule, is used to 346 determine whether the Condition clause of that Policy Rule can 347 be evaluated or not. Examples of an I2NSF Event include time and 348 user actions (e.g. logon, logoff, and actions that violate an 349 ACL). See also I2NSF Action, I2NSF Condition, I2NSF Policy Rule. 351 I2NSF Management System: I2NSF Consumers and Producers operate 352 within the scope of a network management system, which serves as 353 a collection and distribution point for I2NSF security 354 provisioning, monitoring, and other operations. 356 I2NSF NSF-Facing Interface: An Interface dedicated to providing I2NSF 357 Services. For example, this could provide Anti-Virus, (D)DoS, or 358 IPS Services. This is also called the "NSF-Facing Interface". 359 See also: Interface, I2NSF Consumer Interface. 361 I2NSF Policy Rule: An I2NSF Policy Rule is an imperative statement 362 that is used as a means to monitor and control the changing and/or 363 maintaining of the state of one or more managed objects. It 364 consists of three clauses (Event, Condition, and Action). The 365 Event and Condition clauses are Boolean clauses, while the Action 366 clause consists of a set of one or more I2NSF Actions. 367 In this context, "manage" means that one or more of the following 368 six fundamental operations are supported: create, read, write, 369 delete, start, and stop. Note that for this release of I2NSF, 370 only imperative policy rules are in scope. An example of an I2NSF 371 Policy Rule is, in pseudo-code: 373 IF is TRUE 374 IF is TRUE 375 THEN execute 376 END-IF 377 END-IF 379 I2NSF Producer: A Producer is a Role that is assigned to an I2NSF 380 Component that contains functions to send information, and/or 381 provide services, to another I2NSF Component (e.g., for 382 describing, communicating, and/or executing policies, or for 383 transmitting data and/or metadata). See also: I2NSF Consumer, 384 I2NSF Consumer-Facing Interface, I2NSF Producer, I2NSF 385 Producer-Facing Interface, Role. 387 I2NSF Registry: A repository where I2NSF data and metadata 388 information (e.g., alarms and Capabilities, respectively) are 389 stored and maintained. I2NSF Components can connect to the I2NSF 390 Registry using the I2NSF Registration Interface. 391 Operations performed on an I2NSF Registry SHOULD be defined using 392 an Access Control mechanism. Examples of information that SHOULD 393 be registered include Capability metdata, as well as consistent 394 defintions of data and I2NSF Components. 395 See also: Access Control, I2NSF Component, I2NSF Consumer, 396 I2NSF Provider, I2NSF Registration Interface. 398 I2NSF Registration Interface: An Interface dedicated to 399 requesting information from, and writing information about, 400 I2NSF Components and Capabilities. See also: I2NSF Component, 401 I2NSF Consumer, I2NSF Provider, I2NSF Registry. 403 I2NSF Service: A set of functions, provided by an I2NSF Component, 404 which provides data communication, processing, storage, 405 presentation, manipulation, or other functions that can be 406 consumed by I2NSF Components. Exemplary I2NSF Services include 407 Anti-Virus, Authentication, Authorization, Firewall, and IPS 408 Services. See also: I2NSF Component, Interface. 410 Information Model: A representation of concepts of interest to an 411 environment in a form that is independent of data repository, 412 data definition language, query language, implementation language, 413 and protocol. See also: Data Model. 415 Interface: A set of operations one object knows it can invoke on, 416 and expose to, another object. It is a subset of all operations 417 that a given object implements. The same object may have multiple 418 types of interfaces to serve different purposes. 419 See also: I2NSF Component, I2NSF Consumer-Facing Interface, I2NSF 420 Registration Interface, Interface Group, NSF-Facing Interface 422 Interface Group: A set of Interfaces that are related in purpose and 423 which share the same communication mechanisms. 424 See also: Interface. 426 Intrusion Detection System (IDS): A system that detects network 427 intrusions via a variety of filters, monitors, and/or probes. An 428 IDS may be stateful or stateless. See also: IPS. 430 Intrusion Protection System (IPS): A system that protects against 431 network intrusions. An IPS may be stateful or stateless. 432 See also: IDS. 434 Management Domain: A collection of Entities that share a common 435 purpose, which has the following three behavioral features: 436 1) a set of administrators are assigned to govern the Entities 437 that are contained in a Management Domain 438 2) a set of applications are defined that are responsible for 439 executing one or more governance operations 440 3) a set of management mechanisms, such as Policy Rules, are 441 defined to govern the behavior of the Entities contained 442 in the Management Domain. 444 Management Plane: In the context of I2NSF, the Management Plane is 445 an architectural Component that provides common functions to 446 define the behavior of I2NSF Components. The primary use of the 447 Management Plane is to formulate behavioral commands and forward 448 them to the Control Plane. The Control Plane then translates them 449 into a form that can be consumed by I2NSF components. The 450 Management Plane may also instantiate and manage I2NSF Policy 451 Rules. The Management Plane is also responsible for handling and 452 acting on OAM data, which may influence the decision-making 453 processes in the I2NSF Control Plane and other I2NSF Components. 454 See also: Control Plane, Data Plane. 456 Metadata: Data that provides information about other data. 457 Examples include IETF network management protocols (e.g. NETCONF, 458 RESTCONF, IPFIX) or IETF routing interfaces (I2RS). The I2NSF 459 security interface may utilize Metadata to describe and/or 460 prescribe characteristics and behavior of the YANG data models. 462 Middlebox: Any intermediary device performing functions other 463 than the normal, standard functions of an IP router on the 464 datagram path between a source host and destination host 465 [RFC3234]. 467 Network Security Function (NSF): Software that provides a set of 468 security-related services. Examples include detecting unwanted 469 activity and blocking or mitigating the effect of such unwanted 470 activity in order to fulfil service requirements. The NSF can 471 also help in supporting communication stream integrity and 472 confidentiality. 474 NSF-Facing Interface: An Interface dedicated to specifying and 475 monitoring I2NSF Policy Rules that are enforced by one or more 476 NSFs. This is typically defined per I2NSF administrative 477 domain. Note that all features of a given NSF do not have to be 478 used. See also: Consumer-Facing Interface, Interface. 480 Object Constraint Language (OCL): A constraint programming language 481 that is used to specify restrictions on functionality. (from 482 http://www.ietf.org/mail-archive/web/i2nsf/current/msg00762.html) 484 Profile: A structured representation of information that uses a 485 pre-defined set of capabilities of an object, typically in a 486 specific context. Zero or more Capabilities may be changed at 487 runtime. This may be used to simplify how this object interacts 488 with other objects in its environment. 490 Remote Attestation: A function that enables changes to an Entity to 491 be detected by authorized parties (e.g., applications or users). 492 Direct Anonymous Attestation preserves the privacy of the user, 493 whereas remote attestation may not. See also: Attestation, 494 Direct Anonymous Attestation. 496 Role: An abstraction of a Component that models context-specific 497 views and responsibilities of an object as separate Role objects. 498 Role objects can optionally be attached to, and removed from, the 499 object that the Role object describes at runtime. This provides 500 three important benefits. First, it enables different behavior 501 to be supported by the same Component for different contexts. 502 Second, it enables the behavior of a Component to be adjusted 503 dynamically (i.e., at runtime, in response to changes in context) 504 by using one or more Roles to define the behavior desired for 505 each context. Third, it decouples the Roles of a Component from 506 the Applications that use the Component. 508 Tenant: A group of users that share common access privileges to 509 the same software. An I2NSF tenant may be physical or virtual, 510 and may run on a variety of systems or servers. 512 3. IANA Considerations 514 No IANA considerations exist for this document. 516 4. Security Considerations 518 This is a terminology document with no security considerations. 520 5. Contributors 522 The following people contributed to creating this document, and are 523 listed in alphabetical order: 525 Adrian Farrel, Christian Jacquenet, Linda Dunbar, 526 Mohammed Boucadair 528 6. References 529 6.1. Informative References 531 [I-D.ietf-i2nsf-gap-analysis] 532 Hares, S., Moskowitz, R., and Zhang, D., "Analysis of 533 Existing work for I2NSF", draft-ietf-i2nsf-gap-analysis-03 534 (work in progress), March 2017. 536 [RFC8192] 537 Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C. 538 Jacquenet, "I2NSF Problem Statement and Use cases", 539 RFC 8192, July 2017. 541 [I-D.ietf-netmod-acl-model] 542 Bogdanovic, D., Sreenivasa, K., Huang, L., Blair, D., 543 "Network Access Control List (ACL) YANG Data Model", 544 draft-ietf-netmod-acl-model-14 (work in progress), 545 October 2017. 547 [I-D.ietf-opsawg-firewalls] 548 Baker, F. and P. Hoffman, "On Firewalls in Internet 549 Security", draft-ietf-opsawg-firewalls-01 (work in 550 progress), October 2012. 552 [I-D.ietf-sacm-terminology] 553 Birkholz, H., Lu, J., Strassner, J., Cam-Wignet, N., 554 "Secure Automation and Continuous Monitoring (SACM) 555 Terminology", draft-ietf-sacm-terminology-14, 556 December 2017. 558 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 559 Requirement Levels", BCP 14, RFC 2119, March 1997. 561 [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to 562 Accounting Management", RFC 2975, DOI 10.17487/RFC2975, 563 October 2000, . 565 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 566 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 567 . 569 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and 570 Accounting (AAA) Transport Profile", RFC 3539, 571 DOI 10.17487/RFC3539, June 2003, 572 . 574 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 575 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 576 . 578 [X.1252] ITU-T, "Baseline identity management terms and 579 definitions", Recommendation ITU-T X.1252, April 2510 581 Authors' Addresses 583 Susan Hares 584 Huawei 585 7453 Hickory Hill 586 Saline, MI USA 48176 587 Phone: +1-734-604-0332 588 Email: shares@ndzh.com 590 John Strassner 591 Huawei Technologies 592 Santa Clara, CA USA 95050 593 Email: john.sc.strassner@huawei.com 595 Diego R. Lopez 596 Telefonica I+D 597 Don Ramon de la Cruz, 82 598 Madrid 28006 599 Spain 600 Email: diego.r.lopez@telefonica.com 602 Liang Xia (Frank) 603 Huawei 604 101 Software Avenue, Yuhuatai District 605 Nanjing , Jiangsu 210012 606 China 607 Email: Frank.Xialiang@huawei.com 609 Henk Birkholz 610 Fraunhofer SIT 611 Rheinstrasse 75 612 Darmstadt 64295 613 Germany 614 Email: henk.birkholz@sit.fraunhofer.de