idnits 2.17.1 draft-ietf-i2nsf-terminology-03.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 (March 07, 2017) is 2599 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.draft-ietf-supa-generic-policy-info-model' is mentioned on line 374, but not defined == Outdated reference: A later version (-16) exists of draft-ietf-i2nsf-problem-and-use-cases-09 == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-09 == Outdated reference: A later version (-16) exists of draft-ietf-sacm-terminology-11 == Outdated reference: A later version (-03) exists of draft-ietf-supa-generic-policy-info-model-02 Summary: 0 errors (**), 0 flaws (~~), 6 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: September 07, 2017 D. Lopez 5 Telefonica I+D 6 L. Xia 7 Huawei 8 H. Birkholz 9 Fraunhofer SIT 10 March 07, 2017 12 Interface to Network Security Functions (I2NSF) Terminology 13 draft-ietf-i2nsf-terminology-03.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 September 07, 2017. 38 Copyright Notice 40 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . 10 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 59 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 60 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 6.1. Informative References . . . . . . . . . . . . . . . . . 11 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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 [I-D.ietf-i2nsf-problem-and-use-cases]. Motivation and comparison to 70 previous work can be found 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 (users, programs, processes, or other systems) 123 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. 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 functions may, but do not have to, be used. All 172 Capabilities are announced through the I2NSF Registration 173 Interface. Examples are Capabilities that are available from an 174 NSF Server. 176 Client: See I2NSF Consumer. 178 Client-Facing Interface: See I2NSF Consumer-Facing Interface. 180 Component: An encapsulation of software that communicates using 181 Interfaces. A Component may be implemented by hardware and/or 182 software, and be represented using a set of classes. In general, 183 a Component encapsulates a set of data structures and a set of 184 algorithms that implement the function(s) that it provides. 186 Constraint: A Constraint is a limitation or restriction. 187 Constraints may be associated with any type of object (e.g., 188 Events, Conditions, and Actions in Policy Rules). 190 Constraint Programming: A type of programming that uses constraints 191 to define relations between variables in order to find a 192 feasible (and not necessarily optimal) solution. 194 Context: The Context of an Entity is a collection of measured and/ 195 or inferred knowledge that describe the state and the environment 196 in which an Entity exists or has existed. (from 197 http://www.ietf.org/mail-archive/web/i2nsf/current/msg00762.html). 199 Controller: A Controller is a management Component that contains 200 control plane functions to manage and facilitate information 201 sharing, as well as execute security functions. This definition 202 is based on that in [I-D.ietf-sacm-terminology]. 204 Control Plane: In the context of I2NSF, the Control Plane is an 205 architectural Component that provides common control functions 206 to all I2NSF Components, including some or all of the following: 207 authentication, authorization, accounting, auditing, and 208 Capability discovery and negotiation. The Control Plane 209 orchestrates the operation of the Data Plane according to 210 guidance and/or input from the Management Plane. I2NSF Components 211 with Interfaces to the Control Plane have knowledge of the 212 Capabilities of other I2NSF Components within a particular I2NSF 213 administrative domain. This definition is based on that in 214 [I-D.ietf-sacm-terminology]. See also: Data Plane, Management 215 Plane. 217 Customer: A business role of an entity that is involved in the 218 definition and/or consumption of services, and the possible 219 negotiation of a contract to use services from a Provider. 221 Data Center (DC): A facility used to house data processing and 222 communication equipment. 224 Data Confidentiality: Defined in [RFC4949] as "the property that 225 data is not disclosed to system entities unless they have been 226 authorized to know the data." 228 Data Integrity: Defined in [RFC4949] as "the property that data has 229 not been changed, destroyed, or lost in an unauthorized or 230 accidental manner." 232 Data Model: A representation of concepts of interest to an 233 environment in a form that is dependent on data repository, data 234 definition language, query language, implementation language, and 235 protocol (typically one or more of these ). Note the difference 236 between a data **model** and a data **structure**. 237 [I-D.ietf-supa-generic-policy-info-model]. 239 Data Plane: In the context of I2NSF, the Data Plane is an 240 architectural Component that provides operational functions to 241 enable an I2NSF Component to provide and consume packets and 242 flows. See also: Control Plane, Management Plane. 244 Data Provenance: A historical record of the sources, origins and 245 evolution of data that is influenced by inputs, entities, 246 functions and processes. 248 Data Structure: A low-level building block that is used in 249 programming to implement an algorithm. A data model typically 250 contains multiple types of data structures; however, a data 251 structure does not contain a data model. Note the difference 252 between a data **model** and a data **structure**. 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. 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 (based on [I-D.ietf-supa-generic-policy-info-model]). See also 289 I2NSF Condition, I2NSF Event, I2NSF Policy Rule. 291 I2NSF Agent: A software Component that implements an NSF. It 292 typically plays the roles of I2NSF Consumer and I2NSF Producer. 293 For example, it can receive provisioning information and requests 294 for operational and/or monitoring data from an I2NSF Component, 295 and can provide these and other data to I2NSF Consumers. It can 296 also receive I2NSF Policy Rules to change the configuration of 297 one or more network devices, optionally transform each I2NSF 298 Policy Rule into an alternate form (e.g., one that is directly 299 consummable by the network device), and then execute the I2NSF 300 Policy Rules. 302 I2NSF Component: A Component that provides one or more I2NSF 303 Services. I2NSF Components are managed and communicate with other 304 I2NSF Components using I2NSF Interfaces. 306 I2NSF Condition: An I2NSF Condition is defined as a set of 307 attributes, features, and/or values that are to be compared with 308 a set of known attributes, features, and/or values in order to 309 determine whether or not the set of Actions in that (imperative) 310 I2NSF Policy Rule can be executed or not. An I2NSF Condition, 311 when used in the context of an (imperative) I2NSF Policy Rule, 312 may be executed only when the Event clause of its owning 313 I2NSF Policy Rule evaluates to true. Examples of an I2NSF 314 Condition include matching attributes of a packet or flow, and 315 comparing the internal state of an NSF to a desired state. 316 (based on [I-D.ietf-supa-generic-policy-info-model]). See also 317 I2NSF Action, I2NSF Event, I2NSF Policy Rule. 319 I2NSF Consumer: A Consumer is a Role that is assigned to an I2NSF 320 Component that contains functions to provide information to other 321 I2NSF Components. Examples include providing I2NSF Policy Rules 322 to other I2NSF Components. See also: I2NSF Consumer-Facing 323 Interface, I2NSF Producer, I2NSF Producer-Facing Interface, Role. 325 I2NSF Consumer-Facing Interface: An Interface dedicated to 326 requesting information from I2NSF Producers. This is typically 327 defined per I2NSF administrative domain. For example, this 328 Interface could be used to request a set of I2NSF Flow Security 329 Policy Rules from an I2NSF Controller, or from one or more 330 individual NSFs. See also: I2NSF Consumer, I2NSF Provider, I2NSF 331 NSF-Facing Interface, Interface. 333 I2NSF Directly Consummable Policy Rule: An I2NSF Policy Rule is 334 said to be directly consummable if a network device can execute 335 it without translating its content or structure. See also I2NSF 336 Indirectly Consummable Policy Rule, I2NSF Policy Rule. 338 I2NSF Indirectly Consummable Policy Rule: An I2NSF Policy Rule is 339 said to be indirectly consummable if a network device can NOT 340 execute it without first translating its content or structure. See 341 also I2NSF Directly Consummable Policy Rule, I2NSF Policy Rule. 343 I2NSF Event: An I2NSF Event is defined as any important occurrence 344 in time of a change in the system being managed, and/or in the 345 environment of the system being managed. An I2NSF Event, when used 346 in the context of an (imperative) I2NSF Policy Rule, is used to 347 determine whether the Condition clause of that Policy Rule can 348 be evaluated or not. Examples of an I2NSF Event include time and 349 user actions (e.g. logon, logoff, and actions that violate an 350 ACL). (based on [I-D.ietf-supa-generic-policy-info-model]). 351 See also I2NSF Action, I2NSF Condition, I2NSF Policy Rule. 353 I2NSF Management System: I2NSF Consumers and Producers operate 354 within the scope of a network management system, which serves as 355 a collection and distribution point for I2NSF security 356 provisioning, monitoring, and other operations. 358 I2NSF Policy Rule: An I2NSF Policy Rule is an imperative statement 359 that is used as a means to monitor and control the changing and/or 360 maintaining of the state of one or more managed objects. It 361 consists of three Boolean clauses (Event, Condition, and Action). 362 In this context, "manage" means that one or more of the following 363 six fundamental operations are supported: create, read, write, 364 delete, start, and stop). Note that for this release of I2NSF, 365 only imperative policy rules are in scope. An example of an I2NSF 366 Policy Rule is, in pseudo-code: 368 IF is TRUE 369 IF is TRUE 370 THEN execute 371 END-IF 372 END-IF 374 This is based on [I-D.draft-ietf-supa-generic-policy-info-model]. 376 I2NSF Producer: A Producer is a Role that is assigned to an I2NSF 377 Component that contains functions to send information and/or 378 commands to another I2NSF Component (e.g., for describing, 379 communicating, and/or executing policies, or for transmitting 380 data). See also: I2NSF Consumer, I2NSF Consumer-Facing Interface, 381 I2NSF Producer, I2NSF Producer-Facing Interface, Role. 383 I2NSF Producer-Facing Interface: See NSF-Facing Interface. 385 I2NSF Registry: A repository where I2NSF data and metadata 386 information are stored and maintained. I2NSF Components can 387 connect to the I2NSF Registry using the I2NSF Registration 388 Interface; the actions that an I2NSF Component can performing 389 SHOULD be defined using an Access Control mechanism. Examples 390 of information that SHOULD be registered include Capability data, 391 as well as consistent defintions of data and I2NSF Components. 392 See also: Access Control, I2NSF Component, I2NSF Consumer, 393 I2NSF Provider, I2NSF Registration Interface. 395 I2NSF Registration Interface: An Interface dedicated to 396 requesting information from, and writing information about, 397 I2NSF Components. See also: I2NSF Component, I2NSF Consumer, 398 I2NSF Provider, I2NSF Registry. 400 I2NSF Service: A set of functions, provided by an I2NSF Component, 401 which provides data communication, processing, storage, 402 presentation, maniuplation, or other functions that can be 403 consumed by I2NSF Components. Exemplary I2NSF Services include 404 Anti-Virus, Authentication, Authorization, Firewall, and IPS 405 Services. See also: I2NSF Component, Interface. 407 IDS: Intrusion Detection System (see below). 409 IPS: Intrusion Protection System (see below). 411 Information Model: A representation of concepts of interest to an 412 environment in a form that is independent of data repository, 413 data definition language, query language, implementation language, 414 and protocol. See also: Data Model. 415 (from [I-D.ietf-supa-generic-policy-info-model]). 417 Interface: A set of operations one object knows it can invoke on, 418 and expose to, another object. It is a subset of all operations 419 that a given object implements. The same object may have multiple 420 types of interfaces to serve different purposes. 421 See also: I2NSF Component, I2NSF Consumer-Facing Interface, I2NSF 422 Registration Interface, Interface Group, NSF-Facing Interface 424 Interface Group: A set of Interfaces that are related in purpose and 425 which share the same communication mechanisms. 426 See also: Interface. 428 Intrusion Detection System (IDS): A system that detects network 429 intrusions via a variety of filters, monitors, and/or probes. An 430 IDS may be stateful or stateless. See also: IPS. 432 Intrusion Protection System (IPS): A system that protects against 433 network intrusions. An IPS may be stateful or stateless. 434 See also: IDS. 436 Management Plane: In the context of I2NSF, the Management Plane is 437 an architectural Component that provides common functions to 438 define the behavior of I2NSF Components. The primary use of the 439 Management Plane is to transport behavioral commands, and supply 440 OAM data, for making decisions that affect behavior. Examples 441 include modifying the configuration of an I2NSF Component and 442 transporting OAM data. See also: Control Plane, Data Plane. 444 Metadata: Data that provides information about other data. 445 Examples include IETF network management protocols (e.g. NETCONF, 446 RESTCONF, IPFIX) or IETF routing interfaces (I2RS). The I2NSF 447 security interface may utilize Metadata to describe and/or 448 prescribe characteristics and behavior of the YANG data models. 450 Middlebox: Any intermediary device performing functions other 451 than the normal, standard functions of an IP router on the 452 datagram path between a source host and destination host 453 [RFC3234]. 455 Network Security Function (NSF): Software that provides a set of 456 security-related services. Examples include detecting unwanted 457 activity and blocking or mitigating the effect of such unwanted 458 activity in order to fulfil service requirements. The NSF can 459 also help in supporting communication stream integrity and 460 confidentiality. 462 NSF-Facing Interface: An Interface dedicated to specifying and 463 monitoring I2NSF Policy Rules that are enforced by one or more 464 NSFs. This is typically defined per I2NSF administrative 465 domain. Note that all features of a given NSF do not have to be 466 used. See also: Consumer-Facing Interface, Interface. 468 Object Constraint Language (OCL): A constraint programming language 469 that is used to specify restrictions on functionality. (from 470 http://www.ietf.org/mail-archive/web/i2nsf/current/msg00762.html) 472 Profile: A structured representation of information that uses a 473 pre-defined set of capabilities of an object, typically in a 474 specific context. Zero or more Capabilities may be changed at 475 runtime. This may be used to simplify how this object interacts 476 with other objects in its environment. 478 Role: An abstraction of a Component that models context-specific 479 views and responsibilities of an object as separate Role objects. 480 Role objects can optionally be attached to, and removed from, the 481 object that the Role object describes at runtime. This provides 482 three important benefits. First, it enables different behavior 483 to be supported by the same Component for different contexts. 484 Second, it enables the behavior of a Component to be adjusted 485 dynamically (i.e., at runtime, in response to changes in context) 486 by using one or more Roles to define the behavior desired for 487 each context. Third, it decouples the Roles of a Component from 488 the Applications use that Component. 490 Tenant: A group of users that share common access privileges to 491 the same software. An I2NSF tenant may be physical or virtual, 492 and may run on a variety of systems or servers. 494 3. IANA Considerations 496 No IANA considerations exist for this document. 498 4. Security Considerations 500 This is a terminology document with no security considerations. 502 5. Contributors 504 The following people contributed to creating this document, and are 505 listed in alphabetical order: 507 Adrian Farrel, Linda Dunbar 509 6. References 511 6.1. Informative References 513 [I-D.ietf-i2nsf-gap-analysis] 514 Hares, S., Moskowitz, R., and Zhang, D., "Analysis of 515 Existing work for I2NSF", draft-ietf-i2nsf-gap-analysis-03 516 (work in progress), March 2017. 518 [I-D.ietf-i2nsf-problem-and-use-cases] 519 Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C. 520 Jacquenet, "I2NSF Problem Statement and Use cases", draft- 521 ietf-i2nsf-problem-and-use-cases-09 (work in progress), 522 February 2017. 524 [I-D.ietf-netmod-acl-model] 525 Bogdanovic, D., Sreenivasa, K., Huang, L., Blair, D., 526 "Network Access Control List (ACL) YANG Data Model", 527 draft-ietf-netmod-acl-model-09 (work in progress), 528 February 2017. 530 [I-D.ietf-opsawg-firewalls] 531 Baker, F. and P. Hoffman, "On Firewalls in Internet 532 Security", draft-ietf-opsawg-firewalls-01 (work in 533 progress), October 2012. 535 [I-D.ietf-sacm-terminology] 536 Birkholz, H., Lu, J., Strassner, J., Cam-Wignet, N., 537 "Secure Automation and Continuous Monitoring (SACM) 538 Terminology", draft-ietf-sacm-terminology-11, 539 September 2016 541 [I-D.ietf-supa-generic-policy-info-model] 542 Strassner, J., Halpern, J., and J. Coleman, "Generic 543 Policy Information Model for Simplified Use of Policy 544 Abstractions (SUPA)", draft-ietf-supa-generic-policy- 545 info-model-02 (work in progress), January 2017. 547 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 548 Requirement Levels", BCP 14, RFC 2119, March 1997. 550 [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to 551 Accounting Management", RFC 2975, DOI 10.17487/RFC2975, 552 October 2000, . 554 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 555 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 556 . 558 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and 559 Accounting (AAA) Transport Profile", RFC 3539, 560 DOI 10.17487/RFC3539, June 2003, 561 . 563 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 564 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 565 . 567 [X.1252] ITU-T, "Baseline identity management terms and 568 definitions", Recommendation ITU-T X.1252, April 2510 570 Authors' Addresses 572 Susan Hares 573 Huawei 574 7453 Hickory Hill 575 Saline, MI USA 48176 576 Phone: +1-734-604-0332 577 Email: shares@ndzh.com 579 John Strassner 580 Huawei Technologies 581 Santa Clara, CA USA 95050 582 Email: john.sc.strassner@huawei.com 584 Diego R. Lopez 585 Telefonica I+D 586 Don Ramon de la Cruz, 82 587 Madrid 28006 588 Spain 589 Email: diego.r.lopez@telefonica.com 590 Liang Xia (Frank) 591 Huawei 592 101 Software Avenue, Yuhuatai District 593 Nanjing , Jiangsu 210012 594 China 595 Email: Frank.Xialiang@huawei.com 597 Henk Birkholz 598 Fraunhofer SIT 599 Rheinstrasse 75 600 Darmstadt 64295 601 Germany 602 Email: henk.birkholz@sit.fraunhofer.de