idnits 2.17.00 (12 Aug 2021) /tmp/idnits5468/draft-yegin-pana-unspecified-addr-01.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 8, 2010) is 4457 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 335, 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 -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 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 9, 2010 Toshiba 6 L. Morand 7 Orange Labs 8 J. Kaippallimalil 9 Huawei USA 10 March 8, 2010 12 Protocol for Carrying Authentication for Network Access (PANA) with IPv4 13 Unspecified Address 14 draft-yegin-pana-unspecified-addr-01 16 Abstract 18 This document defines how PANA client (PaC) can perform PANA 19 authentication prior to configuring an IP address. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on September 9, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Specification of Requirements . . . . . . . . . . . . . . . 3 63 2. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. PaC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. PAA Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5. AVP Definition . . . . . . . . . . . . . . . . . . . . . . . . 6 67 5.1. Token AVP . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 6. Message Size Considerations . . . . . . . . . . . . . . . . . . 6 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 71 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 74 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 PANA (Protocol for carrying Authentication for Network Access) 80 [RFC5191] as a UDP-based protocol operates with the assumption that 81 the PANA client (PaC) is already configured with an IP address. 82 Private IPv4, globally-routable IPv4 [RFC1918] or IPv6, IPv4 or IPv6 83 link-local are the types of addresses that can be configured by PaCs 84 prior to running PANA [RFC5193]. 86 In case the PaC and the PANA Authentication Agent (PAA) are on the 87 same IP subnet where all hosts in the subnet can be reached in one 88 routing hop, the PaC can run PANA with the PAA prior to configuring 89 an IP address. 91 This document defines an extension of PANA to allow the PaC to use 92 IPv4 unspecified address (0.0.0.0) until it gets authenticated/ 93 authorized; and configures an IP address afterwards (possibly using 94 DHCP). Such a feature is already available in Mobile IPv4 [RFC3344] 95 where MN can use unspecified IPv4 address with Mobile IP protocol 96 until it is assigned a home address, and also DHCP [RFC2131]. 98 1.1. Specification of Requirements 100 In this document, several words are used to signify the requirements 101 of the specification. These words are often capitalized. The key 102 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 103 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 104 are to be interpreted as described in [RFC2119]. 106 2. Details 108 Figure 1 is an example call flow that illustrates use of unspecified 109 IPv4 address with the PaC during PANA authentication. Note that 110 there can be other ways for combining DHCP and PANA call flows. 112 PaC PAA AAA 114 | | | 115 | | | 116 | | | 117 |--1. PANA Client initiation(Token)->| | 118 | | | 119 |<-2. PANA Auth Req(Token)-----------| | 120 | | | 121 |--3. PANA Auth Ans ---------------->| | 122 | | | 123 | |-4. RADIUS Access ->| 124 | | Request (EAP) | 125 | | | 126 | |<-5. RADIUS Access--| 127 | | (EAP Success) | 128 |<-6. PANA Auth Req -----------------| | 129 | | | 130 |--7. PANA Auth Ans ---------------->| | 131 | | | 132 |--8. DHCP Discover----------------->| | 133 | | | 134 |<-9. DHCP Offer---------------------| | 135 | | | 136 |--10. DHCP Request----------------->| | 137 | | | 138 |<-11. DHCP Ack----------------------| | 139 | | | 140 |<-12. IP session data traffic----------------> | 141 | | | 143 Figure 1: Example Call Flow for PANA with IPv4 Unspecified Address 145 Step 1: The PaC initiates PANA by sending a broadcasted PCI carrying 146 a Token AVP that contains a random value generated by the PaC. 148 The source IPv4 address of the PCI is set to 0.0.0.0. The 149 destination IPv4 address is set to 255.255.255.255. 151 Step 2: The PAA responds with a PAR message that includes the token 152 generated by the PaC. The PAR message has its source IPv4 address 153 set to the PAA's IP address, and the destination IPv4 address is set 154 to 255.255.255.255. If the PAA is capable of retrieving the PaC's L2 155 address from incoming PCI, then the PAR is L2-unicast using that L2 156 address. Otherwise, the PAR message will be L2-broadcast. 158 The PaC discovers the PAA's IPv4 address when it receives the PAR 159 message. 161 Step 3: The PaC sends the PAN message to the PAA's newly discovered 162 IPv4 address. 164 Steps 4-7: PANA and RADIUS carrying out the selected EAP method. 166 Steps 8-11: Now that the PaC is authenticated, it proceeds to 167 configuring service IP address using DHCPv4. As soon as the new IPv4 168 address is confirmed by the DHCPACK, the PaC can stop using the 169 unspecified address. 171 Step 12: The PaC can transmit and receive IP data packets using its 172 IP address. 174 A PAA implementation may not be capable of retrieving the PaC's L2 175 address from L2 header of the incoming PANA messages, or be able to 176 send a L2-unicast even if it could retrieve the address. In such a 177 case, the PAA sends PANA messages as L2-broadcast. In order to 178 prevent other PaCs from processing the messages destined for a 179 specific PaC, each PaC is required to supply a randomly generated 180 token as a payload AVP to PCI and expect it to be echoed back by the 181 PAA in the initial PAR. Token AVP is defined for this purpose. 183 Note that any message beyond Step 2 would include the PAA-assigned 184 and PaC-acknowledged PANA Session Id, hence use of Token AVP is not 185 needed for those messages. 187 3. PaC Behavior 189 A PaC SHALL use unspecified address as its source IP address until it 190 configures another IP address. The PaC SHALL send a PCI carrying a 191 Token AVP. The PaC SHOULD NOT include a Token AVP in any other 192 message. 194 The PaC SHALL silently drop any PAR that carries a Token AVP whose 195 token value does not match the one contained in the PCI sent by the 196 PaC. 198 The PaC, before it sends the first PAN to the PAA, SHALL silently 199 drop any PAR that is L2-broadcast and without carrying a Token AVP. 201 Any legacy PaC that does not implement this specification will 202 automatically drop the incoming PAR that carries the Token AVP as 203 this is an unrecognized AVP. This is the standard behavior defined 204 in [RFC5191]. 206 4. PAA Behavior 208 If a PAA receives a PCI whose source IP address is unspecified but 209 that does not carry a Token AVP, then it SHALL drop the PCI. The PAA 210 SHALL ignore a Token AVP if it is contained in any message other than 211 PCI. 213 When the PAA needs to send a packet to a PaC that is using an 214 unspecified IP address, then the PAA shall set the destination IP 215 address to 255.255.255.255. The PAA SHOULD set the destination L2 216 address to the source L2 address retrieved from the incoming PaC 217 packet, when possible; otherwise set to L2 broadcast address. If 218 this is the very first PAR message sent to L2 broadcast address in 219 response to a PCI message containing a Token AVP, then the PAA SHALL 220 include a Token AVP copied from the PCI. The PAA SHOULD NOT include 221 a Token AVP in any other PANA message, as an already-assigned PANA 222 Session Id serves the need. 224 The PAA SHALL set the 'I' (IP Reconfiguration) bit of PAR messages in 225 authentication and authorization phase so that the PaC proceeds to IP 226 address configuration. 228 Any legacy PAA that does not implement this specification would 229 automatically drop the incoming PCI that carries the Token AVP as 230 this is an unrecognized AVP. This is the standard behavior defined 231 in [RFC5191]. 233 5. AVP Definition 235 This document defines one new AVP as described below. 237 5.1. Token AVP 239 The Token AVP (AVP Code TBD) is of type Unsigned64 containing a 240 random value generated by the PaC. 242 6. Message Size Considerations 244 Since IP fragmentation for IP packets using unspecified address is 245 prohibited, link-layer MTU needs to be no less than the IP packet 246 size carrying the largest PANA message in the case where EAP message 247 size is the same as the minimum EAP MTU size (i.e., 1020 octets 248 [RFC3748]). Such a PANA message is the very first PANA-Auth-Request 249 message in Authentication and Authorization phase carrying the 250 following AVPs. 252 o An EAP-Payload AVP that carries an EAP-Request of size being equal 253 to the minimum EAP MTU size. The size of such an AVP is 1020 + 8 254 = 1028 octets. 256 o A Nonce AVP that carries the largest nonce of size 256 octets. 257 The size of such an AVP is 256 + 8 = 264 octets. 259 o An Integrity-Algorithm AVP (12 octets) 261 o A PRF-Algorithm AVP (12 octets) 263 o A Token AVP (16 octets) 265 In this case, the PANA message size including PANA header (16 266 octets), UDP header (8 octets) and IPv4 header (20 octets) is 1028 + 267 264 + 12 + 12 + 16 + 16 + 8 + 20 = 1376 octets. Therefore, the link- 268 layer MTU size for IP packets MUST be no less than 1376 octets when 269 unspecified IPv4 address is used for PANA. Note that Ethernet (MTU = 270 1500 octets) meets this requirement. 272 PANA as an EAP lower-layer reports the EAP MTU to the EAP layer, so 273 that EAP methods can perform appropriate fragmentation [RFC3748]. 274 The EAP MTU is calculated as follows: 276 EAP_MTU = L2_MTU - 356 278 In the above formula, the value of 356 is the PANA overhead (IP, UDP 279 and PANA headers, and PANA AVPs except for the EAP-Payload AVP 280 payload). 282 7. Security Considerations 284 When the PAA is not capable of L2-unicasting PANA messages to the 285 target PaC, other nodes on the same subnet can receive those 286 messages. This may pose a risk if there is any confidential data 287 exposed in the messages. Typically no such exposure exists as PANA, 288 EAP, an EAP methods are defined in a way they can also be used in 289 wireless networks where snooping is always a possibility. 291 8. IANA Considerations 293 As described in Section 5.1 and following the new IANA allocation 294 policy on PANA message [I-D.arkko-pana-iana], a new AVP Code for 295 Token AVP needs to be assigned by IANA. 297 9. Acknowledgments 299 TBD. 301 10. References 303 10.1. Normative References 305 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 306 Yegin, "Protocol for Carrying Authentication for Network 307 Access (PANA)", RFC 5191, May 2008. 309 [RFC5193] Jayaraman, P., Lopez, R., Ohba, Y., Parthasarathy, M., and 310 A. Yegin, "Protocol for Carrying Authentication for 311 Network Access (PANA) Framework", RFC 5193, May 2008. 313 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 314 Levkowetz, "Extensible Authentication Protocol (EAP)", 315 RFC 3748, June 2004. 317 [I-D.arkko-pana-iana] 318 Arkko, J. and A. Yegin, "IANA Rules for PANA (Protocol for 319 Carrying Authentication for Network Access)", 320 draft-arkko-pana-iana-02 (work in progress), 321 February 2010. 323 10.2. Informative References 325 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 326 E. Lear, "Address Allocation for Private Internets", 327 BCP 5, RFC 1918, February 1996. 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, March 1997. 332 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 333 RFC 2131, March 1997. 335 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 336 Networks", RFC 2464, December 1998. 338 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 339 August 2002. 341 Authors' Addresses 343 Alper Yegin 344 Samsung 345 Istanbul 346 Turkey 348 Email: alper.yegin@yegin.org 350 Yoshihiro Ohba 351 Toshiba Corporate Research and Development Center 352 1 Komukai-Toshiba-cho 353 Saiwai-ku, Kawasaki, Kanagawa 212-8582 354 Japan 356 Phone: +81 44 549 2230 357 Email: yoshihiro.ohba@toshiba.co.jp 359 Lionel Morand 360 Orange Labs 362 Phone: +33 1 4529 62 57 363 Email: Lionel.morand@orange-ftgroup.com 365 John Kaippallimalil 366 Huawei USA 367 1700 Alma Dr., Suite 500 368 Plano, TX 75082 369 USA 371 Phone: +1 214 606 2005 372 Email: jkaippal@huawei.com