RFC 7513
Source Address Validation Improvement (SAVI) Solution for DHCP
Pages: 54
Proposed Standard
Proposed Standard
Part 1 of 3 – Pages 1 to 17
Internet Engineering Task Force (IETF) J. Bi Request for Comments: 7513 J. Wu Category: Standards Track G. Yao ISSN: 2070-1721 Tsinghua Univ. F. Baker Cisco May 2015 Source Address Validation Improvement (SAVI) Solution for DHCPAbstract
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 Improvement (SAVI) device. The bindings set up by this procedure are used to filter packets with forged source IP addresses. This mechanism complements BCP 38 (RFC 2827) ingress filtering, providing finer-grained source IP address validation. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7513. Copyright Notice 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Deployment Scenario and Configuration . . . . . . . . . . . . 8 4.1. Elements and Scenario . . . . . . . . . . . . . . . . . . 8 4.2. SAVI Binding Type Attributes . . . . . . . . . . . . . . 10 4.2.1. Trust Attribute . . . . . . . . . . . . . . . . . . . 10 4.2.2. DHCP-Trust Attribute . . . . . . . . . . . . . . . . 11 4.2.3. DHCP-Snooping Attribute . . . . . . . . . . . . . . . 11 4.2.4. Data-Snooping Attribute . . . . . . . . . . . . . . . 11 4.2.5. Validating Attribute . . . . . . . . . . . . . . . . 12 4.2.6. Table of Mutual Exclusions . . . . . . . . . . . . . 13 4.3. Perimeter . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.1. SAVI-DHCP Perimeter Overview . . . . . . . . . . . . 13 4.3.2. SAVI-DHCP Perimeter Configuration Guideline . . . . . 14 4.3.3. On the Placement of the DHCP Server and Relay . . . . 15 4.3.4. An Alternative Deployment . . . . . . . . . . . . . . 15 4.3.5. Considerations regarding Binding Anchors . . . . . . 16 4.4. Other Device Configuration . . . . . . . . . . . . . . . 17 5. Binding State Table (BST) . . . . . . . . . . . . . . . . . . 17 6. DHCP Snooping Process . . . . . . . . . . . . . . . . . . . . 18 6.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 18 6.2. Binding States Description . . . . . . . . . . . . . . . 19 6.3. Events . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.3.1. Timer Expiration Event . . . . . . . . . . . . . . . 19 6.3.2. Control Message Arriving Events . . . . . . . . . . . 19 6.4. The State Machine of DHCP Snooping Process . . . . . . . 21 6.4.1. Initial State: NO_BIND . . . . . . . . . . . . . . . 21 6.4.2. Initial State: INIT_BIND . . . . . . . . . . . . . . 24 6.4.3. Initial State: BOUND . . . . . . . . . . . . . . . . 27 6.4.4. Table of State Machine . . . . . . . . . . . . . . . 30 7. Data Snooping Process . . . . . . . . . . . . . . . . . . . . 31 7.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . 31 7.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 32 7.3. Additional Binding States Description . . . . . . . . . . 33 7.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.5. Message Sender Functions . . . . . . . . . . . . . . . . 35 7.5.1. Duplicate Detection Message Sender . . . . . . . . . 35 7.5.2. Leasequery Message Sender . . . . . . . . . . . . . . 36 7.5.3. Address Verification Message Sender . . . . . . . . . 36 7.6. Initial State: NO_BIND . . . . . . . . . . . . . . . . . 37 7.6.1. Event: EVE_DATA_UNMATCH: A data packet without a matched binding is received . . . . . . . . . . . . . 37 7.6.2. Events Not Observed in NO_BIND for Data Snooping . . 38
7.7. Initial State: DETECTION . . . . . . . . . . . . . . . . 39
7.7.1. Event: EVE_ENTRY_EXPIRE . . . . . . . . . . . . . . . 39
7.7.2. Event: EVE_DATA_CONFLICT: ARP Reply / NA Message
Received from Unexpected System . . . . . . . . . . . 39
7.7.3. Events Not Observed in DETECTION . . . . . . . . . . 39
7.8. Initial State: RECOVERY . . . . . . . . . . . . . . . . . 40
7.8.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE
or successful LEASEQUERY-REPLY is received . . . . . 40
7.8.2. Event: EVE_ENTRY_EXPIRE . . . . . . . . . . . . . . . 41
7.8.3. Events Not Observed in RECOVERY . . . . . . . . . . . 41
7.9. Initial State: VERIFY . . . . . . . . . . . . . . . . . . 41
7.9.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE
or successful LEASEQUERY-REPLY is received . . . . . 41
7.9.2. Event: EVE_DATA_VERIFY: A valid ARP Reply or NA is
received from the device attached via the binding
anchor . . . . . . . . . . . . . . . . . . . . . . . 42
7.9.3. Event: EVE_ENTRY_EXPIRE . . . . . . . . . . . . . . . 42
7.9.4. Event: EVE_DATA_EXPIRE . . . . . . . . . . . . . . . 43
7.9.5. Events Not Observed in VERIFY . . . . . . . . . . . . 43
7.10. Initial State: BOUND . . . . . . . . . . . . . . . . . . 43
7.11. Table of State Machine . . . . . . . . . . . . . . . . . 44
8. Filtering Specification . . . . . . . . . . . . . . . . . . . 45
8.1. Data Packet Filtering . . . . . . . . . . . . . . . . . . 46
8.2. Control Packet Filtering . . . . . . . . . . . . . . . . 46
9. State Restoration . . . . . . . . . . . . . . . . . . . . . . 47
9.1. Attribute Configuration Restoration . . . . . . . . . . . 47
9.2. Binding State Restoration . . . . . . . . . . . . . . . . 47
10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 48
11. Security Considerations . . . . . . . . . . . . . . . . . . . 48
11.1. Security Problems with the Data Snooping Process . . . . 48
11.2. Securing Leasequery Operations . . . . . . . . . . . . . 49
11.3. Client Departure Issues . . . . . . . . . . . . . . . . 49
11.4. Compatibility with Detecting Network Attachment (DNA) . 50
11.5. Binding Number Limitation . . . . . . . . . . . . . . . 51
11.6. Privacy Considerations . . . . . . . . . . . . . . . . . 51
11.7. Fragmented DHCP Messages . . . . . . . . . . . . . . . . 51
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
12.1. Normative References . . . . . . . . . . . . . . . . . . 52
12.2. Informative References . . . . . . . . . . . . . . . . . 53
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
1. Introduction
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 Media Access Control (MAC) address found on an Ethernet switch port or Wi-Fi 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 DHCPv6 Snooping Process (Section 6) and 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 Autoconfiguration (SLAAC) to allocate addresses, First-Come, First-Served Source Address Validation Improvement (FCFS SAVI) [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., FCFS SAVI [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.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].3. Terminology
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-to-Server message: A message that is sent from a DHCP client to a DHCP server or DHCP servers and is one of the following types: o DHCPv4 Discover: DHCPDISCOVER [RFC2131]. o DHCPv4 Request: DHCPREQUEST generated during SELECTING state [RFC2131]. o DHCPv4 Renew: DHCPREQUEST generated during RENEWING state [RFC2131].
o DHCPv4 Rebind: DHCPREQUEST generated during REBINDING state
[RFC2131].
o DHCPv4 Reboot: DHCPREQUEST generated during INIT-REBOOT state
[RFC2131].
o Note: DHCPv4 Request/Renew/Rebind/Reboot messages can be
identified based on Table 4 of [RFC2131].
o DHCPv4 Decline: DHCPDECLINE [RFC2131].
o DHCPv4 Release: DHCPRELEASE [RFC2131].
o DHCPv4 Inform: DHCPINFORM [RFC2131].
o DHCPv4 DHCPLEASEQUERY: A message sent to inquire about the lease
that might exist for an IPv4 address [RFC4388].
o DHCPv6 Request: REQUEST [RFC3315].
o DHCPv6 Solicit: SOLICIT [RFC3315].
o DHCPv6 Confirm: CONFIRM [RFC3315].
o DHCPv6 Decline: DECLINE [RFC3315].
o DHCPv6 Release: RELEASE [RFC3315].
o DHCPv6 Rebind: REBIND [RFC3315].
o DHCPv6 Renew: RENEW [RFC3315].
o DHCPv6 Information-Request: INFORMATION-REQUEST [RFC3315].
o DHCPv6 LEASEQUERY: A message sent to inquire about the lease that
might exist for an IPv6 address [RFC5007].
DHCP Server-to-Client message: A message that is sent from a DHCP
server to a DHCP client and is one of the following types:
o DHCPv4 ACK: DHCPACK [RFC2131].
o DHCPv4 NAK: DHCPNAK [RFC2131].
o DHCPv4 Offer: DHCPOFFER [RFC2131].
o DHCPv4 DHCPLEASEACTIVE: A response to a DHCPLEASEQUERY request
containing lease information [RFC4388].
o DHCPv4 DHCPLEASEUNKNOWN: A response to a DHCPLEASEQUERY request
indicating that the server does not manage the address [RFC4388].
o DHCPv4 DHCPLEASEUNASSIGNED: A response to a DHCPLEASEQUERY request
indicating that the server manages the address and there is no
current lease [RFC4388].
o DHCPv6 Reply: REPLY [RFC3315].
o DHCPv6 Advertise: ADVERTISE [RFC3315].
o DHCPv6 Reconfigure: RECONFIGURE [RFC3315].
o DHCPv6 LEASEQUERY-REPLY: A response to a LEASEQUERY request
[RFC5007].
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 that 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 that 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 a DHCPv6 address when the binding is triggered by a DHCPv6 Confirm message but a DHCPv6 Leasequery exchange [RFC5007] cannot be performed by the SAVI device to fetch the lease.4. Deployment Scenario and Configuration
4.1. Elements and Scenario
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 mechanisms described in
[RFC2827]. 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 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.4.2. SAVI Binding Type Attributes
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.4.2.1. Trust Attribute
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).4.2.2. DHCP-Trust Attribute
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 Sections 6 and 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 [DHCPv6-SHIELD] for more details.4.2.3. DHCP-Snooping Attribute
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-to-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 FCFS SAVI 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 Client A to SAVI Device A, the attachment from Client B to SAVI Device B, and the attachment from Non-SAVI Device 2 to SAVI Device A can be configured with this attribute.4.2.4. Data-Snooping 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.4.2.5. Validating Attribute
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.
4.2.6. Table of Mutual Exclusions
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 Exclusions4.3. Perimeter
4.3.1. SAVI-DHCP Perimeter Overview
SAVI devices form a perimeter separating trusted and untrusted regions of a network, as FCFS SAVI does (Section 2.5 of [RFC6620]). The perimeter is primarily designed for scalability. It has two implications. o SAVI devices only need to establish bindings for directly attached clients, or clients indirectly attached through a non-SAVI protected device, rather than all of the clients in the network. o Each SAVI device only needs to validate the source addresses in traffic from clients attached to it, without checking all the traffic passing by.
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 the DHCP relay and DHCP server is discussed in Section 4.3.3.4.3.2. SAVI-DHCP Perimeter Configuration Guideline
A perimeter separating trusted and untrusted regions of the network is formed as follows: (1) Configure the Validating and DHCP-Snooping attributes TRUE on the direct attachments of all DHCP clients. (2) Configure the Validating and DHCP-Snooping attributes TRUE on the indirect attachments of all DHCP clients (i.e., DHCP clients on protected links). (3) Configure the Trust attribute TRUE on the attachments to other SAVI devices. (4) If a non-SAVI device, or a number of connected non-SAVI devices, are attached only to SAVI devices, set the Trust attribute TRUE on their attachments. (5) Configure the DHCP-Trust attribute TRUE on the direct attachments to trusted DHCP relays and servers. 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.
4.3.3. On the Placement of the DHCP Server and Relay
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 to 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 DHCP Server A is contained in the perimeter, Non-SAVI Device 1 will also be contained in the perimeter. Thus, 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).4.3.4. An Alternative Deployment
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 Configuration4.3.5. Considerations regarding Binding Anchors
The strength of this binding-based mechanism depends on the strength of the binding anchor. The sample binding anchors in [RFC7039] have the property in which 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 where 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.
4.4. Other Device Configuration
In addition to a possible binding anchor configuration specified in Section 4.2, an implementation has the following configuration requirements: (1) Address configuration. For DHCPv4: the SAVI device MUST have an IPv4 address. For DHCPv6: the client of a SAVI device MUST have a link-local address; when the DHCPv6 server is not on the same link as the SAVI device, the SAVI device MUST also have an IPv6 address of at least the same scope as the DHCPv6 Server. (2) DHCP server address configuration: a SAVI device MUST store the list of the DHCP server addresses that it could contact during a leasequery process. (3) A SAVI device may also require security parameters, such as preconfigured keys to establish a secure connection for the leasequery process [RFC4388] [RFC5007] connection.
(page 17 continued on part 2)