idnits 2.17.1 draft-ietf-pana-requirements-05.txt: -(336): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Protocol MUST support PaCs with multiple interfaces, and networks with multiple routers on multi-access links. In other words, PANA MUST not assume PaC has only one network interface, or the access network has only one first hop router, or the PaC is using a point-to-point link. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: PANA MUST NOT assume that the link is connection-oriented. Links MAY or MAY NOT provide disconnect indication. Such notification is desirable in order for the PAA to cleanup resources when a client moves away from the network (e.g., inform the enforcement points that the client is no longer connected). PANA SHOULD have a mechanism to provide disconnect indication. When such indications are not protected by means of physical or link-layer mechanisms, PANA MUST ensure this protection to prevent attackers from leveraging this extension for DoS attacks. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: PANA MUST not assume presence of a secure channel between the PaC and the PAA. PANA MUST be able to provide authentication especially in networks which are not protected against eavesdropping and spoofing. PANA MUST enable protection against replay attacks on both PaCs and PAAs. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RDISC' is mentioned on line 220, but not defined == Missing Reference: 'ADDRCONF' is mentioned on line 437, but not defined == Missing Reference: 'D1' is mentioned on line 678, but not defined == Missing Reference: 'D2' is mentioned on line 682, but not defined == Unused Reference: '8021X' is defined on line 520, but no explicit reference was found in the text == Unused Reference: 'PPP' is defined on line 536, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-pana-usage-scenarios-05 ** Downref: Normative reference to an Informational draft: draft-ietf-pana-usage-scenarios (ref. 'USAGE') -- Possible downref: Non-RFC (?) normative reference: ref. '8021X' -- No information found for draft-ietf-pana-threats - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SECTHREAT' == Outdated reference: A later version (-09) exists of draft-ietf-eap-rfc2284bis-01 -- Possible downref: Normative reference to a draft: ref. 'MULTILINK' ** Obsolete normative reference: RFC 3344 (ref. 'MIPV4') (Obsoleted by RFC 5944) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-21 ** Obsolete normative reference: RFC 3012 (ref. 'MNAAA') (Obsoleted by RFC 4721) ** Obsolete normative reference: RFC 2461 (ref. 'NDISC') (Obsoleted by RFC 4861) -- Possible downref: Non-RFC (?) normative reference: ref. 'FMIPV4' -- Possible downref: Non-RFC (?) normative reference: ref. 'FMIPV6' -- Possible downref: Non-RFC (?) normative reference: ref. 'DHCP' ** Obsolete normative reference: RFC 3041 (ref. 'PRIVACY') (Obsoleted by RFC 4941) Summary: 9 errors (**), 0 flaws (~~), 17 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PANA Working Group Alper E. Yegin, Editor 3 INTERNET-DRAFT Yoshihiro Ohba 4 Date: April 2003 Reinaldo Penno 5 Expires: October 2003 George Tsirtsis 6 Cliff Wang 8 Protocol for Carrying Authentication for 9 Network Access (PANA) 10 Requirements and Terminology 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance 16 with all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 It is expected that future IP devices will have a variety of access 37 technologies to gain network connectivity. Currently there are 38 access-specific mechanisms for providing client information to the 39 network for authentication and authorization purposes. In addition 40 to being limited to specific access media (e.g., 802.1X for IEEE 802 41 links), some of these protocols are limited to specific network 42 topologies (e.g., PPP for point-to-point links). The goal of the 43 PANA is to provide a link-layer agnostic and IPv4/IPv6 compatible 44 client-server protocol that allows a host to be authenticated for 45 network access. The protocol will run between a client's device and 46 an agent device in the network where the agent might be a client of 47 the AAA infrastructure. This document defines the common terminology 48 and identifies the requirements for PANA. 50 Table of Contents 52 Status of this Memo...............................................1 53 Abstract..........................................................1 54 Table of Contents.................................................2 55 1. Introduction...................................................3 56 2. Key Words......................................................4 57 3. Terminology....................................................4 58 4. Requirements...................................................5 59 4.1. Authentication...............................................5 60 4.1.1. Authentication of Client...................................5 61 4.1.2. Authorization, Accounting and Access Control...............6 62 4.1.3. Authentication Backend.....................................6 63 4.1.4. Identifiers................................................7 64 4.2. IP Address Assignment........................................7 65 4.3. EAP Lower Layer Requirements.................................7 66 4.4. PAA-EP Protocol..............................................8 67 4.5. Network......................................................8 68 4.5.1. Multi-access...............................................8 69 4.5.2. Disconnect Indication......................................8 70 4.5.3. Location of PAA............................................9 71 4.5.4. Secure Channel.............................................9 72 4.6. Interaction with Other Protocols............................10 73 4.7. Performance.................................................10 74 4.8. Ordered-delivery, Congestion Control........................10 75 4.9. Miscellaneous...............................................10 76 4.9.1. IP Version Independence...................................10 77 4.9.2. Denial of Service Attacks.................................10 78 4.9.3. Location Privacy..........................................10 79 5. Change Log....................................................11 80 Acknowledgements.................................................11 81 References.......................................................11 82 Authors' Addresses...............................................13 83 Appendix.........................................................14 84 Full Copyright Statement.........................................16 86 1. Introduction 88 Providing secure network access service requires access control 89 based on the authentication and authorization of the clients and the 90 access networks. Initial and subsequent client-to-network 91 authentication provides parameters that are needed to police the 92 traffic flow through the enforcement points. A protocol is needed to 93 carry authentication methods between the client and the access 94 network. IETF PANA Working Group has been chartered with the goal of 95 designing a network-layer access authentication protocol. 97 Link-layer authentication mechanisms are used as enablers of secure 98 network access. A higher-layer authentication is deemed necessary 99 when link-layer authentication mechanisms are either not available 100 for lack of technology or deployment difficulties, or not able to 101 meet the overall requirements, or when multi-layer (e.g., link-layer 102 and network-layer) authentication is needed. Currently there is no 103 standard network-layer solution for authenticating clients for 104 network access. In the absence of such a solution, some inadequate 105 standards-based solutions are deployed or non-standard ad-hoc 106 solutions are invented. [USAGE] Internet-Draft describes the problem 107 statement in detail. 109 The protocol design will be limited to defining a client-server 110 messaging protocol (i.e., a carrier) that will allow authentication 111 payload to be carried between the host/client and an agent/server in 112 the access network for authentication and authorization purposes 113 regardless of the AAA infrastructure that may (or may not) reside on 114 the network. As a network-layer protocol, it will be independent of 115 the underlying access technologies. It will also be applicable to 116 any network topology. 118 The Working Group will not invent new security protocols and 119 mechanisms but instead it will use the existing mechanisms. In 120 particular, the Working Group will not define authentication 121 protocols, key distribution or key agreement protocols, or key 122 derivation. The desired protocol can be viewed as the front-end of 123 the AAA protocol or any other protocol/mechanisms the network is 124 running at the background to authenticate its clients. It will act 125 as a carrier for an already defined security protocol or mechanism. 127 As an example, Mobile IP Working Group has already defined such a 128 carrier for Mobile IPv4 [MIPV4]. Mobile IPv4 registration request 129 message is used as the carrier for authentication extensions (MN-FA 130 [MIPV4], or MN-AAA [MNAAA]) to receive forwarding service from the 131 foreign agents. In that sense, designing the equivalent of Mobile 132 IPv4 registration request messages for general network access is the 133 goal of this work, but not defining the equivalent of MN-FA or MN- 134 AAA extensions. 136 This document defines the common terminology and identifies the 137 requirements of a protocol for PANA. These terminology and 138 requirements will be used to define and limit the scope of the work 139 to be done in this group. 141 2. Key Words 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [KEYWORDS]. 147 3. Terminology 149 Device Identifier (DI) 151 The identifier used by the network as a handle to control and 152 police the network access of a client. Depending on the access 153 technology, identifier might contain any of IP address, link- 154 layer address, switch port number, etc. of a connected device. 155 PANA authentication agent keeps a table for binding device 156 identifiers to the PANA clients. At most one PANA client 157 should be associated with a DI on a PANA authentication agent. 159 PANA Client (PaC) 161 The entity wishing to obtain network access from a PANA 162 authentication agent within a network. A PANA client is 163 associated with a network device and a set of credentials to 164 prove its identity for network access authorization. 166 PANA Authentication Agent (PAA) 168 The entity whose responsibility is to authenticate the 169 credentials provided by a PANA client and grant network 170 access service to the device associated with the client 171 and identified by a DI. 173 Enforcement Point (EP) 175 A node on the access network where per-packet 176 enforcement policies (i.e., filters) are applied on the inbound 177 and outbound traffic of client devices. Information such as DI 178 and (optionally) cryptographic keys are provided by PAA per 179 client for constructing filters on the EP. 181 4. Requirements 183 4.1. Authentication 185 4.1.1. Authentication of Client 187 PANA MUST authenticate a PaC for network access. A PaC can be 188 identified by the credentials (e.g., identifier, authenticator) 189 supplied by one of the users of the device or the device itself. 190 PANA MUST only grant network access service to the device identified 191 by the DI, rather than granting separate access to multiple 192 simultaneous users of the device. Once the network access is granted 193 to the device, the methods used by the device on arbitrating which 194 one of its users can access the network is outside the scope of 195 PANA. 197 PANA MUST NOT define new security protocols or mechanisms. Instead, 198 it MUST be defined as a "carrier" for such protocols. PANA MUST 199 identify which specific security protocol(s) or mechanism(s) it can 200 carry (the "payload"). The current thinking is that a sufficient 201 solution would be for PANA to carry EAP [EAP]. If PANA WG decides 202 that extensions to EAP are needed, it will define requirements for 203 the EAP WG instead of designing such extensions. 205 Providing authentication, integrity and replay protection for data 206 traffic after a successful PANA exchange is outside the scope of 207 this protocol. In networks where physical layer security is not 208 present, link-layer or network-layer (e.g., IPsec) ciphering can be 209 used to provide such security. These mechanisms require presence of 210 cryptographic keying material at PaC and EP, which can be generated 211 by various EAP methods. Although PANA does not deal with key 212 derivation or distribution, it indirectly enables this by the virtue 213 of carrying EAP. The keying material produced by EAP methods cannot 214 be directly used with IPsec. In that case these initial keys can be 215 used with an IPsec key management protocol like IKE to generate the 216 required security associations. Key distribution from PAA to EP 217 SHOULD be handled by a separate protocol that takes care of 218 provisioning in the network (see section 4.3). Providing a complete 219 secure network access solution by also securing router discovery 220 [RDISC], neighbor discovery [NDISC], and address resolution 221 protocols [ARP] is outside the scope as well. Securing IPv6 router 222 discovery and neighbor discovery protocols are within the scope of 223 IETF SEND Working Group. 225 Some access networks might require or allow their clients to get 226 authenticated and authorized by the NAP (network access provider) 227 and ISP before the clients gain network access. NAP is the owner of 228 the access network who provides physical and link-layer connectivity 229 to the clients. PANA MUST be capable of enabling two independent 230 authentication operations (i.e., execution of two separate EAP 231 methods) for the same client. Determining the authorization 232 parameters as a result of two separate authentications is an 233 operational issue and therefore it is outside the scope of PANA. 235 Both the PaC and the PAA MUST be able to authenticate each other for 236 network access. Providing capability of only PAA authenticating the 237 PaC is not sufficient. 239 PANA MUST be capable of carrying out both periodic and on-demand re- 240 authentication. Both the PaC and the PAA MUST be able to initiate 241 both the initial authentication and the re-authentication process. 243 Certain type of service theft is possible when the DI is not 244 protected during or after the PANA exchange [SECTHREAT]. PANA MUST 245 have the capability to exchange DI securely between the PAC and PAA 246 where the network is vulnerable to man-in-the-middle attacks. While 247 PANA MUST provide such a capability, its utility relies on the use 248 of an authentication method that can generate keys for cryptographic 249 computations on PaC and PAA. 251 4.1.2. Authorization, Accounting and Access Control 253 In addition to carrying authentication information, PANA MUST also 254 provide only a binary authorization to indicate whether the PaC is 255 allowed to access full IP services on the network (i.e., able to 256 send and receive any IP packets). Providing finer granularity 257 authorization, such as negotiating QoS parameters, authorizing 258 individual services (e.g., http vs. ssh), individual users sharing 259 the same device, etc. are outside the scope of PANA. 261 Providing access control functionality in the network is outside the 262 scope of PANA. Client access authentication SHOULD be followed by 263 access control to make sure only authenticated and authorized 264 clients can send and receive IP packets via access network. Access 265 control can involve setting access control lists on the EPs. 266 Identification of clients that are authorized to access the network 267 is done by the PANA protocol exchange. 269 Carrying accounting data is outside the scope of PANA. 271 4.1.3. Authentication Backend 273 PANA protocol MUST NOT make any assumptions on the backend 274 authentication protocol or mechanisms. PAA MAY interact with backend 275 AAA infrastructures such as RADIUS or Diameter, but it is not a 276 requirement. When the access network does not rely on an IETF- 277 defined AAA protocol (e.g., RADIUS, Diameter), then it can still use 278 a proprietary backend system, or rely on the information locally 279 stored on the authentication agents. 281 The interaction between the PAA and the backend authentication 282 entities is outside the scope of PANA. 284 4.1.4. Identifiers 286 PANA SHOULD allow various types of identifiers to be used for the 287 PaC (e.g., NAI, IP address, FQDN, etc.). This requirement generally 288 relies on the client identifiers supported by various EAP methods. 290 PANA SHOULD allow various types of identifiers to be used as the DI 291 (e.g., IP address, link-layer address, port number of a switch, 292 etc.) 294 PAA MUST be able to create a binding between the PaC and the 295 associated DI upon successful PANA exchange. The DI MUST be carried 296 either explicitly as part of the PANA payload, or implicitly as the 297 source of the PANA message, or both. Multi-access networks also 298 require use of a cryptographic protection along with DI filtering to 299 prevent unauthorized access [SECTHREAT]. The keying material 300 required by the cryptographic methods needs to be stored as an 301 attribute of DI. The binding between DI and PaC is used for access 302 control and accounting in the network as described in section 4.1.2. 304 4.2. IP Address Assignment 306 Providing address assignment functionality is outside the scope of 307 PANA. PANA protocol design MAY require the PaC to configure an IP 308 address before using this protocol. Allocating an IP address to 309 unauthenticated PaCs may create security vulnerabilities, such as IP 310 address depletion attacks on the access network [SECTHREAT]. This 311 threat may not be an issue for IPv6 because of the large address 312 space, but it can affect IPv4 networks. This threat can be mitigated 313 by allowing the protocol to run without an IP address on the PaC 314 (i.e., using unspecified source address). Such a design choice might 315 limit the re-use of existing security mechanisms, and impose 316 additional implementation complexity. This trade off should be taken 317 into consideration in designing PANA. 319 4.3. EAP Lower Layer Requirements 321 EAP protocol itself imposes various requirements on its transport 322 protocols. These requirements are based on the nature of the EAP 323 protocol, and needs to be satisfied for correct operation. Please 324 see [EAP] for the generic transport requirements that MUST be 325 satisfied by PANA as well. 327 4.4. PAA-EP Protocol 329 PANA does not assume that the PAA is always co-located with the 330 EP(s). Network access enforcement can be provided by one or more 331 nodes on the same IP subnet as the client (e.g., multiple routers), 332 or on another subnet in the access domain (e.g., gateway to the 333 Internet, depending on the network architecture). When the PAA and 334 the EP(s) are separated, there needs to be another transport for 335 client provisioning. This transport is needed to create access 336 control lists to allow authenticated and authorized clients� traffic 337 through the EPs. This WG will preferably identify an existing 338 protocol solution that allows the PAA to deliver the authorization 339 information to one or more EPs when the PAA is separated from EPs. 340 Possible candidates include but not limited to COPS, SNMP, DIAMETER. 341 This task is similar to what MIDCOM Working Group is trying to 342 achieve, therefore some of that WG�s output might be useful here. 344 It is assumed that the communication between PAA and EP(s) is 345 secure. The objective of using this protocol is to provide filtering 346 rules to EP(s) for allowing network access of a recently 347 authenticated and authorized PaC. The chosen protocol MUST be 348 capable of carrying DI and cryptographic keys for a given PaC from 349 PAA to EP. Depending on the PANA protocol design, support for either 350 of the pull model (i.e., EP initiating the PAA-EP protocol exchange 351 per PaC) or the push model (i.e., PAA initiating the PAA-EP protocol 352 exchange per PaC), or both MAY be required. For example, if the 353 design is such that the EP allows the PANA traffic to bypass even 354 for unauthenticated PaCs, it should also allow and expect the PAA to 355 send the filtering information at the end of successful PANA without 356 EP ever sending a request. 358 4.5. Network 360 4.5.1. Multi-access 362 Protocol MUST support PaCs with multiple interfaces, and networks 363 with multiple routers on multi-access links. In other words, PANA 364 MUST not assume PaC has only one network interface, or the access 365 network has only one first hop router, or the PaC is using a point- 366 to-point link. 368 4.5.2. Disconnect Indication 370 PANA MUST NOT assume that the link is connection-oriented. Links MAY 371 or MAY NOT provide disconnect indication. Such notification is 372 desirable in order for the PAA to cleanup resources when a client 373 moves away from the network (e.g., inform the enforcement points 374 that the client is no longer connected). PANA SHOULD have a 375 mechanism to provide disconnect indication. When such indications 376 are not protected by means of physical or link-layer mechanisms, 377 PANA MUST ensure this protection to prevent attackers from 378 leveraging this extension for DoS attacks. 380 This mechanism MUST allow the PAA to be notified about the departure 381 of a PaC from the network. This mechanism MUST also allow a PaC to 382 be notified about the discontinuation of the network access service. 383 Access discontinuation can happen due to various reasons such as 384 network systems going down, or a change in access policy. 386 In case the clients cannot send explicit disconnect messages to the 387 PAA, PAA can still detect their departure by relying on periodic 388 authentication requests. 390 4.5.3. Location of PAA 392 The PAA and PaC MUST be exactly one IP hop away from each other. 393 That means, there must be no IP routers between two. Note that, this 394 does not mean they are on the same physical link. Bridging 395 techniques can place two nodes just exactly one IP hop away from 396 each other although they might be connected to separate physical 397 links. Furthermore, two nodes on the same IP subnet does not 398 necessarily satisfy this requirement, as they can be more than one 399 hop away from each other [MULTILINK]. PAA can be on the NAS (network 400 access server) or WLAN access point or first hop router. The use of 401 PANA when the PAA is multiple IP hops away from the PaC is outside 402 the scope of PANA. 404 A PaC MAY not be pre-configured with the IP address of PAA. 405 Therefore PANA protocol MUST define a dynamic discovery method. 406 Given that the PAA is one hop away from the PaC, there are a number 407 of discovery techniques that could be used (e.g., multicast or 408 anycast) by the PaC to find out the address of the PAA. 410 4.5.4. Secure Channel 412 PANA MUST not assume presence of a secure channel between the PaC 413 and the PAA. PANA MUST be able to provide authentication especially 414 in networks which are not protected against eavesdropping and 415 spoofing. PANA MUST enable protection against replay attacks on both 416 PaCs and PAAs. 418 This requirement partially relies on the EAP protocol and the EAP 419 methods carried over PANA. Use of EAP methods that provide mutual 420 authentication and key derivation/distribution is essential for 421 satisfying this requirement. EAP does not make a secure channel 422 assumption, and supports various authentication methods that can be 423 used in such environments. Additionally, PANA MUST ensure its design 424 does not contain vulnerabilities that can be exploited when it is 425 used over insecure channels. PANA MAY provide a secure channel by 426 deploying a two-phase authentication. First phase can be used for 427 creation of the secure channel, and the second phase is for client 428 and network authentication. 430 4.6. Interaction with Other Protocols 432 Mobility management is outside the scope of PANA. Though, PANA MUST 433 be able to co-exist and not interfere with various mobility 434 management protocols, such as Mobile IPv4 [MIPV4], Mobile IPv6 435 [MIPV6], fast handover protocols [FMIPV4, FMIPV6], and other 436 standard protocols like IPv6 stateless address auto-configuration 437 [ADDRCONF] (including privacy extensions [PRIVACY]), and DHCP 438 [DHCP]. It MUST NOT make any assumptions on the protocols or 439 mechanisms used for IP address configuration of the PaC. 441 4.7. Performance 443 PANA design SHOULD give consideration to efficient handling of 444 authentication process. This is important for gaining network access 445 with minimum latency. As an example, a method like minimizing the 446 protocol signaling by creating local security associations can be 447 used for this purpose. 449 4.8. Ordered-delivery, Congestion Control 451 PANA MUST provide ordered-delivery for messages that carry EAP PDUs 452 as described in [EAP]. PANA MUST provide congestion control for all 453 messages. It can do so by using techniques like delayed 454 initialization and exponential back off. 456 4.9. Miscellaneous 458 4.9.1. IP Version Independence 460 PANA MUST work with both IPv4 and IPv6. 462 4.9.2. Denial of Service Attacks 464 PANA MUST be robust against a class of DoS attacks such as blind 465 masquerade attacks through IP spoofing that swamp the PAA in 466 spending much resources and/or prevent legitimate clients' attempts 467 of network access. 469 4.9.3. Location Privacy 471 Location privacy is outside the scope of PANA. 473 5. Change Log 475 Version 05 477 * Definition of EP added. 478 * Text is clarified to indicate some of the requirements are 479 satisfied by EAP and EAP methods. 480 * IP address pre-configuration requirement changed. 481 * EAP lower layer requirements section added. 482 * Location of PAA further clarified (link vs. subnet vs. IP hops). 483 * PAA-EP protocol section added. 485 Version 04 487 * Minor Editorial corrections. 488 * Inserted the PANA model appendix. 490 Version 03 492 * In section 4.2.2 the requirement for a heartbeat mechanism to 493 provide disconnect indication was removed. Rewording of the 494 section was done. 495 * In section 4.2.3 and 4.1.2 rewording was done to account for the 496 separation of PAA and EP and the protocol between them. 497 * In section 4.2.4 new text was added to account for the possibility 498 to rely on the high layer protocol (EAP) to meet the requirements 499 stated. 500 * In section 4.5 new text was added to allow reliability and 501 congestion control to be provided by the payload protocol, e.g., 502 EAP. 504 Acknowledgements 506 We would like to thank Subir Das, Lionel Morand, Mohan 507 Parthasarathy, Basavaraj Patil and the PANA Working Group members 508 for their valuable contributions to the discussions and preparation 509 of this document. 511 References 513 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 514 Requirement Levels", RFC 2119, March 1997. 516 [USAGE] Y. Ohba, S. Das, B. Patil, H. Soliman, A. Yegin, "Problem 517 Statement and Usage Scenarios for PANA", draft-ietf-pana-usage- 518 scenarios-05.txt, April 2003. Work in progress. 520 [8021X] "IEEE Standards for Local and Metropolitan Area Networks: 521 Port Based Network Access Control", IEEE Draft 802.1X/D11, March 522 2001. 524 [SECTHREAT] M. Parthasarathy, "PANA Threat Analysis and Security 525 Requirements", draft-ietf-pana-threats-03.txt, April 2003. Work in 526 progress. 528 [EAP] L. Blunk, J. Vollbrecht, B. Aboba, J. Carlson, "Extensible 529 Authentication Protocol (EAP)", draft-ietf-eap-rfc2284bis-01.txt, 530 January 2003. Work in progress. 532 [MULTILINK] D. Thaler, C. Huitema, "Multi-link Subnet Support in 533 IPv6", draft-ietf-ipv6-multilink-subnets-00.txt, December 2002. Work 534 in progress. 536 [PPP] W. Simpson (editor), "The Point-To-Point Protocol (PPP)", STD 537 51, RFC 1661, July 1994. 539 [MIPV4] C. Perkins (editor), "IP Mobility Support for IPv4", RFC 540 3344, August 2002. 542 [MIPV6] D. Johnson and C. Perkins, "Mobility Support in IPv6", 543 draft-ietf-mobileip-ipv6-21.txt, February 2003. Work in progress. 545 [MNAAA] C. Perkins, P. Calhoun, "Mobile IPv4 Challenge/Response 546 Extensions", RFC3012, November 2000. 548 [NDISC] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery 549 for IP Version 6 (IPv6)",RFC 2461, December 1998. 551 [ARP] D. Plummer, "An Ethernet Address Resolution Protocol", STD 37, 552 RFC 826, November 1982. 554 [FMIPV4] K. ElMalki (editor), et. al., "Low latency Handoffs in 555 Mobile IPv4", November 2001. Work in progress. 557 [FMIPV6] R. Koodli (editor), et. al., "Fast Handovers for Mobile 558 IPv6", March 2003. Work in progress. 560 [DHCP] R. Droms (editor), et. al., "Dynamic Host Configuration 561 Protocol for IPv6", November 2002. Work in progress. 563 [PRIVACY] T. Narten, R. Draves, "Privacy Extensions for Stateless 564 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 566 Authors' Addresses 568 Alper E. Yegin 569 DoCoMo USA Labs 570 181 Metro Drive, Suite 300 571 San Jose, CA, 95110 572 USA 573 Phone: +1 408 451 4743 574 Email: alper@docomolabs-usa.com 576 Yoshihiro Ohba 577 Toshiba America Research, Inc. 578 P.O. Box 136 579 Convent Station, NJ, 07961-0136 580 USA 581 Phone: +1 973 829 5174 582 Email: yohba@tari.toshiba.com 584 Reinaldo Penno 585 Nortel Networks 586 600 Technology Park 587 Billerica, MA, 01821 588 USA 589 Phone: +1 978 288 8011 590 Email: rpenno@nortelnetworks.com 592 George Tsirtsis 593 Flarion Technologies 594 Bedminster One 595 135 Route 202/206 South 596 Bedminster, NJ, 07921 597 USA 598 Phone : +44 20 88260073 599 E-mail: G.Tsirtsis@Flarion.com, gtsirt@hotmail.com 601 Cliff Wang 602 Smart Pipes 603 565 Metro Place South 604 Dublin, OH, 43017 605 USA 606 Phone: +1 614 923 6241 607 Email: cwang@smartpipes.com 609 Appendix 611 A. PANA Model 613 Following sub-sections capture the PANA usage model in different 614 network architectures with reference to its placement of logical 615 elements such as PANA Client (PaC) and PANA Authentication Agent 616 (PAA) w.r.t Enforcement Point (EP) and Access Router (AR). Four 617 different scenarios are described in following sub-sections. Note 618 that PAA may or may not use AAA infrastructure to verify the 619 credentials of PaC to authorize network access. 621 A.1. PAA Co-located with EP but separated from AR 623 In this scenario (Figure 1), PAA is co-located with the enforcement 624 point on which access control is performed. PaCs communicate with 625 the PAA for network access on behalf of a device (D1, D2, etc.). 626 PANA in this case provides a means to transport the authentication 627 parameters from the PaC to PAA. PAA understands how to verify the 628 credentials. After verification, PAA sends back the success or 629 failure response to PaC. However, PANA does not play any explicit 630 role in performing access control except that it provides a hook to 631 access control mechanisms. This might be the case where PAA is co- 632 located with the access point (an IP-capable L2 access device). 634 PaC -----EP/PAA-+ 635 [D1] | 636 +- ----- AR ----- (AAA) 637 | 638 PaC -----EP/PAA-+ 639 [D2] 641 Figure 1: PAA co-located with EP but separated from AR. 643 A.2. PAA Co-located with AR but separated from EP 645 Figure 2 describes this model. In this scenario, PAA is not co- 646 located with EPs but it is placed on the AR. Although we have shown 647 only one AR here there could be multiple ARs one of which is co- 648 located with the PAA. PaC exchanges the same messages with PAA as 649 discussed earlier. The difference here is when the initial 650 authentication for the PaC succeeds, access control parameters are 651 to be distributed to respective enforcement points so that the 652 corresponding device on which PaC is authenticated must be able to 653 access to the network. Similar to the earlier case, PANA does not 654 play any explicit role in performing access control except that it 655 provides a hook to access control mechanisms. However, a separate 656 protocol is needed between PAA and EP to carry access control 657 parameters. 659 PaC -------- EP --+ 660 [D1] | 661 +--- AR/PAA --- (AAA) 662 | 663 PaC -------- EP --+ 664 [D2] 666 Figure 2: PAA co-located with AR but separated from EP. 668 A.3. PAA Co-located with EP and AR 670 In this scenario (Figure 3), PAA is co-located with the EP and AR on 671 which access control and routing are performed. PaC exchanges the 672 same messages with PAA and PAA performs similar functionalities as 673 above. PANA in this case also does not play any explicit role in 674 performing access control except that it provides a hook to access 675 control mechanisms. 677 PaC ---------- EP/PAA/AR--+ 678 [D1] | 679 + -------(AAA) 680 | 681 PaC ---------- EP/PAA/AR--+ 682 [D2] 684 Figure 3: PAA co-located with EP and AR. 686 A.4. PAA Separated from EP and AR 688 Figure 4 represents this model. In this scenario, PAA is neither co- 689 located with EPs nor with Ars. It still resides on the same IP link 690 as ARs. PaC does similar exchanges with PAA as discussed earlier. 691 Similar to model in A.2, after successful authentication, access 692 control parameters will be distributed to respective enforcement 693 points via a separate protocol and PANA does not play any explicit 694 role in this. 696 PaC ----- EP -----+- AR -----+ 697 | | 698 PaC ----- EP --- -+ | 699 | | 700 PaC ----- EP -----+- AR ---- + ----(AAA) 701 | 702 +- PAA 704 Figure 4: PAA separated from EP and AR. 706 Full Copyright Statement 708 "Copyright (C) The Internet Society (2002). All Rights Reserved. 709 This document and translations of it may be copied and furnished to 710 others, and derivative works that comment on or otherwise explain it 711 or assist in its implementation may be prepared, copied, published 712 and distributed, in whole or in part, without restriction of any 713 kind, provided that the above copyright notice and this paragraph 714 are included on all such copies and derivative works. However, this 715 document itself may not be modified in any way, such as by removing 716 the copyright notice or references to the Internet Society or other 717 Internet organizations, except as needed for the purpose of 718 developing Internet standards in which case the procedures for 719 copyrights defined in the Internet Standards process must be 720 followed, or as required to translate it into languages other than 721 English. 723 The limited permissions granted above are perpetual and will not be 724 revoked by the Internet Society or its successors or assigns. 726 This document and the information contained herein is provided on an 727 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 728 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 729 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 730 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 731 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.