idnits 2.17.1 draft-bi-savi-wlan-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 are 5 instances 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 == Unrecognized Status in 'Intended status: Standard Tracks', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document date (August 7, 2014) is 3542 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) -- Possible downref: Non-RFC (?) normative reference: ref. 'CAPWAP' Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Bi 2 Internet Draft J. Wu 3 Intended status: Standard Tracks Y. Wang 4 Expires: February, 2015 Tsinghua University 5 T. Lin 6 Hangzhou H3C Tech. Co., Ltd. 7 August 7, 2014 9 A SAVI Solution for WLAN 11 draft-bi-savi-wlan-06.txt 13 Abstract 15 This document describes a source address validation solution for WLAN 16 enabling 802.11i or other security mechanisms. This mechanism snoops 17 NDP and DHCP packets to bind IP address to MAC address, and relies on 18 the security of MAC address guaranteed by 802.11i or other mechanisms 19 to filter IP spoofing packets. It can work in the special situations 20 described in the charter of SAVI(Source Address Validation 21 Improvements) workgroup, such as multiple MAC addresses on one 22 interface. This document describes three different deployment 23 scenarios, with solutions for migration of binding entries when hosts 24 move from one access point to another. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on February 8, 2015. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction ................................................ 2 61 2. Conventions used in this document............................ 3 62 3. IP-MAC Binding .............................................. 3 63 3.1. Data Structures......................................... 3 64 3.1.1. IP-MAC Mapping Table............................... 3 65 3.1.2. MAC-IP Mapping Table............................... 4 66 3.2. Pre-conditions for binding.............................. 4 67 3.3. Binding IP addresses to MAC addresses................... 4 68 3.4. Binding Migration....................................... 5 69 3.5. Binding Clearing........................................ 5 70 4. Source Address Validation.................................... 6 71 5. Deployment Scenarios......................................... 6 72 5.1. Centralized WLAN........................................ 6 73 5.1.1. AP Filtering....................................... 7 74 5.1.1.1. Candidate Binding............................. 7 75 5.1.1.2. Packet Filtering.............................. 7 76 5.1.1.3. CAPWAP Extension.............................. 7 77 5.1.1.4. Mobility Solution............................. 9 78 5.1.2. AC Filtering...................................... 10 79 5.2. Autonomous WLAN........................................ 10 80 6. Security Considerations..................................... 10 81 7. IANA Considerations ........................................ 11 82 8. Acknowledgments ............................................ 11 83 9. References ................................................. 11 84 9.1. Normative References................................... 11 85 9.2. Informative References................................. 12 87 1. Introduction 89 This document describes a mechanism to perform per packet IP source 90 address validation in WLAN. This mechanism performs ND snooping or 91 DHCP snooping to bind allocated IP address with authenticated MAC 92 address. Static addresses are bound to the MAC addresses of 93 corresponding hosts manually. Then the mechanism can check validity 94 of source IP address in local packets according to the binding 95 association. The security of MAC address is assured by 802.11i or 96 other mechanisms, thus the binding association is secure. 98 The situation that one interfaces with multiple MAC addresses is a 99 special case mentioned in the charter of SAVI. And this situation is 100 the only special case that challenges MAC-IP binding. The mechanism 101 to handle this situation is specified in the document. 103 There are three deployment scenarios specified in this document. The 104 mechanism is deployed on different devices in different scenarios. 105 The deployment detail is described in the document. 107 When hosts move from one access point to another, the migration of 108 binding entries may be triggered according to the specific mobility 109 scenario. The mechanism to handle host mobility is specified in the 110 document according to different deployment scenarios. 112 2. Conventions used in this document 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC-2119 [RFC2119]. 118 3. IP-MAC Binding 120 This section specifies the operations for creating and clearing of 121 bindings between IP addresses to MAC addresses. 123 3.1. Data Structures 125 3.1.1. IP-MAC Mapping Table 127 This table maps IP addresses to corresponding MAC addresses. IP 128 address is the index of the table. One IP address can only have one 129 corresponding MAC address, while different IP addresses can be mapped 130 to the same MAC address. 132 This table is used in control process. Before creating new IP-MAC 133 bindings, this table must first be consulted in case of conflict in 134 binding entries. Also, this table must be consulted before doing any 135 packet filtering. This table must be synchronized with the MAC-IP 136 table specified in Section 3.1.2. 138 Each entry in IP-MAC mapping table must also record the binding state 139 of the IP address. Addresses snooped in DHCP address assignment 140 procedure must record its state as "DHCPv6", and addresses snooped in 141 Duplicate Address Detection procedure must record its state as 142 "SLAAC". 144 Each entry in IP-MAC mapping table has its lifetime. According to 145 [RFC3315], the address allocated by DHCP has a limited lifetime, so 146 the related entry records its lifetime the same as that of the 147 address. According to [RFC4862], stateless address also has a limited 148 lifetime, and the host set this lifetime by itself. Thus the related 149 entry also records its lifetime the same as that of the address. 151 3.1.2. MAC-IP Mapping Table 153 This table maps MAC addresses to corresponding IP addresses. MAC 154 address is the index of the table. It is a one-to-many mapping table, 155 which means a MAC address can be mapped to multiple IP addresses. 156 Though multiple MAC addresses may exist on one interface, these MAC 157 addresses must be mapped to different IP addresses. 159 This table is used for filtering. Different from wired network, MAC- 160 IP mapping table and IP-MAC mapping table can be maintained 161 separately on different devices. Mechanisms for synchronization 162 between the two tables must be employed for the consistency of the 163 bindings. We will specify the details in Section 5 according to 164 different deployment scenarios. 166 3.2. Pre-conditions for binding 168 In the binding based mechanism, the security of IP address is based 169 on the security of the binding anchor. In WLAN, a number of security 170 mechanisms on link layer make MAC address a strong enough binding 171 anchor, for instance, 802.11i, WAPI, WEP. 173 If MAC address has no protection, attackers can spoof MAC address to 174 succeed in validation. However, in general cases, if MAC address is 175 not protected, more serious attack can be launched than IP spoofing 176 attack. 178 3.3. Binding IP addresses to MAC addresses 180 All the static IP-MAC address pairs are configured into the IP-MAC 181 Mapping Table with the mechanism enabled. 183 An individual procedure handles binding DHCP addresses to MAC 184 addresses. This procedure snoops the DHCP address assignment 185 procedure between attached hosts and DHCP server. DHCP snooping in 186 WLAN is the same as that in wired network specified in [savi-dhcp]. 188 An individual procedure handles binding stateless addresses to MAC 189 addresses. This procedure snoops Duplicate Address Detection 190 procedure. ND snooping in WLAN is the same as that in wired network 191 specified in [RFC6620]. 193 Data packets MAY also trigger the establishment of new IP-MAC binding 194 entries. Data packet with non-bound source IP address with a limited 195 rate is collected to handle DAD message loss in SLAAC procedure, 196 which can be quite frequent in wireless network. The detail of the 197 procedure is specified in Section 4. However, this mechanism will 198 bring potential security risks (e.g. attacks that aimed at exhausting 199 available IP addresses). Thus, it is optional whether to enable the 200 mechanism, and if it is enabled, additional security mechanisms MUST 201 also be employed to cope with the risks. Related security 202 considerations are discussed in Section 6. 204 In some deployment scenarios, the function of address snooping and 205 IP-MAC table maintaining may also be separated onto different devices. 206 Thus to prevent conflictions in binding entries, the device snoops 207 addresses must have interactions with the device maintains the IP-MAC 208 table. We will specify the details in Section 5.1.1. 210 3.4. Binding Migration 212 Different from wired network, SAVI for WLAN must handle migration of 213 binding entries when mobile hosts move from one access point to 214 another. After movement, hosts will not perform another address 215 allocation procedure to obtain new IP addresses, but continue to use 216 the existing IP address. Thus binding entries in the foreign device 217 that the mobile hosts access to cannot be established by snooping. A 218 new mechanism is needed to correctly migrate the binding entry 219 related to the IP address of the mobile host from the home device to 220 the foreign device. We will specify the details in Section 5, 221 according to different deployment scenarios. 223 3.5. Binding Clearing 225 Three kinds of events will trigger binding clearing: 227 1. The lifetime of an IP address in one entry has expired. This IP 228 entry MUST be cleared. 230 2. A host leaves this access point. The entries for all the related 231 MAC addresses MUST be cleared. 233 3. A DHCP RELEASE message is received from the owner of corresponding 234 IP address. This IP entry MUST be cleared. 236 4. Source Address Validation 238 This section describes source address validation procedure on packet. 239 In this procedure, all the frames are assumed to have passed the 240 verifications of 802.11i or other security mechanisms. 242 This procedure has the following steps: 244 1. Extract the IP source and MAC source from the frame. Lookup the 245 MAC address in the MAC-IP Mapping Table and check if the MAC-IP pair 246 exists. If yes, forward the packet. Or else go to step 2. 248 2. Lookup the IP address in the IP-MAC Mapping Table and check if the 249 IP address exists. If no, go to step 3. If yes, check whether The MAC 250 address in the entry is the same as that in the frame. If yes, 251 forward the packet. Else drop the packet. 253 3. If the mechanism that allows data packets to trigger the 254 establishment of new IP-MAC binding entries is enabled, insert a new 255 entry into the IP-MAC Mapping Table and forward the packet. Otherwise 256 drop the packet. 258 In step 2, after the packet is judged valid and forwarded, 259 synchronization between the MAC-IP and IP-MAC mapping table should be 260 triggered. The MAC-IP binding of the packet should be synchronized 261 from IP-MAC mapping table to MAC-IP mapping table and thus the 262 following packets with the same MAC-IP pair will be forwarded without 263 going to step 2. 265 Also in step 3, if a new IP-MAC binding entry is established, it 266 should be synchronized to MAC-IP mapping table. 268 5. Deployment Scenarios 270 This section specifies three deployment scenarios including two under 271 centralized WLAN and one under autonomous WLAN. The deployment 272 details and solutions for host mobility between access points are 273 described respectively in each scenario. 275 5.1. Centralized WLAN 277 Centralized WLAN is comprised of FIT Access Points (AP) and Access 278 Controllers (AC). In this scenario, this document proposes the 279 following two deployment solutions. 281 5.1.1. AP Filtering 283 In this scenario, AC maintains IP-MAC Mapping Table while AP 284 maintains MAC-IP Mapping Table and perform address snooping. 286 5.1.1.1. Candidate Binding 288 AP executes the procedure specified in Section 3.3. Candidate binding 289 is generated after snooping procedure. Candidate binding must be 290 confirmed by AC to be valid. 292 After a candidate binding is generated, AC is notified and checks 293 whether the binding is valid or not. The validity of a candidate 294 binding is determined if the binding does not violate any existing 295 bindings in the IP-MAC Mapping Table. Otherwise if an address is not 296 suitable for a host to use, AC notifies the corresponding AP. If the 297 candidate binding is valid, AC adds an entry into the IP-MAC Mapping 298 Table and notifies AP. Afterwards AP also adds an entry into the 299 local MAC-IP Mapping Table. 301 5.1.1.2. Packet Filtering 303 As specified in Section 4, for incoming data packets, AP looks up the 304 MAC address in the local MAC-IP Mapping Table and check if the MAC-IP 305 pair exists. If yes, AP forwards the packet. Or else AP delivers the 306 packet to AC for further processing. 308 When receiving data packets from AP, AC Looks up the IP address in 309 the local IP-MAC Mapping Table and checks if the IP address exists. 310 If no, according to whether the AC is configured to allow data 311 packets to trigger binding entry creations, AC establishes a new IP- 312 MAC entry then forwards the packet, or drop the packet. If yes, AC 313 checks whether The MAC address in the entry is the same as that in 314 the frame. If yes, AC forwards the packet. Else AC drops the packet. 316 After AC forwards a valid packet, it synchronizes related MAC-IP 317 binding to the MAC-IP mapping table on the AP from which the packet 318 comes. Following packets with the same MAC-IP pair will be forwarded 319 directly by AP without going to AC. 321 5.1.1.3. CAPWAP Extension 323 CAPWAP protocol is used for communication between AP and AC. A new 324 CAPWAP protocol message element is introduced, which extends the 325 [CAPWAP]. The host IP message element is used by both AP and AC to 326 exchange the binding information of hosts. 328 The host IP message element can be used in the process of 329 confirmation of candidate binding. When AP generates a candidate 330 binding, it reports the MAC address and related IP addresses to AC 331 using this message, with suggestions of the state and lifetime of 332 each IP address as specified in Section 3.1.1. After AC checks the 333 validation of the candidate binding, it replies using a message of 334 the same format to inform AP the validation of each IP address with 335 suggestions of its state and lifetime. 337 The host IP message element also can be used in the process of 338 binding migration. In mobility scenario, foreign device the mobile 339 hosts accesses to need to request related bindings from home devices, 340 and host IP message element can be used for interactions between them. 341 Details will be specified in the following sections according to 342 different deployment scenarios. 344 0 1 2 3 345 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Radio ID | Total Length + 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Sender ID | Length | Description + 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | MAC flag | Length | MAC Address... + 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | MAC Address... + 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | IPv4 flag | Length | IPv4 Address... + 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | IPv4 Address... + 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | IPv6 flag | Length | IPv6 Address... + 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | IPv6 Address... + 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Radio ID: An 8-bit value representing the radio, whose value is 365 between 1 and 31. 367 Total Length: Total length of the following fields. 369 Sender ID: An 8-bit value representing the sender of the message. AP 370 is represented by value 1 and AC is represented by value 2. 372 Length: The length of the Value field. 374 Description: A 16-bit value for descriptions of the sender (AP or AC). 376 MAC flag: An 8-bit value representing that the sub-field's type is 377 MAC address, whose value is 1. 379 Length: The length of the MAC Address field. The formats and lengths 380 specified in [EUI-48] and [EUI-64] are supported. 382 MAC Address: A MAC address of the host. 384 IPv4 flag: An 8-bit value representing that the sub-field's type is 385 IPv4 address, whose value is 2. 387 Length: The length of the IPv4 Address field. 389 IPv4 Address: An IPv4 address of the host. There may exist many 390 entries, and each entry is comprised of an IPv4 address, an 8-bit 391 value for address state (only value 1 is used for now), and a 32-bit 392 value for lifetime. 394 IPv6 flag: An 8-bit value representing that the sub-field's type is 395 IPv6 address, whose value is 3. 397 Length: The length of the IPv6 Address field. 399 IPv6 Address: An IPv6 address of the host. There may exist many 400 entries, and each entry is comprised of an IPv6 address, an 8-bit 401 value of address state (also one value for now), and a 32-bit value 402 lifetime. 404 5.1.1.4. Mobility Solution 406 When a host moves from one AP to another, layer-2 association happens 407 before IP packet transfer. Home AP deletes the binding when mobile 408 host is disconnected, and foreign AP immediately requests the bound 409 addresses with the associated MAC from AC using host IP message 410 element specified in Section 5.1.1.2. AC returns the binding with 411 suggestions of its state and lifetime also using the new CAPWAP 412 protocol message. After AP get the addresses should be bound, the 413 binding migration is completed. 415 In WLAN, a host can move from an AC to another AC while keeping using 416 the same IP address. To be compatible with such scenario, ACs must 417 communicate to perform the binding migration. CAPWAP extensions 418 specified in Section 5.1.1.2 can also be used for communications 419 between AC. 421 5.1.2. AC Filtering 423 In this scenario, AC maintains both MAC-IP and IP-MAC Mapping Table 424 and performs both address snooping and packet filtering. So all the 425 packets must be forwarded to AC firstly. 427 AC executes the procedure specified in Section 3.3 and check the 428 validity of IP-MAC pairs by consulting the local IP-MAC mapping table. 429 No extra procedure is needed to establish the IP-MAC bindings. 431 AC executes the procedure specified in Section 4 for packet filtering 432 and no extra procedure is involved. 434 Mobility within one AC does not trigger any binding migration. 435 Mobility between different ACs triggers binding migration. ACs must 436 communicate to perform the binding migration. CAPWAP extensions 437 specified in Section 5.1.1.2 can be used for communications between 438 ACs. 440 5.2. Autonomous WLAN 442 Autonomous WLAN is comprised of FAT Access Points. In this scenario, 443 FAT AP maintains both MAC-IP and IP-MAC Mapping Table and performs 444 both address snooping and packet filtering. 446 FAT AP executes the procedure specified in Section 3.3 and check the 447 validity of IP-MAC pairs by consulting the local IP-MAC mapping table. 448 No extra procedure is needed to establish the IP-MAC bindings. 450 FAT AP executes the procedure specified in Section 4 for packet 451 filtering and no extra procedure is involved. 453 Mobility between different FAT APs will trigger binding migration. 454 FAT APs must communicate to perform the binding migration. CAPWAP 455 extensions specified in Section 5.1.1.2 can be used for 456 communications between FAT AP. 458 6. Security Considerations 460 The security of address allocation methods matters the security of 461 this mechanism. Thus it is necessary to improve the security of 462 stateless auto-configuration and DHCP firstly. 464 In Section 3.3, a mechanism is described to allow data packets to 465 trigger the establishment of new binding entries. If the mechanism is 466 enabled, it can be used to launch attacks which may finally leads to 467 exhaustion of available IP addresses. If no restriction is taken, the 468 attacker can make as many IP-MAC bindings as possible with the same 469 MAC address. In this way, other hosts may fail to trigger any binding 470 entry establishment and thus cannot get their packets pass the SAVI 471 device. To cope with the potential security risks, additional 472 mechanism MUST be employed, e.g. to limit the maximum number of IP 473 addresses that one MAC address can bind to. 475 7. IANA Considerations 477 There is no IANA Consideration currently. 479 8. Acknowledgements 481 The authors would like to thank Guang Yao, Yang Shi and Hao Wang for 482 their contributions to this document. 484 9. References 486 9.1. Normative References 488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 489 Requirement Levels", BCP 14, RFC 2119, March 1997. 491 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 492 M. Carney, "Dynamic Host Configuration Protocol for IPv6 493 (DHCPv6)", RFC3315, July, 2003. 495 [RFC4862] Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless 496 Autoconfiguration", RFC4862, September, 2007. 498 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, " FCFS 499 SAVI: First-Come, First-Served Source Address Validation 500 Improvement for Locally Assigned IPv6 Addresses", RFC6620, 501 May, 2012. 503 [CAPWAP] Control And Provisioning of Wireless Access Points (CAPWAP) 504 Protocol Specification 506 9.2. Informative References 508 [savi-dhcp] 509 Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for 510 DHCP", draft-ietf-savi-dhcp-28 (work in progress), July 511 2014. 513 [EUI-48] "Guidelines For 48-bit Global Identifier (EUI-48)", 514 http://standards.ieee.org/develop/regauth/tut/eui48.pdf 516 [EUI-64] "Guidelines For 64-bit Global Identifier (EUI-64)", 517 http://standards.ieee.org/develop/regauth/tut/eui64.pdf 519 Authors' Addresses 521 Jun Bi 522 Tsinghua University 523 Network Research Center, Tsinghua University 524 Beijing 100084 525 China 526 EMail: junbi@cernet.edu.cn 528 Jianping Wu 529 Tsinghua University 530 Computer Science, Tsinghua University 531 Beijing 100084 532 China 533 EMail: jianping@cernet.edu.cn 535 You Wang 536 Tsinghua University 537 Network Research Center, Tsinghua University 538 Beijing 100084 539 China 540 EMail: wangyou10@mails.tsinghua.edu.cn 542 Tao Lin 543 Hangzhou H3C Tech. Co., Ltd. 544 Beijing 100085 545 China 546 EMail: lintao@h3c.com