idnits 2.17.1 draft-yacine-pana-paa2ep-prot-eval-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2003) is 7499 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'D1' is mentioned on line 426, but not defined == Missing Reference: 'D2' is mentioned on line 434, but not defined == Missing Reference: 'SNMP' is mentioned on line 490, but not defined == Missing Reference: 'RFC2574' is mentioned on line 564, but not defined ** Obsolete undefined reference: RFC 2574 (Obsoleted by RFC 3414) == Missing Reference: 'RFC2748' is mentioned on line 587, but not defined == Missing Reference: 'RFC3084' is mentioned on line 589, but not defined == Missing Reference: 'RFC3535' is mentioned on line 725, but not defined == Unused Reference: 'RADIUS' is defined on line 779, but no explicit reference was found in the text == Unused Reference: 'DIAMETER' is defined on line 794, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-pana-requirements-07 == Outdated reference: A later version (-18) exists of draft-ietf-pana-pana-01 == Outdated reference: A later version (-16) exists of draft-ietf-aaa-diameter-15 Summary: 4 errors (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PANA WG Yacine El Mghazli 3 Internet Draft Alcatel 4 Category: Informational 5 Document: 6 draft-yacine-pana-paa2ep-prot-eval-00.txt 7 Expires: April 2004 October 2003 9 PANA 10 PAA-EP protocol considerations 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026 [STD]. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 The PANA Authentication Agent (PAA) does not necessarily act as an 35 Enforcement Point (EP) to prevent unauthorized access or usage of the 36 network. When a PANA Client (PaC) successfully authenticates itself 37 to the PAA, EP(s) (e.g., access routers) will need to be suitably 38 notified. The PANA working group will identify a (preferably 39 existing) protocol solution that allows the PAA to deliver the 40 authorization information to one or more EPs when the PAA is 41 separated from EPs. 43 The present document aims at discussing the various protocol 44 solutions available and identifying one, which better fits the whole 45 PANA picture. 47 Conventions used in this document 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in [RFC2119]. 53 Table of Contents 55 1. Glossary.......................................................3 56 2. Introduction...................................................3 57 2.1. Document History..........................................4 58 2.2. Scope.....................................................4 59 3. PAA-EP Protocol Requirements...................................5 60 3.1. Push model................................................5 61 3.2. One-to-many PAA-EP relation...............................5 62 3.3. Provisioned Data..........................................5 63 3.4. Re-use of an existing protocol............................5 64 3.5. General Security Requirements.............................5 65 4. Nice-to-have functions.........................................6 66 4.1. Pull model................................................6 67 4.2. Inactive peer detection...................................6 68 4.3. Stateful approach.........................................7 69 4.4. Accounting/Feedback from the EPs..........................7 70 5. PANA framework Assumptions/Issues..............................8 71 5.1. Multiple PAAs.............................................8 72 5.1.1. PAA-PaC relation assumption............................8 73 5.1.2. PAA-EP relation issue..................................9 74 5.2. Inter-PAAs communication.................................12 75 6. PAA-EP Protocol Evaluation....................................13 76 6.1. SNMP.....................................................13 77 6.1.1. SNMP General Applicability............................13 78 6.1.2. Compliancy of SNMP against the PAA-EP reqs............14 79 6.1.3. Compliancy of SNMP against the PANA framework.........15 80 6.2. COPS-PR..................................................15 81 6.2.1. COPS General Applicability............................15 82 6.2.2. COPS extension for provisioning (COPS-PR).............16 83 6.2.3. Compliancy of COPS-PR against the PAA-EP reqs.........17 84 6.2.4. Compliancy of COPS-PR against the PANA framework......17 85 6.3. IAB notice on COPS-PR and PIBs...........................18 86 7. Conclusion....................................................19 87 Security Considerations..........................................19 88 Acknowledgements.................................................19 89 References.......................................................19 90 Author's Addresses...............................................20 91 Full Copyright Statement.........................................21 93 1. Glossary 95 PANA Protocol for Carrying Authentication for Network Access. 97 PaC (PANA Client): 99 The client side of the protocol that resides in the host device, 100 which is responsible for providing the credentials to prove its 101 identity for network, access authorization. 103 DI (Device Identifier): 105 The identifier used by the network as a handle to control and 106 police the network access of a client. Depending on the access 107 technology, this identifier might contain any of IP address, link- 108 layer address, switch port number, etc. of a connected device. 110 PAA (PANA Authentication Agent): 112 The access network side entity of the protocol whose responsibility 113 is to verify the credentials provided by a PANA client and grant 114 network access service to the device associated with the client and 115 identified by a DI. 117 EP (Enforcement Point): 119 A node on the access network where per-packet enforcement policies 120 (i.e., filters) are applied on the inbound and outbound traffic of 121 client devices. Information such as DI and (optionally) 122 cryptographic keys are provided by PAA per client for constructing 123 filters on the EP. 125 2. Introduction 127 Client access authentication should be followed by access control to 128 make sure only authenticated and authorized clients can send and 129 receive IP packets via access network. Access control can involve 130 setting access control lists on the enforcement points. 131 Identification of clients, which are authorized to access the 132 network, is done by the PANA protocol exchange. 134 PANA does not assume that the PAA is always co-located with the 135 EP(s). Network access enforcement can be provided by one or more 136 nodes on the same IP subnet as the client (e.g., multiple routers), 137 or on another subnet in the access domain (e.g., gateway to the 138 Internet, depending on the network architecture). When the PAA and 139 the EP(s) are separated, there needs to be another transport for 140 client provisioning. This transport is needed to create access 141 control lists to allow authenticated and authorized clients' traffic 142 through the EPs. PANA Working Group will preferably identify an 143 existing protocol solution that allows the PAA to deliver the 144 authorization information to one or more EPs when the PAA is 145 separated from EPs. 147 2.1. Document History 149 This document is based on an individual submission [PAA-EP-REQ], 150 which was used as a work basis for discussions around the PAA-EP 151 interface issues within the PANA working group. 153 2.2. Scope 155 First, section 3 details the requirements that the PAA-EP protocol 156 must satisfy in order to meet the needs of PANA when the PAA is 157 separated from EP(s). These are specified in [PANAREQ]. 159 The following section 4 presents some functions the PAA-EP protocol 160 should offer, which have already been discussed on the mailing list. 161 These are not mandatory at all, but one can consider them as "nice- 162 to-have". 164 Then, section 5 discusses the PANA framework assumptions that are 165 being made within the PANA working group. It deals with crucial 166 issues around the authentication process, when the PAA is separated 167 from EP(s). 169 Finally, the last section 6 introduces and compares the various 170 protocol solutions available against the identified requirements for 171 the PAA-EP interface. 173 A compliancy summary of each of the proposed solutions is provided. 175 3. PAA-EP Protocol Requirements 177 3.1. Push model 179 PAA must be able to "push" the provisioning information down to EPs, 180 without any of the EPs "pulling" it. Since PANA exchange takes place 181 between PaC and PAA, EPs are unlikely to be aware of it. 183 EP provisioning takes place once the PaC is authenticated and 184 authorized, hence the event triggering the EP configuration takes 185 place at the PAA. Then it's straightforward to initiate the exchange 186 at the PAA. 188 3.2. One-to-many PAA-EP relation 190 One PAA have to communicate with several EPs once a PaC is 191 authenticated. The PAA-EP protocol must be able to handle this 1:n 192 communication. 194 3.3. Provisioned Data 196 The protocol must carry DI-based filters and cryptographic keys. 198 3.4. Re-use of an existing protocol 200 This work hopefully will not involve any new protocol design, it may 201 involve definition of new AVPs for existing protocols. The PANA 202 working group should try to re-use one of the many protocols around 203 to do this. 205 3.5. General Security Requirements 207 The PAA-EP protocol must provide for message authentication, 208 confidentiality, and integrity. 210 The PAA-EP protocol must define mechanisms to mitigate attacks on the 211 control messages. 213 4. Nice-to-have functions 215 4.1. Pull model 217 The PUSH model (PAA-initiated configuration) should be used for the 218 communication between PAA and EP. 220 However, the PULL model (EP-initiated configuration) might be 221 supported for the following purposes: 223 1. EP Registration/Recovery: 225 When a EP is newly connected to the network, it needs to register 226 itself to the PAA. 228 In a similar manner, when an EP crashes and comes up again, it 229 needs to re-connect its PAA. In general, when a failure is 230 detected, the EP must try to reconnect to the remote PAA or 231 attempt to connect to PAA. 233 2. Traffic-driven configuration (a.k.a. new PAC notification): 235 As stated in [PANA], PaC may also choose to start sending packets 236 before getting authenticated. In that case, the network should 237 detect this and send an unsolicited PANA_start message to PaC. EP 238 is the node that can detect such activity. If EP and PAA are co- 239 located, then an internal mechanism (e.g. API) between the EP 240 module and the PAA module on the same host can prompt PAA to start 241 PANA. In case they are separate, there needs an explicit message 242 to prompt PAA. 244 Upon detecting the need to authenticate a client, EP can send a 245 trigger message to the PAA on behalf of the PaC. This can be one 246 of the messages provided by the PAA-EP protocol, or, in the 247 absence of such a facility, PAC_discovery can be used as well. 248 This message MUST carry the device identifier of the PaC. So that, 249 PAA can send the unsolicited PANA_start message directly to the 250 PaC. 252 4.2. Inactive peer detection 254 The protocol used between PAA and EP should be able to detect 255 inactive peer within an appropriate time period. 257 This can be achieved by having both the EP and remote PAA constantly 258 verify their connection to each other via keep-alive messages: a 259 heartbeat in fact. 261 4.3. Stateful approach 263 The protocol must allow to maintain some states in the PAA in order 264 for an EP that went down and came back up, or an EP that is being 265 introduced in the network to (re-)synchronize with the PAA. 267 In general terms, the PAA-EP protocol needs to support the stateful 268 model between the PAA and the EP(s) and some other mechanism for the 269 EP to learn the policies currently in effect on that access network. 271 4.4. Accounting/Feedback from the EPs 273 The PAA must have an efficient way to to get the accounting 274 information of PaC from EP since the PAA may be a client of the AAA 275 backend infrastructure. 277 5. PANA framework Assumptions/Issues 279 5.1. Multiple PAAs 281 Multiple PAAs may be used for redundancy, load sharing, distributed 282 authentication, or other purposes: 284 a) Redundancy is the case where one or more PAAs are prepared to 285 take over if an active PAA fails. 287 b) Load sharing is the case where two or more PAAs are concurrently 288 active and any PaC that can be authenticated by one of the PAAs 289 can also be authenticated by any of the other PAA. 291 For both redundancy and load sharing, the PAAs involved are 292 equivalently capable. The only difference between these two cases a) 293 and b) is in terms of how many active PAAs there are. 295 c) Distributed authentication is the case where two or more PAAs 296 are concurrently active but certain PANA requests using PANA can 297 only be serviced by certain PAAs. The logical separation can be 298 based on: 300 . Topology: One given PAA is in charge of authenticating a 301 pool of PaCs belonging to the same topological area. 303 . The ISP: One given PAA is in charge of authenticating the 304 PaCs clients to a given ISP. Then it forwards the PANA 305 requests based on the NAI or other identifier. 307 . Etc. 309 Clearly stating the motivation for having multiples PAAs 310 authenticating PaCs and provisioning EPs in an access network has 311 direct consequences on both PAA-PaC and PAA-EP relations. 313 5.1.1. 314 PAA-PaC relation assumption 316 According to [PANA] (section "Discovery and Initial Handshake 317 Phase"), "There can be multiple PAAs on the link. The result does not 318 depend on which PAA PaC chooses. By default PaC chooses the PAA that 319 sent the first response." 320 Then, it is straightforward that the assumption that is being made 321 here is that two or more PAAs are concurrently active and any PaC 322 that can be authenticated by one of the PAAs can also be 323 authenticated by any of the other PAAs. We are clearly in the case 324 where the PaCs load is shared between the multiple PAAs (b). 326 Do note that discovery issues are raised with allowing muliples PAAs 327 to authenticate the various PaCs. [PANA] solves the problem simply 328 stating that the chosen PAA corresponds to the first response. It is 329 consistent with case b). 331 From the PaC perspective, multiple PAAs are concurrently active and 332 any PaC that can be authenticated by one of the PAAs can also be 333 authenticated by any of the other PAA. 335 5.1.2. 336 PAA-EP relation issue 338 In a similar manner, it is crucial for identifying the various PAA-EP 339 protocol requirements to clearly identify the context for having 340 multiples PAAs with respect to the EPs provisioning. 342 One PAA have to communicate with several EPs once a PaC is 343 authenticated is a requirement for the PAA-EP protocol (see section 344 3.2). In the case where there is a single PAA, the assumption being 345 made is that the PAA will provision all the EPs. However, it remains 346 an issue in case we have multiple PAAs. 348 When multiple PAAs authenticates the PaCs, a given PAA can either: 350 a) Redundancy: 351 provision all the EPs of the underlying access network and each EP 352 has a single active PAA. A back-up PAA is ready to take over if 353 the first one fails. 355 +----------------+ 356 +-|---------+ | 357 v v | | 358 +----+ +-+----+ | +-----+ 359 PaC -----| EPa| | PAA1 +-|---------+(AAA)| 360 [D1] +----+ |active|-+-+ +-+---+ 361 +-+----+ | | 362 | | PAA2 +---------+ 363 | +----+-+ 364 +----+ | | 365 PaC -----| EPb| | | 366 [D2] +----+ | | 367 ^ ^ | | 368 +-|---------+ | 369 +----------------+ 371 Figure 1. One single active PAA provisioning all the EPs 373 b) Load sharing: 374 provision all the EPs of the underlying access network and each EP 375 can be controlled by another active PAA. 377 +---------------+ 378 +-|---------+ | 379 v v | | 380 +----+ +-+----+| 381 PaC -----| EPa| | PAA1 +------------+ 382 [D1] +----+ | || | 383 +-+----+| +--+--+ 384 | | |(AAA)| 385 |+----+-+ +--+--+ 386 +----+ || PAA2 | | 387 PaC -----| EPb| || +---------+ 388 [D2] +----+ |+----+-+ 389 ^ ^ | | 390 +-|---------+ | 391 +---------------+ 393 Figure 2. Multiple active PAAs provisioning all the EPs 395 Such a deployment option can prove to be very well adapted to 396 situations where there are multiple PAAs belonging to multiple 397 ISPs. A given PAA belonging to a certain ISP can configure all the 398 EPs of the Access Network. 400 +---------------+ 401 +-|---------+ | 402 v v | | +------+ 403 +----+ +-+----+| | AAA1 | 404 PaC -----| EPa| | PAA1 +---------+(ISP1)| 405 [D1] +----+ |(ISP1)|| +------+ 406 +-+----+| 407 | | 408 |+----+-+ 409 +----+ || PAA2 | +------+ 410 PaC -----| EPb| ||(ISP2)+------+ AAA2 | 411 [D2] +----+ |+----+-+ |(ISP2)| 412 ^ ^ | | +------+ 413 +-|---------+ | 414 +---------------+ 416 Figure 3. Multiple PAAs belonging to multiple ISPs 418 c) Distributed control: 419 provision a pool of EPs within a given area. The pool can be 420 identified based on topological criteria for instance. 422 +-----------+ 423 v | 424 +----+ +-+----+ 425 PaC -----| EPa| | PAA1 +-------------+ 426 [D1] +----+ | | | 427 +------+ +--+--+ 428 ^ |(AAA)| 429 | +--+--+ 430 v | 431 +------+ | 432 +----+ | PAA2 | | 433 PaC -----| EPb| | +----------+ 434 [D2] +----+ +----+-+ 435 ^ | 436 +---------------+ 438 Figure 4. Distributed control of the EPs 440 Such a deployment option can prove to be very well adapted to 441 Access Network with a large number of EP nodes. In such a 442 situation, a single PAA cannot deal with so many EPs, then the NAP 443 can use a given PAA for a given pool of EPs. Do note that this 444 certainly imply inter-PAA communication for synchronization 445 purposes (see next section). 447 Another reason for using this deployment scheme would be to 448 configure only the EPs concerned by the traffic of the 449 authenticated PaC. But this brings up other issues (e.g. mobility 450 case) and it's out of the scope of the present document. 452 The choice between these various deployment options is motivated by 453 PANA-specific considerations. Typically, these can be: 455 . Scalability: How many EPs are managed by the PAA(s)? 457 . Symmetry: Does all the EPs need to be configured with the same 458 rules? 460 . Dynamicity: How often does the EP configuration has to be 461 refreshed? 463 5.2. Inter-PAAs communication 465 When multiple PAAs are employed, their internal organization is 466 considered an implementation issue that is beyond the scope of PANA. 467 PAAs are wholly responsible for coordinating amongst themselves to 468 provide consistency and synchronization. However, PANA does not 469 define the implementation or protocols used between PAAs, nor does it 470 define how to distribute functionality among PAAs. Nevertheless, PANA 471 will support mechanisms for PAA redundancy or fail over, and it is 472 expected that vendors will provide redundancy or fail over solutions 473 within the PANA framework. 475 6. PAA-EP Protocol Evaluation 477 The previous sections described the functions required or simply 478 wished for the PAA-to-EP communication. Do note that the so-called 479 requirements are general enough to allow a large amount of possible 480 solutions for this interface, namely: SNMP, COPS-PR, Diameter, 481 Radius, ForCES, NetConf, directory-based solutions, etc. 483 However, the PANA working group does not wish to choose a disruptive 484 solution for this PAA-EP management interface. In a similar manner, 485 the PANA working group does not wish to bet on premature solutions, 486 whose design is on-going. Hence, the working group will consider the 487 classical configuration protocols available and consequently, only 488 the following protocols were mentioned for final consideration: 490 . SNMP [SNMP] 491 . COPS-PR [COPS-PR] 493 The following sections provide an overview of each of these protocols 494 and its applicability to the PAA-EP interface. 496 6.1. SNMP 498 This section provides a general statement with regards to the 499 applicability of SNMP as the PAA-EP protocol. This evaluation of SNMP 500 is specific to SNMPv3, which provides the security required for PANA 501 usage. SNMPv1 and SNMPv2c would be inappropriate for PANA since they 502 have been declared Historic, and because their messages have only 503 trivial security. 505 6.1.1. 506 SNMP General Applicability 508 The primary advantages of SNMPv3 are that it is a mature, well 509 understood protocol, currently deployed in various scenarios, with 510 mature toolsets available for SNMP managers and agents. 512 Application intelligence is captured in MIB modules, rather than in 513 the messaging protocol. MIB modules define a data model of the 514 information that can be collected and configured for a managed 515 functionality. The SNMP messaging protocol transports the data in a 516 standardized format without needing to understand the semantics of 517 the data being transferred. The endpoints of the communication 518 understand the semantics of the data. 520 Partly due to the lack of security in SNMPv1 and SNMPv2c, and partly 521 due to variations in configuration requirements across vendors, few 522 MIB modules have been developed that enable standardized 523 configuration of managed devices across vendors. Since monitoring can 524 be done using only a least-common-denominator subset of information 525 across vendors, many MIB modules have been developed to provide 526 standardized monitoring of managed devices. As a result, SNMP has 527 been used primarily for monitoring rather than for configuring 528 network nodes. 530 SNMPv3 builds upon the design of widely-deployed SNMPv1 and SNMPv2c 531 versions. Specifically, SNMPv3 shares the separation of data modeling 532 (MIBs) from the protocol to transfer data, so all existing MIBs can 533 be used with SNMPv3. SNMPv3 also uses the SMIv2 standard, and it 534 shares operations and transport with SNMPv2c. The major difference 535 between SNMPv3 and earlier versions is the addition of strong message 536 security and controlled access to data. 538 SNMPv3 uses the architecture detailed in RFC2571, where all SNMP 539 entities are capable of performing certain functions, such as the 540 generation of requests, response to requests, the generation of 541 asynchronous notifications, the receipt of notifications, and the 542 proxy-forwarding of SNMP messages. SNMP is used to read and 543 manipulate virtual databases of managed-application-specific 544 operational parameters and statistics, which are defined in MIB 545 modules. 547 6.1.2. 548 Compliancy of SNMP against the PAA-EP reqs 550 All the requirements as described in section 3 are fully supported by 551 SNMP: 553 a) The protocol must carry DI and keys 554 Already defined MIBs (for filters, IPSec policy, etc.) can 555 be re-used. if not sufficient, PANA-specific MIBs can be 556 designed. 558 b) There might be multiple EPs per PAA. 559 An SNMP manager (PAA) can communicate simultaneously with 560 several agents (EPs). 562 c) The protocol must be secured 563 SNMPv3 includes the User-based Security Model (USM, 564 [RFC2574]), which defines three standardized methods for 565 providing authentication, confidentiality, and integrity. 566 Additionally, USM has specific built-in mechanisms for 567 preventing replay attacks including unique protocol engine 568 IDs, timers and counters per engine and time windows for the 569 validity of messages. 571 d) The protocol may allow the EP to notify a new PaC 572 Using SMI notifications 574 6.1.3. 575 Compliancy of SNMP against the PANA framework 577 When multiple PAAs, since SNMP allow multiple managers (PAAs) per 578 agent (EP), it fits better deployments where the multiple PAAs are 579 configuring all the access network EPs (section 5.1.2, option b, load 580 sharing). SNMP is the very usual Internet Management protocol. 582 SNMP does not provide heartbeat mechanisms, nor a stateful model (see 583 section 2), but this is not required by PANA. 585 6.2. COPS-PR 587 The Common Open Policy Service (COPS) [RFC2748] protocol has been 588 extended to provision configuration information on devices (COPS-PR) 589 [RFC3084]. Work is underway to define data definitions for specific 590 services such as Differentiated Services (DiffServ). 592 6.2.1. 593 COPS General Applicability 595 IETF has defined the COPS protocol [COPS] as a scalable protocol that 596 allows policy servers (PDPs) to communicate policy decisions to 597 network devices (PEPs). COPS was designed to support multiple types 598 of policy clients. 600 The main characteristics of the COPS base protocol include the 601 following: 603 1. The protocol employs a client/server model. The PEP sends 604 requests, updates, and deletions to the remote PDP and the PDP 605 returns decisions back to the PEP. 607 2. The protocol uses TCP as its transport protocol for reliable 608 exchange of messages between policy clients and a server. 610 3. The protocol is extensible in that it is designed to leverage 611 self-identifying objects and can support diverse client 612 specific information without requiring modification of the COPS 613 protocol. 615 4. The protocol was created for the general administration, 616 configuration, and enforcement of policies. 618 5. COPS provides message level security for authentication, replay 619 protection, and message integrity. COPS can make use of 620 existing protocols for security such as IPSEC or TLS to 621 authenticate and secure the channel between the PEP and the 622 PDP. 624 6. The protocol is stateful in two main aspects: 625 a. Request/Decision state is shared and kept synchronized in a 626 transactional manner between client and server. Requests 627 from the client PEP are installed or remembered by the 628 remote PDP until they are explicitly deleted by the PEP. At 629 the same time, Decisions from the remote PDP can be 630 generated asynchronously at any time for a currently 631 installed request state. 632 b. State from various events (Request/Decision pairs) may be 633 inter-associated. The server may respond to new queries 634 differently because of previously installed, related 635 Request/Decision state(s). 637 7. The protocol is also stateful in that it allows the server to 638 push configuration information to the client, and then allows 639 the server to remove such state from the client when it is no 640 longer applicable. 642 6.2.2. 643 COPS extension for provisioning (COPS-PR) 645 In COPS-PR, the PDP may proactively provision the PEP reacting to 646 external events, such as successful client authentication. This model 647 is also known as the push/configuration model. Provisioning may be 648 performed in bulk (e.g., entire EP configuration) or in portions 649 (e.g., updating a filter). 651 The COPS-PR specification [COPS-PR] is independent of the type of 652 policy being provisioned (QoS, Security, etc.). Rather, it focuses on 653 the mechanisms and conventions used to communicate provisioned 654 information between the PDP and its PEPs. The data model assumed in 655 [COPS-PR] is based on the concept of Policy Information Bases (PIBs) 656 that define the policy data. There may be one or more PIBs for given 657 area of policy and different areas of policy may have different sets 658 of PIBs. 660 COPS-PR has been designed within a framework that is optimized for 661 efficiently provisioning policies across devices: 663 . First, COPS-PR allows for efficient transport of attributes, 664 large atomic transactions of data, and efficient and flexible 665 error reporting. 667 . Second, as it has a single connection between the policy client 668 and server per area of policy control identified by a COPS 669 Client-Type, it guarantees only one server updates a particular 670 policy configuration at any given time. Such a policy 671 configuration is effectively locked, even from local console 672 configuration, while the PEP is connected to a PDP via COPS. 673 COPS uses reliable TCP transport and, thus, uses a state 674 sharing/synchronization mechanism and exchanges differential 675 updates only. If either the server or client are rebooted (or 676 restarted) the other would know about it quickly. 678 . Last, it is defined as a real-time event-driven communications 679 mechanism, never requiring polling between the PEP and PDP. 681 6.2.3. 682 Compliancy of COPS-PR against the PAA-EP reqs 684 All the requirements as described in section 3 are fully supported by 685 COPS-PR: 687 a) The protocol must carry DI-based filters and keys: 688 Already defined PIBs (for filters, IPSec policy, etc.) can 689 be re-used. if not sufficient, PANA-specific PIBs can be 690 designed. 692 b) There might be multiple EPs per PAA: 693 COPS-PR PDPs (PAAs) are designed to communicate with several 694 PEPs (EPs). 696 c) The protocol must be secured: 697 COPS-PR has built-in message level security for 698 authentication, replay protection, and message integrity. 699 COPS-PR can also use TLS or IPSec, thus reusing existing 700 security mechanisms that have interoperated in the markets. 702 d) The protocol may allow the EP to notify a new PaC: 703 COPS-PR outsourcing allowed (3GPP-like) 705 6.2.4. 706 Compliancy of COPS-PR against the PANA framework 708 When multiple PAAs, since the COPS-PR framework allow only a single 709 PDP (PAA) to configure a given PEP (EP), it fits better deployments 710 where the multiple PAAs are configuring pools of EPs (section 5.1.2, 711 option c, distributed control). 713 COPS-PR naturally provides heartbeat mechanisms, a stateful model, 714 accounting facilities and nicely supports dynamic configuration (see 715 section 2), but this is not required by PANA. 717 A little more detailed information can be found in [COPS-PANA]. 719 6.3. IAB notice on COPS-PR and PIBs 721 On the one hand, purely technically speaking, when compared to both 722 the whished (section 4) and required (section 3) functions, COPS-PR 723 seems to offer a slightly better solution for the EP configuration. 725 On the other hand, [RFC3535] provides an overview of a workshop held 726 recently by the IAB on Network Management. In the recommendations 727 section, one can read the following: 729 "2. The workshop had rough consensus from the protocol developers 730 that the IETF should not spend resources on COPS-PR development. So 731 far, the operators have only very limited experience with COPS-PR. In 732 general, however, they felt that further development of COPS-PR might 733 be a waste of resources as they assume that COPS-PR does not really 734 address their requirements. 736 3. The workshop had rough consensus from the protocol developers that 737 the IETF should not spend resources on SPPI PIB definitions. The 738 operators had rough consensus that they do not care about SPPI PIBs." 740 7. Conclusion 742 The main output of this evaluation paper is that the PANA 743 requirements for the PAA-EP interface are soft enough to allow almost 744 any of the protocol solutions available. Nevertheless, the PANA 745 working group restrict its choice to the 'classical' and available 746 device configuration protocols, namely SNMP and COPS-PR. 748 Moreover and according the operators will (via the IAB 749 recommendations), today COPS-PR is not promised to a nice future. It 750 could prove to be hazardous to bet on this protocol, however 751 efficient it is. In addition, COPS-PR is maybe too heavy for small 752 configuration sets like those needed in PANA. 754 Hence, since the PAA-EP requirements are well validated by SNMP, it 755 seems better for the PANA working group to mandate this latest 756 solution and take advantage of its widely deployed framework. 758 Security Considerations 760 See section 3.5 762 Acknowledgements 764 This evaluation draft leverages on similar works done in the MIDCOM 765 working group. Thanks to the authors of those IDs. 767 References 769 [STD] Bradner, S., "The Internet Standards Process -- Revision 3", 770 BCP 9, RFC 2026, October 1996. 772 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 773 Requirement Levels", BCP 14, RFC 2119, March 1997. 775 [PANAREQ] R. Penno, et al., "Protocol for Carrying Authentication for 776 Network Access (PANA) Requirements and Terminology" (draft-ietf- 777 pana-requirements-07.txt). 779 [RADIUS] C. Rigney et. al, "Remote Authentication Dial In User 780 Service", RFC2865, June 2000. 782 [COPS-PR] K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, F. 783 Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS Usage for 784 Policy Provisioning,", RFC 3084, March 2001 786 [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and 787 A. Sastry, "The COPS (Common Open Policy Service) Protocol" RFC 788 2748, January 2000. 790 [PANA] D. Forsberg, Y. Ohba, B. Pati, H. Tschofenig, A. Yegin, 791 "Protocol for Carrying Authentication for Network Access 792 (PANA)"(draft-ietf-pana-pana-01.txt). 794 [DIAMETER] P. Calhoun, J. Arkko, E. Guttman, G. Zorn, J. Loughney, 795 "Diameter Base Protocol" (draft-ietf-aaa-diameter-15.txt). 797 [PAA-EP-REQ] Y. El Mghazli , "PANA PAA-EP Protocol Requirements" 798 (draft-yacine-pana-paa-ep-reqs-00.txt). 800 [COPS-PANA] Y. El Mghazli, " Enforcement Point(s) Provisioning and 801 Accounting using COPS-PR" (draft-yacine-pana-cops-ep-00.txt). 803 Author's Addresses 805 Yacine El Mghazli 806 Alcatel 807 Route de Nozay 808 91460 Marcoussis cedex 809 Phone: +33 (0)1 69 63 41 87 810 Email: yacine.el_mghazli@alcatel.fr 812 Full Copyright Statement 814 "Copyright (C) The Internet Society (2003). All Rights Reserved. 816 This document and translations of it may be copied and furnished to 817 others, and derivative works that comment on or otherwise explain it 818 or assist in its implementation may be prepared, copied, published 819 and distributed, in whole or in part, without restriction of any 820 kind, provided that the above copyright notice and this paragraph are 821 included on all such copies and derivative works. However, this 822 document itself may not be modified in any way, such as by removing 823 the copyright notice or references to the Internet Society or other 824 Internet organizations, except as needed for the purpose of 825 developing Internet standards in which case the procedures for 826 copyrights defined in the Internet Standards process must be 827 followed, or as required to translate it into languages other than 828 English. 830 The limited permissions granted above are perpetual and will not be 831 revoked by the Internet Society or its successors or assigns. 833 This document and the information contained herein is provided on an 834 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 835 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 836 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 837 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 838 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.