idnits 2.17.1 draft-yegin-pana-unspecified-addr-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (February 14, 2012) is 4455 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2464' is defined on line 346, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) Summary: 1 error (**), 0 flaws (~~), 2 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: Informational Y. Ohba 5 Expires: August 17, 2012 Toshiba 6 L. Morand 7 Orange Labs 8 J. Kaippallimalil 9 Huawei USA 10 February 14, 2012 12 Protocol for Carrying Authentication for Network Access (PANA) with IPv4 13 Unspecified Address 14 draft-yegin-pana-unspecified-addr-06 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). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on August 17, 2012. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Specification of Requirements . . . . . . . . . . . . . . . 3 57 2. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. PaC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4. PAA Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5. AVP Definition . . . . . . . . . . . . . . . . . . . . . . . . 7 61 5.1. Token AVP . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 6. Message Size Considerations . . . . . . . . . . . . . . . . . . 7 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 65 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 68 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 PANA (Protocol for carrying Authentication for Network Access) 74 [RFC5191] as a UDP-based protocol operates with the assumption that 75 the PANA client (PaC) is already configured with an IP address. 76 Private IPv4, globally-routable IPv4 [RFC1918] or IPv6, IPv4 or IPv6 77 link-local are the types of addresses that can be configured by PaCs 78 prior to running PANA [RFC5193]. 80 In case the PaC and the PANA Authentication Agent (PAA) are on the 81 same IP subnet where all hosts in the subnet can be reached in one 82 routing hop, the PaC can run PANA with the PAA prior to configuring 83 an IP address. 85 This document defines an extension of PANA to allow the PaC to use 86 IPv4 unspecified address (0.0.0.0) until it gets authenticated/ 87 authorized; and configures an IP address afterwards (possibly using 88 DHCP). Such a feature is already available in Mobile IPv4 [RFC3344] 89 where MN can use unspecified IPv4 address with Mobile IP protocol 90 until it is assigned a home address, and also DHCP [RFC2131]. 92 This extension is defined only as a solution for use cases in which 93 PANA authentication is required prior to any kind of IP address 94 allocation or configuration. It is not intended to become the 95 default mode of operation for PANA. 97 1.1. Specification of Requirements 99 In this document, several words are used to signify the requirements 100 of the specification. These words are often capitalized. The key 101 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 102 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 103 are to be interpreted as described in [RFC2119]. 105 2. Details 107 Figure 1 is an example call flow that illustrates use of unspecified 108 IPv4 address with the PaC during PANA authentication. Note that 109 there can be other ways for combining DHCP and PANA call flows. 111 PaC PAA AAA 113 | | | 114 | | | 115 | | | 116 |--1. PANA Client initiation(Token)->| | 117 | | | 118 |<-2. PANA Auth Req(Token)-----------| | 119 | | | 120 |--3. PANA Auth Ans ---------------->| | 121 | | | 122 | |-4. RADIUS Access ->| 123 | | Request (EAP) | 124 | | | 125 | |<-5. RADIUS Access--| 126 | | (EAP Success) | 127 |<-6. PANA Auth Req -----------------| | 128 | | | 129 |--7. PANA Auth Ans ---------------->| | 130 | | | 131 |--8. DHCP Discover----------------->| | 132 | | | 133 |<-9. DHCP Offer---------------------| | 134 | | | 135 |--10. DHCP Request----------------->| | 136 | | | 137 |<-11. DHCP Ack----------------------| | 138 | | | 139 |--12. PANA Notification Req ('P')-->| | 140 | | | 141 |<-13. PANA Notification Ans ('P')---| | 142 | | | 143 |<-14. IP session data traffic----------------> | 144 | | | 146 Figure 1: Example Call Flow for PANA with IPv4 Unspecified Address 148 Step 1: The PaC initiates PANA by sending a broadcasted PCI carrying 149 a Token AVP that contains a random value generated by the PaC. 151 The source IPv4 address of the PCI is set to 0.0.0.0. The source 152 port number is chosen by the PaC. The destination IPv4 address is 153 set to 255.255.255.255. The destination port number is the PANA port 154 number (716). 156 Step 2: The PAA responds with a PAR message that includes the token 157 generated by the PaC. The PAR message has its source IPv4 address 158 set to the PAA's IP address, and the destination IPv4 address is set 159 to 255.255.255.255. If the PAA is capable of retrieving the PaC's L2 160 address from incoming PCI, then the PAR is L2-unicast using that L2 161 address. Otherwise, the PAR message will be L2-broadcast. 163 The PaC discovers the PAA's IPv4 address when it receives the PAR 164 message. 166 Step 3: The PaC sends the PAN message to the PAA's newly discovered 167 IPv4 address. 169 Steps 4-7: PANA and RADIUS carrying out the selected EAP method. 171 Steps 8-11: Now that the PaC is authenticated, it proceeds to 172 configuring service IP address using DHCPv4. In this example the PAA 173 and DHCP server are co-located. The DHCP server responds to the DHCP 174 Discover messages that are coming from authenticated PaCs while the 175 ones from unauthenticated PaCs are silently dropped. Details of how 176 the DHCP server verifies the authenticity of the PaC (e.g., via its 177 bindings to the lower-layer security) are outside the scope of this 178 specification. Scenarios involving separate PAA and DHCP server are 179 also possible. Their details are outside the scope of this 180 specification as well. As soon as the new IPv4 address is confirmed 181 by the DHCPACK, the PaC can stop using the unspecified address. 183 Steps 12 and 13: Following a change of IP address (from unspecified 184 to a DHCP-assigned one), the PaC sends a PNR message with the 'P' 185 (Ping) bit set. The PAA learns the new IP address of the PaC with 186 the help of this message. The PAA responds with a PNA message with 187 the 'P' (Ping) bit set. See [RFC5191] for detailed usage of the 'P' 188 (Ping) bit. 190 Step 14: The PaC can transmit and receive IP data packets using its 191 IP address. Step 14 can be executed in parallel with Steps 12 and 192 13. 194 A PAA implementation may not be capable of retrieving the PaC's L2 195 address from L2 header of the incoming PANA messages, or be able to 196 send a L2-unicast even if it could retrieve the address. In such a 197 case, the PAA sends PANA messages as L2-broadcast. In order to 198 prevent other PaCs from processing the messages destined for a 199 specific PaC, each PaC is required to supply a randomly generated 200 token as a payload AVP to PCI and expect it to be echoed back by the 201 PAA in the initial PAR. Token AVP is defined for this purpose. 203 Note that any message beyond Step 2 would include the PAA-assigned 204 and PaC-acknowledged PANA Session Id, hence use of Token AVP is not 205 needed for those messages. 207 3. PaC Behavior 209 A PaC SHALL use unspecified address as its source IP address until it 210 configures another IP address. The PaC SHALL send a PCI carrying a 211 Token AVP. The PaC SHOULD NOT include a Token AVP in any other 212 message. 214 The PaC SHALL silently drop any PAR that carries a Token AVP whose 215 token value does not match the one contained in the PCI sent by the 216 PaC. 218 The PaC, before it sends the first PAN to the PAA, SHALL silently 219 drop any PAR that is L2-broadcast and without carrying a Token AVP. 221 Any legacy PaC that does not implement this specification will 222 automatically drop the incoming PAR that carries the Token AVP as 223 this is an unrecognized AVP. This is the standard behavior defined 224 in [RFC5191]. 226 4. PAA Behavior 228 If a PAA receives a PCI whose source IP address is unspecified but 229 that does not carry a Token AVP, then it SHALL drop the PCI. 231 When the PAA needs to send a packet to a PaC that is using an 232 unspecified IP address, then the PAA shall set the destination IP 233 address to 255.255.255.255. The PAA SHOULD set the destination L2 234 address to the source L2 address retrieved from the incoming PaC 235 packet, when possible; otherwise set to L2 broadcast address. If 236 this is the very first PAR message sent to L2 broadcast address in 237 response to a PCI message containing a Token AVP, then the PAA SHALL 238 include a Token AVP copied from the PCI. The PAA SHOULD NOT include 239 a Token AVP in any other PANA message, as an already-assigned PANA 240 Session Id serves the need. 242 The PAA SHALL set the 'I' (IP Reconfiguration) bit of PAR messages in 243 authentication and authorization phase so that the PaC proceeds to IP 244 address configuration. See [RFC5191] for detailed usage of the 'I' 245 (IP Reconfiguration) bit. 247 Any legacy PAA that does not implement this specification would 248 automatically drop the incoming PCI that carries the Token AVP as 249 this is an unrecognized AVP. This is the standard behavior defined 250 in [RFC5191]. 252 5. AVP Definition 254 This document defines one new AVP as described below. 256 5.1. Token AVP 258 The Token AVP (AVP Code TBD) is of type Unsigned64 containing a 259 random value generated by the PaC. 261 6. Message Size Considerations 263 Since IP fragmentation for IP packets using unspecified address is 264 prohibited, link-layer MTU needs to be no less than the IP packet 265 size carrying the largest PANA message in the case where EAP message 266 size is the same as the minimum EAP MTU size (i.e., 1020 octets 267 [RFC3748]). Such a PANA message is the very first PANA-Auth-Request 268 message in Authentication and Authorization phase carrying an EAP- 269 Payload AVP. In order to limit the message size, the PAA can choose 270 to separate the PAR carrying the Integrity-Algorithm, PRF-Algorithm, 271 and Token AVPs from the one carrying the very first EAP-Payload AVP. 272 The following computations are made under this assumption. 274 An EAP-Payload AVP that carries an EAP-Request of size being equal to 275 the minimum EAP MTU size. The size of such an AVP is 1020 + 8 = 1028 276 octets. 278 In this case, the PANA message size including PANA header (16 279 octets), UDP header (8 octets) and IPv4 header (20 octets) is 1028 + 280 16 + 8 + 20 = 1072 octets. Therefore, the link-layer MTU size for IP 281 packets MUST be no less than 1072 octets when unspecified IPv4 282 address is used for PANA. Note that Ethernet (MTU = 1500 octets) 283 meets this requirement. 285 PANA as an EAP lower-layer reports the EAP MTU to the EAP layer, so 286 that EAP methods can perform appropriate fragmentation [RFC3748]. 287 The EAP MTU is calculated as follows: 289 EAP_MTU = L2_MTU - 52 291 In the above formula, the value of 52 is the PANA overhead (IP, UDP 292 and PANA headers, and the EAP-Payload AVP header). 294 7. Security Considerations 296 When the PAA is not capable of L2-unicasting PANA messages to the 297 target PaC, other nodes on the same subnet can receive those 298 messages. This may pose a risk if there is any confidential data 299 exposed in the messages. Typically no such exposure exists as PANA, 300 EAP, an EAP methods are defined in a way they can also be used in 301 wireless networks where snooping is always a possibility. 303 8. IANA Considerations 305 As described in Section 5.1 and following the new IANA allocation 306 policy on PANA message [RFC5872], a new AVP Code for Token AVP needs 307 to be assigned by IANA. 309 9. Acknowledgments 311 The authors would like to thank Rafael Marin Lopez and Yasuyuki 312 Tanaka for their valuable comments. 314 10. References 316 10.1. Normative References 318 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 319 Yegin, "Protocol for Carrying Authentication for Network 320 Access (PANA)", RFC 5191, May 2008. 322 [RFC5193] Jayaraman, P., Lopez, R., Ohba, Y., Parthasarathy, M., and 323 A. Yegin, "Protocol for Carrying Authentication for 324 Network Access (PANA) Framework", RFC 5193, May 2008. 326 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 327 Levkowetz, "Extensible Authentication Protocol (EAP)", 328 RFC 3748, June 2004. 330 [RFC5872] Arkko, J. and A. Yegin, "IANA Rules for the Protocol for 331 Carrying Authentication for Network Access (PANA)", 332 RFC 5872, May 2010. 334 10.2. Informative References 336 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 337 E. Lear, "Address Allocation for Private Internets", 338 BCP 5, RFC 1918, February 1996. 340 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 341 Requirement Levels", BCP 14, RFC 2119, March 1997. 343 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 344 RFC 2131, March 1997. 346 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 347 Networks", RFC 2464, December 1998. 349 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 350 August 2002. 352 Authors' Addresses 354 Alper Yegin 355 Samsung 356 Istanbul 357 Turkey 359 Email: alper.yegin@yegin.org 361 Yoshihiro Ohba 362 Toshiba Corporate Research and Development Center 363 1 Komukai-Toshiba-cho 364 Saiwai-ku, Kawasaki, Kanagawa 212-8582 365 Japan 367 Phone: +81 44 549 2230 368 Email: yoshihiro.ohba@toshiba.co.jp 370 Lionel Morand 371 Orange Labs 373 Phone: +33 1 4529 62 57 374 Email: Lionel.morand@orange-ftgroup.com 376 John Kaippallimalil 377 Huawei USA 378 1700 Alma Dr., Suite 500 379 Plano, TX 75082 380 USA 382 Phone: +1 214 606 2005 383 Email: john.kaippallimalil@huawei.com