idnits 2.17.1 draft-ietf-pana-framework-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1716. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1693. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1700. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1706. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (July 11, 2005) is 6863 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'DSL' is defined on line 1416, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) == Outdated reference: A later version (-06) exists of draft-ietf-pana-snmp-04 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-pana-snmp' == Outdated reference: A later version (-18) exists of draft-ietf-pana-pana-08 == Outdated reference: A later version (-07) exists of draft-ietf-pana-ipsec-06 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) == Outdated reference: A later version (-09) exists of draft-ietf-eap-netsel-problem-02 -- Obsolete informational reference (is this intentional?): RFC 2486 (Obsoleted by RFC 4282) == Outdated reference: A later version (-03) exists of draft-yegin-eap-boot-rfc3118-01 Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PANA Working Group P. Jayaraman 3 Internet-Draft Net.Com 4 Expires: January 12, 2006 R. Lopez 5 Univ. of Murcia 6 Y. Ohba (Ed.) 7 Toshiba 8 M. Parthasarathy 9 Nokia 10 A. Yegin 11 Samsung 12 July 11, 2005 14 PANA Framework 15 draft-ietf-pana-framework-05 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on January 12, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2005). 46 Abstract 48 PANA (Protocol for carrying Authentication for Network Access) design 49 provides support for various types of deployments. Access networks 50 can differ based on the availability of lower-layer security, 51 placement of PANA entities, choice of client IP configuration and 52 authentication methods, etc. This document defines a general 53 framework for describing how these various deployment choices are 54 handled by PANA and the access network architectures. Additionally, 55 two possible deployments are described in detail: using PANA over DSL 56 networks and wireless LANs. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1 Specification of Requirements . . . . . . . . . . . . . . 4 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. General PANA Framework . . . . . . . . . . . . . . . . . . . 6 64 4. Environments . . . . . . . . . . . . . . . . . . . . . . . . 11 65 5. IP Address Configuration . . . . . . . . . . . . . . . . . . 13 66 6. Data Traffic Protection . . . . . . . . . . . . . . . . . . 16 67 7. PAA-EP Protocol . . . . . . . . . . . . . . . . . . . . . . 17 68 7.1 PAA and EP Locations . . . . . . . . . . . . . . . . . . . 17 69 7.1.1 Single PAA, Single EP, Co-located . . . . . . . . . . 18 70 7.1.2 Separate PAA and EP . . . . . . . . . . . . . . . . . 18 71 7.2 Notification of PaC Presence . . . . . . . . . . . . . . . 20 72 7.3 Filter Rule Installation . . . . . . . . . . . . . . . . . 20 73 8. Network Selection . . . . . . . . . . . . . . . . . . . . . 21 74 9. Authentication Method Choice . . . . . . . . . . . . . . . . 23 75 10. Example Cases . . . . . . . . . . . . . . . . . . . . . . . 24 76 10.1 DSL Access Network . . . . . . . . . . . . . . . . . . . 24 77 10.1.1 Bridging Mode . . . . . . . . . . . . . . . . . . . 24 78 10.1.2 Router Mode . . . . . . . . . . . . . . . . . . . . 25 79 10.1.3 PANA and Dynamic ISP Selection . . . . . . . . . . . 26 80 10.2 Wireless LAN Example . . . . . . . . . . . . . . . . . . 27 81 10.2.1 PANA with Bootstrapping IPsec . . . . . . . . . . . 27 82 10.2.2 PANA with Bootstrapping WPA/IEEE 802.11i . . . . . . 32 83 10.2.3 Capability Discovery . . . . . . . . . . . . . . . . 34 84 11. Security Considerations . . . . . . . . . . . . . . . . . . 35 85 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 36 86 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 37 87 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 88 14.1 Normative References . . . . . . . . . . . . . . . . . . 38 89 14.2 Informative References . . . . . . . . . . . . . . . . . 39 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 40 91 A. Other Possible Cases for PANA with Bootstrapping IPsec in 92 Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . 42 93 A.1 IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 94 A.2 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 95 Intellectual Property and Copyright Statements . . . . . . . 48 97 1. Introduction 99 PANA (Protocol for carrying Authentication for Network Access) is a 100 link-layer agnostic network access authentication protocol that runs 101 between a node that wants to gain access to the network and a server 102 on the network side. PANA defines a new EAP [RFC3748] lower layer 103 that uses IP between the protocol end points. 105 The motivation to define such a protocol and the requirements are 106 described in [RFC4058]. Protocol details are documented in 107 [I-D.ietf-pana-pana]. [I-D.ietf-pana-ipsec] describes use of IPsec 108 for access control following PANA-based authentication. IPsec can be 109 used for per-packet access control, but nevertheless it is not the 110 only way to achieve this functionality. Alternatives include 111 reliance on physical security and link-layer ciphering. Separation 112 of PANA server from the entity enforcing the access control is 113 envisaged as an optional deployment choice. SNMP [I-D.ietf-pana- 114 snmp] is chosen as the protocol to carry associated information 115 between the separate nodes. 117 PANA design provides support for various types of deployments. 118 Access networks can differ based on the availability of lower-layer 119 security, placement of PANA entities, choice of client IP 120 configuration and authentication methods, etc. 122 PANA can be used in any access network regardless of the underlying 123 security. For example, the network might be physically secured, or 124 secured by means of cryptographic mechanisms after the successful 125 client-network authentication. 127 The PANA client, PANA authentication agent, authentication server, 128 and enforcement point are the relevant functional entities in this 129 design. PANA authentication agent and enforcement point(s) can be 130 placed on various elements in the access network (e.g., access point, 131 access router, dedicated host). 133 IP address configuration mechanisms vary as well. Static 134 configuration, DHCP, stateless address autoconfiguration are possible 135 mechanisms to choose from. If the client configures an IPsec tunnel 136 for enabling per-packet security, configuring IP addresses inside the 137 tunnel becomes relevant, for which there are additional choices such 138 as IKE. 140 This document defines a general framework for describing how these 141 various deployment choices are handled by PANA and the access network 142 architectures. Additionally, two possible deployments are described 143 in detail: PANA over DSL (Digital Subscriber Line) networks and WLANs 144 (Wireless LANs). 146 1.1 Specification of Requirements 148 In this document, several words are used to signify the requirements 149 of the specification. These words are often capitalized. The key 150 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 151 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 152 are to be interpreted as described in [RFC2119]. 154 2. Terminology 156 Pre-PANA address (PRPA) 158 This is an IP address configured on a PANA client before starting 159 the PANA protocol exchange. 161 Post-PANA address (POPA) 163 This is an IP address (optionally) configured on a PANA client 164 after a successful authentication. 166 IPsec Tunnel Inner Address (IPsec-TIA) 168 This is an IP address configured on a PANA client as the inner 169 address of an IPsec tunnel mode SA. 171 IPsec Tunnel Outer Address (IPsec-TOA) 173 This is the address configured on a PANA client as the outer 174 address of an IPsec tunnel mode SA. 176 Secure Association Protocol 178 A protocol that provides a cryptographic binding between the 179 initial entity authentication (and authorization) exchange to the 180 subsequent exchange of data packets. Examples of secure 181 association protocols include the 4-way handshake in IEEE 802.11i 182 [802.11i], and IKE [RFC2409] in IP-based access control. 184 3. General PANA Framework 186 PANA protocol is designed to facilitate authentication and 187 authorization of clients in access networks. PANA is an EAP 188 [RFC3748] lower-layer that carries EAP authentication methods 189 encapsulated inside EAP between a client node and an agent in the 190 access network. While PANA enables the authentication process 191 between the two entities, it is only a part of an overall AAA 192 (Authentication Authorization and Accounting) and access control 193 framework. A AAA and access control framework using PANA is 194 comprised of four functional entities. 196 PANA Client (PaC): 198 The PaC is the client implementation of the PANA protocol. This 199 entity resides on the node that is requesting network access. 200 PaCs can be end hosts, such as laptops, PDAs, cell phones, desktop 201 PCs, or routers that are connected to a network via a wired or 202 wireless interface. A PaC is responsible for requesting network 203 access and engaging in the authentication process using the PANA 204 protocol. 206 PANA Authentication Agent (PAA): 208 The PAA is the server implementation of the PANA protocol. A PAA 209 is in charge of interfacing with the PaCs for authenticating and 210 authorizing them for the network access service. 212 The PAA consults an authentication server in order to verify the 213 credentials and rights of a PaC. If the authentication server 214 resides on the same node as the PAA, an API is sufficient for this 215 interaction. When they are separated (a much more common case in 216 public access networks), a protocol needs to run between the two. 217 AAA protocols like RADIUS [RFC2865] and Diameter [RFC3588] are 218 commonly used for this purpose. 220 The PAA is also responsible for updating the access control state 221 (i.e., filters) depending on the creation and deletion of the 222 authorization state. The PAA communicates the updated state to 223 the enforcement points in the network. If the PAA and EP are 224 residing on the same node, an API is sufficient for this 225 communication. Otherwise, a protocol is required to carry the 226 authorized client attributes from the PAA to the EP. While not 227 prohibiting other protocols, currently SNMP [I-D.ietf-pana-snmp] 228 is suggested for this task. 230 The PAA resides on a node that is typically called a NAS (network 231 access server) in the access network. For example on a BAS 232 (Broadband Access Server) in DSL networks, or PDSN (Packet Data 233 Serving Node) in 3GPP2 networks. The PAA may be one or more IP 234 hops away from the PaCs. 236 Authentication Server (AS): 238 The server implementation that is in charge of verifying the 239 credentials of a PaC that is requesting the network access 240 service. The AS receives requests from the PAA on behalf of the 241 PaCs, and responds with the result of verification together with 242 the authorization parameters (e.g., allowed bandwidth, IP 243 configuration, etc). The AS might be hosted on the same node as 244 the PAA, on a dedicated node on the access network, or on a 245 central server somewhere in the Internet. 247 Enforcement Point (EP): 249 The access control implementation that is in charge of allowing 250 access to authorized clients while preventing access by others. 251 An EP learns the attributes of the authorized clients from the 252 PAA. 254 The EP uses non-cryptographic or cryptographic filters to 255 selectively allow and discard data packets. These filters may be 256 applied at the link-layer or the IP-layer. When cryptographic 257 access control is used, a secure association protocol needs to run 258 between the PaC and EP. Link or network layer protection (for 259 example TKIP, IPsec ESP) is used after the secure association 260 protocol established the necessary security association to enable 261 integrity protection, data origin authentication, replay 262 protection and optionally confidentiality protection. 264 An EP must be located strategically in a local area network to 265 minimize the access of unauthorized clients to the network. For 266 example, the EP can be hosted on the switch that is directly 267 connected to the clients in a wired network. That way the EP can 268 drop unauthorized packets before they reach any other client node 269 or beyond the local area network. 271 Figure 1 illustrates these functional entities and the interfaces 272 (protocols, APIs) among them. 274 RADIUS/ 275 Diameter/ 276 +-----+ PANA +-----+ LDAP/ API +-----+ 277 | PaC |<----------------->| PAA |<---------------->| AS | 278 +-----+ +-----+ +-----+ 279 ^ ^ 280 | | 281 | +-----+ | 282 IKE/ +-------->| EP |<--------+ SNMP/ API 283 4-way handshake +-----+ 285 Figure 1: PANA Functional Model 287 Some of the entities may be co-located depending on the deployment 288 scenario. For example, the PAA and EP would be on the same node 289 (BAS) in DSL networks. In that case a simple API is sufficient 290 between the PAA and EP. In small enterprise deployments the PAA and 291 AS may be hosted on the same node (access router) that eliminates the 292 need for a protocol run between the two. The decision to co-locate 293 these entities or otherwise, and their precise location in the 294 network topology are deployment decisions. 296 Use of IKE or IEEE 802.11i 4-way handshake protocols for secure 297 association is only required in the absence of any lower-layer 298 security prior to running PANA. Physically secured networks (e.g., 299 DSL) or the networks that are already cryptographically secured on 300 the link-layer prior to PANA run (e.g., cdma2000) do not require 301 additional secure association and per-packet ciphering. These 302 networks can bind the PANA authentication and authorization to the 303 lower-layer secure channel that is already available. 305 Figure 2 illustrates the signaling flow for authorizing a client for 306 network access. 308 PaC EP PAA AS 309 | | | | 310 IP address ->| | | | 311 config. | PANA | | AAA | 312 |<------------------------------>|<-------------->| 313 | | SNMP | | 314 (Optional) | |<-------------->| | 315 IP address ->| | | | 316 reconfig. | Sec.Assoc. | | | 317 |<------------->| | | 318 | | | | 319 | Data traffic | | | 320 |<-----------------> | | 321 | | | | 323 Figure 2: PANA Signaling Flow 325 The EP on the access network allows general data traffic from any 326 authorized PaC, whereas it allows only limited type of traffic (e.g., 327 PANA, DHCP, router discovery, etc.) for the unauthorized PaCs. This 328 ensures that the newly attached clients have the minimum access 329 service to engage in PANA and get authorized for the unlimited 330 service. 332 The PaC MUST configure an IP address prior to running PANA. After 333 the successful PANA authentication, depending on the deployment 334 scenario the PaC MAY need to re-configure its IP address or configure 335 additional IP address(es). The additional address configuration MAY 336 be executed as part of the secure association protocol run (e.g., via 337 IKE). 339 An initially unauthorized PaC starts the PANA authentication by 340 discovering the PAA, followed by the EAP exchange over PANA. The PAA 341 interacts with the AS during this process. Upon receiving the 342 authentication and authorization result from the AS, the PAA informs 343 the PaC about the result of its network access request. 345 If the PaC is authorized to gain the access to the network, the PAA 346 also sends the PaC-specific attributes (e.g., IP address, 347 cryptographic keys, etc.) to the EP by using SNMP. The EP uses this 348 information to alter its filters for allowing data traffic from and 349 to the PaC to pass through. 351 In case cryptographic access control needs to be enabled after the 352 PANA authentication, a secure association protocol runs between the 353 PaC and the EP. The PaC should already have the input parameters to 354 this process as a result of the successful PANA exchange. Similarly, 355 the EP should have obtained them from the PAA via SNMP. The secure 356 association protocol exchange produces the required security 357 associations between the PaC and the EP to enable cryptographic data 358 traffic protection. Per-packet cryptographic data traffic protection 359 introduces additional per-packet overhead but the overhead exists 360 only between the PaC and EP and will not affect communications beyond 361 the EP. 363 Finally data traffic can start flowing from and to the newly 364 authorized PaC. 366 4. Environments 368 The PANA protocol can be used on any network environment whether 369 there is a lower-layer secure channel prior to PANA, or one has to be 370 enabled upon successful PANA authentication. 372 With regard to network access authentication two types of networks 373 need to be considered: 375 a. Networks where a secure channel is already available prior to 376 running PANA 378 This type of network is characterized by the existence of 379 protection against spoofing and eavesdropping. Nevertheless, user 380 authentication and authorization is required for network 381 connectivity. 383 One example is a DSL network where the lower-layer security is 384 provided by physical means (a.1). Physical protection of the 385 network wiring ensures that practically there is only one client 386 that can send and receive IP packets on the link. Another example 387 is a cdma2000 network where the lower-layer security is provided 388 by means of cryptographic protection (a.2). By the time the 389 client requests access to the network-layer services, it is 390 already authenticated and authorized for accessing the radio 391 channel, and link-layer ciphering is enabled. 393 The presence of a secure channel before PANA exchange eliminates 394 the need for executing a secure association protocol after PANA. 395 The PANA session can be bound to the communication channel it was 396 carried over. Also, the choice of EAP authentication method 397 depends on the presence of this security during PANA run. Use of 398 some authentication methods outside a secure channel is not 399 recommended (e.g., EAP-MD5). 401 b. Networks where a secure channel is created after running PANA 403 These are the networks where there is no lower-layer protection 404 prior to running PANA. A successful PANA authentication enables 405 generation of cryptographic keys that are used with a secure 406 association protocol to enable per-packet cryptographic 407 protection. 409 PANA authentication is run on an insecure channel that is 410 vulnerable to eavesdropping and spoofing. The choice of EAP 411 method must be resilient to the possible attacks associated with 412 such an environment. Furthermore, the EAP method must be able to 413 create cryptographic keys that will later be used by the secure 414 association protocol. 416 Whether to use a link-layer per-packet security (b.1) or a network 417 layer security (b.2) is a deployment decision. This decision also 418 dictates the choice of the secure association protocol. If link- 419 layer protection is used, the protocol would be link-layer 420 specific. If IP-layer protection is used, the secure association 421 protocol would be IKE and the per-packet security would be 422 provided by IPsec AH/ESP regardless of the underlying link-layer 423 technology. 425 5. IP Address Configuration 427 The PaC configures an IP address before the PANA protocol exchange 428 begins. This address is called a pre-PANA address (PRPA). After a 429 successful authentication, the client may have to configure a post- 430 PANA address (POPA) for communication with other nodes, if the PRPA 431 is a local-use (e.g., a link-local or private address) or a 432 temporarily allocated IP address. An operator might choose 433 allocating a POPA only after successful PANA authorization either to 434 prevent waste of premium (e.g., globally routable) IP resources until 435 the client is authorized, or to enable client identity based address 436 assignment. 438 In case the PaC is a IPv4/IPv6 dual-stacked node, it may configure 439 more than one PRPA. After a successful PANA authentication the PaC 440 may configure multiple POPAs. 442 There are different methods by which a PRPA can be configured. 444 1. In some deployments (e.g., DSL networks) the PaC may be statically 445 configured with an IP address. This address SHOULD be used as a 446 PRPA. 448 2. In IPv4, most clients attempt to configure an address dynamically 449 using DHCP [RFC2131]. If they are unable to configure an address 450 using DHCP, they can configure a link-local address using 451 [I-D.ietf-zeroconf-ipv4-linklocal]. 453 When the network access provider is able to run a DHCP server on 454 the access link, the client would configure the PRPA using DHCP. 455 This address may be from a private address pool [RFC1918]. Also, 456 the lease time on the address may vary. For example, a PRPA 457 configured solely for running PANA can have a short lease time. 458 The PRPA may be used for local-use only (i.e., only for on-link 459 communication, such as for PANA and IPsec tunneling with EP), or 460 also for ultimate end-to-end data communication. 462 In case there is no running DHCP server on the link, the client 463 would fall back to configuring a PRPA via zeroconfiguration 464 technique [I-D.ietf-zeroconf-ipv4-linklocal]. This yields a long- 465 term address that can only be used for on-link communication. 467 3. In IPv6, clients automatically configure a link-local address 468 [RFC2462] when they initialize an interface. Additionally, they 469 may also configure global address(es) when DHCP or router 470 advertisements with global prefixes are made available to the 471 them. 473 In case PAA is not on the same IP subnet as the PaCs are, the 474 deployment must ensure that a non-link-local PRPA is configurable by 475 the clients. 477 When a PRPA is configured, the client starts the PANA protocol 478 exchange. By that time, a dual-stacked client might have configured 479 both an IPv4 address, and one or more IPv6 addresses as PRPAs. 480 Regardless of whether the PaC has both IPv4 and IPv6 PRPAs or only 481 one of those, only one PANA run is required. A dual-stack device 482 that implements PaC or PAA MUST be able to run PANA over both IPv4 483 and IPv6. When a dual-stack PaC or PAA initiates PANA 484 authentication, it chooses either IPv4 or IPv6 where the choice is 485 made depending on the deployment. A dual-stack PaC or PAA that is 486 initiated PANA authentication by its peer MUST use the same IP 487 version that the peer is using. 489 When the client successfully authenticates to the network, it may be 490 required to configure POPAs for its subsequent data communication 491 with the other nodes. 493 If the client is already configured with a non-temporary address that 494 can be used with data communication, it is not required to configure 495 a POPA. Otherwise, the PANA-Bind-Request message allows the PAA to 496 indicate the available configuration methods to the PaC. The PaC can 497 choose one of the methods and act accordingly. 499 1. If the network relies on physical or link layer security, the PaC 500 can configure a POPA using DHCP [RFC2131] [RFC3315] or using IPv6 501 stateless auto-configuration [RFC2461]. If IPv4 is being used, a 502 PRPA is likely to be a link-local or private address, or an 503 address with a short DHCP lease. An IPv4 PRPA SHOULD be 504 unconfigured when the POPA is configured to prevent IPv4 address 505 selection problem [I-D.ietf-zeroconf-ipv4-linklocal]. If IPv6 is 506 used, the link-local PRPA SHOULD NOT be unconfigured [RFC3484]. 508 If the PaC is a dual-stacked node, it can configure both IPv4 and 509 IPv6 type POPAs. The available POPA configuration methods are 510 indicated within the PANA protocol. 512 2. If the network uses IPsec for protecting the traffic on the link 513 subsequent to PANA authentication [I-D.ietf-pana-ipsec], the PaC 514 would use the PRPA as the outer address of IPsec tunnel mode SA 515 (IPsec-TOA). The PaC also needs to configure an inner address 516 (IPsec-TIA). There are different ways to configure an IPsec-TIA 517 which are indicated in a PANA-Bind-Request message. 519 When an IPv4 PRPA is configured, the same address may be used as 520 both IPsec-TOA and IPsec-TIA. In this case, a POPA is not 521 configured. Alternatively, an IPsec-TIA can be obtained via the 522 configuration method available within [RFC3456] for IPv4, and 523 [I-D.ietf-ipsec-ikev2] for both IPv4 and IPv6. This newly 524 configured address constitutes a POPA. Please refer to [I-D.ietf- 525 pana-ipsec] for more details. 527 IKEv2 can enable configuration of one IPv4 IPsec-TIA and one IPv6 528 IPsec-TIA for the same IPsec tunnel mode SA. Therefore, IKEv2 is 529 recommended for handling dual-stacked PaCs where single execution 530 of PANA and IKE is desired. In this case, the same IP version 531 that has been used for PANA is used for IKE, and the IKE entity on 532 the dual-stack PaC will request one or both of IPv4 and IPv6 533 IPsec-TIAs from the IKE entity on the EP and obtain the one(s) 534 that is(are) available on the EP. 536 Although there are potentially a number of different ways to 537 configure a PRPA, and POPA when necessary, it should be noted that 538 the ultimate decision to use one or more of these in a deployment 539 depends on the operator. The decision is dictated by the operator's 540 choice of per-packet protection capability (physical and link-layer 541 vs network-layer), PRPA type (local and temporary vs global and long- 542 term), and POPA configuration mechanisms available in the network. 544 6. Data Traffic Protection 546 Protecting data traffic of authenticated and authorized client from 547 others is another component of providing a complete secure network 548 access solution. Authentication, integrity and replay protection of 549 data packets is needed to prevent spoofing when the underlying 550 network is not physically secured. Encryption is needed when 551 eavesdropping is a concern in the network. 553 When the network is physically secured, or the link-layer ciphering 554 is already enabled prior to PANA, data traffic protection is already 555 in place. In other cases, enabling link-layer ciphering or network- 556 layer ciphering might rely on PANA authentication. The user and 557 network have to make sure that an appropriate EAP method which 558 generates keying materials is used. Once the keying material is 559 available, it needs to be provided to the EP(s) for use with data 560 traffic protection. 562 Network-layer protection, i.e., IPsec, can be used when data traffic 563 protection is required but link-layer protection is not available. 564 Note that the keying material generated by an EAP method is 565 insufficient to be used alone by IPsec AH/ESP or most link layer 566 mechanisms. In addition to the fresh and unique session key derived 567 from the EAP method, IPsec also needs both traffic selectors and 568 other IPsec SA parameters are missing. The shared secret can be used 569 in conjunction with a key management protocol like IKE [RFC2409] to 570 turn a session key into the required IPsec SA. The details of such a 571 mechanism is outside the scope of PANA protocol and is specified in 572 [I-D.ietf-pana-ipsec]. PANA provides bootstrapping functionality for 573 such a mechanism by carrying EAP methods that can generate initial 574 keying material. 576 Using network-layer ciphers should be regarded as a substitute for 577 link-layer ciphers when the latter is not available. Network-layer 578 ciphering can also be used in addition to link-layer ciphering if the 579 added benefits outweigh its cost to the user and the network. In 580 this case, PANA bootstraps only the network-layer ciphering; link- 581 layer ciphering is enabled using any of the existing link-layer 582 specific methods. 584 7. PAA-EP Protocol 586 The PANA protocol provides client authentication and authorization 587 functionality for securing network access. The other component of a 588 complete solution is the access control which ensures that only 589 authenticated and authorized clients can gain access to the network. 590 PANA enables access control by distinguishing authenticated and 591 authorized clients from others and generating filtering information 592 for access control mechanisms. 594 Access control can be achieved by placing EPs (Enforcement Points) in 595 the network for policing the traffic flow. EPs should prevent data 596 traffic from and to any unauthorized client unless it's either PANA 597 or one of the other allowed traffic types (e.g., ARP, IPv6 neighbor 598 discovery, DHCP, etc.). 600 When a PaC is authenticated and authorized, the PAA should notify 601 EP(s) and ask for installing filtering rules to allow the PaC to send 602 and receive data traffic. SNMP is used between PAA and EP(s) for 603 this purpose when these entities are not co-located [I-D.ietf-pana- 604 snmp]. 606 This section describes the possible models on the location of PAA and 607 EP, as well as the basic authorization information that needs to be 608 exchanged between PAA and EP. When PAA and EP are not co-located in 609 a single device, there are other issues such as dead or rebooted peer 610 detection and consideration for specific authorization and accounting 611 models. However, these issues are closely related to the PAA-EP 612 protocol solution and thus not discussed in this document. See 613 [I-D.ietf-pana-snmp] for further discussion. 615 7.1 PAA and EP Locations 617 EPs' location in the network topology should be appropriate for 618 performing access control functionality. When the access control is 619 performed at link-layer, an IP-capable access device on the same link 620 as the client devices is the logical choice. When IPsec-based or 621 non-cryptographic access control mechanisms are used, the EPs' 622 location can range from the first-hop router to other routers within 623 the access network. The first-hop router may be preferred in order 624 to limit the access of unauthorized IP traffic. 626 PAA and EPs should be aware of each other as this is necessary for 627 access control. Generally this can be achieved by manual 628 configuration. Dynamic discovery is another possibility, but this is 629 left to implementations and outside the scope of this document. 631 Since PANA allows the separation of EP and PAA, there are several 632 models depending on the number of EPs and PAAs and their locations. 633 This section describes all possible models on the placement of PAA(s) 634 and EP(s). 636 7.1.1 Single PAA, Single EP, Co-located 638 This model corresponds to the legacy NAS model. Since the PAA and 639 the EP are co-located, the PAA-EP communication can be implemented 640 locally by using, e.g., IPC (Inter-Process Communication). The only 641 difference from the legacy NAS model is the case where there are 642 multiple co-located PAA/EP devices on the same IP link and the PAA/EP 643 devices are link-layer switches or access points. In this case, for 644 a PaC that attaches to a given PAA/EP device, other PAA/EP devices 645 should not be discovered by the PaC even if those devices are on the 646 same IP link. Otherwise, the PaC may result in finding a PAA that is 647 not the closest one to it during the PANA discovery and initial 648 handshake phase and performing PANA with the PAA, which does not 649 correspond to the legacy NAS model. To prevent this, each PAA/EP 650 device on an link-layer switch or access point should not forward 651 multicast PANA discovery message sent by PaCs attached to it to other 652 devices. 654 7.1.2 Separate PAA and EP 656 When PAA is separated from EP, two cases are possible with regard to 657 whether PAA and EP are located in parallel or serial when viewed from 658 PaC, for each of models described in this section. 660 In the first case, PAA is located behind EP. The EP should be 661 configured to always pass through PANA messages and address 662 configuration protocol messages used for configuring an IP address 663 used for initial PANA messaging. This case can typically happen when 664 the EP is an link-layer switch or an access point (the EP also has an 665 IP stack to communicate with PAA via a PAA-EP protocol). 667 +---+ +---+ +---+ 668 |PaC|--------|EP |--------|PAA| 669 +---+ +---+\ +---+ 670 \ 671 +---- Internet 673 Figure 3: PAA and EP in Serial 675 In the other case, PAA is located in parallel to EP. Since the EP is 676 not on the communication path between PaC and PAA, the EP does not 677 have to configure to pass through PANA messages or address 678 configuration protocol messages in this case. This case can 679 typically happen when the EP is a router and the PAA is an 680 authentication gateway without IP routing functionality. 682 +---+ 683 +-----|PAA| 684 / +---+ 685 +---+/ 686 |PaC| 687 +---+\ 688 \ +---+ 689 +-----|EP |---- Internet 690 +---+ 692 Figure 4: PAA and EP in Parallel 694 7.1.2.1 Single PAA, Single EP, Separated 696 The model benefits from separation of data traffic handling and AAA. 697 The EP does not need to have a AAA protocol implementation which 698 might be updated relatively more frequently than the per-packet 699 access enforcement implementation. 701 7.1.2.2 Single PAA, Multiple EPs 703 In this model, a single PAA controls multiple EPs. The PAA may be 704 separated from any EP or co-located with a particular EP. This model 705 might be useful where it is preferable to run a AAA protocol at a 706 single, manageable point. This model is particularly useful in an 707 access network that consists of a large number of access points on 708 which per-packet access enforcement is made. When a PaC is 709 authenticated to the PAA, the PAA should install access control 710 filters on each of the EPs under control of the PAA if the PAA cannot 711 tell which EP the PaC is attached to. Even if the PAA can tell which 712 EP the PaC is attached to, the PAA may install access control filters 713 to those EPs if the PaC is a mobile device that can roam among the 714 EPs. Such pre-installation of filters can reduce handoff latency. 715 If different access authorization policies are applied to different 716 EPs, different filter rules for a PaC may be installed on different 717 EPs. 719 +---+ 720 |EP |--+ 721 +---+ \ 722 \ 723 +---+ +---+ +---+ 724 |PaC| |EP |----|PAA| 725 +---+ +---+ +---+ 726 / 727 +---+ / 728 |EP |--+ 729 +---+ 731 Figure 5: An example model for a single PAA and multiple EPs 733 7.1.2.3 Multiple PAAs 735 The PANA protocol allows multiple PAAs to exist on the same IP link 736 and to be visible to PaCs on the link. PAAs may or may not be co- 737 located with EPs [I-D.ietf-pana-pana]. 739 7.2 Notification of PaC Presence 741 When PAA and EP are separated and PAA is configured to be the 742 initiator of the discovery and initial handshake phase of PANA, EP 743 has the responsibility to detect presence of a new PaC and notifies 744 the PAA(s) of the presence [RFC4058]. Such a presence notification 745 is carried in a PAA-EP protocol message [I-D.ietf-pana-snmp]. 747 7.3 Filter Rule Installation 749 Filtering rules to be installed on EP generally include a device 750 identifier of PaC, and also cryptographic keying material (e.g., IKE 751 pre-shared key [RFC2409]) when cryptographic data traffic protection 752 is needed (See Section 6). Each keying material is uniquely 753 identified with a keying material name (e.g., ID_KEY_ID in IKE 754 [RFC2409]) and has a lifetime for key management, accounting, access 755 control and security reasons in general. In addition to the device 756 identifier and keying material, other filter rules, such as the IP 757 filter rules specified in NAS-Filter-Rule AVPs carried in Diameter 758 EAP application [I-D.ietf-aaa-eap] may be installed on EP. When 759 IPsec is used the filter rules are applied to IP packets carried 760 inside the IPsec tunnel, otherwise, the filter rules are applied to 761 IP packets that are not protected with IPsec. 763 8. Network Selection 765 The network selection problem statement is made in [I-D.ietf-eap- 766 netsel-problem]. The PANA protocol [I-D.ietf-pana-pana] provides a 767 way for networks to advertise which ISPs are available and for a PaC 768 to choose one ISP from the advertised information. When the PaC 769 chooses an ISP in the PANA protocol exchange, the ultimate 770 destination of the AAA exchange is determined based on the identity 771 of the chosen service provider. It is also possible that the PaC 772 does not choose a specific ISP in the PANA protocol exchange. In 773 this case, both the ISP choice and the AAA destination are determined 774 based on the PaC's identity, where the identifier may be an NAI 775 [RFC2486] or the physical port number or link-layer address of the 776 subscriber. 778 As described in [I-D.ietf-eap-netsel-problem], network selection is 779 not only related to AAA routing but also related to payload routing. 780 Once an ISP is chosen and the PaC is successfully authenticated and 781 authorized, the PaC is assigned an address by the ISP. 783 Consider a typical DSL network where the AR (access router), EP, and 784 PAA are co-located on a BAS (Broadband Access Server) in the access 785 network operated by a NAP (Network Access Provider). Figure 6 shows 786 a typical model for ISP selection. 788 <---- NAP ----><--------- ISP ---------> 790 +---ISP1 791 / 792 +---+ +---------+/ 793 |PaC|----|AR/EP/PAA| 794 +---+ +---------+\ 795 BAS \ 796 +---ISP2 798 Figure 6: A Network Selection Model 800 When network selection is made at network-layer with the use of the 801 PANA protocol instead of link-layer specific authentication 802 mechanisms, the IP link between the PaC and PAA needs to exist prior 803 to doing PANA (and prior to network selection). In this model, the 804 PRPA is either given by the NAP or a link-local address is auto- 805 configured. After the successful authentication with the ISP, the 806 PaC may acquire an address (POPA) from the ISP. It also learns the 807 address of the access router (AR), e.g., through DHCP, to be used as 808 its default router. The address of the AR may or may not be in the 809 same IP subnet as that of the PaC's POPA. Note that the physically 810 secured DSL networks do not require IPsec-based access control. 812 Therefore the PaC uses one IP address at a time where the POPA 813 replaces the PRPA upon configuration. 815 9. Authentication Method Choice 817 Authentication methods' capabilities and therefore applicability to 818 various environments differ among them. Not all methods provide 819 support for mutual authentication, key derivation or distribution, 820 and DoS attack resiliency that are necessary for operating in 821 insecure networks. Such networks might be susceptible to 822 eavesdropping and spoofing, therefore a stronger authentication 823 method needs to be used to prevent attacks on the client and the 824 network. 826 The authentication method choice is a function of the underlying 827 security of the network (e.g., physically secured, shared link, 828 etc.). It is the responsibility of the user and the network operator 829 to pick the right method for authentication. PANA carries EAP 830 regardless of the EAP method used. It is outside the scope of PANA 831 to mandate, recommend, or limit use of any authentication methods. 832 PANA cannot increase the strength of a weak authentication method to 833 make it suitable for an insecure environment. PANA can carry these 834 EAP encapsulating methods but it does not concern itself with how 835 they achieve protection for the weak methods (i.e., their EAP method 836 payloads). 838 10. Example Cases 840 10.1 DSL Access Network 842 In a DSL access network, PANA is seen applicable in the following 843 scenarios. 845 A typical DSL access consists of a NAS device at the DSL-access 846 provider and a DSL-modem (CPE) at the customer premises. The CPE 847 devices support multiple modes of operation and PANA is applicable in 848 each of these modes. 850 In the current DSL deployment, a DSLAM (DSL Access Multiplexor) which 851 is placed between the CPE and NAS is a transparent device from PANA 852 perspective. In a future DSL model, the PAA may reside in the DSLAM 853 which may directly connect ISP routers through VLANs. 855 Host--+ +-------- ISP1 856 | DSL link | 857 +----- CPE ----- DSLAM ----- NAS ----+-------- ISP2 858 | (Bridge/ | 859 Host--+ NAPT/Router) +-------- ISP3jG 861 <------- customer --> <------- NAP -----> <---- ISP ---> 862 premise 864 Figure 7: DSL Model 866 The devices at the customer premises have been shown as "hosts" in 867 the above network. 869 DSL networks are protected by physical means. Eavesdropping and 870 spoofing attacks are prevented by keeping the unintended users 871 physically away from the network media. Therefore, generally 872 cryptographic protection of data traffic is not necessary. 873 Nevertheless, if enhanced security is deemed necessary for any 874 reason, IPsec-based access control can be enabled on DSL networks as 875 well by using the method described in [I-D.ietf-pana-ipsec]. 877 10.1.1 Bridging Mode 879 In the bridging mode, the CPE acts as a simple link-layer bridge. 880 The hosts at the customer premises will function as clients to obtain 881 addresses from the NAS device by using DHCP or PPPoE. 883 If PPPoE is used, authentication is typically performed using CHAP or 884 MS-CHAP. 886 PANA will be applicable when the hosts use DHCP to obtain IP address. 887 DHCP does not support authentication of the devices on either side of 888 the DSL access line. In the simplest method of address assignment, 889 the NAS will allocate the IP address to a host with a lease time 890 reasonably sufficient to complete a full PANA based authentication 891 which will be triggered immediately after the address assignment. 892 The hosts will perform the PaC function and the NAS will perform the 893 PAA, EP and AR functions. 895 Host--+ 896 (PaC) | 897 +----- CPE ----- DSLAM ----- NAS ------------- ISP 898 | (Bridge) (PAA,EP,AR) 899 Host--+ 900 (PaC) 902 Figure 8: Bridge Mode 904 The DSL service provider's trunk network should not be accessible to 905 any host that has not successfully completed the PANA authentication 906 phase. 908 10.1.2 Router Mode 910 In this mode, the CPE acts as a router for the customer premises 911 network. The CPE itself may obtain the IP address using DHCP or be 912 configured with a static IP address. Once the CPE is authenticated 913 using PANA and is provided access to the service provider's network, 914 the NAS should begin exchanging routing updates with the CPE. All 915 devices at the customer premises will then have access to the service 916 provider's network. 918 Host--+ 919 | 920 +----- CPE ----- DSLAM ----- NAS ------------- ISP 921 | (Router, PaC) (PAA,EP,AR) 922 Host--+ 924 Figure 9: Router Mode 926 It is possible that both ends of the DSL link are configured with 927 static IP addresses. PANA-based mutual authentication of CPE and NAS 928 is desirable before data traffic is exchanged between the customer 929 premises network and the service provider network. The CPE router 930 may also use NAPT (Network Address Port Tranlation). 932 10.1.3 PANA and Dynamic ISP Selection 934 In some installations, a NAS device is shared by multiple service 935 providers. Each service provider configures the NAS with a certain 936 IP address space. 938 The devices at the customer premises network indicate their choice of 939 service provider and the NAS chooses the IP address from the 940 appropriate service provider's pool. In many cases, the address is 941 assigned not by the NAS but by the AAA server that is managed fully 942 by the service provider. 944 This simplifies the management of the DSL access network as it is not 945 always necessary to configure each DSL access line with the service 946 provider's identity. The service provider is chosen dynamically by 947 the CPE device. This is typically known as "dynamic Internet Service 948 Provider selection". The AAA function is usually overloaded to 949 perform dynamic ISP selection. 951 If the CPE device uses a PPP based protocol (PPP or PPPoE), the ISP 952 is chosen by mapping the username field of a CHAP response to a 953 provider. 955 If the CPE uses DHCP, the 'client-id' field of the DHCP-discover or 956 DHCP-request packet is mapped to the provider. 958 10.1.3.1 Selection as Part of the DHCP protocol or an Attribute of DSL 959 Access Line 961 The ISP selection, therefore the IP address pool, can be conveyed 962 based on the DHCP protocol exchange (as explained earlier), or by 963 associating the DSL access line to the service provider before the 964 PANA authentication begins. When any of these schemes is used, the 965 IP address used during PANA authentication (PRPA) is the ultimate IP 966 address and it does not have to be changed upon successful 967 authorization. 969 10.1.3.2 Selection as Part of the PANA Authentication 971 The ISP selection of the client can be explicitly conveyed during the 972 PANA authentication. In that case, the client can be assigned a 973 temporary IP address (PRPA) prior to PANA authentication. This IP 974 address might be obtained via DHCP with a lease reasonably long to 975 complete PANA authentication, or via the zeroconf technique 976 [I-D.ietf-zeroconf-ipv4-linklocal]. In either case, successful PANA 977 authentication signalling prompts the client to obtain a new (long 978 term) IP address via DHCP. This new IP address (POPA) replaces the 979 previously allocated temporary IP address. 981 10.2 Wireless LAN Example 983 This section describes how PANA can be used on WLANs. In most common 984 WLAN deployments the IP addresses are dynamically configured. 985 Therefore this section does not cover the scenarios where the IP 986 address is statically configured. There are two models depending on 987 which layer security is bootstrapped from PANA authentication, link- 988 layer or IP-layer. When PANA authentication is used for 989 bootstrapping IP-layer security, link-layer security is not 990 necessarily to exist even after PANA authentication. Instead, IPsec- 991 based data traffic protection is bootstrapped from PANA. The PAA can 992 indicate the PaC as to whether link-layer or IP-layer protection is 993 needed, by including a Protection-Capability AVP in PANA-Bind-Request 994 message. In both cases, the most common deployment would be 995 illustrated in Figure 10, where EP is typically co-located with AP 996 (access point) when PANA is used for bootstrapping link-layer 997 security or with AR when PANA is used for bootstrapping IP-layer 998 security. 1000 +-----+ 1001 |AP/EP|----+ 1002 +-----+ | 1003 | 1004 +---+ +-----+ | +---------+ 1005 |PaC| |AP/EP|----+----|AR/PAA/EP|----- Internet 1006 +---+ +-----+ | +---------+ 1007 | 1008 +-----+ | 1009 |AP/EP|----+ 1010 +-----+ 1012 Figure 10: PANA Wireless LAN Model 1014 10.2.1 PANA with Bootstrapping IPsec 1016 In this model, data traffic is protected by using IPsec tunnel mode 1017 SA and an IP address is used as the device identifier of the PaC (see 1018 Section 5 for details). Some or all of AP, DHCPv4 Server (including 1019 PRPA DHCPv4 Server and IPsec-TIA DHCPv4 Server), DHCPv6 Server, PAA 1020 and EP may be co-located in a single device. EP is always co-located 1021 with AR and may be co-located with PAA. When EP and PAA are not co- 1022 located, PAA-EP protocol is used for communication between PAA and 1023 EP. 1025 Note that for all of the cases described in this section, a PBR 1026 (PANA-Bind-Request) and PBA (PANA-Bind-Answer) exchange in PANA 1027 [I-D.ietf-pana-pana] should occur after installing the authorization 1028 parameter to the AR, so that IKE can be performed immediately after 1029 the PANA authentication is successfully completed. The PAA can 1030 obtain the required device identifer (i.e., the IPsec-TOA in this 1031 case) to be installed on the AR from the IP header of a PANA message 1032 sent by the PaC before sending the PBR. However, when the PBR/PBA 1033 exchange fails, the authorization parameters already installed on the 1034 AR must be immediately revoked to avoid unauthorized access. 1036 10.2.1.1 IPv4 1038 Case A: IPsec-TIA obtained by using DHCPv4 1040 In this case, the IPsec-TIA and IPsec-TOA are the same as the 1041 PRPA, and all configuration information including the IP address 1042 is obtained by using DHCPv4 [RFC2131]. No POPA is configured. 1043 Case A is the simplest compared to other ones and might be used in 1044 a network where IP address depletion attack on DHCP is not a 1045 significant concern. The PRPA needs to be a routable address 1046 unless NAT is performed on AR. 1048 PaC AP DHCPv4 Server PAA EP(AR) 1049 | Link-layer | | | | 1050 | association| | | | 1051 |<---------->| | | | 1052 | | | | | 1053 | DHCPv4 | | | 1054 |<-----------+------------>| | | 1055 | | | | 1056 |PANA(Discovery and handshake phase | | 1057 | & PAR/PAN exchange in authentication | 1058 | and authorization phase) | | 1059 |<-----------+-------------------------->| | 1060 | | | | 1061 | | |Authorization| 1062 | | |[IKE-PSK, | 1063 | | | PaC-DI, | 1064 | | | Session-Id] | 1065 | | |------------>| 1066 | | | | 1067 |PANA(PBR/PBA exchange in | | 1068 | authentication and authorization phase) | 1069 |<-----------+-------------------------->| | 1070 | | | | 1071 | | IKE | | 1072 |<-----------+---------------------------------------->| 1073 | | | | 1075 Figure 11: An example case for configuring IPsec-TIA by using 1076 DHCPv4 1078 Case B: IPsec-TIA obtained by using IKE 1080 In this case, the PRPA is obtained by using DHCPv4 and used as the 1081 IPsec-TOA. The POPA is obtained by using IKE (via a Configuration 1082 Payload exchange or equivalent) and used as the IPsec-TIA. An 1083 example sequence for Case B is shown in Figure 12. 1085 Case C: IPsec-TIA obtained by using RFC3456 1087 Like Case B, the PRPA is obtained by using DHCPv4. The difference 1088 is that the POPA (eventually used as IPsec-TIA) and other 1089 configuration parameter are configured by running DHCPv4 over a 1090 special IPsec tunnel mode SA [RFC3456]. Note that the PRPA DHCPv4 1091 Server and IPsec-TIA DHCPv4 Server may be co-located on the same 1092 node. 1094 Note: this case may be used only when IKEv1 is used as the IPsec 1095 key management protocol (IKEv2 does not seem to support RFC3456 1096 equivalent case). 1098 PaC AP DHCPv4 Server PAA EP(AR) 1099 | Link-layer | | | | 1100 | association| | | | 1101 |<---------->| | | | 1102 | | | | | 1103 | DHCPv4 | | | 1104 |<-----------+------------>| | | 1105 | | | | | 1106 |PANA(Discovery and handshake phase | | 1107 | & PAR/PAN exchange in | | 1108 | authentication and authorization phase) | 1109 |<-----------+-------------------------->| | 1110 | | | | 1111 | | |Authorization| 1112 | | |[IKE-PSK, | 1113 | | | PaC-DI, | 1114 | | | Session-Id] | 1115 | | |------------>| 1116 | | | | 1117 |PANA(PBR/PBA exchange in | | 1118 | authentication and authorization phase) | 1119 |<-----------+-------------------------->| | 1120 | | | 1121 | | IKE | 1122 | (with Configuration Payload exchange) | 1123 |<-----------+---------------------------------------->| 1124 | | | | 1125 | | | | 1127 Figure 12: An example case for IPsec-TIA obtained by using IKE 1129 PaC AP DHCPv4 Server PAA 1130 | Link-layer | | | 1131 | association| | | 1132 |<---------->| | | 1133 | | | | 1134 | DHCPv4 | | 1135 |<-----------+-------->| | 1136 | | | 1137 |PANA(Discovery and handshake phase | 1138 | & PAR/PAN exchange in | 1139 | authentication and authorization phase) 1140 |<-----------+-------------------------->| 1141 | | | 1142 | | | EP(AR) 1143 | | | |Authorization 1144 | | | |[IKE-PSK, 1145 | | | | PaC-DI, 1146 | | | | Session-Id] 1147 | | |----------->| 1148 | | | | 1149 |PANA(PBR/PBA exchange in authentication | | 1150 | and authorization phase) | | 1151 |<-----------+-------------------------->| | 1152 | | | | 1153 | IKEv1 phase I & II | 1154 | (to create DHCP SA) | 1155 |<-----------+--------------------------------------->| 1156 | | | 1157 | DHCP over DHCP SA | 1158 |<-----------+--------------------------------------->| 1159 | | | 1160 | IKEv1 phase II | 1161 | (to create IPsec SA for data traffic) | 1162 |<-----------+--------------------------------------->| 1164 Figure 13: An example case for configuring IPsec-TIA by using 1165 RFC3456 1167 10.2.1.2 IPv6 1169 IPsec-TIA (POPA) is obtained by using IKE (via a Configuration 1170 Payload exchange or equivalent). Other configuration information may 1171 be obtained in the same Configuration Payload exchange or may be 1172 obtained by running an additional DHCPv6. 1174 PaC AP PAA EP(AR) 1175 | Link-layer | | | 1176 | association| | | 1177 |<---------->| | | 1178 | | | | 1179 | | | | 1180 |PANA(Discovery and handshake phase | 1181 | & PAR/PAN exchange in | 1182 | authentication and authorization phase) 1183 |<-----------+------------>| | 1184 | | | | 1185 | | | | 1186 | | |Authorization| 1187 | | |[IKE-PSK, | 1188 | | | PaC-DI, | 1189 | | | Session-Id] | 1190 | | |------------>| 1191 | | | | 1192 |PANA(PBR/PBA exchange in | | 1193 | authentication and authorization phase) 1194 |<-----------+------------>| | 1195 | | | 1196 | IKEv2 | 1197 | (with Configuration Payload exchange) | 1198 |<-----------+-------------------------->| 1199 | | | | 1201 Figure 14: An example sequence for configuring IPsec-TIA in IPv6 1203 10.2.2 PANA with Bootstrapping WPA/IEEE 802.11i 1205 In this model, PANA is used for authentication and authorization, and 1206 link-layer ciphering is used for access control. Successful PANA 1207 authentication enables link-layer ciphering which is based on PSK 1208 (Pre-Shared Key) mode of WPA (Wi-Fi Protected Access) [WPA] or IEEE 1209 802.11i [802.11i]. In this document, the key shared between a 1210 station and an AP is referred to as the PMK (Pair-wise Master Key). 1211 The PMK is derived from the EAP AAA-Key as a result of successful 1212 PANA authentication. In this model, MAC addresses are used as the 1213 device identifiers in PANA. 1215 This model allows the separation of PAA from EPs(APs). A typical 1216 purpose of using this model is to reduce AP management cost by 1217 allowing physical separation of RADIUS/Diameter client from access 1218 points, where AP management can be a significant issue when deploying 1219 a large number of access points. Additionally, this centralized AAA 1220 framework enhances mobility-related performance (inter-AP but intra- 1221 PAA mobility does not require additional PANA executions). 1223 By bootstrapping PSK mode of WPA and IEEE 802.11i from PANA it is 1224 also possible to improve wireless LAN security by providing protected 1225 disconnection procedure at L3. 1227 This model does not require any change in the current WPA and IEEE 1228 802.11i specifications. This also means that PANA doesn't provide 1229 any link-layer security features beyond those already provided for in 1230 WPA and IEEE 802.11i. 1232 The IEEE 802.11 specification [802.11] allows Class 1 data frames to 1233 be received in any state. Also, IEEE 802.11i [802.11i] optionally 1234 allows higher-layer data traffic to be received and processed on the 1235 IEEE 802.1X Uncontrolled Ports. This feature allows processing IP- 1236 based traffic (such as ARP, IPv6 neighbor discovery, DHCP, and PANA) 1237 on IEEE 802.1X Uncontrolled Port prior to client authentication. 1239 Until the PaC is successfully authenticated, only a selected type of 1240 IP traffic is allowed over the IEEE 802.1X Uncontrolled Port. Any 1241 other IP traffic is dropped at the AP without being forwarded to the 1242 DS (Distribution System). Upon successful PANA authentication, the 1243 traffic switches to the controlled port. Host configuration, 1244 including obtaining an (potentially new) IP address, takes place on 1245 this port. Usual DHCP-based, and also in the case of IPv6 stateless 1246 autoconfiguration, mechanism is available to the PaC. After this 1247 point, the rest of the IP traffic, including PANA exchanges, are 1248 processed on the controlled port. 1250 When a PaC does not have a PMK for the AP, the following procedure is 1251 taken: 1253 1. The PaC associates with the AP. 1255 2. The PaC configures a PRPA by using DHCP (in the case of IPv4) or 1256 configures a link-local address (in the case of IPv6), and then 1257 runs PANA. 1259 3. Upon successful authentication, the PaC obtains a separate PMK 1260 for each AP controlled by the PAA. 1262 4. The AP initiates IEEE 802.11i 4-way handshake to establish a PTK 1263 (Pair-wise Transient Key) with the PaC, by using the PMK. 1265 5. The PaC obtains a POPA by using any method that the client 1266 normally uses. 1268 10.2.3 Capability Discovery 1270 When a PaC is a mobile, there may be multiple APs available in its 1271 vicinity. Each AP are connected to one of the following types of 1272 access networks. 1274 a) Free access network 1276 There is no IEEE 802.1X or PANA authentication in this access 1277 network. 1279 b) PANA-secured network 1281 There is PANA authentication in this access network. 1283 c) IEEE 802.1X-secured network 1285 There is IEEE 802.1X authentication in this access network. 1287 Type (c) is distinguished from others by checking the capability 1288 information advertised in IEEE 802.11 Beacon frames (IEEE 802.11i 1289 defines RSN Information Element for this purpose). Types (a) and (b) 1290 are not distinguishable until the PaC associates with the AP, gets an 1291 IP address, and engage in PANA discovery. The default PaC behavior 1292 would be to act as if this is a free network and attempt DHCP. This 1293 would be detected by the access network and trigger unsolicited PANA 1294 discovery. A type (b) network would send a PANA-Start-Request to the 1295 client and block general purpose data traffic. This helps the client 1296 discover whether the network is type (a) or type (b). Or if the PaC 1297 is pre-provisioned with the information that this is a PANA enabled 1298 network, it can attempt PAA discovery immediately. The PaC behavior 1299 after connecting to an AP of type (b) network is described in 1300 Section 10.2, Section 10.2.1 and Section 10.2.2. 1302 11. Security Considerations 1304 Security is discussed throughout this document. For protocol- 1305 specific security considerations, refer to [I-D.ietf-pana-pana]. 1307 12. IANA Considerations 1309 This document has no actions for IANA. 1311 13. Acknowledgments 1313 We would like to thank Bernard Aboba, Yacine El Mghazli, Randy 1314 Turner, Hannes Tschofenig and Lionel Morand for their valuable 1315 comments. 1317 14. References 1319 14.1 Normative References 1321 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1322 Requirement Levels", BCP 14, RFC 2119, March 1997. 1324 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1325 Levkowetz, "Extensible Authentication Protocol (EAP)", 1326 RFC 3748, June 2004. 1328 [I-D.ietf-zeroconf-ipv4-linklocal] 1329 Aboba, B., "Dynamic Configuration of Link-Local IPv4 1330 Addresses", draft-ietf-zeroconf-ipv4-linklocal-17 (work in 1331 progress), July 2004. 1333 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 1334 Autoconfiguration", RFC 2462, December 1998. 1336 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1337 Discovery for IP Version 6 (IPv6)", RFC 2461, 1338 December 1998. 1340 [RFC3484] Draves, R., "Default Address Selection for Internet 1341 Protocol version 6 (IPv6)", RFC 3484, February 2003. 1343 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1344 (IKE)", RFC 2409, November 1998. 1346 [I-D.ietf-ipsec-ikev2] 1347 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1348 draft-ietf-ipsec-ikev2-17 (work in progress), 1349 October 2004. 1351 [I-D.ietf-pana-snmp] 1352 Mghazli, Y., "SNMP usage for PAA-EP interface", 1353 draft-ietf-pana-snmp-04 (work in progress), July 2005. 1355 [I-D.ietf-pana-pana] 1356 Forsberg, D., "Protocol for Carrying Authentication for 1357 Network Access (PANA)", draft-ietf-pana-pana-08 (work in 1358 progress), May 2005. 1360 [I-D.ietf-pana-ipsec] 1361 Parthasarathy, M., "PANA Enabling IPsec based Access 1362 Control", draft-ietf-pana-ipsec-06 (work in progress), 1363 May 2005. 1365 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1366 and M. Carney, "Dynamic Host Configuration Protocol for 1367 IPv6 (DHCPv6)", RFC 3315, July 2003. 1369 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1370 RFC 2131, March 1997. 1372 [RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic 1373 Host Configuration Protocol (DHCPv4) Configuration of 1374 IPsec Tunnel Mode", RFC 3456, January 2003. 1376 14.2 Informative References 1378 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1379 "Remote Authentication Dial In User Service (RADIUS)", 1380 RFC 2865, June 2000. 1382 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1383 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1385 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1386 E. Lear, "Address Allocation for Private Internets", 1387 BCP 5, RFC 1918, February 1996. 1389 [I-D.ietf-eap-netsel-problem] 1390 Arkko, J. and B. Aboba, "Network Discovery and Selection 1391 Problem", draft-ietf-eap-netsel-problem-02 (work in 1392 progress), October 2004. 1394 [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", 1395 RFC 2486, January 1999. 1397 [RFC4058] Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang, 1398 "Protocol for Carrying Authentication for Network Access 1399 (PANA) Requirements", RFC 4058, May 2005. 1401 [I-D.ietf-aaa-eap] 1402 Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 1403 Authentication Protocol (EAP) Application", 1404 draft-ietf-aaa-eap-10 (work in progress), November 2004. 1406 [I-D.yegin-eap-boot-rfc3118] 1407 Yegin, A., Tschofenig, H., and D. Forsberg, "Bootstrapping 1408 RFC3118 Delayed DHCP Authentication Using EAP-based 1409 Network Access Authentication", 1410 draft-yegin-eap-boot-rfc3118-01 (work in progress), 1411 January 2005. 1413 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 1414 Messages", RFC 3118, June 2001. 1416 [DSL] DSL Forum Architecture and Transport Working Group, "DSL 1417 Forum TR-058 Multi-Service Architecture and Framework 1418 Requirements", September 2003. 1420 [802.11i] Institute of Electrical and Electronics Engineers, "Draft 1421 supplement to standard for telecommunications and 1422 information exchange between systems - lan/man specific 1423 requirements - part 11: Wireless medium access control 1424 (mac) and physical layer (phy) specifications: 1425 Specification for enhanced security", IEEE 802.11i/D10.0, 1426 2004. 1428 [802.11] Institute of Electrical and Electronics Engineers, 1429 "Information technology - telecommunications and 1430 information exchange between systems - local and 1431 metropolitan area networks - specific requirements part 1432 11: Wireless lan medium access control (mac) and physical 1433 layer (phy) specifications", IEEE Standard 802.11, 1434 1999(R2003). 1436 [WPA] The Wi-Fi Alliance, "WPA (Wi-Fi Protected Access)", Wi- 1437 Fi WPA v3.1, 2004. 1439 Authors' Addresses 1441 Prakash Jayaraman 1442 Network Equipment Technologies, Inc. 1443 6900 Paseo Padre Parkway 1444 Fremont, CA 94555 1445 USA 1447 Phone: +1 510 574 2305 1448 Email: prakash_jayaraman@net.com 1450 Rafa Marin Lopez 1451 University of Murcia 1452 30071 Murcia 1453 Spain 1455 Email: rafa@dif.um.es 1456 Yoshihiro Ohba 1457 Toshiba America Research, Inc. 1458 1 Telcordia Drive 1459 Piscateway, NJ 08854 1460 USA 1462 Phone: +1 732 699 5365 1463 Email: yohba@tari.toshiba.com 1465 Mohan Parthasarathy 1466 Nokia 1467 313 Fairchild Drive 1468 Mountain View, CA 94043 1469 USA 1471 Phone: +1 408 734 8820 1472 Email: mohanp@sbcglobal.net 1474 Alper E. Yegin 1475 Samsung Advanced Institute of Technology 1476 75 West Plumeria Drive 1477 San Jose, CA 95134 1478 USA 1480 Phone: +1 408 544 5656 1481 Email: alper.yegin@samsung.com 1483 Appendix A. Other Possible Cases for PANA with Bootstrapping IPsec in 1484 Wireless LAN 1486 This section describes other possible cases for PANA with 1487 Bootstrapping IPsec in wireless LAN environments. 1489 Appendix A.1 IPv4 1491 Case D: IPsec-TIA obtained by using RFC3118 1493 In this case, the POPA is configured and used as both IPsec-TIA 1494 and IPsec-TOA. The IPsec-TIA is assigned by using RFC3118 1495 (authenticated DHCP) [RFC3118] before running IKE. The PaC 1496 unconfigures the PRPA immediately after the IPsec-TIA is obtained. 1497 The DHCP-PSK needed for authenticated DHCP is distributed from the 1498 PAA to the POPA DHCPv4 server by using the method specified in 1499 [I-D.yegin-eap-boot-rfc3118]. The PRPA is assigned by using 1500 DHCPv4 and may be assigned with a short lease period in order to 1501 provide some level of robustness against IP address depletion 1502 attack. The IPsec-TIA is bound to an IPsec SA by using specifying 1503 the IPsec-TIA as the SA Identification in IKEv1 phase II or IKEv2 1504 CREATE_CHILD_SA exchange as specified in [I-D.ietf-pana-ipsec]. 1505 Once the IPsec-TIA is obtained, the PUR (PANA-Update-Request) and 1506 PUA (PANA-Update-Answer) exchange is performed with using the 1507 obtained IPsec-TIA in order to inform the PAA of the update of the 1508 IP address of the PaC. The IKE procedure should occur after the 1509 PANA-Update exchange. 1511 Note that different DHCP servers may be used for obtaining the 1512 PRPA and the POPA, when the PRPA address space and POPA address 1513 space are under different administrative domains. 1515 PaC AP DHCPv4 Server PAA EP(AR) 1516 | Link-layer | | | | 1517 | association| | | | 1518 |<---------->| | | | 1519 | | | | | 1520 | DHCPv4 | | | 1521 |<-----------+--------->| | | 1522 | | | | | 1523 |PANA(Discovery and handshake phase | | 1524 | & PAR/PAN exchange in | | 1525 | authentication and authorization phase) | 1526 |<-----------+-------------------------->| | 1527 | | | | | 1528 | | | | | 1529 | | |Authorization | | 1530 | | |[DHCP-PSK, | | 1531 | | | Session-Id] | | 1532 | | |<---------------| | 1533 | | | | | 1534 |PANA(PBR/PBA exchange in | | 1535 | authentication and authorization phase) | 1536 |<-----------+-------------------------->| | 1537 | | | | | 1538 |Authenticated DHCPv4 | | | 1539 | (RFC3118) | | | 1540 |<-----------+--------->| | | 1541 | | | | 1542 | PANA(PUR/PUA exchange in access phase based on POPA) | 1543 |<-----------+-------------------------->| | 1544 | | | | 1545 | | |Authorization| 1546 | | |[IKE-PSK, | 1547 | | | PaC-DI, | 1548 | | | Session-Id] | 1549 | | |------------>| 1550 | | IKE | | 1551 |<-----------+---------------------------------------->| 1552 | | | | 1553 | | | | 1555 Figure 15: An example case for IPsec-TIA obtained by using RFC3118 1557 Appendix A.2 IPv6 1558 Case A: IPsec-TIA obtained by using DHCPv6 1560 This case is similar to Case A in IPv4, except that the DHCPv6 1561 procedure can occur at any time after link-layer association and 1562 before IKE. 1564 This case is not recommended since there is an ambiguity on 1565 whether IPv6 Neighbor Discovery for the POPA should run on the 1566 physical interface or inside the IPsec tunnel or both. 1568 PaC AP DHCPv6 Server PAA EP(AR) 1569 | Link-layer | | | | 1570 | association| | | | 1571 |<---------->| | | | 1572 | | | | | 1573 | DHCPv6 | | | 1574 |<-----------+------------>| | | 1575 | | | | 1576 |PANA(Discovery and handshake phase | | 1577 | & PAR/PAN exchange in | | 1578 | authentication and authorization phase) | 1579 |<-----------+-------------------------->| | 1580 | | | | 1581 | | |Authorization| 1582 | | |[IKE-PSK, | 1583 | | | PaC-DI, | 1584 | | | Session-Id] | 1585 | | |------------>| 1586 | | | | 1587 |PANA(PBR/PBA exchange in | | 1588 | authentication and authorization phase) | 1589 |<-----------+-------------------------->| | 1590 | | | | 1591 | | IKE | | 1592 |<-----------+---------------------------------------->| 1593 | | | | 1594 | | | | 1596 Figure 16: An example case for IPsec-TIA obtained by using DHCPv6 1598 Case B: IPsec-TIA obtained by using IPv6 stateless address 1599 autoconfiguration 1601 In this case, the IPsec-TOA and IPsec-TIA are configured through 1602 IPv6 stateless address autoconfiguration before running IKE. 1603 Other configuration information can be obtained by using several 1604 methods including authenticated DHCPv6, Configuration Payload 1605 exchange and DHCPv6 over IPsec SA. 1607 This case is not recommended for the same reason as Case A of 1608 IPv6. 1610 PaC AP PAA EP(AR) 1611 | Link-layer | | | 1612 | association| | | 1613 |<---------->| | | 1614 | | | | 1615 | | | | 1616 |PANA(Discovery and handshake phase | | 1617 | & PAR/PAN exchange in | | 1618 | authentication and authorization phase) | 1619 |<-----------+-------------------------->| | 1620 | | | | 1621 | | |Authorization| 1622 | | |[IKE-PSK, | 1623 | | | PaC-DI, | 1624 | | | Session-Id] | 1625 | | |------------>| 1626 | | | | 1627 |PANA(PBR/PBA exchange in | | 1628 | authentication and authorization phase) | 1629 |<-----------+-------------------------->| | 1630 | | | | 1631 | IPv6 stateless address autoconfiguration | 1632 | (can occur at any time after association and before IKE) 1633 |<-----------+---------------------------------------->| 1634 | | | | 1635 | | IKE | | 1636 |<-----------+---------------------------------------->| 1637 | | | | 1639 Figure 17: An example sequence for IPsec-TIA obtained by using 1640 IPv6 stateless address autoconfiguration 1642 Case C: IPsec-TIA obtained by using authenticated DHCPv6 1644 This case is similar to Case C of IPv4, except that there is no 1645 need for additional PANA-Update exchange to update the the IP 1646 address of the PaC. 1648 PaC AP DHCPv6 Server PAA EP(AR) 1649 | Link-layer | | | | 1650 | association| | | | 1651 |<---------->| | | | 1652 | | | | | 1653 | | | | | 1654 |PANA(Discovery and handshake phase | | 1655 | & PAR/PAN exchange in | | 1656 | authentication and authorization phase) | 1657 |<-----------+-------------------------->| | 1658 | | | | | 1659 | | |Authorization|Authorization| 1660 | | |[DHCP-PSK, |[IKE-PSK, | 1661 | | | Session-Id] | PaC-DI, | 1662 | | | | Session-Id] | 1663 | | |<------------|------------>| 1664 | | | | | 1665 |PANA(PBR/PBA exchange in | | | 1666 | authentication and authorization phase) | 1667 |<-----------+-------------------------->| | 1668 | | | | | 1669 | Authenticated DHCPv6 | | | 1670 |<-----------+------------>| | | 1671 | | | |Authorization| 1672 | | | | [IKE-PSK, | 1673 | | | | PaC-DI, | 1674 | | | | Session-Id]| 1675 | | | |------------>| 1676 | | IKE | | 1677 |<-----------+---------------------------------------->| 1678 | | | | | 1679 | | | | | 1681 Figure 18: An example case for configuring IPsec-TIA by using 1682 authenticated DHCPv6 1684 Intellectual Property Statement 1686 The IETF takes no position regarding the validity or scope of any 1687 Intellectual Property Rights or other rights that might be claimed to 1688 pertain to the implementation or use of the technology described in 1689 this document or the extent to which any license under such rights 1690 might or might not be available; nor does it represent that it has 1691 made any independent effort to identify any such rights. Information 1692 on the procedures with respect to rights in RFC documents can be 1693 found in BCP 78 and BCP 79. 1695 Copies of IPR disclosures made to the IETF Secretariat and any 1696 assurances of licenses to be made available, or the result of an 1697 attempt made to obtain a general license or permission for the use of 1698 such proprietary rights by implementers or users of this 1699 specification can be obtained from the IETF on-line IPR repository at 1700 http://www.ietf.org/ipr. 1702 The IETF invites any interested party to bring to its attention any 1703 copyrights, patents or patent applications, or other proprietary 1704 rights that may cover technology that may be required to implement 1705 this standard. Please address the information to the IETF at 1706 ietf-ipr@ietf.org. 1708 Disclaimer of Validity 1710 This document and the information contained herein are provided on an 1711 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1712 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1713 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1714 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1715 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1716 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1718 Copyright Statement 1720 Copyright (C) The Internet Society (2005). This document is subject 1721 to the rights, licenses and restrictions contained in BCP 78, and 1722 except as set forth therein, the authors retain all their rights. 1724 Acknowledgment 1726 Funding for the RFC Editor function is currently provided by the 1727 Internet Society.