Source Address Validation Improvements (SAVI) J. Bi
Internet-Draft J. Wu
Intended status: Standards Track Tsinghua University
Expires: May 14, 2022 T. Lin
New H3C Technologies Co. Ltd
Y. Wang
L. He
Tsinghua University
November 10, 2021
A SAVI Solution for WLAN
draft-bi-savi-wlan-22
Abstract
This document describes a source address validation solution for
WLANs where 802.11i or other security mechanisms are enabled to
secure MAC addresses. This mechanism snoops NDP and DHCP packets to
bind IP addresses to MAC addresses, and relies on the security of MAC
addresses guaranteed by 802.11i or other mechanisms to filter IP
spoofing packets. It can work in the special situations described in
the charter of SAVI (Source Address Validation Improvements)
workgroup, such as multiple MAC addresses on one interface. This
document describes three different deployment scenarios, with
solutions for migration of binding entries when hosts move from one
access point to another.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 14, 2022.
Bi, et al. Expires May 14, 2022 [Page 1]
Internet-Draft savi-wlan November 2021
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. IP-MAC Binding . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. IP-MAC Mapping Table . . . . . . . . . . . . . . . . 4
3.1.2. MAC-IP Mapping Table . . . . . . . . . . . . . . . . 4
3.2. Pre-conditions for Binding . . . . . . . . . . . . . . . 4
3.3. Binding IP addresses to MAC addresses . . . . . . . . . . 5
3.4. Binding Migration . . . . . . . . . . . . . . . . . . . . 5
3.5. Binding Clearing . . . . . . . . . . . . . . . . . . . . 5
4. Source Address Validation . . . . . . . . . . . . . . . . . . 6
5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 6
5.1. Centralized WLAN . . . . . . . . . . . . . . . . . . . . 7
5.1.1. AP Filtering . . . . . . . . . . . . . . . . . . . . 7
5.1.1.1. Candidate Binding . . . . . . . . . . . . . . . . 7
5.1.1.2. Packet Filtering . . . . . . . . . . . . . . . . 7
5.1.1.3. Negative Entries . . . . . . . . . . . . . . . . 8
5.1.1.4. CAPWAP Extension . . . . . . . . . . . . . . . . 8
5.1.1.5. Mobility Solution . . . . . . . . . . . . . . . . 11
5.1.2. AC Filtering . . . . . . . . . . . . . . . . . . . . 12
5.2. Autonomous WLAN . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7.1. Privacy Considerations . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
Bi, et al. Expires May 14, 2022 [Page 2]
Internet-Draft savi-wlan November 2021
1. Introduction
This document describes a mechanism to perform per packet IP source
address validation in WLAN. This mechanism performs ND snooping or
DHCP snooping to bind allocated IP addresses with authenticated MAC
addresses. Static addresses are bound to the MAC addresses of
corresponding hosts manually. Then the mechanism can check the
validity of the source IP addresses in local packets according to the
binding association. The security of MAC address is assured by
802.11i or other mechanisms, thus the binding association is secure.
IP-MAC binding table in control plane and MAC-IP binding table in
data plane are two important data structures, which are introduced in
detail in the document.
The situation that one interface with multiple MAC addresses is a
special case mentioned in the charter of SAVI. And this situation is
the only special case that challenges MAC-IP binding. The mechanism
to handle this situation is specified in the document.
There are three deployment scenarios specified in this document. The
mechanism is deployed on different devices in different scenarios.
The deployment details are described in the document.
When hosts move from one access point to another, the migration of
binding entries may be triggered according to the specific mobility
scenario. The mechanism to handle host mobility is specified in the
document according to different deployment scenarios.
1.1. Terminology
FIT Access Points: the name of Access Points in Centralized WLAN
deployment scenario.
FAT Access Points: the name of Access Points in Autonomous WLAN
deployment scenario.
Familiarity with SAVI-DHCP and its terminology, as defined in
[RFC7513], is assumed.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Bi, et al. Expires May 14, 2022 [Page 3]
Internet-Draft savi-wlan November 2021
3. IP-MAC Binding
This section specifies the operations for creating and clearing
bindings between IP addresses and MAC addresses.
3.1. Data Structures
3.1.1. IP-MAC Mapping Table
This table maps IP addresses to corresponding MAC addresses. IP
address is the index of the table. One IP address can only have one
corresponding MAC address, while different IP addresses can be mapped
to the same MAC address.
This table is used in the control process. Before creating new IP-
MAC bindings, this table must first be consulted in case of conflicts
in binding entries. Also, this table must be consulted before doing
any packet filtering. This table must be synchronized with the MAC-
IP table specified in Section 3.1.2.
Each entry in IP-MAC mapping table must also record the binding state
of the IP address. The addresses snooped in DHCP address assignment
procedure must record their state as "DHCPv6", and the addresses
snooped in Duplicate Address Detection procedure must record their
state as "SLAAC".
3.1.2. MAC-IP Mapping Table
This table maps MAC addresses to the corresponding IP addresses. MAC
address is the index of the table. It is a one-to-many mapping
table, which means a MAC address can be mapped to multiple IP
addresses. Though multiple MAC addresses may exist on one interface,
these MAC addresses must be mapped to different IP addresses.
This table is used for filtering. Different from wired network, MAC-
IP mapping table and IP-MAC mapping table can be maintained
separately on different devices. Mechanisms for synchronization
between the two tables must be employed for the consistency of the
bindings. We will specify the details in Section 5 according to
different deployment scenarios.
3.2. Pre-conditions for Binding
In the binding based mechanism, the security of IP address is based
on the security of the binding anchor. In WLAN, 802.11i or other
security mechanisms on link layer make MAC address a strong enough
binding anchor.
Bi, et al. Expires May 14, 2022 [Page 4]
Internet-Draft savi-wlan November 2021
If MAC address has no protection, attackers can spoof MAC address to
succeed in validation.
3.3. Binding IP addresses to MAC addresses
All the static IP-MAC address pairs are configured into the IP-MAC
Mapping Table with the mechanism enabled.
An individual procedure handles the binding of DHCP addresses to MAC
addresses. This procedure snoops the DHCP address assignment process
between attached hosts and DHCP server. DHCP snooping in WLANs is
the same as that in wired networks specified in [RFC7513].
An individual procedure handles the binding of stateless addresses to
MAC addresses. This procedure snoops Address Resolution procedure
between attached hosts and neighbors as described in [RFC4861] or
Duplicate Address Detection procedure as described in [RFC4862].
Based on the principle of roaming experience first in WLAN, the new
binding anchor is preferred, and removing the security connection of
the old binding anchor is triggered.
In some deployment scenarios, the functions of address snooping and
IP-MAC table maintenance may also be separated onto different
devices. Thus, to prevent conflicts in binding entries, the device
for address snooping must interact with the device that maintains the
IP-MAC table. We will specify the details in Section 5.1.1.
3.4. Binding Migration
Different from wired network, SAVI for WLAN must handle the migration
of binding entries when a mobile host moves from one access point to
another. After the movement, the host will not perform another
address allocation procedure to obtain new IP addresses, but continue
to use the existing IP address(es). Thus, binding entries in the
foreign device that the mobile hosts access to cannot be established
by snooping. A new mechanism is needed to correctly migrate the
binding entry related to the IP address of the mobile host from the
home device to the foreign device. If the host binds multiple
entries, multiple entries will be migrated. For example, when the
host is assigned multiple addresses, multiple binding entries will be
generated, and these entries will be migrated. We will specify the
details in Section 5, according to different deployment scenarios.
3.5. Binding Clearing
Three kinds of events will trigger binding clearing:
Bi, et al. Expires May 14, 2022 [Page 5]
Internet-Draft savi-wlan November 2021
1. A host leaves explicitly this access point. The entries for all
related MAC addresses in MAC-IP table MUST be cleared.
2. A DHCP RELEASE message is received from the owner of the
corresponding IP address. This IP entry in IP-MAC mapping table
and the corresponding entries in MAC-IP mapping table MUST be
cleared.
3. A timeout message of AC's client idle-time is received. The
entries for all related MAC addresses in MAC-IP table MUST be
cleared.
4. Source Address Validation
This section describes source address validation procedure on
packets. In this procedure, all the frames are assumed to have
passed the verifications of 802.11i or other security mechanisms.
This procedure has the following steps:
1. Extract the IP source and MAC source from the frame. Lookup the
MAC address in the MAC-IP Mapping Table and check if the MAC-IP
pair exists. If yes, forward the packet. Otherwise, go to step
2.
2. Look up the IP address in the IP-MAC Mapping Table and check if
the IP address exists. If not, go to step 3. If yes, check
whether the MAC address in the entry is the same as that in the
frame. If yes, forward the packet. Otherwise, drop the packet.
In step 2, after the packet is judged to be valid and forwarded,
synchronization between the MAC-IP and IP-MAC mapping tables should
be triggered. The MAC-IP binding of the packet should be
synchronized from IP-MAC mapping table to MAC-IP mapping table, and
thus the following packets with the same MAC-IP pair will be
forwarded without going to step 2.
5. Deployment Scenarios
This section specifies three deployment scenarios, including two
under centralized WLAN and one under autonomous WLAN. The deployment
details and solutions for host mobility between access points are
described respectively for each scenario.
Bi, et al. Expires May 14, 2022 [Page 6]
Internet-Draft savi-wlan November 2021
5.1. Centralized WLAN
Centralized WLAN is comprised of FIT Access Points (AP) and Access
Controllers (AC). In this scenario, this document proposes the
following two deployment solutions.
5.1.1. AP Filtering
With this deployment solution, the validated data packets received by
an AP do not go through the AC, and only control packets and the
questionable data packets go through the AC. In this scenario, the
AC maintains IP-MAC Mapping Table, while the AP maintains MAC-IP
Mapping Table and performs address snooping.
5.1.1.1. Candidate Binding
An AP executes the procedure specified in Section 3.3. The candidate
bindings are generated after snooping procedure. Candidate bindings
must be confirmed by the AC to be valid.
After a candidate binding is generated, the AC is notified and checks
whether the binding is valid or not. The validity of a candidate
binding is determined if the binding does not violate any existing
bindings in the IP-MAC Mapping Table. Otherwise, if an address is
not suitable for a host to use, the AC notifies the corresponding AP.
If the candidate binding is valid, the AC adds an entry into the IP-
MAC Mapping Table and notifies the AP. Afterwards, the AP also adds
an entry into the local MAC-IP Mapping Table.
5.1.1.2. Packet Filtering
As specified in Section 4, for incoming data packets, an AP looks up
the MAC address in the local MAC-IP Mapping Table and checks if the
MAC-IP pair exists. If yes, the AP forwards the packet. Otherwise,
the AP delivers the packet to the AC for further processing.
When receiving a data packet from the AP, the AC looks up the IP
address in the local IP-MAC Mapping Table and checks if the IP
address exists. If not, the AC drops the packet. If yes, the AC
checks whether the MAC address in the entry is the same as that in
the frame. If yes, the AC forwards the packet. Otherwise, the AC
drops the packet.
After the AC forwards a valid packet, it synchronizes the related
MAC-IP binding to the MAC-IP mapping table on the AP from which the
packet comes. Following packets with the same MAC-IP pair will be
forwarded directly by the AP without going to the AC.
Bi, et al. Expires May 14, 2022 [Page 7]
Internet-Draft savi-wlan November 2021
5.1.1.3. Negative Entries
In the AP Filtering scenario, APs MAY drop packets directly without
sending them to the AC by enabling the establishment of negative
entries on APs. Specifically, APs may establish negative entries in
the following circumstances.
1. When an AP receives a certain number of packets within a certain
amount of time with the same MAC-IP pair that does not exist in
the local MAC-IP Table, it establishes a negative entry for this
MAC-IP pair. Then the AP drops all following packets that have
the same MAC-IP pair as indicated in this negative entry without
sending them to the AC for further processing.
2. When an AP receives a certain number of packets within a certain
amount of time with the same MAC address but different MAC-IP
pairs and none of these MAC-IP pairs exist in the local MAC-IP
Table, it establishes a negative entry for this MAC address. Then
the AP drops all following packets that have the same MAC address
as indicated in this negative entry without sending them to the AC
for further processing.
Each negative entry has a limited lifetime. The number of packets
and duration of time to trigger the establishment of the negative
entry, and the lifetime of the negative entry are configurable.
5.1.1.4. CAPWAP Extension
CAPWAP protocol is used for communication between the AP and the AC.
A new CAPWAP protocol message element is introduced, which extends
[RFC5415]. The host IP message element is used by both the AP and
the AC to exchange the binding information of hosts.
The host IP message element can be used in the process of
confirmation of candidate bindings. When the AP generates a
candidate binding, it reports the MAC address and related IP
addresses to the AC using this message, with suggestions of the state
of each IP address as specified in Section 3.1.1. After the AC
checks the validation of the candidate binding, it replies using a
message of the same format to inform the AP of the validation of each
IP address with a suggested state.
The host IP message element can be used in the process of binding
migration. When migration happens, the source device uses this
message to report the MAC address and related IP addresses to the
destination device, with suggestions for the state of each IP address
as specified in Section 3.1.1. After the destination device checks
the validation of the candidate binding, it replies using a message
Bi, et al. Expires May 14, 2022 [Page 8]
Internet-Draft savi-wlan November 2021
of the same format to inform the source device the validation of each
IP address with a suggested state.
The host IP message element can also be used in other scenarios when
the synchronization between MAC-IP and IP-MAC tables is required as
specified in Section 3.5 and Section 4. When the synchronization
from IP-MAC table to MAC-IP table is triggered, the source device
which holds the IP-MAC table reports the MAC address and the related
IP addresses to the destination device which holds the MAC-IP table
using this message, with suggestions of the state of each IP address
as specified in Section 3.1.1. The destination device replies using
a message of the same format to acknowledge the source device.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Total Length +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender ID | Length | Description +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC flag | Length | MAC Address... +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address... +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 flag | Length | blank ... +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address 1(32 bit) +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State | blank ... +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lifetime +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address 2(32 bit) +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State | blank ... +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lifetime +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address n(32 bit) +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State | blank ... +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lifetime +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 flag | Length | IPv6 Address... +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bi, et al. Expires May 14, 2022 [Page 9]
Internet-Draft savi-wlan November 2021
| IPv6 Address 1(128 bit) +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State | blank ... +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lifetime +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address 2(128 bit) +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State | blank ... +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lifetime +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address n(128 bit) +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State | blank ... +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lifetime +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSSID flag | Length | BSSID... +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSSID +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Radio ID: An 8-bit value representing the radio, whose value is
between 1 and 31.
Total Length: Total length of the following fields.
Sender ID: An 8-bit value representing the sender of the message. AP
is represented by value 1 and AC is represented by value 2.
Length: The length of the Value field.
Description: A 16-bit value for a description of the sender (AP or
AC).
MAC flag: An 8-bit value representing that the sub-field's type is
MAC address, whose value is 1.
Length: The length of the MAC Address field. The formats and lengths
specified in EUI-48 and EUI-64 [EUI] are supported.
MAC Address: A MAC address of the host. At least one MAC address
block MUST appear in the message, otherwise the message is considered
as invalid.
Bi, et al. Expires May 14, 2022 [Page 10]
Internet-Draft savi-wlan November 2021
IPv4 flag: An 8-bit value representing that the sub-field's type is
IPv4 address, whose value is 2.
Length: The length of the IPv4 Address field.
IPv4 Address: An IPv4 address of the host. There may exist many
entries, and each entry is comprised of an IPv4 address, an 8-bit
value for address state (value 1 means available, value 0 means
unavailable, value 255 means candidate), and a 32-bit value for
lifetime. Lifetime is a reserved field for future application under
abnormal conditions. It is required to list all IPv4 addresses
before IPv6 address blocks.
IPv6 flag: An 8-bit value representing that the sub-field's type is
IPv6 address, a DHCPv6-assigned IP address represented by value 3 and
a locally assigned IP address represented by value 4.
Length: The length of the IPv6 Address field.
IPv6 Address: An IPv6 address of the host. There may exist many
entries, and each entry is comprised of an IPv6 address, an 8-bit
value of address state (value 1 means available, value 0 means
unavailable, value 255 means candidate), and a 32-bit value lifetime.
Lifetime is a reserved field for future application under abnormal
conditions. All IPv4 and IPv6 addresses bind to the MAC address that
appears before them in the message.
BSSID flag: An 8-bit value representing that the sub-field's type is
BSSID, whose value is 5.
Length: The length of the BSSID field. The formats and lengths
specified in EUI-48 and EUI-64 [EUI] are supported.
BSSID: A basic service set identifier representing the BSS.
5.1.1.5. Mobility Solution
When a host moves from one AP to another, layer-2 association happens
before the IP packets are forwarded. The home AP deletes the binding
when mobile host is disconnected, and the foreign AP immediately
requests the bound addresses with the associated MAC from the AC.
The AC returns the binding with a suggested state. After the foreign
AP get the addresses should be bound, the binding migration is
completed. The protocol used for communication between the foreign
AP and the AC is the same as described in Section 5.1.1.4, while in
this scenario, the AC serves the role of the source device and the
foreign AP serves the role of the destination device.
Bi, et al. Expires May 14, 2022 [Page 11]
Internet-Draft savi-wlan November 2021
In WLAN, a host can move from an AC to another AC while keeping using
the same IP address. To be compatible with such scenario, ACs must
communicate to perform the binding migration. The protocol used for
communication between ACs is the same as described in
Section 5.1.1.4, while in this scenario the home AC serves the role
of the source device and the foreign AC serves the role of the
destination device.
5.1.2. AC Filtering
In this scenario, an AC maintains both MAC-IP and IP-MAC Mapping
Table and performs both address snooping and packet filtering. So,
all the packets must be forwarded to the AC first.
The AC executes the procedure specified in Section 3.3 and checks the
validity of IP-MAC pairs by consulting the local IP-MAC mapping
table. No extra procedure is needed to establish the IP-MAC
bindings.
The AC executes the procedure specified in Section 4 for packet
filtering, and no extra procedure is involved.
Mobility within one AC does not trigger any binding migration.
Mobility between different ACs triggers binding migration. ACs must
communicate to perform the binding migration. The protocol used for
communication between ACs is the same as described in
Section 5.1.1.4, while in this scenario the home AC serves the role
of the source device and the foreign AC serves the role of the
destination device.
5.2. Autonomous WLAN
Autonomous WLAN is comprised of FAT Access Points. In this scenario,
a FAT AP maintains both MAC-IP and IP-MAC Mapping Table and performs
both address snooping and packet filtering.
The FAT AP executes the procedure specified in Section 3.3 and checks
the validity of IP-MAC pairs by consulting the local IP-MAC mapping
table. No extra procedure is needed to establish the IP-MAC
bindings.
The FAT AP executes the procedure specified in Section 4 for packet
filtering, and no extra procedure is involved.
Mobility between different FAT APs will trigger binding migration.
FAT APs must communicate to perform the binding migration. The
protocol used for communication between FAT APs is the same as
described in Section 5.1.1.4, while in this scenario the home FAT AP
Bi, et al. Expires May 14, 2022 [Page 12]
Internet-Draft savi-wlan November 2021
serves the role of the source device and the foreign FAT AP serves
the role of the destination device.
6. IANA Considerations
There is no IANA consideration currently.
7. Security Considerations
The security of address allocation methods matters the security of
this mechanism. Thus, it is necessary to improve the security of
stateless auto-configuration and DHCP first.
7.1. Privacy Considerations
A SAVI device MUST delete binding anchor information as soon as
possible, except where there is an identified reason why that
information is likely to be involved in the detection, prevention, or
tracing of actual source-address spoofing. Information about hosts
that never spoof (probably the majority of hosts) SHOULD NOT be
logged.
8. Acknowledgements
The authors would like to thank Guang Yao, Yang Shi, and Hao Wang for
their contributions to this document.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
9.2. Informative References
[EUI] IEEE Standards Association, "Guidelines for Use of
Extended Unique Identifier (EUI), Organizationally Unique
Identifier (OUI), and Company ID (CID)", 2017,
<https://standards.ieee.org/content/dam/ieee-
standards/standards/web/documents/tutorials/eui.pdf>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
Bi, et al. Expires May 14, 2022 [Page 13]
Internet-Draft savi-wlan November 2021
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley,
Ed., "Control And Provisioning of Wireless Access Points
(CAPWAP) Protocol Specification", RFC 5415,
DOI 10.17487/RFC5415, March 2009,
<https://www.rfc-editor.org/info/rfc5415>.
[RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address
Validation Improvement (SAVI) Solution for DHCP",
RFC 7513, DOI 10.17487/RFC7513, May 2015,
<https://www.rfc-editor.org/info/rfc7513>.
Authors' Addresses
Jun Bi
Tsinghua University
Beijing 100084
China
Email: junbi@cernet.edu.cn
Jianping Wu
Tsinghua University
Beijing 100084
China
Email: jianping@cernet.edu.cn
Tao Lin
New H3C Technologies Co. Ltd
466 Changhe Road, Binjiang District
Hangzhou, Zhejiang 310052
China
Email: lintao@h3c.com
Bi, et al. Expires May 14, 2022 [Page 14]
Internet-Draft savi-wlan November 2021
You Wang
Tsinghua University
Beijing 100084
China
Email: you@opennetworking.org
Lin He
Tsinghua University
Beijing 100084
China
Email: he-l14@mails.tsinghua.edu.cn
Bi, et al. Expires May 14, 2022 [Page 15]