8. Filtering Specification
This section specifies how to use bindings to filter out packets with
spoofed source addresses.
Filtering policies are different for data packets and control
packets. DHCP, ARP, and Neighbor Discovery Protocol (NDP) [RFC4861]
messages are classified as control packets. All other packets are
classified as data packets.
8.1. Data Packet Filtering
Data packets from attachments with the Validating attribute TRUE MUST
have their source addresses validated. There is one exception to
A packet whose source IP address is a link-local address cannot be
checked against DHCP assignments, as it is not assigned using DHCP.
Note: as explained in Section 1, a SAVI solution for link-local
addresses, e.g., FCFS SAVI [RFC6620], can be enabled to check packets
with a link-local source address.
If the source IP address of a packet is not a link-local address, but
there is not a matching entry in the BST with BOUND state, this
packet MUST be discarded. However, the packet may trigger the Data
Snooping Process (Section 7) if the Data-Snooping attribute is set on
Data packets from an attachment with the Validating attribute set
FALSE will be forwarded without having their source addresses
The SAVI device MAY log packets that fail source address validation.
8.2. Control Packet Filtering
For attachments with the Validating attribute:
DHCPv4 Client-to-Server messages in which the source IP address is
neither all zeros nor bound with the corresponding binding anchor in
the BST MUST be discarded.
DHCPv6 Client-to-Server messages in which the source IP address is
neither a link-local address nor bound with the corresponding binding
anchor in the BST MUST be discarded.
NDP messages in which the source IP address is neither a link-local
address nor bound with the corresponding binding anchor MUST be
NA messages in which the target address is neither a link-local
address nor bound with the corresponding binding anchor MUST be
ARP messages in which the protocol is IP and the sender protocol
address is neither all zeros nor bound with the corresponding binding
anchor MUST be discarded.
ARP Reply messages in which the target protocol address is not bound
with the corresponding binding anchor MUST be discarded.
For attachments with other attributes:
DHCP Server-to-Client messages not from attachments with the DHCP-
Trust attribute or Trust attribute MUST be discarded.
For attachments with no attribute:
DHCP Server-to-Client messages from such attachments MUST be
The SAVI device MAY record any messages that are discarded.
9. State Restoration
If a SAVI device reboots, the information kept in volatile memory
will be lost. This section specifies the restoration of attribute
configuration and the BST.
9.1. Attribute Configuration Restoration
The loss of attribute configuration will not break the network: no
action will be performed on traffic from attachments with no
attribute. However, the loss of attribute configuration makes this
SAVI function unable to work.
To avoid the loss of binding anchor attribute configuration, the
configuration MUST be able to be stored in non-volatile storage.
After the reboot of the SAVI device, if the configuration of binding
anchor attributes is found in non-volatile storage, the configuration
MUST be used.
9.2. Binding State Restoration
The loss of binding state will cause the SAVI devices to discard
legitimate traffic. Simply using the Data Snooping Process to
recover a large number of bindings is a heavy overhead and may cause
considerable delay. Thus, recovering bindings from non-volatile
storage, as specified below, is RECOMMENDED.
Binding entries MAY be saved into non-volatile storage whenever a new
binding entry changes to BOUND state. If a binding with BOUND state
is removed, the saved entry MUST be removed correspondingly. The
time when each binding entry is established is also saved.
If the BST is stored in non-volatile storage, the SAVI device SHOULD
restore binding state from the non-volatile storage immediately after
reboot. Using the time when each binding entry was saved, the SAVI
device should check whether the entry has become obsolete by
comparing the saved lifetime and the difference between the current
time and time when the binding entry was established. Obsolete
entries that would have expired before the reboot MUST be removed.
The following constants are recommended for use in this context:
o MAX_DHCP_RESPONSE_TIME (120s): Maximum Solicit timeout value
(SOL_MAX_RT from [RFC3315])
o MAX_LEASEQUERY_DELAY (10s): Maximum LEASEQUERY timeout value
(LQ_MAX_RT from [RFC5007])
o DETECTION_TIMEOUT (0.5s): Maximum duration of a hardware address
verification step in the VERIFY state (TENT_LT from [RFC6620])
o DATA_SNOOPING_INTERVAL: Minimum interval between two successive
EVE_DATA_UNMATCH events triggered by an attachment.
Recommended interval: 60s and configurable
o OFFLINK_DELAY: Period after a client is last detected before the
binding anchor is being removed. Recommended delay: 30s
11. Security Considerations
11.1. Security Problems with the Data Snooping Process
There are two security problems with the Data Snooping Process
(1) The Data Snooping Process is costly, but an attacker can trigger
it simply through sending a number of data packets. To avoid
Denial-of-Service attacks against the SAVI device itself, the
Data Snooping Process MUST be rate limited. A constant
DATA_SNOOPING_INTERVAL is used to control the frequency. Two
Data Snooping Processes on one attachment MUST be separated by a
minimum interval time of DATA_SNOOPING_INTERVAL. If this value
is changed, the value needs to be large enough to minimize DoS
(2) The Data Snooping Process may set up incorrect bindings if the
clients do not reply to the detection probes (Section 7.6.1).
An attack will pass the duplicate detection if the client
assigned the target address does not reply to the detection
probes. The DHCP Leasequery procedure performed by the SAVI
device just tells whether or not the address is assigned in the
network. However, the SAVI device cannot determine whether the
address is just assigned to the triggering attachment from the
11.2. Securing Leasequery Operations
In [RFC4388] and [RFC5007], the specific case of DHCP Leasequeries
originated by "access concentrators" is addressed extensively. SAVI
devices are very similar to access concentrators in that they snoop
on DHCP traffic and seek to validate source addresses based on the
results. Accordingly, the recommendations for securing leasequery
operations for access concentrators in Section 7 of [RFC4388] and
Section 5 of [RFC5007] MUST be followed when leasequeries are made
from SAVI devices. [RFC5007] RECOMMENDS that communications between
the querier and the DHCP server are protected with IPsec. It is
pointed out that there are relatively few devices involved in a given
administrative domain (SAVI devices, DHCP relays, and DHCP servers)
so that manual configuration of keying material would not be overly
11.3. Client Departure Issues
After a binding is set up, the corresponding client may leave its
attachment point. It may depart temporarily due to signal fade or
permanently by moving to a new attachment point or leaving the
network. In the signal fade case, since the client may return
shortly, the binding should be kept momentarily, lest legitimate
traffic from the client be blocked. However, if the client leaves
permanently, keeping the binding can be a security issue. If the
binding anchor is a property of the attachment point rather than the
client, e.g., the switch port but not incorporating the MAC address,
an attacker using the same binding anchor can send packets using IP
addresses assigned to the client. Even if the binding anchor is a
property of the client, retaining binding state for a departed client
for a long time is a waste of resources.
Whenever a direct client departs from the network, a link-down event
associated with the binding anchor will be triggered. SAVI-DHCP
monitors such events and performs the following mechanism.
(1) Whenever a client with the Validating attribute leaves, a timer
of duration OFFLINK_DELAY is set on the corresponding binding
(2) If a DAD Neighbor Solicitation / Gratuitous ARP request is
received that targets the address during OFFLINK_DELAY, the
entry MAY be removed.
(3) If the client returns on-link during OFFLINK_DELAY, cancel the
In this way, the bindings of a departing client are kept for
OFFLINK_DELAY. In cases of link flapping, the client will not be
blocked. If the client leaves permanently, the bindings will be
removed after OFFLINK_DELAY.
SAVI-DHCP does not handle the departure of indirect clients because
it will not be notified of such events. Switches supporting indirect
attachment (e.g., through a separate non-SAVI switch) SHOULD use
information specific to the client such as its MAC address as part of
the binding anchor.
11.4. Compatibility with Detecting Network Attachment (DNA)
DNA [RFC4436] [RFC6059] is designed to decrease the handover latency
after reattachment to the same network. DNA mainly relies on
performing a reachability test by sending unicast Neighbor
Solicitation / Router Solicitation / ARP Request messages to
determine whether a previously configured address is still valid.
Although DNA provides optimization for clients, there is insufficient
information for this mechanism to migrate the previous binding or
establish a new binding. If a binding is set up only by snooping the
reachability test message, the binding may be invalid. For example,
an attacker can perform the reachability test with an address bound
to another client. If a binding is migrated to the attacker, the
attacker can successfully obtain the binding from the victim.
Because this mechanism wouldn't set up a binding based on snooping
the DNA procedure, it cannot achieve perfect compatibility with DNA.
However, it only means the reconfiguration of the interface is slowed
but not prevented. Details are discussed as follows.
In Simple DNAv6 [RFC6059], the probe is sent with the source address
set to a link-local address, and such messages will not be discarded
by the policy specified in Section 8.2. If a client is reattached to
a previous network, the detection will be completed, and the address
will be regarded as valid by the client. However, the candidate
address is not contained in the probe. Thus, the binding cannot be
recovered through snooping the probe. As the client will perform
DHCP exchange at the same time, the binding will be recovered from
the DHCP Snooping Process. The DHCP Request messages will not be
filtered out in this case because they have link-local source
addresses. Before the DHCP procedure is completed, packets will be
filtered out by the SAVI device. In other words, if this SAVI
function is enabled, Simple DNAv6 will not help reduce the handover
latency. If the Data-Snooping attribute is configured on the new
attachment of the client, the data-triggered procedure may reduce
In DNAv4 [RFC4436], the ARP Probe will be discarded because an
unbound address is used as the sender protocol address. As a result,
the client will regard the address under detection as valid.
However, the data traffic will be filtered. The DHCP Request message
sent by the client will not be discarded because the source IP
address field should be all zeros as required by [RFC2131]. Thus, if
the address is still valid, the binding will be recovered from the
DHCP Snooping Process.
11.5. Binding Number Limitation
A binding entry will consume certain high-speed memory resources. In
general, a SAVI device can afford only a quite limited number of
binding entries. In order to prevent an attacker from overloading
the resources of the SAVI device, a binding entry limit is set on
each attachment. The binding entry limit is the maximum number of
bindings supported on each attachment with the Validating attribute.
No new binding should be set up after the limit has been reached. If
a DHCP Reply assigns more addresses than the remaining binding entry
quota of each client, the message will be discarded and no binding
will be set up.
11.6. Privacy Considerations
A SAVI device MUST delete binding anchor information as soon as
possible (i.e., as soon as the state for a given address is back to
NO_BIND), 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
11.7. Fragmented DHCP Messages
This specification does not preclude reassembly of fragmented DHCP
messages, but it also does not require it. If DHCP fragmentation
proves to be an issue, the issue will need to be specified and
addressed. (This topic is beyond the scope of this document.)
Special thanks to Jean-Michel Combes, Christian Vogt, Joel M.
Halpern, Eric Levy-Abegnoli, Marcelo Bagnulo Braun, Jari Arkko, Elwyn
Davies, Barry Leiba, Ted Lemon, Leaf Yeh, Ralph Droms, and Alberto
Garcia for careful review and evaluation comments on the mechanism
Thanks to Mark Williams, Erik Nordmark, Mikael Abrahamsson, David
Harrington, Pekka Savola, Xing Li, Lixia Zhang, Bingyang Liu, Duanqi
Zhou, Robert Raszuk, Greg Daley, John Kaippallimalil, and Tao Lin for
their valuable contributions.
Network Research Center, Tsinghua University
Dept. of Computer Science, Tsinghua University
Network Research Center, Tsinghua University
Santa Barbara, CA 93117