Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7513

Source Address Validation Improvement (SAVI) Solution for DHCP

Pages: 54
Proposed Standard
Part 3 of 3 – Pages 45 to 54
First   Prev   None

Top   ToC   RFC7513 - Page 45   prevText

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.
Top   ToC   RFC7513 - Page 46

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.
Top   ToC   RFC7513 - Page 47
   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.
Top   ToC   RFC7513 - Page 48
   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
Top   ToC   RFC7513 - Page 49
        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.
Top   ToC   RFC7513 - Page 50
   (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
Top   ToC   RFC7513 - Page 51
   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.)
Top   ToC   RFC7513 - Page 52

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>.
Top   ToC   RFC7513 - Page 53
   [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>.
Top   ToC   RFC7513 - Page 54

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