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
   this rule.

   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
   the attachment.

   Data packets from an attachment with the Validating attribute set
   FALSE will be forwarded without having their source addresses
   validated.

   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
   discarded.

   NA messages in which the target address is neither a link-local
   address nor bound with the corresponding binding anchor MUST be
   discarded.

   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
   discarded.

   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.

10.  Constants

   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
   (Section 7):

   (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
        attacks.

   (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
        DHCPLEASEQUERY Reply.

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
   burdensome.

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
        entries.

   (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
        timer.

   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
   latency.

   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
   logged.

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.)

12.  References

12.1.  Normative References

   [RFC826]  Plummer, D., "Ethernet Address Resolution Protocol: Or
              Converting Network Protocol Addresses to 48.bit Ethernet
              Address for Transmission on Ethernet Hardware", STD 37,
              RFC 826, DOI 10.17487/RFC0826, November 1982,
              <http://www.rfc-editor.org/info/rfc826>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, DOI 10.17487/RFC2131, March 1997,
              <http://www.rfc-editor.org/info/rfc2131>.

   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
              C., and M. Carney, "Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
              2003, <http://www.rfc-editor.org/info/rfc3315>.

   [RFC4388]  Woundy, R. and K. Kinnear, "Dynamic Host Configuration
              Protocol (DHCP) Leasequery", RFC 4388,
              DOI 10.17487/RFC4388, February 2006,
              <http://www.rfc-editor.org/info/rfc4388>.

   [RFC4436]  Aboba, B., Carlson, J., and S. Cheshire, "Detecting
              Network Attachment in IPv4 (DNAv4)", RFC 4436,
              DOI 10.17487/RFC4436, March 2006,
              <http://www.rfc-editor.org/info/rfc4436>.

   [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,
              <http://www.rfc-editor.org/info/rfc4861>.

   [RFC5007]  Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
              "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007,
              September 2007, <http://www.rfc-editor.org/info/rfc5007>.

   [RFC5227]  Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227,
              DOI 10.17487/RFC5227, July 2008,
              <http://www.rfc-editor.org/info/rfc5227>.

   [RFC6059]  Krishnan, S. and G. Daley, "Simple Procedures for
              Detecting Network Attachment in IPv6", RFC 6059,
              DOI 10.17487/RFC6059, November 2010,
              <http://www.rfc-editor.org/info/rfc6059>.

   [RFC6620]  Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
              SAVI: First-Come, First-Served Source Address Validation
              Improvement for Locally Assigned IPv6 Addresses",
              RFC 6620, DOI 10.17487/RFC6620, May 2012,
              <http://www.rfc-editor.org/info/rfc6620>.

12.2.  Informative References

   [DHCPv6-SHIELD]
              Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield:
              Protecting Against Rogue DHCPv6 Servers", Work in
              Progress, draft-ietf-opsec-dhcpv6-shield-07, May 2015.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
              May 2000, <http://www.rfc-editor.org/info/rfc2827>.

   [RFC3736]  Droms, R., "Stateless Dynamic Host Configuration Protocol
              (DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736,
              April 2004, <http://www.rfc-editor.org/info/rfc3736>.

   [RFC7039]  Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed.,
              "Source Address Validation Improvement (SAVI) Framework",
              RFC 7039, DOI 10.17487/RFC7039, October 2013,
              <http://www.rfc-editor.org/info/rfc7039>.

   [RFC7341]  Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
              Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport",
              RFC 7341, DOI 10.17487/RFC7341, August 2014,
              <http://www.rfc-editor.org/info/rfc7341>.

Acknowledgments

   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
   and text.

   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.

Authors' Addresses

   Jun Bi
   Network Research Center, Tsinghua University
   Beijing  100084
   China

   EMail: junbi@tsinghua.edu.cn


   Jianping Wu
   Dept. of Computer Science, Tsinghua University
   Beijing  100084
   China

   EMail: jianping@cernet.edu.cn


   Guang Yao
   Network Research Center, Tsinghua University
   Beijing  100084
   China

   EMail: yaoguang@cernet.edu.cn


   Fred Baker
   Cisco Systems
   Santa Barbara, CA  93117
   United States

   EMail: fred@cisco.com