idnits 2.17.1 draft-bi-savi-wlan-16.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 13, 2018) is 1984 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) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Bi 3 Internet-Draft J. Wu 4 Intended status: Standards Track Y. Wang 5 Expires: May 17, 2019 Tsinghua University 6 T. Lin 7 New H3C Technologies Co. Ltd 8 November 13, 2018 10 A SAVI Solution for WLAN 11 draft-bi-savi-wlan-16 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 May 17, 2019. 43 Copyright Notice 45 Copyright (c) 2018 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 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions used in this document . . . . . . . . . . . . . . 3 63 3. IP-MAC Binding . . . . . . . . . . . . . . . . . . . . . . . 3 64 3.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 3 65 3.1.1. IP-MAC Mapping Table . . . . . . . . . . . . . . . . 3 66 3.1.2. MAC-IP Mapping Table . . . . . . . . . . . . . . . . 4 67 3.2. Pre-conditions for binding . . . . . . . . . . . . . . . 4 68 3.3. Binding IP addresses to MAC addresses . . . . . . . . . . 5 69 3.4. Binding Migration . . . . . . . . . . . . . . . . . . . . 5 70 3.5. Binding Clearing . . . . . . . . . . . . . . . . . . . . 6 71 4. Source Address Validation . . . . . . . . . . . . . . . . . . 6 72 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 7 73 5.1. Centralized WLAN . . . . . . . . . . . . . . . . . . . . 7 74 5.1.1. AP Filtering . . . . . . . . . . . . . . . . . . . . 7 75 5.1.2. AC Filtering . . . . . . . . . . . . . . . . . . . . 12 76 5.2. Autonomous WLAN . . . . . . . . . . . . . . . . . . . . . 12 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 79 7.1. Issues with Triggerring Establishment of Binding Entries 80 by Data Packets . . . . . . . . . . . . . . . . . . . . . 13 81 7.2. Privacy Considerations . . . . . . . . . . . . . . . . . 13 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 85 9.2. Informative References . . . . . . . . . . . . . . . . . 14 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Introduction 90 This document describes a mechanism to perform per packet IP source 91 address validation in WLAN. This mechanism performs ND snooping or 92 DHCP snooping to bind allocated IP address with authenticated MAC 93 address. Static addresses are bound to the MAC addresses of 94 corresponding hosts manually. Then the mechanism can check validity 95 of source IP address in local packets according to the binding 96 association. The security of MAC address is assured by 802.11i or 97 other mechanisms, thus the binding association is secure. 99 The situation that one interfaces with multiple MAC addresses is a 100 special case mentioned in the charter of SAVI. And this situation is 101 the only special case that challenges MAC-IP binding. The mechanism 102 to handle this situation is specified in the document. 104 There are three deployment scenarios specified in this document. The 105 mechanism is deployed on different devices in different scenarios. 106 The deployment detail is described in the document. 108 When hosts move from one access point to another, the migration of 109 binding entries may be triggered according to the specific mobility 110 scenario. The mechanism to handle host mobility is specified in the 111 document according to different deployment scenarios. 113 1.1. Terminology 115 FIT Access Points: the name of Access Points in Centralized WLAN 116 deployment scenario. 118 FAT Access Points: the name of Access Points in Autonomous WLAN 119 deployment scenario. 121 2. Conventions used in this document 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC-2119 [RFC2119]. 127 3. IP-MAC Binding 129 This section specifies the operations for creating and clearing of 130 bindings between IP addresses to MAC addresses. 132 3.1. Data Structures 134 3.1.1. IP-MAC Mapping Table 136 This table maps IP addresses to corresponding MAC addresses. IP 137 address is the index of the table. One IP address can only have one 138 corresponding MAC address, while different IP addresses can be mapped 139 to the same MAC address. 141 This table is used in control process. Before creating new IP-MAC 142 bindings, this table must first be consulted in case of conflict in 143 binding entries. Also, this table must be consulted before doing any 144 packet filtering. This table must be synchronized with the MAC-IP 145 table specified in Section 3.1.2. 147 Each entry in IP-MAC mapping table must also record the binding state 148 of the IP address. Addresses snooped in DHCP address assignment 149 procedure must record its state as "DHCPv6", and addresses snooped in 150 Duplicate Address Detection procedure must record its state as 151 "SLAAC". 153 Each entry in IP-MAC mapping table has its lifetime. According to 154 RFC3315 [RFC3315], the address allocated by DHCP has a limited 155 lifetime, so the related entry records its lifetime the same as that 156 of the address. According to RFC4862 [RFC4862], stateless address 157 also has a limited lifetime, and the host set this lifetime by 158 itself. Thus the related entry also records its lifetime the same as 159 that of the address. 161 3.1.2. MAC-IP Mapping Table 163 This table maps MAC addresses to corresponding IP addresses. MAC 164 address is the index of the table. It is a one-to-many mapping 165 table, which means a MAC address can be mapped to multiple IP 166 addresses. Though multiple MAC addresses may exist on one interface, 167 these MAC addresses must be mapped to different IP addresses. 169 This table is used for filtering. Different from wired network, MAC- 170 IP mapping table and IP-MAC mapping table can be maintained 171 separately on different devices. Mechanisms for synchronization 172 between the two tables must be employed for the consistency of the 173 bindings. We will specify the details in Section 5 according to 174 different deployment scenarios. 176 3.2. Pre-conditions for binding 178 In the binding based mechanism, the security of IP address is based 179 on the security of the binding anchor. In WLAN, 802.11i or other 180 security mechanisms on link layer make MAC address a strong enough 181 binding anchor. 183 If MAC address has no protection, attackers can spoof MAC address to 184 succeed in validation. However, in general cases, if MAC address is 185 not protected, more serious attack can be launched than IP spoofing 186 attack. 188 3.3. Binding IP addresses to MAC addresses 190 All the static IP-MAC address pairs are configured into the IP-MAC 191 Mapping Table with the mechanism enabled. 193 An individual procedure handles binding DHCP addresses to MAC 194 addresses. This procedure snoops the DHCP address assignment 195 procedure between attached hosts and DHCP server. DHCP snooping in 196 WLAN is the same as that in wired network specified in RFC7513 197 [RFC7513]. 199 An individual procedure handles binding stateless addresses to MAC 200 addresses. This procedure snoops Duplicate Address Detection 201 procedure. ND snooping in WLAN is the same as that in wired network 202 specified in [RFC6620] [RFC6620]. 204 Data packets MAY also trigger the establishment of new IP-MAC binding 205 entries. Data packet with non-bound source IP address with a limited 206 rate is collected to handle DAD message loss in SLAAC procedure, 207 which can be quite frequent in wireless network. The detail of the 208 procedure is specified in Section 4. However, this mechanism will 209 bring potential security risks (e.g. attacks that aimed at exhausting 210 available IP addresses). Thus, it is optional whether to enable the 211 mechanism, and if it is enabled, additional security mechanisms MUST 212 also be employed to cope with the risks. Related security 213 considerations are discussed in Section 6. 215 In some deployment scenarios, the function of address snooping and 216 IP-MAC table maintaining may also be separated onto different 217 devices. Thus to prevent conflictions in binding entries, the device 218 snoops addresses must have interactions with the device maintains the 219 IP-MAC table. We will specify the details in Section 5.1.1. 221 3.4. Binding Migration 223 Different from wired network, SAVI for WLAN must handle migration of 224 binding entries when mobile hosts move from one access point to 225 another. After movement, hosts will not perform another address 226 allocation procedure to obtain new IP addresses, but continue to use 227 the existing IP address. Thus binding entries in the foreign device 228 that the mobile hosts access to cannot be established by snooping. A 229 new mechanism is needed to correctly migrate the binding entry 230 related to the IP address of the mobile host from the home device to 231 the foreign device. We will specify the details in Section 5, 232 according to different deployment scenarios. 234 3.5. Binding Clearing 236 Three kinds of events will trigger binding clearing: 238 1. The lifetime of an IP address in one entry has expired. This IP 239 entry in IP-MAC mapping table and corresponding entries in MAC-IP 240 mapping table MUST be cleared. 242 2. A host leaves this access point. The entries for all related MAC 243 addresses in MAC-IP table MUST be cleared. 245 3. A DHCP RELEASE message is received from the owner of 246 corresponding IP address. This IP entry in IP-MAC mapping table 247 and corresponding entries in MAC-IP mapping table MUST be 248 cleared. 250 The protocols used for synchronization between MAC-IP and IP-MAC 251 tables will be specified in Section 5.1.1.4. 253 4. Source Address Validation 255 This section describes source address validation procedure on packet. 256 In this procedure, all the frames are assumed to have passed the 257 verifications of 802.11i or other security mechanisms. 259 This procedure has the following steps: 261 1. Extract the IP source and MAC source from the frame. Lookup the 262 MAC address in the MAC-IP Mapping Table and check if the MAC-IP 263 pair exists. If yes, forward the packet. Or else go to step 2. 265 2. Lookup the IP address in the IP-MAC Mapping Table and check if 266 the IP address exists. If no, go to step 3. If yes, check 267 whether The MAC address in the entry is the same as that in the 268 frame. If yes, forward the packet. Else drop the packet. 270 3. If the mechanism that allows data packets to trigger the 271 establishment of new IP-MAC binding entries is enabled, insert a 272 new entry into the IP-MAC Mapping Table and forward the packet. 273 Otherwise drop the packet. 275 In step 2, after the packet is judged valid and forwarded, 276 synchronization between the MAC-IP and IP-MAC mapping table should be 277 triggered. The MAC-IP binding of the packet should be synchronized 278 from IP-MAC mapping table to MAC-IP mapping table and thus the 279 following packets with the same MAC-IP pair will be forwarded without 280 going to step 2. 282 Also in step 3, if a new IP-MAC binding entry is established, it 283 should be synchronized to MAC-IP mapping table. The protocols used 284 for synchronization between MAC-IP and IP-MAC tables will be 285 specified in Section 5.1.1.4. 287 5. Deployment Scenarios 289 This section specifies three deployment scenarios including two under 290 centralized WLAN and one under autonomous WLAN. The deployment 291 details and solutions for host mobility between access points are 292 described respectively in each scenario. 294 5.1. Centralized WLAN 296 Centralized WLAN is comprised of FIT Access Points (AP) and Access 297 Controllers (AC). In this scenario, this document proposes the 298 following two deployment solutions. 300 5.1.1. AP Filtering 302 With this deployment solution, data packets received by the APs do 303 not go through the ACs and only control packets (including 304 questionable data packets) go through the ACs. In this scenario, AC 305 maintains IP-MAC Mapping Table while AP maintains MAC-IP Mapping 306 Table and perform address snooping. 308 5.1.1.1. Candidate Binding 310 AP executes the procedure specified in Section 3.3. Candidate 311 binding is generated after snooping procedure. Candidate binding 312 must be confirmed by AC to be valid. 314 After a candidate binding is generated, AC is notified and checks 315 whether the binding is valid or not. The validity of a candidate 316 binding is determined if the binding does not violate any existing 317 bindings in the IP-MAC Mapping Table. Otherwise if an address is not 318 suitable for a host to use, AC notifies the corresponding AP. If the 319 candidate binding is valid, AC adds an entry into the IP-MAC Mapping 320 Table and notifies AP. Afterwards AP also adds an entry into the 321 local MAC-IP Mapping Table. 323 5.1.1.2. Packet Filtering 325 As specified in Section 4, for incoming data packets, AP looks up the 326 MAC address in the local MAC-IP Mapping Table and check if the MAC-IP 327 pair exists. If yes, AP forwards the packet. Or else AP delivers 328 the packet to AC for further processing. 330 When receiving data packets from AP, AC Looks up the IP address in 331 the local IP-MAC Mapping Table and checks if the IP address exists. 332 If no, according to whether the AC is configured to allow data 333 packets to trigger binding entry creations, AC establishes a new IP- 334 MAC entry then forwards the packet, or drop the packet. If yes, AC 335 checks whether The MAC address in the entry is the same as that in 336 the frame. If yes, AC forwards the packet. Else AC drops the 337 packet. 339 After AC forwards a valid packet, it synchronizes related MAC-IP 340 binding to the MAC-IP mapping table on the AP from which the packet 341 comes. Following packets with the same MAC-IP pair will be forwarded 342 directly by AP without going to AC. 344 5.1.1.3. Negative Entries 346 In the AP Filtering scenario, APs MAY drop packets directly without 347 sending them to AC by enabling the establishment of negative entries 348 on APs. Specifically, APs may establish negative entries in the 349 following circumstances. 351 1. When AP receives a certain amount of packets within a certain 352 amount of time with the same MAC-IP pair that does not exist in 353 the local MAC-IP Table, it establishes a negative entry for this 354 MAC-IP pair. Then AP drops all following packets that have the 355 same MAC-IP pair as indicated in this negative entry without 356 sending them to AC for further processing. 358 2. When AP receives a certain amount of packets within a certain 359 amount of time with the same MAC address but different MAC-IP 360 pairs and none of these MAC-IP pairs exist in the local MAC-IP 361 Table, it establishes a negative entry for this MAC address. 362 Then AP drops all following packets that have the same MAC 363 address as indicated in this negative entry without sending them 364 to AC for further processing. 366 Each negative entry has a limited lifetime. The number of packets 367 and duration of time to trigger the establishment of the negative 368 entry, and the lifetime of the negative entry are configurable. 370 5.1.1.4. CAPWAP Extension 372 CAPWAP protocol is used for communication between AP and AC. A new 373 CAPWAP protocol message element is introduced, which extends RFC5415 374 [RFC5415]. The host IP message element is used by both AP and AC to 375 exchange the binding information of hosts. 377 The host IP message element can be used in the process of 378 confirmation of candidate binding. When AP generates a candidate 379 binding, it reports the MAC address and related IP addresses to AC 380 using this message, with suggestions of the state and lifetime of 381 each IP address as specified in Section 3.1.1. After AC checks the 382 validation of the candidate binding, it replies using a message of 383 the same format to inform AP the validation of each IP address with 384 suggestions of its state and lifetime. 386 The host IP message element can be used in the process of binding 387 migration. When migration happens, the source device reports the MAC 388 address and related IP addresses to the destination device using this 389 message, with suggestions of the state and lifetime of each IP 390 address as specified in Section 3.1.1. After the destination device 391 checks the validation of the candidate binding, it replies using a 392 message of the same format to inform the source device the validation 393 of each IP address with suggestions of its state and lifetime. 395 The host IP message element can also be used in other scenarios when 396 synchronization between MAC-IP and IP-MAC tables is required as 397 specified in Section 3.5 and Section 4. When synchronization from 398 IP-MAC table to MAC-IP table is triggered, the source device which 399 holds the IP-MAC table reports the MAC address and related IP 400 addresses to the destination device which holds the MAC-IP table 401 using this message, with suggestions of the state and lifetime of 402 each IP address as specified in Section 3.1.1. The destination 403 device replies using a message of the same format to acknowledge the 404 source device. 406 0 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Radio ID | Total Length + 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Sender ID | Length | Description + 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | MAC flag | Length | MAC Address... + 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | MAC Address... + 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | IPv4 flag | Length | blank ... + 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | IPv4 Address 1(32 bit) + 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | State | blank ... + 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | lifetime + 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | IPv4 Address 2(32 bit) + 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | State | blank ... + 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | lifetime + 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | ........ + 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | IPv4 Address n(32 bit) + 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | State | blank ... + 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | lifetime + 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | IPv6 flag | Length | IPv6 Address... + 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | IPv6 Address 1(128 bit) + 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | State | blank ... + 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | lifetime + 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | IPv6 Address 2(128 bit) + 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | State | blank ... + 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | lifetime + 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | ........ + 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | IPv6 Address n(128 bit) + 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | State | blank ... + 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | lifetime + 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 Radio ID: An 8-bit value representing the radio, whose value is 463 between 1 and 31. 465 Total Length: Total length of the following fields. 467 Sender ID: An 8-bit value representing the sender of the message. AP 468 is represented by value 1 and AC is represented by value 2. 470 Length: The length of the Value field. 472 Description: A 16-bit value for descriptions of the sender (AP or 473 AC). 475 MAC flag: An 8-bit value representing that the sub-field's type is 476 MAC address, whose value is 1. 478 Length: The length of the MAC Address field. The formats and lengths 479 specified in EUI-48 [EUI-48] and EUI-64 [EUI-64] are supported. 481 MAC Address: A MAC address of the host. At least one MAC address 482 block MUST appear in the message, otherwise the message is considered 483 as invalid. 485 IPv4 flag: An 8-bit value representing that the sub-field's type is 486 IPv4 address, whose value is 2. 488 Length: The length of the IPv4 Address field. 490 IPv4 Address: An IPv4 address of the host. There may exist many 491 entries, and each entry is comprised of an IPv4 address, an 8-bit 492 value for address state (value 1 means available, value 0 means 493 unavailable, value 255 means candidate), and a 32-bit value for 494 lifetime. It is required to list all IPv4 addresses before IPv6 495 address blocks. 497 IPv6 flag: An 8-bit value representing that the sub-field's type is 498 IPv6 address, whose value is 3. 500 Length: The length of the IPv6 Address field. 502 IPv6 Address: An IPv6 address of the host. There may exist many 503 entries, and each entry is comprised of an IPv6 address, an 8-bit 504 value of address state (value 1 means available, value 0 means 505 unavailable, value 255 means candidate), and a 32-bit value lifetime. 506 All IPv4 and IPv6 addresses bind to the MAC address that appears 507 before them in the message. 509 5.1.1.5. Mobility Solution 511 When a host moves from one AP to another, layer-2 association happens 512 before IP packet transfer. Home AP deletes the binding when mobile 513 host is disconnected, and foreign AP immediately requests the bound 514 addresses with the associated MAC from AC. AC returns the binding 515 with suggestions of its state and lifetime. After AP get the 516 addresses should be bound, the binding migration is completed. The 517 protocol used for communication between foreign AP and AC is the same 518 as described in Section 5.1.1.4, while in this scenario AC serves the 519 role of the source device and foreign AP serves the role of the 520 destination device. 522 In WLAN, a host can move from an AC to another AC while keeping using 523 the same IP address. To be compatible with such scenario, ACs must 524 communicate to perform the binding migration. The protocol used for 525 communication between ACs is the same as described in 526 Section 5.1.1.4, while in this scenario home AC serves the role of 527 the source device and foreign AC serves the role of the destination 528 device. 530 5.1.2. AC Filtering 532 In this scenario, AC maintains both MAC-IP and IP-MAC Mapping 533 Table and performs both address snooping and packet filtering. So 534 all the packets must be forwarded to AC firstly. 536 AC executes the procedure specified in Section 3.3 and check the 537 validity of IP-MAC pairs by consulting the local IP-MAC mapping 538 table. No extra procedure is needed to establish the IP-MAC 539 bindings. 541 AC executes the procedure specified in Section 4 for packet filtering 542 and no extra procedure is involved. 544 Mobility within one AC does not trigger any binding migration. 545 Mobility between different ACs triggers binding migration. ACs must 546 communicate to perform the binding migration. The protocol used for 547 communication between ACs is the same as described in 548 Section 5.1.1.4, while in this scenario home AC serves the role of 549 the source device and foreign AC serves the role of the destination 550 device. 552 5.2. Autonomous WLAN 554 Autonomous WLAN is comprised of FAT Access Points. In this scenario, 555 FAT AP maintains both MAC-IP and IP-MAC Mapping Table and performs 556 both address snooping and packet filtering. 558 FAT AP executes the procedure specified in Section 3.3 and check the 559 validity of IP-MAC pairs by consulting the local IP-MAC mapping 560 table. No extra procedure is needed to establish the IP-MAC 561 bindings. 563 FAT AP executes the procedure specified in Section 4 for packet 564 filtering and no extra procedure is involved. 566 Mobility between different FAT APs will trigger binding migration. 567 FAT APs must communicate to perform the binding migration. The 568 protocol used for communication between FAT APs is the same as 569 described in Section 5.1.1.4, while in this scenario home FAT AP 570 serves the role of the source device and foreign FAT AP serves the 571 role of the destination device. 573 6. IANA Considerations 575 There is no IANA Consideration currently. 577 7. Security Considerations 579 The security of address allocation methods matters the security of 580 this mechanism. Thus it is necessary to improve the security of 581 stateless auto-configuration and DHCP firstly. 583 7.1. Issues with Triggerring Establishment of Binding Entries by Data 584 Packets 586 In Section 3.3, a mechanism is described to allow data packets to 587 trigger the establishment of new binding entries to handle DAD 588 message loss in SLAAC procedure. If the mechanism is enabled, it can 589 be used to launch attacks which may finally leads to exhaustion of 590 available IP addresses. If no restriction is taken, the attacker can 591 make as many IP-MAC bindings as possible with the same MAC address. 592 In this way, other hosts may fail to trigger any binding entry 593 establishment and thus cannot get their packets pass the SAVI device. 594 To cope with the potential security risks, additional mechanism MUST 595 be employed, e.g. to limit the maximum number of IP addresses that 596 one MAC address can bind to. 598 Packet loss in wireless networks can be handled in a more robust way 599 by other source address validation mechanisms, e.g. 600 [draft-ietf-6lo-rfc6775-update-21] with an extension protocol in 601 [draft-ietf-6lo-ap-nd-08]. However it requires protocol changes and 602 thus it is out of the scope of SAVI. 604 7.2. Privacy Considerations 606 A SAVI device MUST delete binding anchor information as soon as 607 possible, except where there is an identified reason why that 608 information is likely to be involved in the detection, prevention, or 609 tracing of actual source-address spoofing. Information about hosts 610 that never spoof (probably the majority of hosts) SHOULD NOT be 611 logged. 613 8. Acknowledgements 615 The authors would like to thank Guang Yao, Yang Shi and Hao Wang for 616 their contributions to this document. 618 9. References 620 9.1. Normative References 622 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 623 Requirement Levels", BCP 14, RFC 2119, March 1997. 625 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 626 C., and M. Carney, "Dynamic Host Configuration Protocol 627 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 628 2003, . 630 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 631 Address Autoconfiguration", RFC 4862, DOI 10.17487/ 632 RFC4862, September 2007, . 635 [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, 636 Ed., "Control And Provisioning of Wireless Access Points 637 (CAPWAP) Protocol Specification", RFC 5415, DOI 10.17487/ 638 RFC5415, March 2009, . 641 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 642 SAVI: First-Come, First-Served Source Address Validation 643 Improvement for Locally Assigned IPv6 Addresses", RFC 644 6620, DOI 10.17487/RFC6620, May 2012, . 647 [RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address 648 Validation Improvement (SAVI) Solution for DHCP", RFC 649 7513, DOI 10.17487/RFC7513, May 2015, . 652 9.2. Informative References 654 [EUI-48] "Guidelines For 48-bit Global Identifier (EUI-48)", 655 http://standards.ieee.org/develop/regauth/tut/eui48.pdf 657 [EUI-64] "Guidelines For 64-bit Global Identifier (EUI-64)", 658 http://standards.ieee.org/develop/regauth/tut/eui64.pdf 660 [draft-ietf-6lo-ap-nd-08] 661 Thubert, P., Sarikaya, B., Sethi, M., and Struik, R., 662 "Address Protected Neighbor Discovery for Low-power and 663 Lossy Networks", draft-ietf-6lo-ap-nd-08 (work in 664 progress), October, 2018. 666 [draft-ietf-6lo-rfc6775-update-21] 667 Thubert, P., Nordmark, E., Chakrabarti, S., and C. 668 Perkins, "Registration Extensions for 6LoWPAN Neighbor 669 Discovery", draft-ietf-6lo-rfc6775-update-21 (work in 670 progress), June 2018. 672 Authors' Addresses 674 Jun Bi 675 Tsinghua University 676 Network Research Center, Tsinghua University 677 Beijing 100084 678 China 680 Email: junbi@cernet.edu.cn 682 Jianping Wu 683 Tsinghua University 684 Computer Science, Tsinghua University 685 Beijing 100084 686 China 688 Email: jianping@cernet.edu.cn 690 You Wang 691 Tsinghua University 692 Network Research Center, Tsinghua University 693 Beijing 100084 694 China 696 Email: wangyou10@mails.tsinghua.edu.cn 698 Tao Lin 699 New H3C Technologies Co. Ltd 700 466 Changhe Road, Binjiang District 701 Hangzhou, Zhejiang Province 310052 702 China 704 Email: lintao@h3c.com