| Source Address Validation Improvement | J. Bi |
| Internet-Draft | J. Wu |
| Intended status: Standards Track | G. Yao |
| Expires: August 23, 2015 | Tsinghua Univ. |
| F. Baker | |
| Cisco | |
| February 19, 2015 |
SAVI Solution for DHCP
draft-ietf-savi-dhcp-34
This document specifies the procedure for creating a binding between a DHCPv4/DHCPv6-assigned IP address and a binding anchor on a Source Address Validation Improvements (SAVI) device. The bindings set up by this procedure are used to filter packets with forged source IP addresses. This mechanism complements BCP 38 ingress filtering, providing finer-grained source IP address validation.
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 http://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 August 23, 2015.
Copyright (c) 2015 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 (http://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.
This document describes a fine-grained source address validation mechanism for IPv4 and IPv6 packets. This mechanism creates bindings between IP addresses assigned to network interfaces by DHCP and suitable binding anchors (Section 4.3.5). As discussed in Section 3 and [RFC7039], a "binding anchor" is an attribute that is immutable or difficult to change that may be used to identify the system an IP address has been assigned to; common examples include a MAC address found on an Ethernet switch port or WiFi security association. The bindings are used to identify and filter packets originated by these interfaces using forged source IP addresses. In this way, this mechanism can prevent hosts from using IP addresses assigned to any other attachment point in or not associated with the network. This behavior is referred to as "spoofing", and is key to amplification attacks, in which a set of systems send messages to another set of systems claiming to be from a third set of systems, and sending the replies to systems that don't expect them. Whereas BCP 38 [RFC2827] protects a network from a neighboring network by providing prefix granularity source IP address validity, this mechanism protects a network, including a Local Area Network, from itself by providing address granularity source IP validity when DHCP/DHCPv6 is used to assign IPv4/IPv6 addresses. Both provide a certain level of traceability, in that packet drops indicate the presence of a system that is producing packets with spoofed IP addresses.
SAVI-DHCP snoops DHCP address assignments to set up bindings between IP addresses assigned by DHCP and corresponding binding anchors. It includes the DHCPv4 and v6 snooping process (Section 6), the Data Snooping process (Section 7), as well as a number of other technical details. The Data Snooping process is a data-triggered procedure that snoops the IP header of data packets to set up bindings. It is designed to avoid a permanent blockage of valid addresses in the case that DHCP snooping is insufficient to set up all the valid bindings.
This mechanism is designed for the stateful DHCP scenario [RFC2131], [RFC3315]. Stateless DHCP [RFC3736] is out of scope for this document, as it has nothing to do with IP address allocation. An alternative SAVI method would have be used in those cases. For hosts using Stateless Address Auto-Configuration (SLAAC) to allocate addresses, SAVI-FCFS [RFC6620] should be enabled. SAVI-DHCP is primarily designed for pure DHCP scenarios in which only addresses assigned through DHCP are allowed. However, it does not block link-local addresses, as they are not assigned using DHCP. It is RECOMMENDED that the administration deploy a SAVI solution for link-local addresses, e.g., SAVI-FCFS [RFC6620].
This mechanism works for networks that use DHCPv4 only, DHCPv6 only, or both DHCPv4 and DHCPv6. However, the DHCP address assignment mechanism in IPv4/IPv6 transition scenarios, e.g., [RFC7341], are beyond the scope of this document.
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 RFC 2119 [RFC2119].
Binding anchor: A "binding anchor" is defined to be a physical and/or link-layer property of an attached device, as in [RFC7039]. A list of sample binding anchors can be found in Section 3.2 of that document. To the degree possible, a binding anchor associates an IP address with something unspoofable that identifies a single client system or one of its interfaces. See Section 4.3.5 for more detail.
Attribute: A configurable property of each binding anchor (port, MAC Address, or other information) that indicates the actions to be performed on packets received from the attached network device.
DHCP address: An IP address assigned via DHCP.
SAVI-DHCP: The name of this SAVI function for DHCP-assigned addresses.
SAVI device: A network device on which SAVI-DHCP is enabled.
Non-SAVI device: A network device on which SAVI-DHCP is not enabled.
DHCP Client-Server message: A message that is sent from a DHCP client to a DHCP server or DHCP servers. Such a message is of one of the following types:
DHCP Server-to-Client message: A message that is sent from a DHCP server to a DHCP client. Such a message is of one of the following types:
Lease time: The lease time in IPv4 [RFC2131] or the valid lifetime in IPv6 [RFC3315].
Binding entry: A rule that associates an IP address with a binding anchor.
Binding State Table (BST): The data structure that contains the binding entries.
Binding entry limit: The maximum number of binding entries that may be associated with a binding anchor. Limiting the number of binding entries per binding anchor prevents a malicious or malfunctioning node from overloading the binding table on a SAVI device.
Direct attachment: Ideally, a SAVI device is an access device that hosts are attached to directly. In such a case, the hosts are direct attachments (i.e., they attach directly) to the SAVI device.
Indirect attachment: A SAVI device MAY be an aggregation device that other access devices are attached to, and which hosts in turn attach to. In such a case, the hosts are indirect attachments (i.e., they attach indirectly) to the SAVI device.
Unprotected link: Unprotected links are links that connect to hosts or networks of hosts receive their DHCP traffic by another path, and are therefore outside the SAVI perimeter.
Unprotected device: An unprotected device is a device associated with an unprotected link. One example might be the gateway router of a network.
Protected link: If DHCP messages for a given attached device always use a given link, the link is considered to be "protected" by the SAVI Device, and is therefore within the SAVI perimeter.
Protected device: A protected device is a device associated with a protected link. One example might be a desktop switch in the network, or a host.
Cut Vertex: A cut vertex is any vertex whose removal increases the number of connected components in a (network) graph. This is a concept in graph theory. This term is used in Section 6.1 to accurately specify the required deployment location of SAVI devices when they only perform the DHCP Snooping Process.
Identity Association (IA): "A collection of addresses assigned to a client." [RFC3315]
Detection message: a Neighbor Solicitation or ARP message intended by the Data Snooping Process to detect a duplicate address.
DHCP_DEFAULT_LEASE: default lifetime for DHCPv6 address when the binding is triggered by a DHCPv6 Confirm message but a DHCPv6 lease query exchange [RFC5007] cannot be performed by the SAVI device to fetch the lease.
The essential elements in a SAVI-DHCP deployment scenario include at least one DHCP server (which may or may not be assigned an address using DHCP, and therefore may or may not be protected), zero or more protected DHCP clients, and one or more SAVI devices. It may also include DHCP relays, when the DHCP server is not co-located with a set of clients, and zero or more protected Non-SAVI devices. Outside the perimeter, via unprotected links, there may be many unprotected devices.
+-------------+
| unprotected |
| device |
+------+------+
|
+--------+ +-----+------+ +----------+
|DHCP +-----+ Non-SAVI +----+Bogus DHCP|
|Server A| | Device 1 | |Server |
+--------+ +-----+------+ +----------+
|trusted, unprotected link
. . . . . . . . . . . . . . . . .|. . . . . . . . . . . . . .
. | .
. Protection +---+------+ trusted link .
. Perimeter | SAVI +--------------+ .
. | Device C| | .
. +---+------+ | .
. | | .
. untrusted, +----------+ +---+------+ +------+---+ .
. protected | SAVI | | Non SAVI| | SAVI | .
. link+------+ Device A+----+ Device 3+-------+ Device B| .
. | +----+--+--+ +----------+ +-+---+----+ .
. | | +----------+ . . . . . | | .
. | . . . . . . | . . | | .
. | . | . | . +--------+ | .
. +----+-----+. +--+---+ . +----+-+ . +--+---+ . +---+----+ .
. | Non-SAVI |. |Client| . |DHCP | . |Client| . |DHCP | .
. | Device 2 |. |A | . |Relay | . |B | . |Server B| .
. +----------+. +------+ . +------+ . +------+ . +--------+ .
. . . . . . . . . . . . . . . . . . .
Figure 1: SAVI-DHCP Scenario
Figure 1 shows a deployment scenario that contains these elements. Note that a physical device can instantiate multiple elements, e.g., a switch can be both a SAVI device and a DHCP relay, or in a cloud computing environment, a physical host may contain a virtual switch plus some number of virtual hosts. In such cases, the links are logical links rather than physical links.
Networks are not usually isolated. As a result, traffic from other networks, including transit traffic as specified in [RFC6620] (e.g., traffic from another SAVI switch or a router) may enter a SAVI-DHCP network through the unprotected links. Since SAVI solutions are limited to validating traffic generated from a local link, SAVI-DHCP does not set up bindings for addresses assigned in other networks and cannot validate them. Traffic from unprotected links should be checked by an unprotected device or [RFC2827] mechanisms. The generation and deployment of such a mechanism is beyond the scope of this document.
Traffic from protected links is, however, locally generated, and should have its source addresses validated by SAVI-DHCP if possible. In the event that there is an intervening protected non-SAVI device between the host and the SAVI device, however, use of the physical attachment point alone as a binding anchor is insufficiently secure, as the several devices on a port or other point of attachment can spoof each other. Hence, additional information such as a MAC address SHOULD be used to disambiguate them.
As illustrated in Figure 1, a system attached to a SAVI device can be a DHCP client, a DHCP relay/server, a SAVI device, or a non-SAVI device. Different actions are performed on traffic originated from different elements. To distinguish among their requirements, several properties are associated with their point of attachment on the SAVI device.
When a binding association is uninstantiated, e.g., when no host is attached to the SAVI device using a given port or other binding anchor, the binding port attributes take default values unless overridden by configuration. By default, a SAVI switch does not filter DHCP messages, nor does it attempt to validate source addresses, which is to say that the binding attributes are ignored until SAVI-DHCP is itself enabled. This is because a SAVI switch that depends on DHCP cannot tell, a priori, which ports have valid DHCP servers attached, or which have routers or other equipment that would validly appear to use an arbitrary set of source addresses. When SAVI has been enabled, the attributes take effect.
The "Trust Attribute" is a Boolean value. If TRUE, it indicates that the packets from the corresponding attached device need not have their source addresses validated. Examples of a trusted attachment would be a port to another SAVI device, or to an IP router, as shown in Figure 1. In both cases, traffic using many source IP addresses will be seen. By default, the Trust attribute is FALSE, indicating that any device found on that port will seek an address using DHCP and be limited to using such addresses.
SAVI devices will not set up bindings for points of attachment with the Trust attribute set TRUE; no packets, including DHCP messages, from devices with this attribute on their attachments will be validated. However DHCP Server-to-Client messages will be snooped on attachment points with the Trust attribute set TRUE in the same way as if they had the DHCP-Trust attribute set (see Section 4.2.2.)
The "DHCP-Trust Attribute" is similarly a Boolean attribute. It indicates whether the attached device is permitted to initiate DHCP Server-to-Client messages. In Figure 1, the points of attachment of the DHCP Server and the DHCP Relay would have this attribute set TRUE, and attachment points that have Trust set TRUE are implicitly treated as if DHCP-Trust is TRUE..
If the DHCP-Trust Attribute is TRUE, SAVI devices will forward DHCP Server-to-Client messages from the points of attachment with this attribute. If the DHCP Server-to-Client messages can trigger the state transitions, the binding setup processes specified in Section 6 and Section 7 will handle them. By default, the DHCP-Trust attribute is FALSE, indicating that the attached system is not a DHCP server.
A DHCPv6 implementor can refer to [I-D.ietf-opsec-dhcpv6-shield] for more details.
The "DHCP-Snooping Attribute" is similarly a Boolean attribute. It indicates whether bindings will be set up based on DHCP snooping.
If this attribute is TRUE, DHCP Client-Server messages to points of attachment with this attribute will trigger creation of bindings based on the DHCP Snooping Process described in Section 6. If it is FALSE, either the Trust attribute must be TRUE (so that bindings become irrelevant) or another SAVI mechanism such as SAVI-FCFS must be used on the point of attachment.
The DHCP-Snooping attribute is configured on the DHCP Client's point of attachment. This attribute can be also used on the attachments to protected Non-SAVI devices that are used by DHCP clients. In Figure 1, the attachment from the Client A to the SAVI Device A, the attachment from the Client B to the SAVI Device B, and the attachment from the Non-SAVI Device 2 to the SAVI Device A can be configured with this attribute.
The "Data-Snooping Attribute" is a Boolean attribute. It indicates whether data packets from the corresponding point of attachment may trigger the binding setup procedure.
Data packets from points of attachment with this attribute may trigger the setup of bindings. SAVI devices will set up bindings on points of attachment with this attribute based on the data-triggered process described in Section 7.
If the DHCP-Snooping attribute is configured on a point of attachment, the bindings on this attachment are set up based on DHCP message snooping. However, in some scenarios, a DHCP client may use a DHCP address without the DHCP address assignment procedure being performed on its current attachment. For such attached devices, the Data Snooping Process, which is described in Section 7, is necessary. This attribute is configured on such attachments. The usage of this attribute is further discussed in Section 7.
Since some networks require DHCP deployment and others avoid it, there is no obvious universal default value for the Data-Snooping Attribute. Hence, the Data-Snooping Attribute should default to FALSE, and a mechanism should be implemented to conveniently set it to TRUE on all points of attachment for which the Trust attribute is FALSE.
The "Validating Attribute" is a Boolean attribute. It indicates whether packets from the corresponding attachment will have their IP source addresses validated based on binding entries on the attachment.
If it is TRUE, packets coming from attachments with this attribute will be validated based on binding entries on the attachment as specified in Section 8. If it is FALSE, they will not. Since the binding table is used in common with other SAVI algorithms, it merely signifies whether the check will be done, not whether it will be done for SAVI-DHCP originated bindings.
This attribute is by default the inverse of the Trust attribute; source addresses on untrusted links are validated by default. It MAY be set FALSE by the administration.
The expected use case is when SAVI is used to monitor but not block forged transmissions. The network manager, in that case, may set the DHCP-Snooping and/or Data-Snooping attribute TRUE but the Validating attribute FALSE.
Different types of attributes may indicate mutually exclusive actions on a packet. Mutually exclusive attributes MUST NOT be set TRUE on the same attachment. The compatibility of different attributes is listed in Figure 2. Note that although Trust and DHCP-Trust are compatible, there is no need to configure DHCP-Trust to TRUE on an attachment with Trust attribute TRUE.
+----------+----------+----------+----------+----------+----------+ | | | | DHCP- | Data- | | | | Trust |DHCP-Trust| Snooping | Snooping |Validating| +----------+----------+----------+----------+----------+----------+ | | | | mutually | mutually | mutually | | Trust | - |compatible| exclusive| exclusive| exclusive| +----------+----------+----------+----------+----------+----------+ | | | | | | | |DHCP-Trust|compatible| - |compatible|compatible|compatible| +----------+----------+----------+----------+----------+----------+ |DHCP- |mutually | | | | | |Snooping |exclusive |compatible| - |compatible|compatible| +----------+----------+----------+----------+----------+----------+ |Data- |mutually | | | | | |Snooping |exclusive |compatible|compatible| - |compatible| +----------+----------+----------+----------+----------+----------+ | |mutually | | | | | |Validating|exclusive |compatible|compatible|compatible| - | +----------+----------+----------+----------+----------+----------+
Figure 2: Table of Mutual Exclusions
SAVI devices form a perimeter separating trusted and untrusted regions of a network, as SAVI-FCFS does ( Section 2.5 of [RFC6620]). The perimeter is primarily designed for scalability. It has two implications.
Consider the example in Figure 1. The protection perimeter is formed by SAVI Devices A, B and C. In this case, SAVI device B does not create a binding for client A. However, because SAVI device A filters spoofed traffic from client A, SAVI device B can avoid receiving spoofed traffic from client A.
The perimeter in SAVI-DHCP is not only a perimeter for data packets, but also a perimeter for DHCP messages. DHCP server response messages incoming across the perimeter will be dropped (Section 8). The placement of the DHCP Relay and DHCP Server, which are not involved in [RFC6620], is related to the construction of the perimeter. The requirement on the placement and configuration of DHCP Relay and DHCP Server are discussed in Section 4.3.3.
A perimeter separating trusted and untrusted regions of the network is formed as follows:
In this way, the points of attachments with the Validating attribute TRUE (and generally together with attachments of unprotected devices) on SAVI devices can form a perimeter separating DHCP clients and trusted devices. Data packet checks are only performed on the perimeter. The perimeter is also a perimeter for DHCP messages. The DHCP-Trust attribute is only TRUE on links inside the perimeter. Only DHCP Server-to-Client messages originated within the perimeter are trusted.
As a result of the configuration guidelines, SAVI devices only trust DHCP Server-to-Client messages originated inside the perimeter. Thus, the trusted DHCP Relays and DHCP Servers must be placed within the perimeter. DHCP Server-to-Client messages will be filtered on the perimeter. Server-to-relay messages will not be filtered, as they are within the perimeter. In this way, DHCP Server-to-Client messages from bogus DHCP servers are filtered on the perimeter, having entered through untrusted points of attachment. The SAVI devices are protected from forged DHCP messages.
DHCP Server-to-Client messages arriving at the perimeter from outside the perimeter are not trusted. There is no distinction between a DHCP server owned and operated by the correct administration but outside the SAVI perimeter and a bogus DHCP server. For example, in Figure 1, DHCP server A is valid, but it is attached to Non-SAVI device 1. A bogus DHCP server is also attached Non-SAVI device 1. While one could imagine a scenario in which the valid one had a statistically configured port number and MAC address, and therefore a binding, by default SAVI-DHCP cannot distinguish whether a message received from the port of Non-SAVI device 1 is from DHCP server A or the bogus DHCP server. If the DHCP server A is contained in the perimeter, Non-SAVI device 1 will also be contained in the perimeter. Thus, the DHCP server A cannot be contained within the perimeter apart from manual configuration of the binding anchor.
Another consideration on the placement is that if the DHCP server/relay is not inside the perimeter, the SAVI devices may not be able to set up bindings correctly, because the SAVI devices may not be on the path between the clients and the server/relay, or the DHCP messages are encapsulated (e.g., Relay-reply and Relay-forward).
In common deployment practice, the traffic from the unprotected network is treated as trustworthy, which is to say that it is not filtered. In such a case, the Trust attribute can be set TRUE on the unprotected link. If Non-SAVI devices, or a number of connected Non-SAVI devices, are only attached to SAVI devices and unprotected devices, their attachment to SAVI devices can have the Trust attribute set TRUE. Then an unclosed perimeter will be formed, as illustrated in Figure 3.
| . . Protection |
| | | Perimeter |
| | | |
| Unprotected | | Unprotected |
| Link | | Link |
| | | |
| | | |
| +----+---+ +----+---+ +--------+ |
| |SAVI +----+Non-SAVI+----+SAVI | |
| |Device | |Device | |Device | |
| +----+---+ +--------+ +----+---+ |
| | | |
\_____________+___________________________+________/
| |
| |
+--------+ +--------+
|DHCP | |DHCP |
|Client | |Client |
+--------+ +--------+
Figure 3: Alternative Perimeter Configuration
The strength of this binding-based mechanism depends on the strength of the binding anchor. The sample binding anchors in [RFC7039] have the property that they associate an IP address with a direct physical or secure virtual interface such as a switch port, a subscriber association, or a security association. In addition, especially in the case that a protected non-SAVI device such as a desktop switch or a hub is between the client and SAVI devices, they MAY be extended to also include a MAC address or other link-layer attribute. In short, a binding anchor is intended to associate an IP address with something unspoofable that identifies a single client system or one of its interfaces; this may be a physical or virtual interface or that plus disambiguating link-layer information.
If the binding anchor is spoofable, such as a plain MAC address, or non-exclusive, such as a switch port extended using a non-SAVI device, an attacker can use a forged binding anchor to evade validation. Indeed, using a binding anchor that can be easily spoofed can lead to worse outcomes than allowing spoofed IP traffic. Thus, a SAVI device MUST use a non-spoofable and exclusive binding anchor.
In addition to a possible binding anchor configuration specified in Section 4.2, an implementation has the following configuration requirements:
The Binding State Table, which may be implemented centrally in the switch or distributed among its ports, is used to contain the bindings between the IP addresses assigned to the attachments and the corresponding binding anchors of the attachments. Note that in this description, there is a binding entry for each IPv4 or IPv6 address associated with each binding anchor, and there may be several of each such address, especially if the port is extended using a protected non-SAVI device. Each binding entry, has 5 fields:
The IA is not present in the BST for three reasons:
An example of such a table is shown in Figure 4.
+---------+----------+-----------+-----------+--------+----------+ | Anchor | Address | State | Lifetime | TID | Timeouts | +---------+----------+-----------+-----------+--------+----------+ | Port_1 | IP_1 | BOUND | 65535 | TID_1 | 0 | +---------+----------+-----------+-----------+--------+----------+ | Port_1 | IP_2 | BOUND | 10000 | TID_2 | 0 | +---------+----------+-----------+-----------+--------+----------+ | Port_2 | IP_3 | INIT_BIND | 1 | TID_3 | 0 | +---------+----------+-----------+-----------+--------+----------+
Figure 4: Example Binding State Table
This section specifies the process of setting up bindings based on DHCP snooping. This process is illustrated using a state machine.
The rationale of the DHCP Snooping Process is that if a DHCP client is legitimately using a DHCP-assigned address, the DHCP address assignment procedure that assigns the IP address to the client must have been performed via the client's point of attachment. This assumption works when the SAVI device is always on the path(s) from the DHCP client to the DHCP server(s)/relay(s). Without considering the movement of DHCP clients, the SAVI device should be the cut vertex whose removal will separate the DHCP client and the remaining network containing the DHCP server(s)/ and relay(s). For most of the networks whose topologies are simple, it is possible to deploy this SAVI function at proper devices to meet this requirement.
However, if there are multiple paths from a DHCP client to the DHCP server and the SAVI device is only on one of them, there is an obvious failure case: the SAVI device may not be able to snoop the DHCP procedure. Host movement may also make this requirement difficult to meet. For example, when a DHCP client moves from one attachment to another attachment in the same network, it may fail to reinitialize its interface or send a Confirm message because of incomplete protocol implementation. Thus, there can be scenarios in which only performing this DHCP Snooping Process is insufficient to set up bindings for all the valid DHCP addresses. These exceptions and the solutions are discussed in Section 7.
Following binding states are present in this process and the corresponding state machine:
NO_BIND: No binding has been set up.
INIT_BIND: A potential binding has been set up.
BOUND: The binding has been set up.
This section describes events in this process and the corresponding state machine transitions. The DHCP message categories (e.g., DHCPv4 Discover) defined in Section 3 are used extensively in the definitions of events and elsewhere in the state machine definition. If an event will trigger the creation of a new binding entry, the binding entry limit on the binding anchor MUST NOT be exceeded.
EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires.
EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is received.
EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received.
EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received.
EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is received.
EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received.
EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with Rapid Commit option is received.
EVE_DHCP_REPLY: A DHCPv4 ACK or a DHCPv6 Reply message is received.
EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is received.
EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is received.
EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY-REPLY (refer to section 4.3.3 of [RFC5007]) is received.
Note: the events listed here do not cover all the DHCP messages in Section 3. The messages which do not really determine address usage (DHCPv4 Discover, DHCPv4 Inform, DHCPv6 Solicit without Rapid Commit, DHCPv6 Information-Request, DHCPv4 Offer, DHCPv6 Advertise, DHCPv6 Reconfigure), and which are not necessary to snoop (DHCPv4 NAK, refer to section 6.4.2.1), are not included. Note also that DHCPv4 DHCPLEASEQUERY is not used in the DHCP Snooping process to avoid confusion with Section 7. Also since the LEASEQUERY should have been originated by the SAVI Device itself, the destination check should verify that the message is directed to this SAVI device - and it should not be forwarded once it has been processed here.
Moreover, only if a DHCP message can pass the following checks, the corresponding event is regarded as a valid event:
On receiving a DHCP message without triggering a valid event, the state will not change, and the actions will not be performed. Note that if a message does not trigger a valid event but it can pass the checks in Section 8.2, it MUST be forwarded.
This section specifies state transitions and their corresponding actions.
The SAVI device MUST forward the message.
The SAVI device will generate an entry in the BST. The Binding anchor field is set to the binding anchor of the attachment from which the message is received. The State field is set to INIT_BIND. The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the message. If the message is DHCPv4 Request, the Address field can be set to the address to request, i.e., the 'requested IP address'. An example of the entry is illustrated in Figure 5.
+--------+-------+---------+-----------------------+-----+----------+ | Anchor |Address| State | Lifetime | TID | Timeouts | +--------+-------+---------+-----------------------+-----+----------+ | Port_1 | |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 0 | +--------+-------+---------+-----------------------+-----+----------+
Figure 5: Binding entry in BST on Request/Rapid Commit/Reboot triggered initialization
Resulting state: INIT_BIND - A potential binding has been set up
The SAVI device MUST forward the message.
The SAVI device will generate an entry in the BST. The Binding anchor field is set to the binding anchor of the attachment from which the message is received. The State field is set to INIT_BIND. The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the message. If the message is DHCPv4 Reboot, the Address field can be set to the address to request, i.e., the 'requested IP address'. An example of the entry is illustrated in Figure 5.
Resulting state: INIT_BIND - A potential binding has been set up
The SAVI device MUST forward the message.
The SAVI device will generate an entry in the BST. The Binding anchor field is set to the binding anchor of the attachment from which the message is received. The State field is set to INIT_BIND. The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the message. An example of the entry is illustrated in Figure 5.
Resulting state: INIT_BIND - A potential binding has been set up
The SAVI device MUST forward the message.
The SAVI device will generate corresponding entries in the BST for each address in each Identity Association (IA) option of the Confirm message. The Binding anchor field is set to the binding anchor of the attachment from which the message is received. The State field is set to INIT_BIND. The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the message. The Address field is set to the address(es) to confirm. An example of the entries is illustrated in Figure 6.
+--------+-------+---------+-----------------------+-----+----------+ | Anchor |Address| State | Lifetime | TID | Timeouts | +--------+-------+---------+-----------------------+-----+----------+ | Port_1 | Addr1 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 0 | +--------+-------+---------+-----------------------+-----+----------+ | Port_1 | Addr2 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 0 | +--------+-------+---------+-----------------------+-----+----------+
Figure 6: Binding entry in BST on Confirm triggered initialization
Resulting state: INIT_BIND - A potential binding has been set up
These cannot happen because they are each something that happens AFTER a binding has been created.
The message MUST be forwarded to the corresponding client.
If the message is DHCPv4 ACK, the Address field of the corresponding entry (i.e., the binding entry whose TID is the same of the message) is set to the address in the message(i.e., 'yiaddr' in DHCPv4 ACK). The Lifetime field is set to the sum of the lease time in ACK message and MAX_DHCP_RESPONSE_TIME. The State field is changed to BOUND.
If the message is DHCPv6 Reply, there are following cases:
Note: the SAVI devices do not check if the assigned addresses are duplicated because in SAVI-DHCP scenarios, the DHCP servers are the only source of valid addresses. However, the DHCP servers should be configured to make sure no duplicated addresses are assigned.
+--------+-------+-------+------------------------+-----+----------+ | Anchor |Address| State | Lifetime | TID | Timeouts | +--------+-------+-------+------------------------+-----+----------+ | Port_1 | Addr1 | BOUND | 2*MAX_LEASEQUERY_DELAY | TID | 0 | +--------+-------+-------+------------------------+-----+----------+ | Port_1 | Addr2 | BOUND | 2*MAX_LEASEQUERY_DELAY | TID | 0 | +--------+-------+-------+------------------------+-----+----------+
Figure 7: From INIT_BIND to BOUND on DHCP Reply in response to Confirm
Transition +--------+-------+-------+------------------------+-----+----------+ | Anchor |Address| State | Lifetime | TID | Timeouts | +--------+-------+-------+------------------------+-----+----------+ | Port_1 | Addr1 | BOUND |Lease time+ | TID | 0 | | | | |MAX_DHCP_RESPONSE_TIME | | | +--------+-------+-------+------------------------+-----+----------+ | Port_1 | Addr2 | BOUND |Lease time+ | TID | 0 | | | | |MAX_DHCP_RESPONSE_TIME | | | +--------+-------+-------+------------------------+-----+----------+
Figure 8: From INIT_BIND to BOUND on DHCP Reply in response to Request
Resulting state: BOUND - The binding has been set up
The entry MUST be deleted from BST.
Resulting state: An entry that has been deleted from the BST may be considered to be in the state "NO_BIND" - No binding has been set up.
If no DHCP Server-to-Client messages which assign addresses or confirm addresses are received, corresponding entries will expire automatically. Thus, other DHCP Server-to-Client messages (e.g., DHCPv4 NAK) are not specially processed.
As a result, the following events, should they occur, are ignored until either a DHCPv4 ACK or a DHCPv6 Reply message is received or the lifetime of the binding entry expires.
In each case, the message MUST be forwarded.
Resulting state: INIT_BIND - A potential binding has been set up
The entry MUST be deleted from BST.
Resulting state: An entry that has been deleted from the BST may be considered to be in the state "NO_BIND" - No binding has been set up.
The message MUST be forwarded.
The SAVI device first gets all the addresses ("Requested IP address" in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, addresses in all the IA options of DHCPv6 Decline/Release) to decline/release in the message. Then the corresponding entries MUST be removed.
Resulting state in each relevant BST entry: An entry that has been deleted from the BST may be considered to be in the state "NO_BIND" - No binding has been set up.
The message MUST be forwarded.
The SAVI device first gets all the addresses ("Requested IP address" in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, addresses in all the IA options of DHCPv6 Decline/Release) to decline/release in the message. Then the corresponding entries MUST be removed.
Resulting state in each relevant BST entry: An entry that has been deleted from the BST may be considered to be in the state "NO_BIND" - No binding has been set up.
The message MUST be forwarded.
In such case, a new TID will be used by the client. The TID field of the corresponding entries MUST be set to the new TID. Note that TID check will not be performed on such messages.
Resulting state: BOUND: The binding has been set up
The message MUST be forwarded.
In such case, a new TID will be used by the client. The TID field of the corresponding entries MUST be set to the new TID. Note that TID check will not be performed on such messages.
Resulting state: BOUND: The binding has been set up
The message MUST be forwarded.
The DHCP Reply messages received in current states should be in response to DHCP Renew/Rebind.
If the message is DHCPv4 ACK, the SAVI device updates the binding entry with matched TID, with the Lifetime field set to be the sum of the new lease time and MAX_DHCP_RESPONSE_TIME, leaving the entry in the state BOUND.
If the message is DHCPv6 Reply, the SAVI device checks each IA Address option in each IA option. For each:
Resulting state: NO_BIND or BOUND, as specified.
The message MUST be forwarded.
The message should be in response to the Lease query message sent in Section 6.4.2. The related binding entry can be determined based on the address in the IA Address option in the Lease query-reply message. The Lifetime field of the corresponding binding entry is set to the sum of the lease time in the LEASEQUERY-REPLY message and MAX_DHCP_RESPONSE_TIME.
Resulting state: BOUND: The binding has been set up
The following events are ignored if received while the indicated entry is in the state BOUND. Any required action will be the result of the next message in the client/server exchange.
The main state transits are listed as follows. Note that not all the details are specified in the table and the diagram.
State Event Action Next State
NO_BIND RQ/RC/CF/RE Generate entry INIT_BIND
INIT_BIND RPL Record lease time BOUND
(send lease query if no lease)
INIT_BIND EVE_ENTRY_EXPIRE Remove entry NO_BIND
BOUND RLS/DCL Remove entry NO_BIND
BOUND EVE_ENTRY_EXPIRE Remove entry NO_BIND
BOUND RPL Set new lifetime BOUND
BOUND LQR Record lease time BOUND
Figure 9: State Transition Table
RQ: EVE_DHCP_REQUEST
CF: EVE_DHCP_CONFIRM
RC: EVE_DHCP_SOLICIT_RC
RE: EVE_DHCP_REBOOT
RPL: EVE_DHCP_REPLY
DCL: EVE_DHCP_DECLINE
RLS: EVE_DHCP_RELEASE
LQR: EVE_DHCP_LEASEQUERY
+-------------+
| |
/--------+ NO_BIND |<--------\
| ----->| | |
| | +-------------+ |EVE_DHCP_RELEASE
EVE_DHCP_REQUEST | | |EVE_DHCP_DECLINE
EVE_DHCP_CONFIRM | |EVE_ENTRY_EXPIRE |EVE_ENTRY_EXPIRE
EVE_DHCP_SOLICIT_RC| | |
EVE_DHCP_REBOOT | | |
| | |
| | |
v | |
+-------------+ +------------+
| | EVE_DHCP_REPLY | |
| INIT_BIND --------------------->| BOUND |<-\
| | | | |
+-------------+ +------------+ |
| |
\--------/
EVE_DHCP_REPLY
EVE_DHCP_LEASEQUERY
Figure 10: Diagram of Transit
The rationale of the DHCP Snooping Process specified in Section 6 is that if a DHCP client's use of a DHCP address is legitimate, the corresponding DHCP address assignment procedure must have been finished during the attachment of the DHCP client. This is the case when the SAVI device is continuously on the path(s) from the DHCP client to the DHCP server(s)/relay(s). However, there are two cases in which this does not work:
The Data Snooping Process can avoid the permanent blocking of legitimate traffic in case one of these two exceptions occurs. This process is performed on attachments with the Data-Snooping attribute. Data packets without a matching binding entry may trigger this process to set up bindings.
Snooping data traffic introduces considerable burden on the processor and ASIC-to-Processor bandwidth of SAVI devices. Because of the overhead of this process, the implementation of this process is OPTIONAL. This function SHOULD be enabled unless the implementation is known to be used in the scenarios without the above exceptions. For example, if the implementation is to be used in networks with tree topology and without host local-link movement, there is no need to implement this process in such scenarios.
This process is not intended to set up a binding whenever a data packet without a matched binding entry is received. Instead, unmatched data packets trigger this process probabilistically and generally a number of unmatched packets will be discarded before the binding is set up. The parameter(s) of this probabilistic process SHOULD be configurable, defaulting to a situation where data snooping is disabled.
This process makes use of NS/ARP and DHCP LEASEQUERY to set up bindings. If an address is not used by another client in the network, and the address has been assigned in the network, the address can be bound with the binding anchor of the attachment from which the unmatched packet is received.
The Data Snooping Process provides an alternative path for binding entries to reach the BOUND state in the exceptional cases explained in Section 7.1 when there are no DHCP messages that can be snooped by the SAVI device.
In some of the exceptional cases (especially the dynamic topology case), by the time the binding has reached the BOUND state the DHCP messages may be passing through the SAVI device. In this case the events driven by DHCP messages that are expected in the BOUND state in the DHCP Snooping Process may occur and the binding can be handled by the DHCP Snooping Process state machine.
In any event, the lease expiry timeout event will occur even if no others do. This will cause the binding to be deleted and the state to logically return to NO_BIND state. Either the DHCP or the Data Snooping Process will be reinvoked if the lease is still place. If DHCP messages are still not passing through the SAVI device, there will be a brief disconnection during which data packets passing through the SAVI device will be dropped. The probabilistic initiation of the Data Snooping Process can then take over again and return the binding state to BOUND in due course.
The security issues concerning this process are discussed is Section 11.1.
In addition to NO_BIND and BOUND from Section 6.2, three new states used in this process are listed here. The INIT_BIND state is not used, as it is entered by observing a DHCP message.
DETECTION: The address in the entry is undergoing local duplication detection.
RECOVERY: The SAVI device is querying the assignment and lease time of the address in the entry through DHCP lease query.
VERIFY: The SAVI device is verifying that the device connected to the attachment point has a hardware address that matches the one returned in the DHCP lease query.
Because the mechanisms used for the operations carried out while the binding is in these three states operate over unreliable protocols, each operation is carried out twice with a timeout that is triggered if no response is received.
To handle the Data Snooping Process, five extra events, described here, are needed in addition to those used by the DHCP Snooping Process (see Section 6.3). If an event will trigger the creation of a new binding entry, the binding entry limit on the binding anchor MUST NOT be exceeded.
EVE_DATA_UNMATCH: A data packet without a matched binding is received.
EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message against an address in DETECTION state is received from a host other than the one for which the entry was added (i.e., a host attached at another point than the one on which the triggering data packet was received).
EVE_DATA_LEASEQUERY:
EVE_DATA_VERIFY: An ARP Reply/Neighbor Advertisement(NA) message has been received in the VERIFY state from the device connected to the attachment point on which the data packet was received.
The triggering packet should pass the following checks to trigger a valid event:
EVE_DATA_EXPIRE: A timer expires indicating that a response to a hardware address verification message sent in the VERIFY state has not been received within the specified DETECTION_TIMEOUT period.
EVE_ENTRY_EXPIRE: A timer expires after the Lifetime indicated in the relevant BST entry has elapsed. This is identical to the usage in the DHCP Snooping Process.
The Data Snooping Process involves sending three different messages to other network devices. Each message may be sent up to twice since they are sent over unreliable transports and are sent in different states. The functions defined in this section specify the messages to be sent in the three cases. In each case the message to be sent depends on whether the triggering data packet is an IPv4 or an IPv6 packet.
Send a message to check if the source address in the data packet that triggered the data snooping process has a local conflict (that is, it uses an address that is being used by another node):
As both the ARP and DAD processes are unreliable (either the packet to or from the other system may be lost in transit, see [RFC6620]), if there is no response after the DETECTION_TIMEOUT an EVE_ENTRY_EXPIRE is generated.
Send a DHCP lease query message to the DHCP server(s) to determine if it has given out a lease for the source address in the triggering data packet. A list of authorized DHCP servers is kept by the SAVI device. The list should be either pre-configured with the IPv4 and/or IPv6 addresses or dynamically discovered: For networks using IPV4 this can be done by sending DHCPv4 Discover messages and parsing the returned DHCPv4 Offer messages; for networks using IPv6 discovery can be done by sending DHCPv6 SOLICIT messages and parsing the returned ADVERTISE messages. See Section 11.2 regarding the securing of the process and the advisability of using the DHCPv6 All_DHCP_Relay_Agents_and_Servers or All_DHCP_Servers multicast addresses. The same TID should be used for all lease query messages sent in response to a triggering data message on an attachment point. The TID is generated if the TID field in the BST entry is empty and recorded in the TID field of the BST entry when the first message is sent. Subsequent messages use the TID from the BST entry.
As DHCP lease queries are an unreliable process (either the packet to or from the server may be lost in transit), if there is no response after the MAX_LEASEQUERY_DELAY an EVE_DATA_EXPIRE is generated. Note that multiple response messages may be received if the list of authorized servers contains more than one address of the appropriate type and, in the case of DHCPv6, the responses may contain additional addresses for which leases have been allocated.
Send a message to verify that the link layer address in the attached device that sent the triggering data packet matches the link layer address contained in the lease query response:
As both the ARP and NS/NA processes are unreliable (either the packet to or from the other system may be lost in transit, see [RFC6620]), if there is no response after the DETECTION_TIMEOUT an EVE_DATA_EXPIRE is generated.
Make a probabilistic determination as to whether to act on this event. The probability may be configured or calculated based on the state of the SAVI device. This probability should be low enough to mitigate the damage from DoS attack against this process.
Create a new entry in the BST. Set the Binding Anchor field to the corresponding binding anchor of the attachment. Set the Address field to the source address of the packet.
Address conflicts MUST be detected and prevented.
The packet that triggers this event SHOULD be discarded.
An example of the BST entry during duplicate address detection is illustrated in Figure 11.
+--------+-------+---------+-----------------------+-----+----------+ | Anchor |Address| State | Lifetime | TID | Timeouts | +--------+-------+---------+-----------------------+-----+----------+ | Port_1 | Addr1 |DETECTION| DETECTION_TIMEOUT | | 0 | +--------+-------+---------+-----------------------+-----+----------+
Figure 11: Binding entry in BST on data triggered initialization
Resulting state: DETECTION - The address in the entry is undergoing local duplication detection - or RECOVERY - DHCP lease(s) associated with the address are being queried.
EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message received from unexpected system
EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or LEASEQUERY-REPLY is received
EVE_DATA_VERIFY: A valid ARP Reply or NA message received from the attached device
All EVE_DHCP_* events defined in Section 6.3.2 are treated as described in the DHCP Snooping Process (Section 6.4.1) and may result in that process being triggered.
EVE_ENTRY_EXPIRE:
EVE_DATA_EXPIRE:
When this event occurs, no address conflict has been detected during the previous DETECTION_TIMEOUT period.
An example of the entry is illustrated in Figure 12.
+--------+-------+----------+----------------------+-----+----------+ | Anchor |Address| State | Lifetime | TID | Timeouts | +--------+-------+----------+----------------------+-----+----------+ | Port_1 | Addr1 | RECOVERY | MAX_LEASEQUERY_DELAY | TID | 0 | +--------+-------+----------+----------------------+-----+----------+
Figure 12: Binding entry in BST on Lease Query
Resulting state: DETECTION - If a second local conflict period is required - or RECOVERY - The SAVI device is querying the assignment and lease time of the address in the entry through DHCP Leasequery
Remove the entry.
Resulting state: NO_BIND - No binding has been set up
EVE_DATA_UNMATCH: A data packet without matched binding is received
All EVE_DHCP_* events defined in Section 6.3.2
EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is received
Set the State in the BST entry to VERIFY. Depending on the type of triggering source IP address, process the received DHCP lease query response:
Resulting state: VERIFY - awaiting verification or otherwise of the association of the IP address with the connected interface.
Depending on the value of the Timeouts field in the BST entry, either send repeat lease query messages or discard the binding:
Resulting state: RECOVERY - if repeat lease queries are sent - or NO_BIND - if no successful responses to lease query messages have been received.
EVE_DATA_UNMATCH: A data packet without matched binding is received
EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message received from unexpected system
EVE_DATA_VERIFY: A valid ARP Reply or NA message received from the attached device
All EVE_DHCP_* events defined in Section 6.3.2
EVE_DATA_EXPIRE:
If lease query messages were sent to more than one DHCP server during RECOVERY state, additional successful lease query responses may be received relating to the source IP address. The conflict resolution mechanisms specified in Section 6.8 of [RFC4388] and Section 4.3.4 of [RFC5007] can be used to determine the message from which values are used to update the BST Lifetime entry and the hardware address obtained from DHCP, as described in Section 7.8.1. In the case of DHCPv6 queries, the LEASEQUERY-REPLY may contain additional addresses as described in Section 7.8.1. If so additional BST entries MUST be created or ones previously created updated as described in that section.
Resulting state: VERIFY (no change).
Depending on the type of triggering source IP address, this event may indicate that the device attached via the binding anchor in the BST entry is configured by DHCP using the IP address:
If the binding entry has been verified, set the State in the BST entry to BOUND. Clear the TID field. Cancel the verification timer.
Resulting state: VERIFY (no change) - if IPv4 DHCPLEASEQUERY "chaddr" address does not match ARP Reply hardware address - or BOUND - otherwise.
The DHCP lease lifetime has expired before the entry could be verified. Remove the entry. Transition to NO_BIND state.
Resulting state: NO_BIND - No binding has been set up
Depending on the value of the Timeouts field in the BST entry, either send a repeat validation message or discard the binding:
Resulting state: VERIFY - additional verification message sent - or NO_BIND - No binding has been set up
EVE_DATA_UNMATCH: A data packet without matched binding is received
EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message received from unexpected system
All EVE_DHCP_* events defined in Section 6.3.2
Upon entry to the state BOUND, control the system continues as if a DHCP message assigning the address has been observed, as in Section 6.4.3. The BST entry has been restored.
Note that the TID field contains no value after the binding state changes to BOUND. The TID field is recovered from snooping DHCP Renew/Rebind messages if these are observed as described in the DHCP Snooping Process. Because TID is used to associate binding entries with messages from DHCP servers, it must be recovered; or else a number of state transitions of this mechanism will be not executed normally.
The main state transitions are listed as follows.
State Event Action Next State NO_BIND EVE_DATA_UNMATCH Start duplicate detect DETECTION DETECTION EVE_ENTRY_EXPIRE 1 Repeat duplicate detect DETECTION DETECTION EVE_ENTRY_EXPIRE 2 Start lease query RECOVERY DETECTION EVE_DATA_CONFLICT Remove entry NO_BIND RECOVERY EVE_ENTRY_EXPIRE 1 Repeat lease query RECOVERY RECOVERY EVE_ENTRY_EXPIRE 2 No lease found; remove entry NO_BIND RECOVERY EVE_DATA_LEASEQUERY Set lease time; Start verify VERIFY VERIFY EVE_ENTRY_EXPIRE Lease expiry; remove entry NO_BIND VERIFY EVE_DATA_LEASEQUERY Resolve lease conflict(s) VERIFY VERIFY EVE_DATA_VERIFY Finish validation BOUND or NO_BIND VERIFY EVE_DATA_EXPIRE 1 Repeat verify VERIFY VERIFY EVE_DATA_EXPIRE 2 Verify failed; remove entry NO_BIND BOUND EVE_ENTRY_EXPIRE Lease expiry; remove entry NO_BIND BOUND RENEW/REBIND Record TID BOUND
Figure 13: State Transition Table
+-------------+ EVE_ENTRY_EXPIRE
/---------+ |<------------------------\
| | NO_BIND | EVE_DATA_EXPIRE |
EVE_DATA_UNMATCH | /----->| |<----\ (2nd VRF_DELAY) |
| | +-------------+ | |
| | EVE_ENTRY_EXPIRE | |
| | (2nd LQ_DELAY) | |
EVE_ENTRY_EXPIRE | | | EVE_ENTRY_EXPIRE |
(1st DAD_DELAY) | | | (1st LQ_DELAY) |
/------\ | | | /--------\ |
| | | | EVE_DATA_CONFLICT \---\ | | |
| v v | | v | |
| +-------------+ EVE_ENTRY_EXPIRE +------------+ | |
| | | (2nd DAD_DELAY) | | | |
\----+ DETECTION ------------------------>| RECOVERY +--/ |
| | | | |
+-------------+ (To NO_BIND) +------------+ |
^ | |
| EVE_DATA_LEASEQUERY | |
/----------\ | | |
| | | EVE_ENTRY_EXPIRE | |
EVE_DHCP_RENEW| v | v |
EVE_DHCP_REBIND| +-------------+ +-------------+ |
| | | | +--/
\----+ BOUND |<---------------+ VERIFY |
| | EVE_DATA_VERIFY| |<-\
+-------------+ +-------------+ |
| |
\----------/
EVE_DATA_LEASEQUERY
EVE_DATA_EXPIRE
(1st VRF_DELAY)
Figure 14: Diagram of Transit
LQ_DELAY: MAX_LEASEQUERY_DELAY
VRF_DELAY: DETECTION_TIMEOUT
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 NDP (Neighbor Discovery Protocol) [RFC4861] messages are classified as control packets. All other packets are classified as data packets.
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., the SAVI-FCFS [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 BST with state BOUND, 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.
For attachments with the Validating attribute:
DHCPv4 Client-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-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 sender protocol address is neither all zeros address 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.
If a SAVI device reboots, the information kept in volatile memory will be lost. This section specifies the restoration of attribute configuration and BST.
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 SAVI device, if the configuration of binding anchor attributes is found in non-volatile storage, the configuration MUST be used.
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, to recover 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 which would have expired before the reboot MUST be removed.
The following constants are recommended for use in this context:
There are two security problems about the Data Snooping Process Section 7:
In [RFC4388] and [RFC5007] the specific case of DHCP lease queries 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 lease query operations for access concentrators in Section 7 of [RFC4388] and Section 5 of [RFC5007] MUST be followed when lease queries 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 servers) so that manual configuration of keying material would not be overly burdensome.
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.
In this way, the bindings of a departing client are kept for OFFLINK_DELAY. In case 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.
DNA [RFC4436][RFC6059] is designed to decrease the handover latency after re-attachment to the same network. DNA mainly relies on performing reachability test by sending unicast Neighbor Solicitation/Router Solicitation/ARP Request message 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 reachability test with an address bound to another client. If 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 re-configuration 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 re-attached 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 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 is 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 zero as required by [RFC2131]. Thus, if the address is still valid, the binding will be recovered from the DHCP Snooping Process.
A binding entry will consume a 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 resource 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 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.
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 the majority of hosts that never spoof SHOULD NOT be logged.
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, that will need to be specified.
This memo asks the IANA for no new parameters.
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 valuation 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.
This document was generated using the xml2rfc tool.
| [I-D.ietf-opsec-dhcpv6-shield] | Gont, F., Will, W. and G. Velde, "DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers", Internet-Draft draft-ietf-opsec-dhcpv6-shield-05, January 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, May 2000. |
| [RFC3736] | Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. |
| [RFC7039] | Wu, J., Bi, J., Bagnulo, M., Baker, F. and C. Vogt, "Source Address Validation Improvement (SAVI) Framework", RFC 7039, October 2013. |
| [RFC7341] | Sun, Q., Cui, Y., Siodelski, M., Krishnan, S. and I. Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC 7341, August 2014. |