idnits 2.17.00 (12 Aug 2021) /tmp/idnits5076/draft-yegin-pana-unspecified-addr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 1, 2010) is 4464 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: 'RFC2464' is defined on line 341, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5193 == Outdated reference: draft-arkko-pana-iana has been published as RFC 5872 -- Possible downref: Non-RFC (?) normative reference: ref. 'IANAADFAM' -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Yegin 3 Internet-Draft Samsung 4 Intended status: Standards Track Y. Ohba 5 Expires: September 2, 2010 Toshiba 6 March 1, 2010 8 Protocol for Carrying Authentication for Network Access (PANA) with IPv4 9 Unspecified Address 10 draft-yegin-pana-unspecified-addr-00 12 Abstract 14 This document defines how PANA client (PaC) can perform PANA 15 authentication prior to configuring an IP address. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on September 2, 2010. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Specification of Requirements . . . . . . . . . . . . . . . 3 59 2. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. PaC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. PAA Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5. AVP Definition . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5.1. PAC-L2-ADDR AVP . . . . . . . . . . . . . . . . . . . . . . 6 64 6. Message Size Considerations . . . . . . . . . . . . . . . . . . 6 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 67 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 70 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 PANA (Protocol for carrying Authentication for Network Access) 76 [RFC5191] as a UDP-based protocol operates with the assumption that 77 the PANA client (PaC) is already configured with an IP address. 78 Private IPv4, globally-routable IPv4 [RFC1918] or IPv6, IPv4 or IPv6 79 link-local are the types of addresses that can be configured by PaCs 80 prior to running PANA [RFC5193]. 82 In case the PaC and the PANA Authentication Agent (PAA) are on the 83 same IP subnet, PaC can run PANA with the PAA prior to configuring an 84 IP address. 86 This document defines an extension of PANA to allow the PaC to use 87 IPv4 unspecified address (0.0.0.0) until it gets authenticated/ 88 authorized; and configures an IP address afterwards (possibly using 89 DHCP). Such a feature is already available in Mobile IPv4 [RFC3344] 90 where MN can use unspecified IPv4 address with Mobile IP protocol 91 until it is assigned a home address, and also DHCP [RFC2131]. 93 1.1. Specification of Requirements 95 In this document, several words are used to signify the requirements 96 of the specification. These words are often capitalized. The key 97 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 98 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 99 are to be interpreted as described in [RFC2119]. 101 2. Details 103 Figure 1 is an example call flow that illustrates use of unspecified 104 IPv4 address with the PaC during PANA authentication. Note that 105 there can be other ways for combining DHCP and PANA call flows. 107 PaC PAA AAA 109 | | | 110 | | | 111 | | | 112 |--1. PANA Client initiation-------->| | 113 | | | 114 |<-2. PANA Auth Req -----------------| | 115 | | | 116 |--3. PANA Auth Ans ---------------->| | 117 | | | 118 | |-4. RADIUS Access ->| 119 | | Request (EAP) | 120 | | | 121 | |<-5. RADIUS Access--| 122 | | (EAP Success) | 123 |<-6. PANA Auth Req -----------------| | 124 | | | 125 |--7. PANA Auth Ans ---------------->| | 126 | | | 127 |--8. DHCP Discover----------------->| | 128 | | | 129 |<-9. DHCP Offer---------------------| | 130 | | | 131 |--10. DHCP Request----------------->| | 132 | | | 133 |<-11. DHCP Ack----------------------| | 134 | | | 135 |<-12. IP session data traffic----------------> | 136 | | | 138 Figure 1: Example Call Flow for PANA with IPv4 Unspecified Address 140 Step 1: The PaC initiates PANA by sending a broadcasted PCI. 142 The source IPv4 address of the PCI is set to 0.0.0.0. The 143 destination IPv4 address is set to 255.255.255.255. 145 Step 2: The PAA responds with a PAR message which has its source IPv4 146 address set to the PAA's IP address, and the destination IPv4 address 147 is set to 255.255.255.255. If the PAA is capable of retrieving the 148 PaC's L2 address from incoming PCI, then the PAR is L2-unicasted 149 using that L2 address. Otherwise, the PAR message will be L2- 150 broadcasted. 152 The PaC discovers the PAA's IPv4 address when it receives the PAR 153 message. 155 Step 3: The PaC sends the PAN message to the PAA's newly discovered 156 IPv4 address. 158 Steps 4-7: PANA and RADIUS carrying out the selected EAP method. 160 Steps 8-11: Now that the PaC is authenticated, it proceeds to 161 configuring service IP address using DHCPv4. As soon as the new IPv4 162 address is confirmed by the DHCPACK, the PaC can stop using the 163 unspecified address. 165 Step 12: The PaC can transmit and receive IP data packets using its 166 IP address. 168 A PAA implementation may not be capable of retrieving the PaC's L2 169 address from L2 header of the incoming PANA messages, or be able to 170 send a L2-unicast even if it could retrieve the address. In such a 171 case, the PAA sends PANA messages as L2-broadcast. In order to 172 prevent other PaCs from processing the messages destined for a 173 specific PaC, each PaC is required to supply its own L2 address as a 174 payload AVP to PCI and expect it to be echoed back by the PAA in the 175 initial PAR. PAC-L2-ADDR AVP is defined for this purpose. 177 [TBD: Or, alternatively a randomly-generated token can be carried 178 instead of the L2 address. It serves the same purpose.] 180 Note that any message beyond Step 2 would include the PAA-assigned 181 and PaC-acknowledged PANA Session Id, hence use of PAC-L2-ADDR AVP is 182 not needed for those messages. 184 3. PaC Behavior 186 A PaC shall use unspecified address as its source IP address until it 187 configures another IP address. The PaC shall send a PCI that carries 188 its L2 address in the PAC-L2-ADDR AVP. The PaC shall not include 189 PAC-L2-ADDR AVP in any other message. 191 The PaC shall silently drop any PAR that carries a PAC-L2-ADDR AVP 192 whose L2 address payload does not match the L2 address on the 193 receiving interface of the PaC. 195 Any legacy PaC that does not implement this specification would 196 automatically drop the incoming PAR that carries the PAC-L2-ADDR AVP 197 as this is an unrecognized AVP. This is the standard behavior 198 defined in [RFC5191]. 200 4. PAA Behavior 202 If a PAA receives a PCI whose source IP address is unspecified but 203 that does not carry a PAC-L2-ADDR AVP, then it shall drop the PCI. 204 The PAA shall drop any message with PAC-L2-ADDR AVP if the message 205 type is other than PCI. When the PAA is capable of retrieving the 206 source L2 address of the incoming packets, if the address retrieved 207 does not match the address in the PAC-L2-ADDR AVP payload, then the 208 PAA shall drop the packet. 210 When the PAA needs to send a packet to a PaC that is using an 211 unspecified IP address, then the PAA shall set the destination IP 212 address to 255.255.255.255. The PAA should set the destination L2 213 address to the source L2 address retrieved from the incoming PaC 214 packet, when possible; otherwise set to L2 broadcast address. If 215 this is the very first PAR message in PANA session, then the PAA 216 shall include a PAC-L2-ADDR AVP with the payload set to the L2 217 address of the PaC. The PAA shall not include PAC-L2-ADDR AVP in any 218 other PANA message, as an already-assigned PANA Session Id serves the 219 need. 221 The PAA shall set the 'I' (IP Reconfiguration) bit of PAR messages in 222 authentication and authorization phase so that the PaC proceeds to IP 223 address configuration. 225 5. AVP Definition 227 This document defines one new AVP as described below. 229 5.1. PAC-L2-ADDR AVP 231 The PAC-L2-ADDR AVP (AVP Code TBD) contains a link-layer address of 232 the PaC. The first two octets represents the AddressType, which 233 contains an Address Family defined in [IANAADFAM]. Address families 234 other than that are defined for link-layer MUST NOT be used for this 235 AVP. The remaining octets encode the address value. The length of 236 the address value is determined by the AddressType. The AddressType 237 is used to discriminate the content and format of the remaining 238 octets for the address value. 240 6. Message Size Considerations 242 Since IP fragmentation for IP packets using unspecified address is 243 prohibited, link-layer MTU needs to be no less than the IP packet 244 size carrying the largest PANA message in the case where EAP message 245 size is the same as the minimum EAP MTU size (i.e., 1020 octets 247 [RFC3748]). Such a PANA message is the very first PANA-Auth-Request 248 message in Authentication and Authorization phase carrying the 249 following AVPs. 251 o An EAP-Payload AVP that carries an EAP-Request of size being equal 252 to the minimum EAP MTU size. The size of such an AVP is 1020 + 8 253 = 1028 octets. 255 o A Nonce AVP that carries the largest nonce of size 256 octets. 256 The size of such an AVP is 256 + 8 = 264 octets. 258 o An Integrity-Algorithm AVP (12 octets) 260 o A PRF-Algorithm AVP (12 octets) 262 o A PAC-L2-ADDR AVP (L2_ADDR_LEN + 10 octets) where L2_ADDR_LEN 263 represents the length of the link-layer address in octets. For 264 example, L2_ADDR_LEN = 6 for IEEE 802 MAC address. 266 In this case, the PANA message size including PANA header (16 267 octets), UDP header (8 octets) and IPv4 header (20 octets) is 1028 + 268 264 + 12 + 12 + L2_ADDR_LEN + 10 + 16 + 8 + 20 = (1370 + L2_ADDR_LEN) 269 octets. Therefore, the link-layer MTU size for IP packets MUST be no 270 less than (1370 + L2_ADDR_LEN) octets when unspecified IPv4 address 271 is used for PANA. Note that Ethernet (MTU = 1500 octets) meets this 272 requirement. 274 PANA as an EAP lower-layer reports the EAP MTU to the EAP layer, so 275 that EAP methods can perform appropriate fragmentation [RFC3748]. 276 The EAP MTU is calculated as follows: 278 EAP_MTU = L2_MTU - (350 + L2_ADDR_LEN) 280 In the above formula, the value of (350 + L2_ADDR_LEN) is the PANA 281 overhead (IP and PANA headers, and PANA AVPs except for the EAP- 282 Payload AVP payload). 284 7. Security Considerations 286 When the PAA is not capable of L2-unicasting PANA messages to the 287 target PaC, other nodes on the same subnet can receive those 288 messages. This may pose a risk if there is any confidential data 289 exposed in the messages. Typically no such exposure exists as PANA, 290 EAP, an EAP methods are defined in a way they can also be used in 291 wireless networks where snooping is always a possibility. 293 8. IANA Considerations 295 As described in Section 5.1 and following the new IANA allocation 296 policy on PANA message [I-D.arkko-pana-iana], a new AVP Code for PAC- 297 L2-ADDR AVP needs to be assigned by IANA. 299 9. Acknowledgments 301 TBD. 303 10. References 305 10.1. Normative References 307 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 308 Yegin, "Protocol for Carrying Authentication for Network 309 Access (PANA)", RFC 5191, May 2008. 311 [RFC5193] Jayaraman, P., Lopez, R., Ohba, Y., Parthasarathy, M., and 312 A. Yegin, "Protocol for Carrying Authentication for 313 Network Access (PANA) Framework", RFC 5193, May 2008. 315 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 316 Levkowetz, "Extensible Authentication Protocol (EAP)", 317 RFC 3748, June 2004. 319 [I-D.arkko-pana-iana] 320 Arkko, J. and A. Yegin, "IANA Rules for PANA (Protocol for 321 Carrying Authentication for Network Access)", 322 draft-arkko-pana-iana-02 (work in progress), 323 February 2010. 325 [IANAADFAM] 326 IANA, "Address Family Numbers", 327 http://www.iana.org/assignments/address-family-numbers. 329 10.2. Informative References 331 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 332 E. Lear, "Address Allocation for Private Internets", 333 BCP 5, RFC 1918, February 1996. 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, March 1997. 338 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 339 RFC 2131, March 1997. 341 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 342 Networks", RFC 2464, December 1998. 344 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 345 August 2002. 347 Authors' Addresses 349 Alper Yegin 350 Samsung 351 Istanbul 352 Turkey 354 Email: alper.yegin@yegin.org 356 Yoshihiro Ohba 357 Toshiba Corporate Research and Development Center 358 1 Komukai-Toshiba-cho 359 Saiwai-ku, Kawasaki, Kanagawa 212-8582 360 Japan 362 Phone: +81 44 549 2230 363 Email: yoshihiro.ohba@toshiba.co.jp