RFC 7513
Source Address Validation Improvement (SAVI) Solution for DHCP
RFC 7513 🎀 Source Address Validation Improvement (SAVI) Solution for DHCP
okay bestie, RFC 7513 is here and it's a whole vibe 🦋 It's a Standards Track document from the Internet Engineering Task Force (IETF), published in May 2015, with ISSN 2070-1721. The authors are J. Bi, J. Wu, and G. Yao from Tsinghua Univ., plus F. Baker from Cisco. The title block doesn't list anything it obsoletes or updates, so it's standing on its own ✨
Abstract 💜
okay so this doc lays out how to make a binding between an IP address that DHCPv4 or DHCPv6 handed out and a binding anchor on a Source Address Validation Improvement (SAVI) device 🫶 Those bindings are what get used to filter out packets with forged source IP addresses. It's giving extra protection on top of BCP 38 (RFC 2827) ingress filtering, with finer-grained source IP address validation 💅
Status of This Memo 🌸
this is an Internet Standards Track document 🌈
it's a product of the Internet Engineering Task Force (IETF), which means it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 5741 📚
for the current status of this document, any errata, and how to send feedback, go to 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) as they're in effect on the date it was published. Please read these carefully, because they spell out your rights and restrictions for this document 🫶 Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They're also 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 . . . . . . . . . . . . . . . . . . . . . . . 541. Introduction ✨
okay so this doc describes a fine-grained source address validation mechanism for IPv4 and IPv6 packets 🦋 It creates bindings between IP addresses that DHCP assigned to network interfaces 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, and that may be used to identify the system an IP address has been assigned to. Common examples are a Media Access Control (MAC) address found on an Ethernet switch port, or a Wi-Fi security association 💜
the bindings are then used to identify and filter packets that come from these interfaces while using forged source IP addresses 🫶 That way, the mechanism can stop hosts from using IP addresses assigned to some other attachment point in the network, or to one that isn't associated with the network at all. That behavior is called "spoofing", and it's the key ingredient in amplification attacks 💀 In those, a set of systems sends messages to another set of systems while claiming to be from a third set, and the replies go to systems that never asked for them.
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 give you a certain level of traceability, because dropped packets point to a system that's producing packets with spoofed IP addresses 🔥
SAVI-DHCP snoops DHCP address assignments so it can set up bindings between IP addresses assigned by DHCP and their corresponding binding anchors 🌸 It includes the DHCPv4 and DHCPv6 Snooping Process (Section 6) and the Data Snooping Process (Section 7), plus a bunch of other technical details. The Data Snooping Process is data-triggered, meaning it snoops the IP header of data packets to set up bindings. It's designed to avoid permanently blocking valid addresses in case DHCP snooping isn't enough 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, since 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 mainly built for pure DHCP scenarios, where only addresses assigned through DHCP are allowed. However, it does not block link-local addresses, because they aren't assigned using DHCP. It is RECOMMENDED that the administration deploy a SAVI solution for link-local addresses, e.g., FCFS SAVI [RFC6620] 💖
this works for networks that use DHCPv4 only, DHCPv6 only, or both DHCPv4 and DHCPv6 🌈 The DHCP address assignment mechanism in IPv4/IPv6 transition scenarios, e.g., [RFC7341], is 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 ✨
Okay bestie, time for the vocab list! 📖💖 These definitions are the foundation for everything else, so let's get them right.
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:
- DHCPv4 Discover: DHCPDISCOVER [RFC2131].
- DHCPv4 Request: DHCPREQUEST generated during SELECTING state [RFC2131].
- DHCPv4 Renew: DHCPREQUEST generated during RENEWING state [RFC2131].
- DHCPv4 Rebind: DHCPREQUEST generated during REBINDING state [RFC2131].
- DHCPv4 Reboot: DHCPREQUEST generated during INIT-REBOOT state [RFC2131].
- Note: DHCPv4 Request/Renew/Rebind/Reboot messages can be identified based on Table 4 of [RFC2131].
- DHCPv4 Decline: DHCPDECLINE [RFC2131].
- DHCPv4 Release: DHCPRELEASE [RFC2131].
- DHCPv4 Inform: DHCPINFORM [RFC2131].
- DHCPv4 DHCPLEASEQUERY: A message sent to inquire about the lease that might exist for an IPv4 address [RFC4388].
- DHCPv6 Request: REQUEST [RFC3315].
- DHCPv6 Solicit: SOLICIT [RFC3315].
- DHCPv6 Confirm: CONFIRM [RFC3315].
- DHCPv6 Decline: DECLINE [RFC3315].
- DHCPv6 Release: RELEASE [RFC3315].
- DHCPv6 Rebind: REBIND [RFC3315].
- DHCPv6 Renew: RENEW [RFC3315].
- DHCPv6 Information-Request: INFORMATION-REQUEST [RFC3315].
- 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:
- DHCPv4 ACK: DHCPACK [RFC2131].
- DHCPv4 NAK: DHCPNAK [RFC2131].
- DHCPv4 Offer: DHCPOFFER [RFC2131].
- DHCPv4 DHCPLEASEACTIVE: A response to a DHCPLEASEQUERY request containing lease information [RFC4388].
- DHCPv4 DHCPLEASEUNKNOWN: A response to a DHCPLEASEQUERY request indicating that the server does not manage the address [RFC4388].
- DHCPv4 DHCPLEASEUNASSIGNED: A response to a DHCPLEASEQUERY request indicating that the server manages the address and there is no current lease [RFC4388].
- DHCPv6 Reply: REPLY [RFC3315].
- DHCPv6 Advertise: ADVERTISE [RFC3315].
- DHCPv6 Reconfigure: RECONFIGURE [RFC3315].
- 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
Okay so, the main cast of a SAVI-DHCP deployment! 🎬 You need 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 🎀
okay so the "DHCP-Trust Attribute" is another Boolean one 💅 it tells you whether the attached device is allowed to send DHCP Server-to-Client messages 🫶 in Figure 1, the DHCP server and the DHCP relay would have this set to TRUE ✨ and any attachment point with Trust set to TRUE is treated as if DHCP-Trust is TRUE too, no extra setup needed 🌸
if DHCP-Trust is TRUE, SAVI devices will forward DHCP Server-to-Client messages coming in from those attachment points 🦋 and if those messages can kick off state transitions, the binding setup processes in Sections 6 and 7 will be the ones handling them 🧚 by default DHCP-Trust is FALSE, which just means the attached system is not a DHCP server 🙈
if you're a DHCPv6 implementor, [DHCPv6-SHIELD] has way more details 💖
4.2.3. DHCP-Snooping Attribute 🍓
the "DHCP-Snooping Attribute" is also a Boolean (we love consistency 💜) and it tells you whether bindings get set up based on DHCP snooping 👀
if it's TRUE, DHCP Client-to-Server messages going to attachment points with this attribute will create bindings through the DHCP Snooping Process from Section 6 ✨ if it's FALSE, then either Trust has to be TRUE (so bindings don't even matter anymore) or some other SAVI mechanism, like FCFS SAVI, has to be running on that attachment point 🫠
this one gets configured on the DHCP client's point of attachment 💅 it can also go on attachments to protected non-SAVI devices that DHCP clients are using 🌈 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 all be set up with this attribute 🦋
4.2.4. Data-Snooping Attribute 🌸
the "Data-Snooping Attribute" is a Boolean 🎀 and it says whether data packets from that attachment point are allowed to trigger the binding setup procedure 🧚
data packets from attachment points with this attribute can set up bindings 💖 SAVI devices will create bindings on those points using the data-triggered process from Section 7 ✨
okay here's the tea 🫖 if DHCP-Snooping is configured on an attachment point, bindings there get set up from DHCP message snooping 🍓 but sometimes a DHCP client uses a DHCP address without the address assignment procedure ever running on its current attachment 🙈 for those attached devices, the Data Snooping Process from Section 7 is necessary 😭 so this attribute gets configured on those attachments, and Section 7 has more on how it's used 💜
since some networks need DHCP and others avoid it, there's no obvious universal default for Data-Snooping 🤷♀️ so Data-Snooping should default to FALSE, and there should be a mechanism that can easily set it to TRUE on every attachment point where Trust is FALSE 🔥
4.2.5. Validating Attribute 🫧
the "Validating Attribute" is a Boolean 🍓 it indicates whether packets from that attachment will have their IP source addresses checked against the binding entries on the attachment 💅
if it's TRUE, packets from those attachments get validated against the binding entries like Section 8 says 🦋 if it's FALSE, they don't 🙅♀️ since the binding table is shared with other SAVI algorithms, this attribute only signals whether the check happens, not whether it happens for SAVI-DHCP bindings specifically 🧚
by default, Validating is the inverse of Trust ✨ so source addresses on untrusted links get validated automatically 🌈 the administration MAY set it to FALSE 🎀
the expected use case is when SAVI is only monitoring forged transmissions and not blocking them 👀 in that situation, the network manager may set DHCP-Snooping and/or Data-Snooping to TRUE but leave Validating FALSE 💜
4.2.6. Table of Mutual Exclusions 💀
different attributes can mean mutually exclusive things for a packet 😭 mutually exclusive attributes MUST NOT be set to TRUE on the same attachment 🚫 the compatibility of each attribute pair is in Figure 2 💖 also, Trust and DHCP-Trust are compatible, but you don't need to set DHCP-Trust to TRUE on an attachment that already has Trust set to 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 that separates the trusted and untrusted regions of a network 🫧 FCFS SAVI does this too (see Section 2.5 of [RFC6620]) 💅 the perimeter is mainly built for scalability 📈 it has two implications:
- SAVI devices only need to set up bindings for directly attached clients, or clients attached indirectly through a non-SAVI protected device 🧚 they don't need to cover every client in the network 🙌
- each SAVI device only has to validate source addresses in traffic from the clients attached to it 🦋 it doesn't have to check all the traffic passing by 😌
look at the example in Figure 1 👀 the protection perimeter is formed by SAVI Devices A, B, and C 🌈 here SAVI Device B doesn't create a binding for Client A 🙈 but since SAVI Device A filters the spoofed traffic from Client A, SAVI Device B can avoid getting spoofed traffic from Client A at all 💖
the SAVI-DHCP perimeter isn't just for data packets 🎀 it's also a perimeter for DHCP messages 🫶 DHCP server response messages coming in across the perimeter get dropped (Section 8) 🚫 the placement of the DHCP relay and DHCP server is related to building the perimeter, even though they aren't involved in [RFC6620] 🧠 the requirements on where the DHCP relay and DHCP server go and how they're configured are discussed in Section 4.3.3 ✨
4.3.2. SAVI-DHCP Perimeter Configuration Guideline 📝
here's how to form a perimeter that separates the trusted and untrusted regions of the network 🏗️
- configure Validating and DHCP-Snooping to TRUE on the direct attachments of all DHCP clients 💅
- configure Validating and DHCP-Snooping to TRUE on the indirect attachments of all DHCP clients (aka DHCP clients on protected links) 🦋
- configure Trust to TRUE on the attachments to other SAVI devices 🫶
- if a non-SAVI device, or a bunch of connected non-SAVI devices, are attached only to SAVI devices, set Trust to TRUE on their attachments 🌸
- configure DHCP-Trust to TRUE on the direct attachments to trusted DHCP relays and servers 🧚
this way, the attachment points with Validating set to TRUE (and usually together with attachments of unprotected devices) on SAVI devices can form a perimeter that separates DHCP clients from trusted devices 💜 data packet checks only happen on the perimeter 🎯 the perimeter is also a perimeter for DHCP messages 📨 DHCP-Trust is only TRUE on links inside the perimeter 🏠 only DHCP Server-to-Client messages that originate within the perimeter are trusted 🫡
4.3.3. On the Placement of the DHCP Server and Relay 🧭
because of the configuration guidelines, SAVI devices only trust DHCP Server-to-Client messages that originate inside the perimeter ✨ so the trusted DHCP relays and DHCP servers must be placed within the perimeter 🫶 DHCP Server-to-Client messages get filtered on the perimeter 🚧 Server-to-Relay messages don't get filtered, since they're already inside the perimeter 💅 that means DHCP Server-to-Client messages from bogus DHCP servers get filtered on the perimeter after entering through untrusted attachment points 🛡️ the SAVI devices are protected from forged DHCP messages 💖
DHCP Server-to-Client messages arriving at the perimeter from outside it are not trusted 🙅♀️ there's no way to tell a DHCP server that's owned and run by the correct administration but sits outside the SAVI perimeter apart from a bogus DHCP server 😭 for example, in Figure 1, DHCP Server A is valid, but it's attached to Non-SAVI Device 1 🫠 a bogus DHCP server is also attached to Non-SAVI Device 1 💀 sure, you could imagine a world where the valid server had a statistically configured port number and MAC address, and therefore a binding 🤔 but by default SAVI-DHCP can't tell whether a message received from the port of Non-SAVI Device 1 came from DHCP Server A or from the bogus one 🙈 if DHCP Server A is contained in the perimeter, Non-SAVI Device 1 will also be contained in the perimeter 🏰 so DHCP Server A can't be contained within the perimeter unless the binding anchor is configured manually 🔧
one more thing about placement 🧩 if the DHCP server or relay is not inside the perimeter, the SAVI devices might not be able to set up bindings correctly 😬 that's because the SAVI devices may not be on the path between the clients and the server or relay, or because the DHCP messages are encapsulated (for example, Relay-reply and Relay-forward) 🎀
4.3.4. An Alternative Deployment ✨
Okay so in common deployment practice, traffic from the unprotected network is treated as trustworthy 🫶, which basically means it's not filtered. In that 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 you get an unclosed perimeter, as shown 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 meant to tie an IP address to something unspoofable that identifies a single-client system or one of its interfaces. That can be a physical or virtual interface, or that plus disambiguating link-layer information.
If the binding anchor is spoofable, like a plain MAC address, or non-exclusive, like a switch port extended using a non-SAVI device, an attacker can use a forged binding anchor to evade validation 😭 Honestly, using a binding anchor that can be easily spoofed can lead to worse outcomes than allowing spoofed IP traffic. So a SAVI device MUST use a non-spoofable and exclusive binding anchor 🚫
4.4. Other Device Configuration 🍓
Besides a possible binding anchor configuration specified in Section 4.2, an implementation has the following configuration requirements:
- 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.
- DHCP server address configuration: a SAVI device MUST store the list of the DHCP server addresses that it could contact during a leasequery process.
- A SAVI device may also require security parameters, such as preconfigured keys to establish a secure connection for the leasequery process [RFC4388] [RFC5007] connection.
5. Binding State Table (BST) 🧚
The Binding State Table is the table that holds the bindings between the IP addresses assigned to the attachments and the matching binding anchors of those attachments. It may be implemented centrally in the switch or distributed among its ports. 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 six fields:
- Binding Anchor (listed as "Anchor" in subsequent figures): the binding anchor, i.e., one or more physical and/or link-layer properties of the attachment.
- IP Address (listed as "Address" in subsequent figures): the IPv4 or IPv6 address assigned to the attachment by DHCP.
- State: the state of the binding. Possible values of this field are listed in Sections 6.2 and 7.3.
- Lifetime: the remaining seconds of the binding. Internally, this MAY be stored as the timestamp value at which the lifetime expires.
- Transaction ID (TID): the Transaction ID [RFC2131] [RFC3315] of the corresponding DHCP transaction. The TID field is used to associate DHCP Server-to-Client messages with corresponding binding entries.
- Timeouts: the number of timeouts that expired in the current state (only used in the Data Snooping Process; see Section 7).
The IA is not present in the BST for three reasons 🙈
- The lease of each address in one IA is assigned separately.
- When the binding is set up based on data snooping, the IA cannot be recovered from the leasequery protocol.
- DHCPv4 does not define an IA.
Here's an example of such a table 🌸
+---------+----------+-----------+-----------+--------+----------+
| 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 Table6. DHCP Snooping Process 👑
This section specifies the process of setting up bindings based on DHCP snooping. The process is illustrated using a state machine 💅
6.1. Rationale
The whole idea behind the DHCP Snooping Process is this: if a DHCP client is legitimately using a DHCP-assigned address, then the DHCP address assignment procedure that assigned that IP address to the client must have been run through 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 separates the DHCP client from the rest of the network containing the DHCP server(s)/relay(s). For most networks with simple topologies, it's possible to deploy this SAVI function at the proper devices to meet this requirement ✨
But if there are multiple paths from a DHCP client to the DHCP server and the SAVI device is only on one of them, there's an obvious failure case: the SAVI device may not be able to snoop the DHCP procedure 😬 Host movement can also make this requirement hard 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. So there can be scenarios where only performing this DHCP Snooping Process isn't enough to set up bindings for all the valid DHCP addresses. These exceptions and their solutions are discussed in Section 7 🫶
6.2. Binding States Description
The 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.
6.3. Events
This section describes the 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. 🚨
6.3.1. Timer Expiration Event
EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires. ⏰
6.3.2. Control Message Arriving Events 🎀
Okay bestie, these are the DHCP messages that count as actual events 💅 Each one gets its own name so the state machine can grab it and do something with it.
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 the 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: these events don't cover every DHCP message from Section 3 🙈 The ones that don't really decide address usage are left out: DHCPv4 Discover, DHCPv4 Inform, DHCPv6 Solicit without Rapid Commit, DHCPv6 Information-Request, DHCPv4 Offer, DHCPv6 Advertise, and DHCPv6 Reconfigure. So are the ones that don't need snooping, like DHCPv4 Negative Acknowledgment (NAK), which you can read about in Section 6.4.2.3. Also, DHCPv4 DHCPLEASEQUERY isn't used in the DHCP Snooping Process, so nobody gets confused with Section 7 🧚 And 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.
Now, a DHCP message only counts as a valid event if it passes these checks ✨
- Attribute check: the DHCP Server-to-Client messages and LEASEQUERY-REPLY should come from attachments with the DHCP-Trust attribute. The DHCP Client-to-Server messages should come from attachments with the DHCP-Snooping attribute.
- Destination check: the DHCP Server-to-Client messages should be destined to attachments with the DHCP-Snooping attribute. This makes sure the binding gets set up on the SAVI device nearest to the destination client 💖
- Binding anchor check: the DHCP Client-to-Server messages that may trigger modification or removal of an existing binding entry must have a matching binding anchor with the corresponding entry.
- TID check: the DHCP Server-to-Client/Client-to-Server messages that may cause modification of existing binding entries must have a matched TID with the corresponding entry. This check isn't done on LEASEQUERY and LEASEQUERY-REPLY messages, since those get exchanged between the SAVI devices and the DHCP servers. It's also not done on DHCP Renew/Rebind messages 🦋
- Binding limitation check: the DHCP messages must not cause new binding setup on an attachment whose binding entry limitation has been reached (refer to Section 11.5).
- Address check: the source address of the DHCP messages should pass the check specified in Section 8.2.
If a DHCP message doesn't trigger a valid event, the state doesn't change and no actions get performed 🌸 But if it doesn't trigger a valid event and it can still pass the checks in Section 8.2, it MUST be forwarded. Periodt 💅
6.4. The State Machine of DHCP Snooping Process 👑
This section is where the state transitions and their matching actions get spelled out, so get ready 🔥
6.4.1. Initial State: NO_BIND 🌈
6.4.1.1. Event: EVE_DHCP_REQUEST - A DHCPv4 Request or a DHCPv6 Request message is received
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 the message came in from. The State field is set to INIT_BIND. The Lifetime field is set to MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the message. If the message is a DHCPv4 Request, the Address field can be set to the address to request, which is the 'requested IP address' ✨ Here's what the entry looks like, 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 Initialization Triggered by
Request/Rapid Commit/Reboot MessagesResulting state: INIT_BIND. A potential binding has been set up 🦋
6.4.1.2. Event: EVE_DHCP_REBOOT - A DHCPv4 Reboot message is received
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 the message came in from. The State field is set to INIT_BIND. The Lifetime field is set to MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the message. If the message is a DHCPv4 Reboot, the Address field can be set to the address to request, which is the 'requested IP address'. The example entry is the one in Figure 5.
Resulting state: INIT_BIND. A potential binding has been set up 🌸
6.4.1.3. Event: EVE_DHCP_SOLICIT_RC - A DHCPv6 Solicitation message with the Rapid Commit option is received
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 the message came in from. The State field is set to INIT_BIND. The Lifetime field is set to MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the message. The example entry is the one in Figure 5.
Resulting state: INIT_BIND. A potential binding has been set up ✨
6.4.1.4. Event: EVE_DHCP_CONFIRM - A DHCPv6 Confirm message is received
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 the message came in from. The State field is set to INIT_BIND. The Lifetime field is set to 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. Here are the entries, 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 InitializationResulting state: INIT_BIND. A potential binding has been set up 🎀
6.4.1.5. Events That Cannot Happen in the NO_BIND State
These events can't happen in NO_BIND, and it's giving "why not?" but the reason is actually simple 🙈 Each one only happens AFTER a binding has been created:
EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires.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_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 is received.
Since there's no binding yet, there's nothing for these to act on 💀
6.4.2. Initial State: INIT_BIND 🦋
6.4.2.1. Event: EVE_DHCP_REPLY ✨ - A DHCPv4 ACK or a DHCPv6 Reply message is received
The message MUST be forwarded to the corresponding client 💌
Okay so if it's a DHCPv4 ACK, the binding entry with the same TID as the message gets its Address field set to the address in the message (aka yiaddr in DHCPv4 ACK) 🎀. Its Lifetime becomes the sum of the lease time in the ACK and MAX_DHCP_RESPONSE_TIME, and the State flips to BOUND 🦋.
If it's a DHCPv6 Reply, there are a few cases to check 👀
- If the status code is not "Success", no modification of corresponding entries will be made. Corresponding entries will expire automatically if no "Success" Reply is received during the lifetime. The entries are not removed immediately because the client may be able to use the addresses whenever a "Success" Reply is received ("If the client receives any Reply messages that do not indicate a NotOnLink status, the client can use the addresses in the IA and ignore any messages that indicate a NotOnLink status" [RFC3315]).
- If the status code is "Success", the SAVI device checks the IA options in the Reply message.
- A. If there are IA options in the Reply message, the SAVI device checks each IA option. When the first assigned address is found, the
Addressfield of the binding entry with a matchedTIDis set to the address. TheLifetimefield is set to the sum of the lease time in the Reply message andMAX_DHCP_RESPONSE_TIME. TheStatefield is changed toBOUND. If there is more than one address assigned in the message, new binding entries are set up for the remaining address assigned in the IA options. An example of the entries is illustrated in Figure 8. SAVI devices do not specially process IA options with a NoAddrsAvail status because there should be no address contained in such IA options. - B. Otherwise, the DHCP Reply message is in response to a Confirm message. The state of the binding entries with a matched
TIDis changed toBOUND. Because [RFC3315] does not require the lease time of addresses to be contained in the Reply message, the SAVI device SHOULD send a LEASEQUERY [RFC5007] message querying by IP address to the All_DHCP_Servers multicast address [RFC3315] or a list of configured DHCP server addresses. The LEASEQUERY message is generated for each IP address if multiple addresses are confirmed. The lifetime of corresponding entries is set to2*MAX_LEASEQUERY_DELAY. If there is no response message afterMAX_LEASEQUERY_DELAY, send the LEASEQUERY message again. An example of the entries is illustrated in Figure 7. If the SAVI device does not send the LEASEQUERY message, a preconfigured lifetimeDHCP_DEFAULT_LEASEMUST be set on the corresponding entry. (Note: it is RECOMMENDED to use T1 configured on DHCP servers as theDHCP_DEFAULT_LEASE.)
- A. If there are IA options in the Reply message, the SAVI device checks each IA option. When the first assigned address is found, the
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
RequestResulting state: BOUND - The binding has been set up. 🌸
6.4.2.2. Event: EVE_ENTRY_EXPIRE - The lifetime of a binding entry expires ⏰
The entry MUST be deleted from the BST. 🗑️
Resulting state: An entry that has been deleted from the BST may be considered to be in the "NO_BIND" state - No binding has been set up.
6.4.2.3. Events That Are Ignored in INIT_BIND 🙈
If no DHCP Server-to-Client messages that 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.
EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is receivedEVE_DHCP_CONFIRM: A DHCPv6 Confirm message is receivedEVE_DHCP_REBOOT: A DHCPv4 Reboot message is receivedEVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is receivedEVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is receivedEVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with the Rapid Commit option is receivedEVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is receivedEVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is receivedEVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY-REPLY is received
In each case, the message MUST be forwarded.
Resulting state: INIT_BIND - A potential binding has been set up. 💜
6.4.3. Initial State: BOUND 🦋
6.4.3.1. Event: EVE_ENTRY_EXPIRE - The lifetime of a binding entry expires ⏰
The entry MUST be deleted from the BST.
Resulting state: An entry that has been deleted from the BST may be considered to be in the "NO_BIND" state - No binding has been set up.
6.4.3.2. Event: EVE_DHCP_DECLINE - A DHCPv4 Decline or a DHCPv6 Decline message is received 🙅♀️
The message MUST be forwarded.
First, the SAVI device gets all the addresses ("Requested IP address" in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, and 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 "NO_BIND" state - No binding has been set up.
6.4.3.3. Event: EVE_DHCP_RELEASE - A DHCPv4 Release or a DHCPv6 Release message is received 👋
The message MUST be forwarded.
First, the SAVI device gets all the addresses ("Requested IP address" in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, and 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 "NO_BIND" state - No binding has been set up.
6.4.3.4. Event: EVE_DHCP_REBIND - A DHCPv4 Rebind or a DHCPv6 Rebind message is received 🔄
The message MUST be forwarded.
In such a 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 the TID check will not be performed on such messages.
Resulting state: BOUND: The binding has been set up.
6.4.3.5. Event: EVE_DHCP_RENEW - A DHCPv4 Renew or a DHCPv6 Renew message is received 🔁
The message MUST be forwarded.
In such a 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 the TID check will not be performed on such messages.
Resulting state: BOUND: The binding has been set up.
6.4.3.6. Event: EVE_DHCP_REPLY - A DHCPv4 ACK or a DHCPv6 Reply message is received 💌
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 a 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 BOUND state.
If the message is DHCPv6 Reply, the SAVI device checks each IA Address option in each IA option. For each:
- If the IA entry in the REPLY message has the status "NoBinding", there is no address in the option, and no operation on an address is performed.
- If the valid lifetime of an IA Address option is 0, the binding entry with a matched
TIDand address is removed, leaving it effectively in theNO_BINDstate. - Otherwise, set the
Lifetimefield of the binding entry with the matchedTIDand address to be the sum of the new valid lifetime andMAX_DHCP_RESPONSE_TIME, leaving the entry in theBOUNDstate.
Resulting state: NO_BIND or BOUND, as specified.
6.4.3.7. Event: EVE_DHCP_LEASEQUERY - A successful DHCPv6 LEASEQUERY_REPLY is received 🧾
The message MUST be forwarded.
The message should be in response to the LEASEQUERY 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 LEASEQUERY-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.
6.4.3.8. Events Not Processed in the State BOUND 🚫
The following events are ignored if received while the indicated entry is in the BOUND state. Any required action will be the result of the next message in the client/server exchange.
EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is receivedEVE_DHCP_CONFIRM: A DHCPv6 Confirm message is receivedEVE_DHCP_REBOOT: A DHCPv4 Reboot message is receivedEVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with the Rapid Commit option is received
6.4.4. Table of State Machine ✨
Okay so here's the main state transit cheat sheet 📋💖 Heads up: not every detail is in the table or the diagram, so don't skip the text around them, bestie 🫶
State Event Action Next State
---------------------------------------------------------------------
NO_BIND RQ/RC/CF/RE Generate entry INIT_BIND
INIT_BIND RPL Record lease time BOUND
(send leasequery 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 BOUNDFigure 9: State Transition Table 🎀
RQ: EVE_DHCP_REQUEST
RC: EVE_DHCP_SOLICIT_RC
CF: EVE_DHCP_CONFIRM
RE: EVE_DHCP_REBOOT
RPL: EVE_DHCP_REPLY
RLS: EVE_DHCP_RELEASE
DCL: EVE_DHCP_DECLINE
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_LEASEQUERYFigure 10: Diagram of Transit 🦋
7. Data Snooping Process 🌈
7.1. Scenario
The big idea behind the DHCP Snooping Process in Section 6 is this: if a DHCP client is legitimately using a DHCP address, the address assignment procedure must have been finished while the client was attaching. That works fine when the SAVI device is always on the path(s) from the DHCP client to the DHCP server(s)/relay(s). BUT there are two cases where it totally breaks 💀
- Multiple paths: there's more than one feasible link-layer path from the client to the DHCP server/relay, and the SAVI device isn't on every one of them. The client might get its address through a path that skips the SAVI device, but its packets can then travel over paths that do go through it, like when the path through the link-layer network changes. Since the SAVI device couldn't snoop the DHCP exchange, the DHCP Snooping Process can't set up the corresponding binding 😭
- Dynamic path: there's only one feasible link-layer path from the client to the DHCP server/relay, but it's dynamic because of a topology change (for example, some link breaks due to failure or a planned change) or a link-layer path change. This also covers local-link movement of clients without the address confirm/reconfiguration process. Example: a host changes its attached switch port in a super short time. In these cases the DHCP Snooping Process will not set up the corresponding binding 🙈
The Data Snooping Process can avoid permanently blocking legitimate traffic when one of these two exceptions happens. This process runs 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 puts a considerable burden on the processor and the ASIC-to-Processor bandwidth of SAVI devices. Because of that overhead, implementing this process is OPTIONAL. This function SHOULD be enabled unless the implementation is known to be used in scenarios without the above exceptions. For example, if the implementation is going to be used in networks with tree topology and without host local-link movement, there's no need to implement this process in those scenarios 🌸
This process is not meant to set up a binding every time a data packet without a matched binding entry shows up. Instead, unmatched data packets trigger this process probabilistically, and generally a number of unmatched packets will be discarded before the binding gets set up. The parameter(s) of this probabilistic process SHOULD be configurable, defaulting to a situation where data snooping is disabled 💅
7.2. Rationale
This process uses NS/ARP and DHCP Leasequery to set up bindings. If an address isn't 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 where the unmatched packet came in ✨
The Data Snooping Process gives binding entries another way to reach the BOUND state in the exceptional cases explained in Section 7.1, when there are no DHCP messages the SAVI device can snoop 🦋
In some of the exceptional cases (especially the dynamic topology case), by the time the binding reaches the BOUND state, DHCP messages may be passing through the SAVI device. In that 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. That causes the binding to be deleted, and the state logically returns to NO_BIND state. Either the DHCP or the Data Snooping Process will be reinvoked if the lease is still in place. If DHCP messages still aren't passing through the SAVI device, there will be a brief disconnection, and data packets passing through the SAVI device will be dropped during it 😬 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 in Section 11.1 🔐
7.3. Additional Binding States Description
In addition to NO_BIND and BOUND from Section 6.2, three new states are used in this process. They're listed here. The INIT_BIND state is not used, since it's 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 Leasequery.
- 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 Leasequery.
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 ⏳
7.4. Events
To handle the Data Snooping Process, six extra events are needed in addition to those used by the DHCP Snooping Process (see Section 6.3). They're described here 🌷 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: An ARP Reply / Neighbor Advertisement (NA) message against an address in the DETECTION state is received from a host other than the one for which the entry was added (i.e., a host attached at a point other than the one on which the triggering data packet was received).EVE_DATA_LEASEQUERY:- IPv4: A
DHCPLEASEACTIVEmessage with theIP Address Lease Timeoption is received. Note that theDHCPLEASEUNKNOWNandDHCPLEASEUNASSIGNEDreplies are ignored 🙃 - IPv6: A successful
LEASEQUERY-REPLYis received.
- IPv4: A
EVE_DATA_VERIFY: An ARP Reply / 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 🔍
- Attribute check: the data packet should be from attachments with the Data-Snooping attribute; the
DHCPLEASEACTIVE/LEASEQUERY-REPLYmessages should be from attachments with the DHCP-Snooping attribute. - Binding limitation check: the data messages must not cause new binding setup on an attachment whose binding entry limitation has been reached (refer to Section 11.5).
- Address check: For
EVE_DATA_LEASEQUERY, the source address of theDHCPLEASEQUERYmessages must pass the check specified in Section 8.2. ForEVE_DATA_CONFLICTandEVE_DATA_VERIFY, the source address and target address of the ARP or NA messages must pass the check specified in Section 8.2. - Interval check: the interval between two successive
EVE_DATA_UNMATCHevents triggered by an attachment MUST be no smaller thanDATA_SNOOPING_INTERVAL. - TID check: the
DHCPLEASEACTIVE/LEASEQUERY-REPLYmessages must have a matched TID with the corresponding entry. - Prefix check: the source address of the data packet should be of a valid local prefix, as specified in Section 7 of [RFC7039].
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 specifiedDETECTION_TIMEOUTperiod ⏰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 💖
7.5. Message Sender Functions
The Data Snooping Process involves sending three different messages to other network devices. Each message may be sent up to two times, since they're sent over unreliable transports and 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 🌈
7.5.1. Duplicate Detection Message Sender 💅
okay so this one's the duplicate detection sender 🫶 its whole job is to check if the source address in the data packet that kicked off the Data Snooping Process is causing a local conflict (aka another node on the network is already using that address) 😭
- IPv4 address: Broadcast an Address Resolution Protocol (ARP) Request [RFC826] or an ARP Probe [RFC5227] for the address to the local network. An ARP Response will be expected from the device on the attachment point where the triggering data packet came in. An ARP Reply received on any other port indicates a duplicate address. 🌸
- IPv6 address: Send a Duplicate Address Detection (DAD) message (Neighbor Solicitation message) to the solicited-node multicast address [RFC4861] targeting the address. Ideally, only the host on that point of attachment responds with a Neighbor Advertisement. A Neighbor Advertisement received on any other port indicates a duplicate address. 🦋
ngl both the ARP and DAD processes are unreliable 🙈 the packet can get lost on the way to or from the other system (see [RFC6620]), so if there's no response after the DETECTION_TIMEOUT, an EVE_ENTRY_EXPIRE gets generated. 💀
7.5.2. Leasequery Message Sender 🧚
okay this one is giving detective energy 🔍 we send a DHCPLEASEQUERY message to the DHCP server(s) to find out if they've handed out a lease for the source address in the triggering data packet. ✨
the SAVI device keeps a list of authorized DHCP servers. that list should be either preconfigured with the IPv4 and/or IPv6 addresses, or dynamically discovered. for IPv4 networks, that means sending DHCPv4 Discover messages and parsing the returned DHCPv4 Offer messages. for IPv6 networks, you send DHCPv6 SOLICIT messages and parse the returned ADVERTISE messages. 💖
the same TID should be used for all LEASEQUERY messages sent in response to a triggering data message on an attachment point. the TID gets generated if the TID field in the BST entry is empty, and it's recorded in the TID field of the BST entry when the first message goes out. later messages reuse the TID from the BST entry. 🎀
(1) IPv4 address: Send a DHCPLEASEQUERY [RFC4388] message querying by IP address to each DHCPv4 server in the list of authorized servers, with an IP Address Lease Time option (option 51). If the server has a valid lease for the address, the requested information comes back in a DHCPLEASEACTIVE message. 👑
(2) IPv6 address: Send a LEASEQUERY [RFC5007] message querying by IP address to each DHCPv6 server in the list of authorized servers, using the server address as the link-address in the LEASEQUERY message. If the server has a valid lease for the address, the requested information comes back in a LEASEQUERY-REPLY message marked as successful (i.e., without an OPTION_STATUS_CODE in the reply). The IA Address option(s) returned contain any IPv6 addresses bound to the same link, together with the lease validity time. 🌈
DHCP Leasequeries are unreliable too (the packet can get lost to or from the server), so if there's no response after the MAX_LEASEQUERY_DELAY, an EVE_DATA_EXPIRE is generated. ⭐ also, multiple response messages may show up if the list of authorized servers has more than one address of the right type. and for DHCPv6, the responses may include extra addresses that have leases allocated. 😭
7.5.3. Address Verification Message Sender 🌷
this one checks that the link-layer address of the attached device that sent the triggering data packet matches the link-layer address in the leasequery response. 🕵️♀️
- IPv4 address: Send an ARP Request with the Target Protocol Address set to the IP address in the BST entry. The ARP Request is only sent to the attachment that triggered the binding. If the attached device has the IP address bound to the interface attached to the SAVI device, an ARP Reply should be received containing the hardware address of the interface on the attached device, which can be compared with the leasequery value. 🍓
- IPv6 address: Send a Neighbor Solicitation (NS) message with the target address set to the IP address in the BST entry. The NS is only sent to the attachment that triggered the binding. If the attached device has the IP address bound to the interface attached to the SAVI device, an NA should be received indicating that the attached device has the IP address configured on the interface. 🫧
again, both the ARP and NS/NA processes are unreliable (the packet can get lost to or from the other system, see [RFC6620]), so if there's no response after the DETECTION_TIMEOUT, an EVE_DATA_EXPIRE is generated. 💜
7.6. Initial State: NO_BIND 🌙
7.6.1. Event: EVE_DATA_UNMATCH: A data packet without a matched binding is received 🫣
first, make a probabilistic decision about whether to act on this event. the probability can be configured or calculated based on the state of the SAVI device. it should be low enough to soften the damage from DoS attacks against this process. 🛡️
then create a new entry in the BST. set the Binding Anchor field to the corresponding binding anchor of the attachment, and set the Address field to the source address of the packet. ✨
Address conflicts MUST be detected and prevented. 🚨
If local address detection is performed:
- Set the State field to
DETECTION. Set the Lifetime of the created entry toDETECTION_TIMEOUT. Set the Timeouts field to0. Start detecting any local address conflicts by sending a Duplicate Address Detection Message (Section 7.5.1). Transition toDETECTIONstate. 🔎
If local address detection is not performed:
- Set the State field to
RECOVERY. Set the Lifetime of the created entry toLEASEQUERY_DELAY. Set the Timeouts field to0. Start recovering any DHCP lease associated with the source IP address by sending one or more LEASEQUERY messages (Section 7.5.2). Transition toRECOVERYstate. 📬
The packet that triggers this event SHOULD be discarded. 🗑️
here's what the BST entry looks like during duplicate address detection, per 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 - The DHCP lease(s) associated with the address is being queried. 🥰
7.6.2. Events Not Observed in NO_BIND for Data Snooping 🙃
EVE_DATA_CONFLICT: An ARP Reply / NA message is received from an unexpected system. 🚩
EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or LEASEQUERY-REPLY is received. 🧾
EVE_DATA_VERIFY: A valid ARP Reply or NA message is 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: Expiration of the DECTECTION_TIMEOUT ⏰
EVE_DATA_EXPIRE: Expiration of the DECTECTION_TIMEOUT ⏰
7.7. Initial State: DETECTION 🕰️
7.7.1. Event: EVE_ENTRY_EXPIRE 🫠
when this event happens, no address conflict has been detected during the previous DETECTION_TIMEOUT period. 🙌
If the Timeouts field in the BST entry is 0:
- Set the Lifetime of the BST entry to
DETECTION_TIMEOUT. Set the Timeouts field to1. Restart detecting any local address conflicts by sending a second Duplicate Address Detection Message (Section 7.5.1). Remain inDETECTIONstate. 🔄
If the Timeouts field in the BST entry is 1:
- Assume there is no local address conflict. Set the State field to
RECOVERY. Set the Lifetime of the BST entry toLEASEQUERY_DELAY. Set the Timeouts field to0. Start recovering any DHCP lease associated with the source IP address by sending one or more LEASEQUERY messages (Section 7.5.2). Transition toRECOVERYstate. 🎉
here's an example of the entry, per Figure 12:
+--------+-------+----------+----------------------+-----+----------+
| Anchor |Address| State | Lifetime | TID | Timeouts |
+--------+-------+----------+----------------------+-----+----------+
| Port_1 | Addr1 | RECOVERY | MAX_LEASEQUERY_DELAY | TID | 0 |
+--------+-------+----------+----------------------+-----+----------+Figure 12: Binding Entry in BST on Leasequery
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. 🧐
7.7.2. Event: EVE_DATA_CONFLICT: ARP Reply / NA Message Received from Unexpected System 🚫
remove the entry. bye bye 👋
Resulting state: NO_BIND - No binding has been set up. 🌸
7.7.3. Events Not Observed in DETECTION 🫥
EVE_DATA_UNMATCH: A data packet without a 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 🪄
7.8. Initial State: RECOVERY ✨
7.8.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or successful LEASEQUERY-REPLY is received 📬✨
Okay bestie, so a valid DHCPLEASEACTIVE or a successful LEASEQUERY-REPLY just showed up 😭. First things first, flip the State in the BST entry to VERIFY 💅. Then check what kind of triggering source IP address you're dealing with and process the Leasequery response to match:
IPv4 address: 🌸
- Update the Lifetime field in the BST entry to the sum of the value encoded in the IP Address Lease Time option of the DHCPLEASEACTIVE message and MAX_DHCP_RESPONSE_TIME.
- Record the value of the
chaddrfield (hardware address) in the message so you can check it against the hardware address that shows up during verification in the next state. 🔍 - Set the Timeouts field to
0. - Kick off verification by sending an Address Verification Message (see Section 7.5.3).
- Transition to VERIFY state.
- Start an additional verification timer with a duration of
DETECTION_TIMEOUT. When it expires, anEVE_DATA_EXPIREevent gets generated. ⏰
IPv6 address: 🦋
- Update the Lifetime field in the BST entry to the sum of the valid lifetime pulled from the OPTION_CLIENT_DATA option in the LEASEQUERY-REPLY message and MAX_DHCP_RESPONSE_TIME.
- Set the Timeouts field to
0. - Start the verification process by sending an Address Verification Message (see Section 7.5.3).
- Transition to VERIFY state.
- Start an additional verification timer with a duration of
DETECTION_TIMEOUT. When it expires, anEVE_DATA_EXPIREevent gets generated.
Now for the multi-address moment 🧚. If multiple addresses show up in the LEASEQUERY-REPLY, new BST entries MUST be created for the extra addresses using the same binding anchor. Those entries get created with state set to VERIFY, and their other fields are set the same way we just did for the triggering source IP address. Then you start the verification process and the verification timers for each additional address too. Iconic behaviour, honestly 👑.
Resulting state: VERIFY, which means we're awaiting verification (or not) of the association between the IP address and the connected interface 🫶.
7.8.2. Event: EVE_ENTRY_EXPIRE ⏳
Time for a choice 🍓. Depending on the Timeouts field in the BST entry, you either send repeat LEASEQUERY messages or throw the binding out.
If the Timeouts field in the BST entry is 0:
- No responses to the LEASEQUERY message(s) we sent came back during the first LEASEQUERY_DELAY period. Set the Lifetime of the BST entry to LEASEQUERY_DELAY.
- Set the Timeouts field to
1. - Restart the recovery of any DHCP lease tied to the source IP address by sending one or more LEASEQUERY messages (Section 7.5.2).
- Remain in RECOVERY state.
If the Timeouts field in the BST entry is 1:
- No responses to the LEASEQUERY messages sent during two LEASEQUERY_DELAY periods came back. So we assume no leases exist and that the source IP address is bogus 💀.
- Delete the BST entry.
- Transition to NO_BIND state.
Resulting state: RECOVERY if repeat leasequeries are sent, or NO_BIND if no successful responses to LEASEQUERY messages have been received.
7.8.3. Events Not Observed in RECOVERY 🙈
These are the events that should not show up while you're in RECOVERY, bestie:
EVE_DATA_UNMATCH: A data packet without a matched binding is received.EVE_DATA_CONFLICT: An ARP Reply / NA message is received from an unexpected system.EVE_DATA_VERIFY: A valid ARP Reply or NA message is received from the attached device.- All
EVE_DHCP_*events defined in Section 6.3.2. EVE_DATA_EXPIRE: Expiration of theDECTECTION_TIMEOUT.
7.9. Initial State: VERIFY 💜
7.9.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or successful LEASEQUERY-REPLY is received 🌈
Here's the drama 🎭. If LEASEQUERY messages went out to more than one DHCP server during RECOVERY state, extra successful leasequery responses might roll in for the source IP address. The conflict resolution mechanisms in Section 6.8 of [RFC4388] and Section 4.3.4 of [RFC5007] can help you figure out which message's values to use for updating the BST Lifetime and the hardware address obtained from DHCP, as described in Section 7.8.1. For DHCPv6 queries, the LEASEQUERY-REPLY may contain additional addresses, as described in Section 7.8.1 too. If that happens, additional BST entries MUST be created, or the ones previously created get updated as described in that section.
Resulting state: VERIFY (no change) ✨.
7.9.2. Event: EVE_DATA_VERIFY: A valid ARP Reply or NA is received from the device attached via the binding anchor 🔥
Depending on the type of triggering source IP address, this event might mean the device attached via the binding anchor in the BST entry got configured by DHCP using that IP address:
IPv4 address: Check that the sender hardware address in the ARP Reply matches the saved chaddr field (hardware address) from the previously received DHCPLEASEACTIVE message. If it doesn't match, ignore this event, since a subsequent retry may provide verification. If the hardware addresses match, the binding entry has been verified 🎉.
IPv6 address: Simply receiving a valid NA from the triggering source IP address at the binding anchor port provides verification for the binding entry 🦋.
If the binding entry has been verified, set the state in the BST entry to BOUND. Clear the TID field. Cancel the verification timer. Verified and vibing 🫶.
Resulting state: VERIFY (no change) if the IPv4 DHCPLEASEQUERY chaddr address doesn't match the ARP Reply hardware address. Otherwise, the resulting state is BOUND.
7.9.3. Event: EVE_ENTRY_EXPIRE ⌛
The DHCP lease lifetime ran out before the entry could be verified 😭. So remove the entry and transition to NO_BIND state.
Resulting state: NO_BIND, which means no binding has been set up.
7.9.4. Event: EVE_DATA_EXPIRE 🔁
Again, depending on the Timeouts field in the BST entry, you either send a repeat validation message or discard the binding:
If the Timeouts field in the BST entry is 0:
- No response to the verification message we sent came back during the first DETECTION_TIMEOUT period. Set the Timeouts field to
1. - Restart the verification process by sending an Address Verification Message (see Section 7.5.3).
- Start a verification timer with a duration of
DETECTION_TIMEOUT. When it expires, anEVE_DATA_EXPIREevent gets generated. - Remain in VERIFY state.
If the Timeouts field in the BST entry is 1:
- No responses to the verification messages sent during two DETECTION_TIMEOUT periods were received. So we assume the configuration of the triggering source IP address can't be verified, and that the source IP address is bogus 💅.
- Delete the BST entry.
- Transition to NO_BIND state.
Resulting state: VERIFY, meaning an additional verification message was sent, or NO_BIND, meaning no binding has been set up.
7.9.5. Events Not Observed in VERIFY 🙅♀️
EVE_DATA_UNMATCH: A data packet without a matched binding is received.EVE_DATA_CONFLICT: An ARP Reply / NA message is received from an unexpected system.- All
EVE_DHCP_*events defined in Section 6.3.2.
7.10. Initial State: BOUND 🎀
Upon entry to the BOUND state, control of the system carries on as if a DHCP message assigning the address had been observed, as in Section 6.4.3. The BST entry has been restored. Yay, back in business 🌸.
Heads up though: the TID field contains no value once the binding state changes to BOUND 👀. The TID field gets recovered from snooping DHCP Renew/Rebind messages if those 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 won't be executed normally. Not optional, babe 💖.
7.11. Table of State Machine 🗺️
Here's the whole state machine in one glance. The main state transitions are listed below:
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 leasequery RECOVERY
DETECTION EVE_DATA_CONFLICT Remove entry NO_BIND
RECOVERY EVE_ENTRY_EXPIRE 1 Repeat leasequery 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 TransitAnd the timer shorthands 🧠:
LQ_DELAY:MAX_LEASEQUERY_DELAYVRF_DELAY:DETECTION_TIMEOUT
8. Filtering Specification ✨
okay so this section is all about how to use bindings to filter out packets with spoofed source addresses 🕵️♀️💅
Filtering rules are different for data packets and control packets. DHCP, ARP, and Neighbor Discovery Protocol (NDP) [RFC4861] messages count as control packets. Everything else counts as a data packet 🧚
8.1. Data Packet Filtering
Data packets from attachments with the Validating attribute TRUE MUST have their source addresses validated 🔥 There's one exception to this, bestie.
A packet whose source IP address is a link-local address can't be checked against DHCP assignments, because it wasn't assigned using DHCP 🙈
Note: as explained in Section 1, a SAVI solution for link-local addresses, e.g., FCFS SAVI [RFC6620], can be enabled to check packets with a link-local source address.
If the source IP address of a packet is not a link-local address, but there's no matching entry in the BST with BOUND state, this packet MUST be discarded 💀 However, the packet may trigger the Data Snooping Process (Section 7) if the Data-Snooping attribute is set on the attachment 🌸
Data packets from an attachment with the Validating attribute set FALSE will be forwarded without having their source addresses validated 🦋
The SAVI device MAY log packets that fail source address validation 📝
8.2. Control Packet Filtering
For attachments with the Validating attribute:
- DHCPv4 Client-to-Server messages where the source IP address is neither all zeros nor bound with the corresponding binding anchor in the BST MUST be discarded 🚫
- DHCPv6 Client-to-Server messages where 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 where the source IP address is neither a link-local address nor bound with the corresponding binding anchor MUST be discarded 🚫
- NA messages where the target address is neither a link-local address nor bound with the corresponding binding anchor MUST be discarded 🚫
- ARP messages where the protocol is IP and the sender protocol address is neither all zeros nor bound with the corresponding binding anchor MUST be discarded 🚫
- ARP Reply messages where 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-Trustattribute orTrustattribute MUST be discarded 🫶
For attachments with no attribute:
- DHCP Server-to-Client messages from such attachments MUST be discarded 🙅♀️
The SAVI device MAY record any messages that are discarded 🎀
9. State Restoration 🌈
If a SAVI device reboots, whatever is kept in volatile memory is gone, periodt 😭 This section explains how to get the attribute configuration and the BST back.
9.1. Attribute Configuration Restoration
Losing the attribute configuration won't break the network, because no action gets taken on traffic from attachments with no attribute 🌸 But it does mean this SAVI function can't work anymore, which is a big mood-killer 😩
To avoid losing the binding anchor attribute configuration, the configuration MUST be able to be stored in non-volatile storage 💾 After the SAVI device reboots, if the binding anchor attribute configuration is found in non-volatile storage, the configuration MUST be used ✨
9.2. Binding State Restoration
If the binding state is lost, the SAVI devices will end up discarding legit traffic 😭 Using the Data Snooping Process to recover a huge pile of bindings is a heavy lift and can cause a lot of delay. So recovering bindings from non-volatile storage, as described 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 too 🗑️ The time when each binding entry is established gets saved as well ⏰
If the BST is stored in non-volatile storage, the SAVI device SHOULD restore binding state from that storage right after reboot 🔄 Using the saved time for each binding entry, the SAVI device should check whether the entry has gone stale, by comparing the saved lifetime with the difference between the current time and the time the binding entry was established. Obsolete entries that would have expired before the reboot MUST be removed 🧹
10. Constants 🎀
The following constants are RECOMMENDED for use in this context 💖
MAX_DHCP_RESPONSE_TIME(120s): Maximum Solicit timeout value (SOL_MAX_RT from [RFC3315]) ⏱️MAX_LEASEQUERY_DELAY(10s): Maximum LEASEQUERY timeout value (LQ_MAX_RT from [RFC5007]) ⏳DETECTION_TIMEOUT(0.5s): Maximum duration of a hardware address verification step in the VERIFY state (TENT_LT from [RFC6620]) 🦋DATA_SNOOPING_INTERVAL: Minimum interval between two successiveEVE_DATA_UNMATCHevents triggered by an attachment. Recommended interval: 60s and configurable 🌷OFFLINK_DELAY: Period after a client is last detected before the binding anchor is being removed. Recommended delay: 30s 👋
11. Security Considerations 🔐
This part is serious business, bestie, so pay attention 😤
11.1. Security Problems with the Data Snooping Process
There are two security problems with the Data Snooping Process (Section 7) 😬
- The Data Snooping Process is costly, but an attacker can trigger it simply by sending a bunch of data packets 🚨 To avoid Denial-of-Service attacks against the SAVI device itself, the Data Snooping Process MUST be rate limited. A constant
DATA_SNOOPING_INTERVALis used to control the frequency. Two Data Snooping Processes on one attachment MUST be separated by a minimum interval time ofDATA_SNOOPING_INTERVAL. If this value is changed, the value needs to be large enough to minimize DoS attacks 🛡️ - The Data Snooping Process may set up incorrect bindings if the clients do not reply to the detection probes (Section 7.6.1). An attack will pass the duplicate detection if the client assigned the target address does not reply to the detection probes 👀 The DHCP Leasequery procedure performed by the SAVI device just tells whether or not the address is assigned in the network. However, the SAVI device cannot determine from the DHCPLEASEQUERY Reply whether the address was just assigned to the triggering attachment 🙃
11.2. Securing Leasequery Operations
In [RFC4388] and [RFC5007], the specific case of DHCP Leasequeries originated by "access concentrators" is covered in depth 📚 SAVI devices are very similar to access concentrators, because they snoop on DHCP traffic and try to validate source addresses based on the results 👯♀️ So the recommendations for securing leasequery operations for access concentrators in Section 7 of [RFC4388] and Section 5 of [RFC5007] MUST be followed when leasequeries are made from SAVI devices 🔐 [RFC5007] RECOMMENDS that communications between the querier and the DHCP server are protected with IPsec 🔒 It's pointed out that there are relatively few devices involved in a given administrative domain (SAVI devices, DHCP relays, and DHCP servers), so manually configuring keying material wouldn't be overly burdensome 🔑
11.3. Client Departure Issues
After a binding is set up, the corresponding client may leave its attachment point 🚪 It might leave temporarily because of signal fade, or permanently by moving to a new attachment point or leaving the network 📶 In the signal fade case, the client may come back shortly, so the binding should be kept for a moment, lest legit traffic from the client gets blocked 🥺 But if the client leaves for good, keeping the binding can be a security issue 🚨 If the binding anchor is a property of the attachment point rather than the client (like the switch port, without including the MAC address), an attacker using the same binding anchor can send packets using IP addresses assigned to the client 😱 Even when the binding anchor is a property of the client, keeping 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 gets triggered ⚡ SAVI-DHCP monitors these events and performs the following mechanism 👀
- Whenever a client with the
Validatingattribute leaves, a timer of durationOFFLINK_DELAYis set on the corresponding binding entries ⏲️ - If a DAD Neighbor Solicitation / Gratuitous ARP request that targets the address is received during
OFFLINK_DELAY, the entry MAY be removed 🧹 - If the client returns on-link during
OFFLINK_DELAY, cancel the timer 🙌
This way, the bindings of a departing client are kept for OFFLINK_DELAY. During link flapping, the client won't get blocked 🫧 If the client leaves for good, the bindings get removed after OFFLINK_DELAY 👋
SAVI-DHCP doesn't handle the departure of indirect clients, because it won't be notified of those events 🤷♀️ Switches supporting indirect attachment (e.g., through a separate non-SAVI switch) SHOULD use client-specific information, such as its MAC address, as part of the binding anchor 💜
11.4. Compatibility with Detecting Network Attachment (DNA) 💅
Okay so DNA ([RFC4436] [RFC6059]) is all about cutting down the handover latency when a client reattaches to the same network 🏃♀️💨. It mostly works by running a reachability test, sending unicast Neighbor Solicitation / Router Solicitation / ARP Request messages to check whether an address the client already has is still valid.
Here's the tea 🫖: DNA doesn't give enough info to migrate the old binding or set up a new one. If a binding only gets built by snooping the reachability test messages, it might be invalid 😬. An attacker could run the reachability test using an address that's bound to another client, and if the binding gets migrated over to the attacker, they can totally grab the binding from the victim 💀. Since this mechanism won't set up a binding from snooping the DNA procedure, it can't be perfectly compatible with DNA. BUT (no caps, it's just vibes 🙈) that only means the interface reconfiguration is slowed down, not blocked. Let's break it down.
In Simple DNAv6 [RFC6059], the probe is sent with the source address set to a link-local address, and those messages won't get dropped by the policy in Section 8.2 🫶. If a client reattaches to a previous network, the detection finishes and the client treats the address as valid. The catch is the candidate address isn't in the probe, so you can't recover the binding by snooping the probe 😭. Since the client does a DHCP exchange at the same time, the binding gets recovered through the DHCP Snooping Process instead. The DHCP Request messages aren't filtered out here, because they have link-local source addresses ✨. Packets get filtered by the SAVI device until the DHCP procedure is done, so if this SAVI function is turned on, Simple DNAv6 won't actually help reduce handover latency 🥀. If the Data-Snooping attribute is configured on the client's new attachment, the data-triggered procedure might cut down on latency 🦋.
In DNAv4 [RFC4436], the ARP Probe gets discarded because it uses an unbound address as the sender protocol address 🙅♀️. So the client thinks the address under detection is valid, but the data traffic gets filtered 🚫. The DHCP Request message the client sends won't be discarded, because the source IP address field should be all zeros as required by [RFC2131] 🎀. So if the address is still valid, the binding gets recovered from the DHCP Snooping Process 🌸.
11.5. Binding Number Limitation 🧮
A binding entry eats up some high-speed memory 🍟. In general, a SAVI device can only afford a pretty limited number of binding entries. To stop an attacker from overloading the SAVI device's resources, there's a binding entry limit on each attachment 🛡️. That limit is the maximum number of bindings supported on each attachment with the Validating attribute. Once the limit is hit, no new binding should be set up 🙅♀️. And if a DHCP Reply assigns more addresses than the remaining binding entry quota of each client, the whole message gets discarded and no binding gets set up 💅.
11.6. Privacy Considerations 🔐
A SAVI device MUST delete binding anchor information as soon as possible (i.e., as soon as the state for a given address is back to NO_BIND), unless there's an identified reason that information is likely to be involved in detecting, preventing, or tracing actual source-address spoofing 🕵️♀️. Information about hosts that never spoof (probably the majority of hosts) SHOULD NOT be logged 🙈✨.
Privacy is the whole point here, bestie 🫶. Keep only what you truly need and let the rest go.
11.7. Fragmented DHCP Messages 🧩
This specification doesn't rule out reassembling fragmented DHCP messages, but it doesn't require it either 🤷♀️. If DHCP fragmentation turns out to be an issue, that issue will need to be specified and addressed. (This topic is outside the scope of this document 🙃.)
12. References 📚
12.1. Normative References 💜
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or
Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission on Ethernet Hardware", STD 37,
RFC 826, DOI 10.17487/RFC0826, November 1982,
<http://www.rfc-editor.org/info/rfc826>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<http://www.rfc-editor.org/info/rfc2131>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration
Protocol (DHCP) Leasequery", RFC 4388,
DOI 10.17487/RFC4388, February 2006,
<http://www.rfc-editor.org/info/rfc4388>.
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
Network Attachment in IPv4 (DNAv4)", RFC 4436,
DOI 10.17487/RFC4436, March 2006,
<http://www.rfc-editor.org/info/rfc4436>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>.
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
"DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007,
September 2007, <http://www.rfc-editor.org/info/rfc5007>.
[RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227,
DOI 10.17487/RFC5227, July 2008,
<http://www.rfc-editor.org/info/rfc5227>.
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for
Detecting Network Attachment in IPv6", RFC 6059,
DOI 10.17487/RFC6059, November 2010,
<http://www.rfc-editor.org/info/rfc6059>.
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
SAVI: First-Come, First-Served Source Address Validation
Improvement for Locally Assigned IPv6 Addresses",
RFC 6620, DOI 10.17487/RFC6620, May 2012,
<http://www.rfc-editor.org/info/rfc6620>.12.2. Informative References 🌷
[DHCPv6-SHIELD]
Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield:
Protecting Against Rogue DHCPv6 Servers", Work in
Progress, draft-ietf-opsec-dhcpv6-shield-07, May 2015.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736,
April 2004, <http://www.rfc-editor.org/info/rfc3736>.
[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed.,
"Source Address Validation Improvement (SAVI) Framework",
RFC 7039, DOI 10.17487/RFC7039, October 2013,
<http://www.rfc-editor.org/info/rfc7039>.
[RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport",
RFC 7341, DOI 10.17487/RFC7341, August 2014,
<http://www.rfc-editor.org/info/rfc7341>.Acknowledgments 🫶
Special thanks to Jean-Michel Combes, Christian Vogt, Joel M. Halpern, Eric Levy-Abegnoli, Marcelo Bagnulo Braun, Jari Arkko, Elwyn Davies, Barry Leiba, Ted Lemon, Leaf Yeh, Ralph Droms, and Alberto Garcia for their careful review and evaluation comments on the mechanism and text 💖.
Thanks to Mark Williams, Erik Nordmark, Mikael Abrahamsson, David Harrington, Pekka Savola, Xing Li, Lixia Zhang, Bingyang Liu, Duanqi Zhou, Robert Raszuk, Greg Daley, John Kaippallimalil, and Tao Lin for their valuable contributions ✨👑.
Authors' Addresses 🖋️
Jun Bi
Network Research Center, Tsinghua University
Beijing 100084
China
EMail: junbi@tsinghua.edu.cn
Jianping Wu
Dept. of Computer Science, Tsinghua University
Beijing 100084
China
EMail: jianping@cernet.edu.cn
Guang Yao
Network Research Center, Tsinghua University
Beijing 100084
China
EMail: yaoguang@cernet.edu.cn
Fred Baker
Cisco Systems
Santa Barbara, CA 93117
United States
EMail: fred@cisco.com📦 where this page comes from
- ietf: rfc7513 2015-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms