< draft-ietf-savi-dhcp-32.txt   draft-ietf-savi-dhcp-33.txt >
Source Address Validation Improvement J. Bi Source Address Validation Improvement J. Bi
Internet-Draft J. Wu Internet-Draft J. Wu
Intended status: Standards Track G. Yao Intended status: Standards Track G. Yao
Expires: July 30, 2015 Tsinghua Univ. Expires: August 16, 2015 Tsinghua Univ.
F. Baker F. Baker
Cisco Cisco
January 26, 2015 February 12, 2015
SAVI Solution for DHCP SAVI Solution for DHCP
draft-ietf-savi-dhcp-32 draft-ietf-savi-dhcp-33
Abstract Abstract
This document specifies the procedure for creating a binding between This document specifies the procedure for creating a binding between
a DHCPv4/DHCPv6-assigned IP address and a binding anchor on a Source a DHCPv4/DHCPv6-assigned IP address and a binding anchor on a Source
Address Validation Improvements (SAVI) device. The bindings set up Address Validation Improvements (SAVI) device. The bindings set up
by this procedure are used to filter packets with forged source IP by this procedure are used to filter packets with forged source IP
addresses. This mechanism complements BCP 38 ingress filtering, addresses. This mechanism complements BCP 38 ingress filtering,
providing finer-grained source IP address validation. providing finer-grained source IP address validation.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 30, 2015. This Internet-Draft will expire on August 16, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Deployment Scenario and Configuration . . . . . . . . . . . . 7 4. Deployment Scenario and Configuration . . . . . . . . . . . . 8
4.1. Elements and Scenario . . . . . . . . . . . . . . . . . . 8 4.1. Elements and Scenario . . . . . . . . . . . . . . . . . . 8
4.2. SAVI Binding Type Attributes . . . . . . . . . . . . . . 9 4.2. SAVI Binding Type Attributes . . . . . . . . . . . . . . 10
4.2.1. Trust Attribute . . . . . . . . . . . . . . . . . . . 9 4.2.1. Trust Attribute . . . . . . . . . . . . . . . . . . . 10
4.2.2. DHCP-Trust Attribute . . . . . . . . . . . . . . . . 10 4.2.2. DHCP-Trust Attribute . . . . . . . . . . . . . . . . 11
4.2.3. DHCP-Snooping Attribute . . . . . . . . . . . . . . . 10 4.2.3. DHCP-Snooping Attribute . . . . . . . . . . . . . . . 11
4.2.4. Data-Snooping Attribute . . . . . . . . . . . . . . . 11 4.2.4. Data-Snooping Attribute . . . . . . . . . . . . . . . 11
4.2.5. Validating Attribute . . . . . . . . . . . . . . . . 11 4.2.5. Validating Attribute . . . . . . . . . . . . . . . . 12
4.2.6. Table of Mutual Exclusions . . . . . . . . . . . . . 12 4.2.6. Table of Mutual Exclusions . . . . . . . . . . . . . 13
4.3. Perimeter . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3. Perimeter . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3.1. SAVI-DHCP Perimeter Overview . . . . . . . . . . . . 12 4.3.1. SAVI-DHCP Perimeter Overview . . . . . . . . . . . . 13
4.3.2. SAVI-DHCP Perimeter Configuration Guideline . . . . . 13 4.3.2. SAVI-DHCP Perimeter Configuration Guideline . . . . . 14
4.3.3. On the Placement of the DHCP Server and Relay . . . . 14 4.3.3. On the Placement of the DHCP Server and Relay . . . . 15
4.3.4. An Alternative Deployment . . . . . . . . . . . . . . 14 4.3.4. An Alternative Deployment . . . . . . . . . . . . . . 15
4.3.5. Considerations regarding Binding Anchors . . . . . . 15 4.3.5. Considerations regarding Binding Anchors . . . . . . 16
4.4. Other Device Configuration . . . . . . . . . . . . . . . 16 4.4. Other Device Configuration . . . . . . . . . . . . . . . 17
5. Binding State Table (BST) . . . . . . . . . . . . . . . . . . 16 5. Binding State Table (BST) . . . . . . . . . . . . . . . . . . 17
6. DHCP Snooping Process . . . . . . . . . . . . . . . . . . . . 17 6. DHCP Snooping Process . . . . . . . . . . . . . . . . . . . . 18
6.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2. Binding States Description . . . . . . . . . . . . . . . 18 6.2. Binding States Description . . . . . . . . . . . . . . . 19
6.3. Events . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.3. Events . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.3.1. Timer Expiration Event . . . . . . . . . . . . . . . 18 6.3.1. Timer Expiration Event . . . . . . . . . . . . . . . 19
6.3.2. Control Message Arriving Events . . . . . . . . . . . 18 6.3.2. Control Message Arriving Events . . . . . . . . . . . 19
6.4. The State Machine of DHCP Snooping Process . . . . . . . 20 6.4. The State Machine of DHCP Snooping Process . . . . . . . 21
6.4.1. Initial State: NO_BIND - No binding has been set up . 20 6.4.1. Initial State: NO_BIND - No binding has been set up . 21
6.4.2. Initial State: INIT_BIND - A potential binding has 6.4.2. Initial State: INIT_BIND - A potential binding has
been set up . . . . . . . . . . . . . . . . . . . . . 22 been set up . . . . . . . . . . . . . . . . . . . . . 23
6.4.3. Initial State: BOUND - The binding has been set up . 25 6.4.3. Initial State: BOUND - The binding has been set up . 26
6.4.4. Table of State Machine . . . . . . . . . . . . . . . 27 6.4.4. Table of State Machine . . . . . . . . . . . . . . . 29
7. Data Snooping Process . . . . . . . . . . . . . . . . . . . . 29 7. Data Snooping Process . . . . . . . . . . . . . . . . . . . . 30
7.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . 29 7.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . 31
7.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 30 7.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 32
7.3. Additional Binding States Description . . . . . . . . . . 30 7.3. Additional Binding States Description . . . . . . . . . . 32
7.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . 31 7.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.5. Initial State: state NO_BIND - No binding has been set up 32 7.5. Message Sender Functions . . . . . . . . . . . . . . . . 34
7.5.1. Event: EVE_DATA_UNMATCH: A data packet without 7.5.1. Duplicate Detection Message Sender . . . . . . . . . 34
matched binding is received . . . . . . . . . . . . . 32 7.5.2. Lease Query Message Sender . . . . . . . . . . . . . 35
7.5.2. Events not observed in NO_BIND . . . . . . . . . . . 33 7.5.3. Address Verification Message Sender . . . . . . . . . 36
7.6. Initial State: state DETECTION - The address in the entry 7.6. Initial State: state NO_BIND - No binding has been set up 36
is under local duplication detection . . . . . . . . . . 33 7.6.1. Event: EVE_DATA_UNMATCH: A data packet without a
7.6.1. Event: EVE_ENTRY_EXPIRE . . . . . . . . . . . . . . . 33 matched binding is received . . . . . . . . . . . . . 36
7.6.2. Event: EVE_DATA_CONFLICT: ARP Reply/Neighbor 7.6.2. Events not observed in NO_BIND for data snooping . . 37
7.7. Initial State: state DETECTION - The address in the entry
is undergoing local duplication detection . . . . . . . . 38
7.7.1. Event: EVE_ENTRY_EXPIRE . . . . . . . . . . . . . . . 38
7.7.2. Event: EVE_DATA_CONFLICT: ARP Reply/Neighbor
Advertisement(NA) message received from unexpected Advertisement(NA) message received from unexpected
system . . . . . . . . . . . . . . . . . . . . . . . 34 system . . . . . . . . . . . . . . . . . . . . . . . 39
7.6.3. Events not observed in DETECTION . . . . . . . . . . 34 7.7.3. Events not observed in DETECTION . . . . . . . . . . 39
7.7. Initial State: state RECOVERY - The SAVI device is 7.8. Initial State: state RECOVERY - The SAVI device is
querying the assignment and lease time of the address in querying the assignment and lease time of the address in
the entry through DHCP Leasequery . . . . . . . . . . . . 34 the entry through DHCP Leasequery . . . . . . . . . . . . 39
7.7.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE 7.8.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE
or LEASEQUERY-REPLY is received . . . . . . . . . . . 34 or successful LEASEQUERY-REPLY is received . . . . . 39
7.7.2. Event: EVE_ENTRY_EXPIRE . . . . . . . . . . . . . . . 36 7.8.2. Event: EVE_ENTRY_EXPIRE . . . . . . . . . . . . . . . 40
7.7.3. Events not observed in RECOVERY . . . . . . . . . . . 36 7.8.3. Events not observed in RECOVERY . . . . . . . . . . . 40
7.8. Initial State: state BOUND - The binding has been set up 36 7.9. Initial State: state VERIFY - Verification of the use of
7.9. Table of State Machine . . . . . . . . . . . . . . . . . 36 the source IP address by the device interface attached to
8. Filtering Specification . . . . . . . . . . . . . . . . . . . 38 the SAVI device . . . . . . . . . . . . . . . . . . . . . 41
8.1. Data Packet Filtering . . . . . . . . . . . . . . . . . . 38 7.9.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE
8.2. Control Packet Filtering . . . . . . . . . . . . . . . . 38 or successful LEASEQUERY-REPLY is received . . . . . 41
9. State Restoration . . . . . . . . . . . . . . . . . . . . . . 39 7.9.2. Event: EVE_DATA_VERIFY: A valid ARP Reply or NA is
9.1. Attribute Configuration Restoration . . . . . . . . . . . 39 received from the device attached via the binding
9.2. Binding State Restoration . . . . . . . . . . . . . . . . 39 anchor . . . . . . . . . . . . . . . . . . . . . . . 41
10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 40 7.9.3. Event: EVE_ENTRY_EXPIRE . . . . . . . . . . . . . . . 42
11. Security Considerations . . . . . . . . . . . . . . . . . . . 40 7.9.4. Event: EVE_DATA_EXPIRE . . . . . . . . . . . . . . . 42
11.1. Security Problems about the Data Snooping Process . . . 40 7.9.5. Events not observed in VERIFY . . . . . . . . . . . . 42
11.2. Client departure issues . . . . . . . . . . . . . . . . 41 7.10. Initial State: state BOUND - The binding has been set up 42
11.3. Duplicate Bindings to the Same Address . . . . . . . . . 42 7.11. Table of State Machine . . . . . . . . . . . . . . . . . 43
11.4. Compatibility with DNA (Detecting Network Attachment) . 42 8. Filtering Specification . . . . . . . . . . . . . . . . . . . 44
11.5. Binding Number Limitation . . . . . . . . . . . . . . . 43 8.1. Data Packet Filtering . . . . . . . . . . . . . . . . . . 45
11.6. Privacy Considerations . . . . . . . . . . . . . . . . . 43 8.2. Control Packet Filtering . . . . . . . . . . . . . . . . 45
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 9. State Restoration . . . . . . . . . . . . . . . . . . . . . . 46
13. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 44 9.1. Attribute Configuration Restoration . . . . . . . . . . . 46
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 9.2. Binding State Restoration . . . . . . . . . . . . . . . . 46
14.1. Normative References . . . . . . . . . . . . . . . . . . 44 10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 47
14.2. Informative References . . . . . . . . . . . . . . . . . 45 11. Security Considerations . . . . . . . . . . . . . . . . . . . 47
11.1. Security Problems about the Data Snooping Process . . . 47
11.2. Securing Lease Query Operations . . . . . . . . . . . . 48
11.3. Client departure issues . . . . . . . . . . . . . . . . 48
11.4. Compatibility with DNA (Detecting Network Attachment) . 49
11.5. Binding Number Limitation . . . . . . . . . . . . . . . 50
11.6. Privacy Considerations . . . . . . . . . . . . . . . . . 50
11.7. Fragmented DHCP Messages . . . . . . . . . . . . . . . . 50
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
13. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 51
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
14.1. Normative References . . . . . . . . . . . . . . . . . . 51
14.2. Informative References . . . . . . . . . . . . . . . . . 52
1. Introduction 1. Introduction
This document describes a fine-grained source IPv4 or IPv6 source This document describes a fine-grained source address validation
address validation mechanism. This mechanism creates bindings mechanism for IPv4 and IPv6 packets. This mechanism creates bindings
between IP addresses assigned to network interfaces by DHCP and between IP addresses assigned to network interfaces by DHCP and
suitable binding anchors (Section 4.3.5). As discussed in Section 3 suitable binding anchors (Section 4.3.5). As discussed in Section 3
and [RFC7039], a "binding anchor" is an attribute that is immutable and [RFC7039], a "binding anchor" is an attribute that is immutable
or difficult to change that may be used to identify the system an IP or difficult to change that may be used to identify the system an IP
address has been assigned to; common examples include a MAC address address has been assigned to; common examples include a MAC address
found on an Ethernet switch port or WiFi security association. The found on an Ethernet switch port or WiFi security association. The
bindings are used to identify and filter packets originated by these bindings are used to identify and filter packets originated by these
interfaces using forged source IP addresses. In this way, this interfaces using forged source IP addresses. In this way, this
mechanism can prevent hosts from using IP addresses assigned to the mechanism can prevent hosts from using IP addresses assigned to any
other attachment points or invalid in the network. This behavior is other attachment point in or not associated with the network. This
referred to as "spoofing", and is key to amplification attacks, in behavior is referred to as "spoofing", and is key to amplification
which a set of systems send messages to another set of systems attacks, in which a set of systems send messages to another set of
claiming to be from a third set of systems, and sending the replies systems claiming to be from a third set of systems, and sending the
to systems that don't expect them. If [RFC2827] protects a network replies to systems that don't expect them. Whereas BCP 38 [RFC2827]
from a neighboring network by providing prefix granularity source IP protects a network from a neighboring network by providing prefix
address validity, this mechanism protects a network, including a granularity source IP address validity, this mechanism protects a
Local Area Network, from itself by providing address granularity network, including a Local Area Network, from itself by providing
source IP validity when DHCP/DHCPv6 is used to assign IPv4/IPv6 address granularity source IP validity when DHCP/DHCPv6 is used to
addresses. Both provide a certain level of traceability, in that assign IPv4/IPv6 addresses. Both provide a certain level of
packet drops indicate the presence of a system that is producing traceability, in that packet drops indicate the presence of a system
packets with spoofed IP addresses. that is producing packets with spoofed IP addresses.
SAVI-DHCP snoops DHCP address assignments to set up bindings between SAVI-DHCP snoops DHCP address assignments to set up bindings between
IP addresses assigned by DHCP and corresponding binding anchors. It IP addresses assigned by DHCP and corresponding binding anchors. It
includes the DHCPv4 and v6 snooping process (Section 6), the Data includes the DHCPv4 and v6 snooping process (Section 6), the Data
Snooping process (Section 7), as well as a number of other technical Snooping process (Section 7), as well as a number of other technical
details. The Data Snooping process is a data-triggered procedure details. The Data Snooping process is a data-triggered procedure
that snoops the header of data packet to set up bindings. It is that snoops the IP header of data packets to set up bindings. It is
designed to avoid a permanent block of valid addresses in the case designed to avoid a permanent blockage of valid addresses in the case
that DHCP snooping is insufficient to set up all the valid bindings. that DHCP snooping is insufficient to set up all the valid bindings.
This mechanism is designed for the stateful DHCP scenario [RFC2131], This mechanism is designed for the stateful DHCP scenario [RFC2131],
[RFC3315]. Stateless DHCP [RFC3736] is out of scope for this [RFC3315]. Stateless DHCP [RFC3736] is out of scope for this
document, as it has nothing to do with IP address allocation. The document, as it has nothing to do with IP address allocation. An
appropriate SAVI method must be used in those cases. For hosts using alternative SAVI method would have be used in those cases. For hosts
Stateless Auto-Configuration to allocate addresses, SAVI-FCFS using Stateless Address Auto-Configuration (SLAAC) to allocate
[RFC6620] should be enabled. Besides, this mechanism is primarily addresses, SAVI-FCFS [RFC6620] should be enabled. SAVI-DHCP is
designed for pure DHCP scenarios in which only addresses assigned primarily designed for pure DHCP scenarios in which only addresses
through DHCP are allowed. However, it does not block link-local assigned through DHCP are allowed. However, it does not block link-
addresses, as they are not assigned using DHCP. It is RECOMMENDED local addresses, as they are not assigned using DHCP. It is
that the administration enable a SAVI solution for link-local RECOMMENDED that the administration deploy a SAVI solution for link-
addresses, e.g., SAVI-FCFS [RFC6620]. local addresses, e.g., SAVI-FCFS [RFC6620].
This mechanism works for DHCPv4-only, DHCPv6-only, or both DHCPv4 and This mechanism works for networks that use DHCPv4 only, DHCPv6 only,
DHCPv6. However, the DHCP address assignment mechanism in IPv4/IPv6 or both DHCPv4 and DHCPv6. However, the DHCP address assignment
transition scenarios, e.g., [RFC7341], are beyond the scope of this mechanism in IPv4/IPv6 transition scenarios, e.g., [RFC7341], are
document. beyond the scope of this document.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Terminology 3. Terminology
Binding anchor: A "binding anchor" is defined to be a physical and/or Binding anchor: A "binding anchor" is defined to be a physical and/or
skipping to change at page 6, line 4 skipping to change at page 6, line 19
[RFC2131] [RFC2131]
o Note: DHCPv4 Request/Renew/Rebind/Reboot messages can be o Note: DHCPv4 Request/Renew/Rebind/Reboot messages can be
identified based on the Table 4 of [RFC2131] identified based on the Table 4 of [RFC2131]
o DHCPv4 Decline: DHCPDECLINE [RFC2131] o DHCPv4 Decline: DHCPDECLINE [RFC2131]
o DHCPv4 Release: DHCPRELEASE [RFC2131] o DHCPv4 Release: DHCPRELEASE [RFC2131]
o DHCPv4 Inform: DHCPINFORM [RFC2131] o DHCPv4 Inform: DHCPINFORM [RFC2131]
o DHCPv4 DHCPLEASEQUERY: A message sent to enquire about the lease
that might exist for an IPv4 address. [RFC4388]
o DHCPv6 Request: REQUEST [RFC3315] o DHCPv6 Request: REQUEST [RFC3315]
o DHCPv6 Solicit: SOLICIT [RFC3315] o DHCPv6 Solicit: SOLICIT [RFC3315]
o DHCPv6 Confirm: CONFIRM [RFC3315] o DHCPv6 Confirm: CONFIRM [RFC3315]
o DHCPv6 Decline: DECLINE [RFC3315] o DHCPv6 Decline: DECLINE [RFC3315]
o DHCPv6 Release: RELEASE [RFC3315] o DHCPv6 Release: RELEASE [RFC3315]
o DHCPv6 Rebind: REBIND [RFC3315] o DHCPv6 Rebind: REBIND [RFC3315]
o DHCPv6 Renew: RENEW [RFC3315] o DHCPv6 Renew: RENEW [RFC3315]
o DHCPv6 Information-Request: INFORMATION-REQUEST [RFC3315] o DHCPv6 Information-Request: INFORMATION-REQUEST [RFC3315]
o DHCPv6 LEASEQUERY: A message sent to enquire about the lease that
might exist for an IPv6 address. [RFC5007]
DHCP Server-to-Client message: A message that is sent from a DHCP DHCP Server-to-Client message: A message that is sent from a DHCP
server to a DHCP client. Such a message is of one of the following server to a DHCP client. Such a message is of one of the following
types: types:
o DHCPv4 ACK: DHCPACK [RFC2131] o DHCPv4 ACK: DHCPACK [RFC2131]
o DHCPv4 NAK: DHCPNAK [RFC2131] o DHCPv4 NAK: DHCPNAK [RFC2131]
o DHCPv4 Offer: DHCPOFFER [RFC2131] o DHCPv4 Offer: DHCPOFFER [RFC2131]
o DHCPv4 DHCPLEASEACTIVE: A response to a DHCPLEASEQUERY request.
[RFC4388]
o DHCPv6 Reply: REPLY [RFC3315] o DHCPv6 Reply: REPLY [RFC3315]
o DHCPv6 Advertise: ADVERTISE [RFC3315] o DHCPv6 Advertise: ADVERTISE [RFC3315]
o DHCPv6 Reconfigure: RECONFIGURE [RFC3315] o DHCPv6 Reconfigure: RECONFIGURE [RFC3315]
o DHCPv6 LEASEQUERY-REPLY: A response to a LEASEQUERY request.
[RFC5007]
Lease time: The lease time in IPv4 [RFC2131] or the valid lifetime in Lease time: The lease time in IPv4 [RFC2131] or the valid lifetime in
IPv6 [RFC3315]. IPv6 [RFC3315].
Binding entry: A rule that associates an IP address with a binding Binding entry: A rule that associates an IP address with a binding
anchor. anchor.
Binding State Table (BST): The data structure that contains the Binding State Table (BST): The data structure that contains the
binding entries. binding entries.
Binding entry limit: The maximum number of binding entries that may Binding entry limit: The maximum number of binding entries that may
be associated with a binding anchor. Limiting the number of binding be associated with a binding anchor. Limiting the number of binding
entries per binding anchor prevents a malicious or malfunctioning entries per binding anchor prevents a malicious or malfunctioning
node from overloading the binding table on a SAVI device. node from overloading the binding table on a SAVI device.
Direct attachment: Ideally, a SAVI device is an access device that Direct attachment: Ideally, a SAVI device is an access device that
hosts are attached to directly. In such a case, the hosts are direct hosts are attached to directly. In such a case, the hosts are direct
attachments (e.g., they attach directly) to the SAVI device. attachments (i.e., they attach directly) to the SAVI device.
Indirect attachment: A SAVI device MAY be an aggregation device that Indirect attachment: A SAVI device MAY be an aggregation device that
other access devices are attached to, and which hosts in turn attach other access devices are attached to, and which hosts in turn attach
to. In such a case, the hosts are indirect attachments (e.g., they to. In such a case, the hosts are indirect attachments (i.e., they
attach indirectly) to the SAVI device. attach indirectly) to the SAVI device.
Unprotected link: Unprotected links are links that connect to hosts Unprotected link: Unprotected links are links that connect to hosts
or networks of hosts that the device may not see DHCP messages to, or networks of hosts receive their DHCP traffic by another path, and
and are therefore outside the SAVI perimeter. are therefore outside the SAVI perimeter.
Unprotected device: An unprotected device is a device associated with Unprotected device: An unprotected device is a device associated with
an unprotected link. One example might be the gateway router of a an unprotected link. One example might be the gateway router of a
network. network.
Protected link: Protected links are links that connect to hosts that Protected link: If DHCP messages for a given attached device always
the device will invariably see DHCP messages to, and are therefore use a given link, the link is considered to be "protected" by the
within the SAVI perimeter. SAVI Device, and is therefore within the SAVI perimeter.
Protected device: A protected device is a device associated with a Protected device: A protected device is a device associated with a
protected link. One example might be a desktop switch in the protected link. One example might be a desktop switch in the
network, or a host. network, or a host.
Cut Vertex: A cut vertex is any vertex whose removal increases the Cut Vertex: A cut vertex is any vertex whose removal increases the
number of connected components. This is a concept in graph theory. number of connected components in a (network) graph. This is a
This term is used in Section 6.1 to accurately specify the required concept in graph theory. This term is used in Section 6.1 to
deployment location of SAVI devices when they only perform the DHCP accurately specify the required deployment location of SAVI devices
snooping process. when they only perform the DHCP Snooping Process.
Identity Association (IA): "A collection of addresses assigned to a Identity Association (IA): "A collection of addresses assigned to a
client." [RFC3315] client." [RFC3315]
Detection message: a Neighbor Solicitation or ARP message intended to Detection message: a Neighbor Solicitation or ARP message intended by
detect a duplicate address by the Data Snooping Process. the Data Snooping Process to detect a duplicate address.
DHCP_DEFAULT_LEASE: default lifetime for DHCPv6 address when the DHCP_DEFAULT_LEASE: default lifetime for DHCPv6 address when the
binding is triggered by a DHCPv6 Confirm message but a DHCPv6 lease binding is triggered by a DHCPv6 Confirm message but a DHCPv6 lease
query exchange [RFC5007] cannot be performed by the SAVI device to query exchange [RFC5007] cannot be performed by the SAVI device to
fetch the lease. fetch the lease.
4. Deployment Scenario and Configuration 4. Deployment Scenario and Configuration
4.1. Elements and Scenario 4.1. Elements and Scenario
The essential elements in a SAVI-DHCP deployment scenario include a The essential elements in a SAVI-DHCP deployment scenario include at
DHCP server (which may or may not be assigned an address using DHCP, least one DHCP server (which may or may not be assigned an address
and therefore may or may not be protected), zero or more protected using DHCP, and therefore may or may not be protected), zero or more
DHCP clients, and one or more SAVI devices. It may also include DHCP protected DHCP clients, and one or more SAVI devices. It may also
relays, when the DHCP server is not co-located with a set of clients, include DHCP relays, when the DHCP server is not co-located with a
and zero or more protected Non-SAVI devices. Outside the perimeter, set of clients, and zero or more protected Non-SAVI devices. Outside
via unprotected links, there may be many unprotected devices. the perimeter, via unprotected links, there may be many unprotected
devices.
+--------+ +------------+ +----------+ +-------------+
|DHCP |-----| Non-SAVI |----|Bogus DHCP| | unprotected |
| device |
+------+------+
|
+--------+ +-----+------+ +----------+
|DHCP +-----+ Non-SAVI +----+Bogus DHCP|
|Server A| | Device 1 | |Server | |Server A| | Device 1 | |Server |
+--------+ +-----|------+ +----------+ +--------+ +-----+------+ +----------+
|unprotected link |trusted, unprotected link
. . . . . . . . . . .|. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .|. . . . . . . . . . . . . .
. | . . | .
. Protection +---|------+ . . Protection +---+------+ trusted link .
. Perimeter | SAVI |--------------+ . . Perimeter | SAVI +--------------+ .
. | Device C| | . . | Device C| | .
. +---|------+ | . . +---+------+ | .
. | | . . | | .
. +----------+ +---|------+ +------|---+ . . untrusted, +----------+ +---+------+ +------+---+ .
protected . | SAVI | | Non SAVI| | SAVI | . . protected | SAVI | | Non SAVI| | SAVI | .
link +----.-| Device A|----| Device 3|-------| Device B| . . link+------+ Device A+----+ Device 3+-------+ Device B| .
| . +----|--|--+ +----------+ +-|---|----+ . . | +----+--+--+ +----------+ +-+---+----+ .
| . | +----------+ . . . . . | | . . | | +----------+ . . . . . | | .
| '. . . . . . . | . . | | . . | . . . . . . | . . | | .
| | . | . +--------+ | . . | . | . | . +--------+ | .
+----|-----+ +--|---+ . +----|-+ . +--|---+ . +---|----+ . . +----+-----+. +--+---+ . +----+-+ . +--+---+ . +---+----+ .
| Non-SAVI | |Client| . |DHCP | . |Client| . |DHCP | . . | Non-SAVI |. |Client| . |DHCP | . |Client| . |DHCP | .
| Device 2 | |A | . |Relay | . |B | . |Server B| . . | Device 2 |. |A | . |Relay | . |B | . |Server B| .
+----------+ +------+ . +------+ . +------+ . +--------+ . . +----------+. +------+ . +------+ . +------+ . +--------+ .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 1: SAVI-DHCP Scenario Figure 1: SAVI-DHCP Scenario
Figure 1 shows a deployment scenario that contains these elements. Figure 1 shows a deployment scenario that contains these elements.
Note that a physical device can instantiate multiple elements, e.g., 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 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 computing environment, a physical host may contain a virtual switch
plus some number of virtual hosts. In such cases, the links are plus some number of virtual hosts. In such cases, the links are
logical links rather than physical links. logical links rather than physical links.
Networks are not usually isolated. As a result, traffic from other Networks are not usually isolated. As a result, traffic from other
networks, including transit traffic as specified in [RFC6620] (e.g., networks, including transit traffic as specified in [RFC6620] (e.g.,
traffic from another SAVI switch or a router) may enter a SAVI-DHCP traffic from another SAVI switch or a router) may enter a SAVI-DHCP
network through the unprotected links. Since SAVI solutions are network through the unprotected links. Since SAVI solutions are
limited to validating traffic generated from a local link, SAVI-DHCP limited to validating traffic generated from a local link, SAVI-DHCP
does not set up bindings for addresses assigned in other networks and does not set up bindings for addresses assigned in other networks and
cannot validate them. Traffic from unprotected links should be cannot validate them. Traffic from unprotected links should be
checked by an unprotected system or [RFC2827] mechanisms. The checked by an unprotected device or [RFC2827] mechanisms. The
generation and deployment of such a mechanism is beyond the scope of generation and deployment of such a mechanism is beyond the scope of
this document. this document.
Traffic from protected links is, however, locally generated, and Traffic from protected links is, however, locally generated, and
should be checked by SAVI-DHCP if possible. In the event that there should have its source addresses validated by SAVI-DHCP if possible.
is an intervening protected non-SAVI device between the host and the In the event that there is an intervening protected non-SAVI device
SAVI device, however, use of the physical attachment point alone as a between the host and the SAVI device, however, use of the physical
binding anchor is insufficiently secure, as the several devices on a attachment point alone as a binding anchor is insufficiently secure,
port or other point of attachment can spoof each other. Hence, as the several devices on a port or other point of attachment can
additional information such as a MAC address SHOULD be used to spoof each other. Hence, additional information such as a MAC
disambiguate them. address SHOULD be used to disambiguate them.
4.2. SAVI Binding Type Attributes 4.2. SAVI Binding Type Attributes
As illustrated in Figure 1, a system attached to a SAVI device can be 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 a DHCP client, a DHCP relay/server, a SAVI device, or a non-SAVI
device. Different actions are performed on traffic originated from device. Different actions are performed on traffic originated from
different elements. To distinguish among their requirements, several different elements. To distinguish among their requirements, several
properties are associated with their point of attachment on the SAVI properties are associated with their point of attachment on the SAVI
device. device.
skipping to change at page 9, line 45 skipping to change at page 10, line 41
until SAVI-DHCP is itself enabled. This is because a SAVI switch until SAVI-DHCP is itself enabled. This is because a SAVI switch
that depends on DHCP cannot tell, a priori, which ports have valid that depends on DHCP cannot tell, a priori, which ports have valid
DHCP servers attached, or which have routers or other equipment that DHCP servers attached, or which have routers or other equipment that
would validly appear to use an arbitrary set of source addresses. would validly appear to use an arbitrary set of source addresses.
When SAVI has been enabled, the attributes take effect. When SAVI has been enabled, the attributes take effect.
4.2.1. Trust Attribute 4.2.1. Trust Attribute
The "Trust Attribute" is a Boolean value. If TRUE, it indicates that The "Trust Attribute" is a Boolean value. If TRUE, it indicates that
the packets from the corresponding attached device need not have the packets from the corresponding attached device need not have
their source addresses validated. Examples of a trusted binding their source addresses validated. Examples of a trusted attachment
anchor would be a port to another SAVI device, or to an IP router, as would be a port to another SAVI device, or to an IP router, as shown
shown in Figure 1. In both cases, traffic using many source IP in Figure 1. In both cases, traffic using many source IP addresses
addresses will be seen. By default, the Trust attribute is FALSE, will be seen. By default, the Trust attribute is FALSE, indicating
indicating that any device found on that port will seek an address that any device found on that port will seek an address using DHCP
using DHCP and be limited to using such addresses. and be limited to using such addresses.
SAVI devices will not set up bindings for points of attachment with SAVI devices will not set up bindings for points of attachment with
the Trust attribute set TRUE; DHCP messages and data packets from the Trust attribute set TRUE; no packets, including DHCP messages,
attached devices with this attribute will not be checked. If the from devices with this attribute on their attachments will be
DHCP Server-to-Client messages from attached devices with this validated. However DHCP Server-to-Client messages will be snooped on
attribute can trigger the state transitions specified in Section 6 attachment points with the Trust attribute set TRUE in the same way
and Section 7, the corresponding processes in Section 6 and Section 7 as if they had the DHCP-Trust attribute set (see Section 4.2.2.)
will handle these messages.
4.2.2. DHCP-Trust Attribute 4.2.2. DHCP-Trust Attribute
The "DHCP-Trust Attribute" is similarly a Boolean attribute. It The "DHCP-Trust Attribute" is similarly a Boolean attribute. It
indicates whether the attached device is permitted to initiate DHCP indicates whether the attached device is permitted to initiate DHCP
Server-to-Client messages. In Figure 1, the points of attachment of Server-to-Client messages. In Figure 1, the points of attachment of
the DHCP Server and the DHCP Relay would have this attribute set the DHCP Server and the DHCP Relay would have this attribute set
TRUE, and ports that are trusted would have it set TRUE. TRUE, and attachment points that have Trust set TRUE are implicitly
treated as if DHCP-Trust is TRUE..
If the DHCP-Trust Attribute is TRUE, SAVI devices will forward DHCP If the DHCP-Trust Attribute is TRUE, SAVI devices will forward DHCP
Server-to-Client messages from the points of attachment with this Server-to-Client messages from the points of attachment with this
attribute. If the DHCP Server-to-Client messages can trigger the attribute. If the DHCP Server-to-Client messages can trigger the
state transitions, the binding setup processes specified in Section 6 state transitions, the binding setup processes specified in Section 6
and Section 7 will handle them. By default, the DHCP-Trust attribute and Section 7 will handle them. By default, the DHCP-Trust attribute
is FALSE, indicating that the attached system is not a DHCP server. is FALSE, indicating that the attached system is not a DHCP server.
A DHCPv6 implementor can refer to [I-D.ietf-opsec-dhcpv6-shield] for A DHCPv6 implementor can refer to [I-D.ietf-opsec-dhcpv6-shield] for
more details. more details.
4.2.3. DHCP-Snooping Attribute 4.2.3. DHCP-Snooping Attribute
The "DHCP-Snooping Attribute" is similarly a Boolean attribute. It The "DHCP-Snooping Attribute" is similarly a Boolean attribute. It
indicates whether bindings will be set up based on DHCP snooping. indicates whether bindings will be set up based on DHCP snooping.
If this attribute is TRUE, DHCP Client-Server messages to points of If this attribute is TRUE, DHCP Client-Server messages to points of
attachment with this attribute will trigger creation of bindings attachment with this attribute will trigger creation of bindings
based on the DHCP snooping procedure described in Section 6. If it based on the DHCP Snooping Process described in Section 6. If it is
is FALSE, either the Trust attribute must be TRUE (so that bindings FALSE, either the Trust attribute must be TRUE (so that bindings
become irrelevant) or another SAVI mechanism such as SAVI-FCFS must become irrelevant) or another SAVI mechanism such as SAVI-FCFS must
be used on the point of attachment. be used on the point of attachment.
The DHCP-Snooping attribute is configured on the DHCP Client's point The DHCP-Snooping attribute is configured on the DHCP Client's point
of attachment. This attribute can be also used on the attachments to of attachment. This attribute can be also used on the attachments to
protected Non-SAVI devices that are used by DHCP clients. In protected Non-SAVI devices that are used by DHCP clients. In
Figure 1, the attachment from the Client A to the SAVI Device A, the Figure 1, the attachment from the Client A to the SAVI Device A, the
attachment from the Client B to the SAVI Device B, and the attachment attachment from the Client B to the SAVI Device B, and the attachment
from the Non-SAVI Device 2 to the SAVI Device A can be configured from the Non-SAVI Device 2 to the SAVI Device A can be configured
with this attribute. with this attribute.
Whenever this attribute is set TRUE on a point of attachment, the
"Validating Attribute" MUST also be set TRUE.
4.2.4. Data-Snooping Attribute 4.2.4. Data-Snooping Attribute
The "Data-Snooping Attribute" is a Boolean attribute. It indicates The "Data-Snooping Attribute" is a Boolean attribute. It indicates
whether data packets from the corresponding point of attachment may whether data packets from the corresponding point of attachment may
trigger the binding setup procedure. trigger the binding setup procedure.
Data packets from points of attachment with this attribute may Data packets from points of attachment with this attribute may
trigger the setup of bindings. SAVI devices will set up bindings on trigger the setup of bindings. SAVI devices will set up bindings on
points of attachment with this attribute based on the data-triggered points of attachment with this attribute based on the data-triggered
process described in Section 7. process described in Section 7.
If the DHCP-Snooping attribute is configured on a point of If the DHCP-Snooping attribute is configured on a point of
attachment, the bindings on this attachment are set up based on DHCP attachment, the bindings on this attachment are set up based on DHCP
message snooping. However, in some scenarios, a DHCP client may use message snooping. However, in some scenarios, a DHCP client may use
a DHCP address without the DHCP address assignment procedure being a DHCP address without the DHCP address assignment procedure being
performed on its current attachment. For such attached devices, the performed on its current attachment. For such attached devices, the
Data-Snooping process, which is described in Section 7, is necessary. Data Snooping Process, which is described in Section 7, is necessary.
This attribute is configured on such attachments. The usage of this This attribute is configured on such attachments. The usage of this
attribute is further discussed in Section 7. attribute is further discussed in Section 7.
Whenever this attribute is set on an attachment, the "Validating Since some networks require DHCP deployment and others avoid it,
Attribute" MUST be set on the same attachment. Since some networks there is no obvious universal default value for the Data-Snooping
require DHCP deployment and others avoid it, there is no obvious Attribute. Hence, the Data-Snooping Attribute should default to
universal default value for the Data-Snooping Attribute. However, FALSE, and a mechanism should be implemented to conveniently set it
note that deployment of SLAAC (and therefore SAVI-FCFS) is generally to TRUE on all points of attachment for which the Trust attribute is
configuration-free, while the deployment of DHCP involves at minimum FALSE.
the deployment of a server. Hence, the Data-Snooping Attribute
should default to FALSE, and a mechanism should be implemented to
conveniently set it to TRUE on all points of attachment for which the
Trust attribute is FALSE.
4.2.5. Validating Attribute 4.2.5. Validating Attribute
The "Validating Attribute" is a Boolean attribute. It indicates The "Validating Attribute" is a Boolean attribute. It indicates
whether packets from the corresponding attachment will have their IP whether packets from the corresponding attachment will have their IP
source addresses validated based on binding entries on the source addresses validated based on binding entries on the
attachment. attachment.
If it is TRUE, packets coming from attachments with this attribute If it is TRUE, packets coming from attachments with this attribute
will be checked based on binding entries on the attachment as will be validated based on binding entries on the attachment as
specified in Section 8. If it is FALSE, they will not. Since the specified in Section 8. If it is FALSE, they will not. Since the
binding table is used in common with other SAVI algorithms, it merely binding table is used in common with other SAVI algorithms, it merely
signifies whether the check will be done, not whether it will be done signifies whether the check will be done, not whether it will be done
for SAVI-DHCP originated bindings. for SAVI-DHCP originated bindings.
This attribute is by default the inverse of the Trust attribute; This attribute is by default the inverse of the Trust attribute;
source addresses on untrusted links are validated by default. It MAY source addresses on untrusted links are validated by default. It MAY
be set FALSE by the administration. be set FALSE by the administration.
The expected use case is when SAVI is used to monitor but not block The expected use case is when SAVI is used to monitor but not block
unvalidated transmissions. The network manager, in that case, may forged transmissions. The network manager, in that case, may set the
set the DHCP-Snooping and/or Data-Snooping attribute TRUE but the DHCP-Snooping and/or Data-Snooping attribute TRUE but the Validating
VALIDATING attribute FALSE. attribute FALSE.
4.2.6. Table of Mutual Exclusions 4.2.6. Table of Mutual Exclusions
Different types of attributes may indicate mutually exclusive actions Different types of attributes may indicate mutually exclusive actions
on a packet. Mutually exclusive attributes MUST NOT be set TRUE on on a packet. Mutually exclusive attributes MUST NOT be set TRUE on
the same attachment. The compatibility of different attributes is the same attachment. The compatibility of different attributes is
listed in Figure 2. Note that although Trust and DHCP-Trust are listed in Figure 2. Note that although Trust and DHCP-Trust are
compatible, there is no need to configure DHCP-Trust to TRUE on an compatible, there is no need to configure DHCP-Trust to TRUE on an
attachment with Trust attribute TRUE. attachment with Trust attribute TRUE.
skipping to change at page 13, line 5 skipping to change at page 13, line 49
SAVI devices form a perimeter separating trusted and untrusted SAVI devices form a perimeter separating trusted and untrusted
regions of a network, as SAVI-FCFS does ( Section 2.5 of [RFC6620]). regions of a network, as SAVI-FCFS does ( Section 2.5 of [RFC6620]).
The perimeter is primarily designed for scalability. It has two The perimeter is primarily designed for scalability. It has two
implications. implications.
o SAVI devices only need to establish bindings for directly attached o SAVI devices only need to establish bindings for directly attached
clients, or clients indirectly attached through a non-SAVI clients, or clients indirectly attached through a non-SAVI
protected device, rather than all of the clients in the network. protected device, rather than all of the clients in the network.
o Each SAVI device only need to validate traffic from clients o Each SAVI device only needs to validate the source addresses in
attached to it, without checking all the traffic passing by. traffic from clients attached to it, without checking all the
traffic passing by.
Consider the example in Figure 1. The protection perimeter is formed Consider the example in Figure 1. The protection perimeter is formed
by SAVI Devices A, B and C. In this case, SAVI device B does not by SAVI Devices A, B and C. In this case, SAVI device B does not
create a binding for client A. However, because SAVI device A filters create a binding for client A. However, because SAVI device A
spoofed traffic from client A, SAVI device B can avoid receiving filters spoofed traffic from client A, SAVI device B can avoid
spoofed traffic from client A. receiving spoofed traffic from client A.
The perimeter in SAVI-DHCP is not only a perimeter for data packets, The perimeter in SAVI-DHCP is not only a perimeter for data packets,
but also a perimeter for DHCP messages. The placement of the DHCP but also a perimeter for DHCP messages. DHCP server response
Relay and DHCP Server, which are not involved in [RFC6620], is messages incoming across the perimeter will be dropped (Section 8).
related to the construction of the perimeter. The requirement on the The placement of the DHCP Relay and DHCP Server, which are not
placement and configuration of DHCP Relay and DHCP Server are involved in [RFC6620], is related to the construction of the
discussed in Section 4.3.3. perimeter. The requirement on the placement and configuration of
DHCP Relay and DHCP Server are discussed in Section 4.3.3.
4.3.2. SAVI-DHCP Perimeter Configuration Guideline 4.3.2. SAVI-DHCP Perimeter Configuration Guideline
A perimeter separating trusted and untrusted regions of the network A perimeter separating trusted and untrusted regions of the network
is formed as follows: is formed as follows:
(1) Configure the Validating and DHCP-Snooping attributes TRUE on (1) Configure the Validating and DHCP-Snooping attributes TRUE on
the direct attachments of all DHCP clients. the direct attachments of all DHCP clients.
(2) Configure the Validating and DHCP-Snooping attributes TRUE on (2) Configure the Validating and DHCP-Snooping attributes TRUE on
skipping to change at page 13, line 48 skipping to change at page 14, line 46
on their attachments. on their attachments.
(5) Configure the DHCP-Trust attribute TRUE on the direct (5) Configure the DHCP-Trust attribute TRUE on the direct
attachments to trusted DHCP relays and servers. attachments to trusted DHCP relays and servers.
In this way, the points of attachments with the Validating attribute In this way, the points of attachments with the Validating attribute
TRUE (and generally together with attachments of unprotected devices) TRUE (and generally together with attachments of unprotected devices)
on SAVI devices can form a perimeter separating DHCP clients and on SAVI devices can form a perimeter separating DHCP clients and
trusted devices. Data packet checks are only performed on the trusted devices. Data packet checks are only performed on the
perimeter. The perimeter is also a perimeter for DHCP messages. The perimeter. The perimeter is also a perimeter for DHCP messages. The
DHCP-Trust attribute is only TRUE on the inside links of the DHCP-Trust attribute is only TRUE on links inside the perimeter.
perimeter. Only DHCP server-to-client messages originated within the Only DHCP Server-to-Client messages originated within the perimeter
perimeter are trusted. are trusted.
4.3.3. On the Placement of the DHCP Server and Relay 4.3.3. On the Placement of the DHCP Server and Relay
As a result of the configuration guideline, SAVI devices only trust As a result of the configuration guidelines, SAVI devices only trust
DHCP Server-to-Client messages originated inside the perimeter. DHCP Server-to-Client messages originated inside the perimeter.
Thus, the trusted DHCP Relays and DHCP Servers must be placed within Thus, the trusted DHCP Relays and DHCP Servers must be placed within
the perimeter. DHCP server-to-client messages will be filtered on the perimeter. DHCP Server-to-Client messages will be filtered on
the perimeter. Server-to-relay messages will not be filtered, as the perimeter. Server-to-relay messages will not be filtered, as
they are within the perimeter. In this way, DHCP server-to-client they are within the perimeter. In this way, DHCP Server-to-Client
messages from bogus DHCP servers are filtered on the perimeter, messages from bogus DHCP servers are filtered on the perimeter,
having entered through untrusted points of attachment. The SAVI having entered through untrusted points of attachment. The SAVI
devices are protected from forged DHCP messages. devices are protected from forged DHCP messages.
DHCP server-to-client messages arriving at the perimeter from outside DHCP Server-to-Client messages arriving at the perimeter from outside
the perimeter are not trusted. There is no distinction between a the perimeter are not trusted. There is no distinction between a
DHCP server owned and operated by the correct administration but DHCP server owned and operated by the correct administration but
outside the SAVI perimeter and a bogus DHCP server. For example, in outside the SAVI perimeter and a bogus DHCP server. For example, in
Figure 1, DHCP server A is valid, but it is attached to Non-SAVI Figure 1, DHCP server A is valid, but it is attached to Non-SAVI
device 1. A bogus DHCP server is also attached Non-SAVI device 1. device 1. A bogus DHCP server is also attached Non-SAVI device 1.
While one could imagine a scenario in which the valid one had a While one could imagine a scenario in which the valid one had a
statistically configured port number and MAC address, and therefore a statistically configured port number and MAC address, and therefore a
binding, by default SAVI-DHCP cannot distinguish whether a message binding, by default SAVI-DHCP cannot distinguish whether a message
received from the port of Non-SAVI device 1 is from DHCP server A or received from the port of Non-SAVI device 1 is from DHCP server A or
the bogus DHCP server. If the DHCP server A is contained in the the bogus DHCP server. If the DHCP server A is contained in the
skipping to change at page 14, line 49 skipping to change at page 16, line 5
In common deployment practice, the traffic from the unprotected In common deployment practice, the traffic from the unprotected
network is treated as trustworthy, which is to say that it is not network is treated as trustworthy, which is to say that it is not
filtered. In such a case, the Trust attribute can be set TRUE on the filtered. In such a case, the Trust attribute can be set TRUE on the
unprotected link. If Non-SAVI devices, or a number of connected Non- unprotected link. If Non-SAVI devices, or a number of connected Non-
SAVI devices, are only attached to SAVI devices and unprotected SAVI devices, are only attached to SAVI devices and unprotected
devices, their attachment to SAVI devices can have the Trust devices, their attachment to SAVI devices can have the Trust
attribute set TRUE. Then an unclosed perimeter will be formed, as attribute set TRUE. Then an unclosed perimeter will be formed, as
illustrated in Figure 3. illustrated in Figure 3.
To configure such a perimeter, at minimum the DHCP messages from
unprotected networks MUST be ensured to be trustworthy. Achieving
this is beyond the scope of this document.
| . . Protection | | . . Protection |
| | | Perimeter | | | | Perimeter |
| | | | | | | |
| Unprotected | | Unprotected | | Unprotected | | Unprotected |
| Link | | Link | | Link | | Link |
| | | | | | | |
| | | | | | | |
| +--------+ +--------+ +--------+ | | +----+---+ +----+---+ +--------+ |
| |SAVI |----|Non-SAVI|----|SAVI | | | |SAVI +----+Non-SAVI+----+SAVI | |
| |Device | |Device | |Device | | | |Device | |Device | |Device | |
| +--------+ +--------+ +--------+ | | +----+---+ +--------+ +----+---+ |
| | | | | | | |
\__________________________________________________/ \_____________+___________________________+________/
| | | |
| | | |
+--------+ +--------+ +--------+ +--------+
|DHCP | |DHCP | |DHCP | |DHCP |
|Client | |Client | |Client | |Client |
+--------+ +--------+ +--------+ +--------+
Figure 3: Alternative Perimeter Configuration Figure 3: Alternative Perimeter Configuration
4.3.5. Considerations regarding Binding Anchors 4.3.5. Considerations regarding Binding Anchors
The strength of this binding-based mechanism depends on the strength The strength of this binding-based mechanism depends on the strength
of the binding anchor. The sample binding anchors in [RFC7039] have of the binding anchor. The sample binding anchors in [RFC7039] have
the property that they associate an IP address with a direct physical the property that they associate an IP address with a direct physical
or secure virtual interface such as a switch port, a subscriber or secure virtual interface such as a switch port, a subscriber
association, or a security association. In addition, especially in association, or a security association. In addition, especially in
the case that a protected non-SAVI device such as a desktop switch or the case that a protected non-SAVI device such as a desktop switch or
a hub is between the client device and the SAVI switch, they MAY be a hub is between the client and SAVI devices, they MAY be extended to
extended to also include a MAC address or other link-layer attribute. also include a MAC address or other link-layer attribute. In short,
In short, a binding anchor is intended to associate an IP address a binding anchor is intended to associate an IP address with
with something unspoofable that identifies a single client system or something unspoofable that identifies a single client system or one
one of its interfaces; this may be a physical or virtual interface or of its interfaces; this may be a physical or virtual interface or
that plus disambiguating link-layer information. that plus disambiguating link-layer information.
If the binding anchor is spoofable, such as a plain MAC address, or If the binding anchor is spoofable, such as a plain MAC address, or
non-exclusive, such as a switch port extended using a non-SAVI non-exclusive, such as a switch port extended using a non-SAVI
device, an attacker can use a forged binding anchor to evade device, an attacker can use a forged binding anchor to evade
validation. Indeed, using a binding anchor that can be easily validation. Indeed, using a binding anchor that can be easily
spoofed can lead to worse outcomes than allowing IP spoofing traffic. spoofed can lead to worse outcomes than allowing spoofed IP traffic.
Thus, a SAVI device MUST use a non-spoofable and exclusive binding Thus, a SAVI device MUST use a non-spoofable and exclusive binding
anchor. anchor.
4.4. Other Device Configuration 4.4. Other Device Configuration
In addition to a possible binding anchor configuration specified in In addition to a possible binding anchor configuration specified in
Section 4.2, an implementation has the following configuration Section 4.2, an implementation has the following configuration
requirements: requirements:
(1) Address configuration. For DHCPv4: the client of a SAVI device (1) Address configuration. For DHCPv4: the SAVI device MUST have an
MUST have an IPv4 address. For DHCPv6: the client of a SAVI IPv4 address. For DHCPv6: the client of a SAVI device MUST have
device MUST have a link-local address; when the DHCPv6 server is a link-local address; when the DHCPv6 server is not on the same
not on the same link as the SAVI device, the SAVI device MUST link as the SAVI device, the SAVI device MUST also have an IPv6
also have a global IPv6 address. address of at least the same scope as the DHCPv6 Server.
(2) DHCP server address configuration: a SAVI device MUST store the (2) DHCP server address configuration: a SAVI device MUST store the
list of the DHCP server addresses that it could contact during a list of the DHCP server addresses that it could contact during a
Lease query process. Lease query process.
(3) A SAVI device may also require security parameters, such as pre-
configured keys to establish a secure connection for the Lease
query process [RFC4388][RFC5007] connection.
5. Binding State Table (BST) 5. Binding State Table (BST)
The Binding State Table, which may be implemented centrally in the The Binding State Table, which may be implemented centrally in the
switch or distributed among its ports, is used to contain the switch or distributed among its ports, is used to contain the
bindings between the IP addresses assigned to the attachments and the bindings between the IP addresses assigned to the attachments and the
corresponding binding anchors of the attachments. Note that in this corresponding binding anchors of the attachments. Note that in this
description, there is a binding entry for each IPv4 or IPv6 address description, there is a binding entry for each IPv4 or IPv6 address
associated with each binding anchor, and there may be several of each associated with each binding anchor, and there may be several of each
such address, especially if the port is extended using a protected such address, especially if the port is extended using a protected
non-SAVI device. Each binding entry, has 5 fields: non-SAVI device. Each binding entry, has 5 fields:
o Binding Anchor(Anchor): the binding anchor, i.e., a physical and/ o Binding Anchor(Anchor): the binding anchor, i.e., one or more
or link-layer property of the attachment. physical and/ or link-layer properties of the attachment.
o IP Address(Address): the IPv4 or IPv6 address assigned to the o IP Address(Address): the IPv4 or IPv6 address assigned to the
attachment by DHCP. attachment by DHCP.
o State: the state of the binding. Possible values of this field o State: the state of the binding. Possible values of this field
are listed in Section 6.2 and Section 7.3. are listed in Section 6.2 and Section 7.3.
o Lifetime: the remaining seconds of the binding. Internally, this o Lifetime: the remaining seconds of the binding. Internally, this
MAY be stored as the timestamp value at which the lifetime MAY be stored as the timestamp value at which the lifetime
expires. expires.
o TID: the Transaction ID (TID) ( [RFC2131] [RFC3315]) of the o TID: the Transaction ID (TID) ( [RFC2131] [RFC3315]) of the
corresponding DHCP transaction. TID field is used to associate corresponding DHCP transaction. TID field is used to associate
DHCP Server-to-Client messages with corresponding binding entries. DHCP Server-to-Client messages with corresponding binding entries.
o Timeouts: the number of timeouts that expired in the current state
(only used in Data Snooping Process, see Section 7.)
The IA is not present in the BST for three reasons: The IA is not present in the BST for three reasons:
o The lease of each address in one IA is assigned separately. o The lease of each address in one IA is assigned separately.
o When the binding is set up based on data-snooping, the IA cannot o When the binding is set up based on data snooping, the IA cannot
be recovered from the lease query protocol. be recovered from the lease query protocol.
o DHCPv4 does not define an IA. o DHCPv4 does not define an IA.
An instance of this table is shown in Figure 4. An example of such a table is shown in Figure 4.
+---------+----------+----------+-----------+-------+ +---------+----------+-----------+-----------+--------+----------+
| Anchor | Address | State | Lifetime |TID | | Anchor | Address | State | Lifetime | TID | Timeouts |
+---------+----------+----------+-----------+-------+ +---------+----------+-----------+-----------+--------+----------+
| Port_1 | IP_1 | BOUND | 65535 |TID_1 | | Port_1 | IP_1 | BOUND | 65535 | TID_1 | 0 |
+---------+----------+----------+-----------+-------+ +---------+----------+-----------+-----------+--------+----------+
| Port_1 | IP_2 | BOUND | 10000 |TID_2 | | Port_1 | IP_2 | BOUND | 10000 | TID_2 | 0 |
+---------+----------+----------+-----------+-------+ +---------+----------+-----------+-----------+--------+----------+
| Port_2 | IP_3 |INIT_BIND | 1 |TID_3 | | Port_2 | IP_3 | INIT_BIND | 1 | TID_3 | 0 |
+---------+----------+----------+-----------+-------+ +---------+----------+-----------+-----------+--------+----------+
Figure 4: Instance of BST Figure 4: Example Binding State Table
6. DHCP Snooping Process 6. DHCP Snooping Process
This section specifies the process of setting up bindings based on This section specifies the process of setting up bindings based on
DHCP snooping. This process is illustrated using a state machine. DHCP snooping. This process is illustrated using a state machine.
6.1. Rationale 6.1. Rationale
The rationale of the DHCP Snooping Process is that if a DHCP client The rationale of the DHCP Snooping Process is that if a DHCP client
is legitimately using a DHCP-assigned address, the DHCP address is legitimately using a DHCP-assigned address, the DHCP address
assignment procedure that assigns the IP address to the client must assignment procedure that assigns the IP address to the client must
have been performed on the client's point of attachment. This basis have been performed via the client's point of attachment. This
works when the SAVI device is always on the path(s) from the DHCP assumption works when the SAVI device is always on the path(s) from
client to the DHCP server(s)/relay(s). Without considering the the DHCP client to the DHCP server(s)/relay(s). Without considering
movement of DHCP clients, the SAVI device should be the cut vertex the movement of DHCP clients, the SAVI device should be the cut
whose removal will separate the DHCP client and the remaining network vertex whose removal will separate the DHCP client and the remaining
containing the DHCP server(s)/ and relay(s). For most of the network containing the DHCP server(s)/ and relay(s). For most of the
networks whose topologies are simple, it is possible to deploy this networks whose topologies are simple, it is possible to deploy this
SAVI function at proper devices to meet this requirement. SAVI function at proper devices to meet this requirement.
However, if there are multiple paths from a DHCP client to the DHCP However, if there are multiple paths from a DHCP client to the DHCP
server and the SAVI device is only on one of them, there is an server and the SAVI device is only on one of them, there is an
obvious failure case: the SAVI device may not be able to snoop the obvious failure case: the SAVI device may not be able to snoop the
DHCP procedure. Host movement may also make this requirement DHCP procedure. Host movement may also make this requirement
difficult to meet. For example, when a DHCP client moves from one difficult to meet. For example, when a DHCP client moves from one
attachment to another attachment in the same network, it may fail to attachment to another attachment in the same network, it may fail to
reinitialize its interface or send a Confirm message because of reinitialize its interface or send a Confirm message because of
incomplete protocol implementation. Thus, there can be scenarios in incomplete protocol implementation. Thus, there can be scenarios in
which only performing this DHCP snooping process is insufficient to which only performing this DHCP Snooping Process is insufficient to
set up bindings for all the valid DHCP addresses. These exceptions set up bindings for all the valid DHCP addresses. These exceptions
and the solutions are discussed in Section 7. and the solutions are discussed in Section 7.
6.2. Binding States Description 6.2. Binding States Description
Following binding states are present in this process and the Following binding states are present in this process and the
corresponding state machine: corresponding state machine:
NO_BIND: No binding has been set up. NO_BIND: No binding has been set up.
INIT_BIND: A potential binding has been set up. INIT_BIND: A potential binding has been set up.
BOUND: The binding has been set up. BOUND: The binding has been set up.
6.3. Events 6.3. Events
This section describes events in this process and the corresponding This section describes events in this process and the corresponding
state machine. 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 6.3.1. Timer Expiration Event
EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires. EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires.
6.3.2. Control Message Arriving Events 6.3.2. Control Message Arriving Events
EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is
received. received.
skipping to change at page 19, line 5 skipping to change at page 20, line 16
option is received. option is received.
EVE_DHCP_REPLY: A DHCPv4 ACK or a DHCPv6 Reply 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 EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is
received. received.
EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is
received. received.
EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY_REPLY (refer to EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY-REPLY (refer to
section 4.3.3 of [RFC5007]) is received. section 4.3.3 of [RFC5007]) is received.
Note: the events listed here do not cover all the DHCP messages in Note: the events listed here do not cover all the DHCP messages in
section 3. The messages which do not really determine address usage Section 3. The messages which do not really determine address usage
(DHCPv4 Discover, DHCPv4 Inform, DHCPv6 Solicit without Rapid Commit, (DHCPv4 Discover, DHCPv4 Inform, DHCPv6 Solicit without Rapid Commit,
DHCPv6 Information-Request, DHCPv4 Offer, DHCPv6 Advertise, DHCPv6 DHCPv6 Information-Request, DHCPv4 Offer, DHCPv6 Advertise, DHCPv6
Reconfigure), and which are not necessary to snoop (DHCPv4 NAK, refer Reconfigure), and which are not necessary to snoop (DHCPv4 NAK, refer
to section 6.4.2.1), are not included. to section 6.4.2.1), are not included. Note also that DHCPv4
DHCPLEASEQUERY is not used in the DHCP Snooping process to avoid
confusion with Section 7. Also since the LEASEQUERY should have been
originated by the SAVI Device itself, the destination check should
verify that the message is directed to this SAVI device - and it
should not be forwarded once it has been processed here.
Moreover, only if a DHCP message can pass the following checks, the Moreover, only if a DHCP message can pass the following checks, the
corresponding event is regarded as a valid event: corresponding event is regarded as a valid event:
o Attribute check: the DHCP Server-to-Client messages and o Attribute check: the DHCP Server-to-Client messages and
LEASEQUERY_REPLY should be from attachments with DHCP-Trust LEASEQUERY-REPLY should be from attachments with DHCP-Trust
attribute; the DHCP Client-Server messages should be from attribute; the DHCP Client-Server messages should be from
attachments with DHCP-Snooping attribute. attachments with DHCP-Snooping attribute.
o Destination check: the DHCP Server-to-Client messages should be o Destination check: the DHCP Server-to-Client messages should be
destined to attachments with DHCP-Snooping attribute. This check destined to attachments with DHCP-Snooping attribute. This check
is performed to ensure the binding is set up on the SAVI device is performed to ensure the binding is set up on the SAVI device
which is nearest to the destination client. which is nearest to the destination client.
o Binding anchor check: the DHCP Client-Server messages which may o Binding anchor check: the DHCP Client-Server messages which may
trigger modification or removal of an existing binding entry must trigger modification or removal of an existing binding entry must
skipping to change at page 20, line 22 skipping to change at page 21, line 37
6.4.1.1. Event: EVE_DHCP_REQUEST - A DHCPv4 Request or a DHCPv6 Request 6.4.1.1. Event: EVE_DHCP_REQUEST - A DHCPv4 Request or a DHCPv6 Request
message is received message is received
The SAVI device MUST forward the message. The SAVI device MUST forward the message.
The SAVI device will generate an entry in the BST. The Binding The SAVI device will generate an entry in the BST. The Binding
anchor field is set to the binding anchor of the attachment from anchor field is set to the binding anchor of the attachment from
which the message is received. The State field is set to INIT_BIND. which the message is received. The State field is set to INIT_BIND.
The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID
field is set to the TID of the message. If the message is DHCPv4 field is set to the TID of the message. If the message is DHCPv4
Request or DHCPv4 Reboot, the Address field can be set to the address Request, the Address field can be set to the address to request,
to request, i.e., the 'requested IP address'. An example of the i.e., the 'requested IP address'. An example of the entry is
entry is illustrated in Figure 5. illustrated in Figure 5.
+---------+-------+---------+-----------------------+-------+ +--------+-------+---------+-----------------------+-----+----------+
| Anchor |Address| State | Lifetime |TID | | Anchor |Address| State | Lifetime | TID | Timeouts |
+---------+-------+---------+-----------------------+-------+ +--------+-------+---------+-----------------------+-----+----------+
| Port_1 | |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | | Port_1 | |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 0 |
+---------+-------+---------+-----------------------+-------+ +--------+-------+---------+-----------------------+-----+----------+
Figure 5: Binding entry in BST on Request/Rapid Commit/Reboot Figure 5: Binding entry in BST on Request/Rapid Commit/Reboot
triggered initialization triggered initialization
Resulting state: INIT_BIND - A potential binding has been set up Resulting state: INIT_BIND - A potential binding has been set up
6.4.1.2. Event: EVE_DHCP_REBOOT - A DHCPv4 Reboot message is received 6.4.1.2. Event: EVE_DHCP_REBOOT - A DHCPv4 Reboot message is received
The SAVI device MUST forward the message. The SAVI device MUST forward the message.
The SAVI device will generate an entry in the BST. The Binding The SAVI device will generate an entry in the BST. The Binding
anchor field is set to the binding anchor of the attachment from anchor field is set to the binding anchor of the attachment from
which the message is received. The State field is set to INIT_BIND. which the message is received. The State field is set to INIT_BIND.
The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID
field is set to the TID of the message. If the message is DHCPv4 field is set to the TID of the message. If the message is DHCPv4
Request or DHCPv4 Reboot, the Address field can be set to the address Reboot, the Address field can be set to the address to request, i.e.,
to request, i.e., the 'requested IP address'. An example of the the 'requested IP address'. An example of the entry is illustrated
entry is illustrated in Figure 5. in Figure 5.
Resulting state: INIT_BIND - A potential binding has been set up Resulting state: INIT_BIND - A potential binding has been set up
6.4.1.3. Event: EVE_DHCP_SOLICIT_RC - A DHCPv6 Solicitation message 6.4.1.3. Event: EVE_DHCP_SOLICIT_RC - A DHCPv6 Solicitation message
with Rapid Commit option is received with Rapid Commit option is received
The SAVI device MUST forward the message. The SAVI device MUST forward the message.
The SAVI device will generate an entry in the BST. The Binding The SAVI device will generate an entry in the BST. The Binding
anchor field is set to the binding anchor of the attachment from anchor field is set to the binding anchor of the attachment from
which the message is received. The State field is set to INIT_BIND. which the message is received. The State field is set to INIT_BIND.
The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID
field is set to the TID of the message. If the message is DHCPv4 field is set to the TID of the message. An example of the entry is
Request or DHCPv4 Reboot, the Address field can be set to the address illustrated in Figure 5.
to request, i.e., the 'requested IP address'. An example of the
entry is illustrated in Figure 5.
Resulting state: INIT_BIND - A potential binding has been set up 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 6.4.1.4. Event: EVE_DHCP_CONFIRM - A DHCPv6 Confirm message is received
The SAVI device MUST forward the message. The SAVI device MUST forward the message.
The SAVI device will generate corresponding entries in the BST for The SAVI device will generate corresponding entries in the BST for
each address in each Identity Association (IA) option of the Confirm each address in each Identity Association (IA) option of the Confirm
message. The Binding anchor field is set to the binding anchor of message. The Binding anchor field is set to the binding anchor of
the attachment from which the message is received. The State field the attachment from which the message is received. The State field
is set to INIT_BIND. The Lifetime field is set to be is set to INIT_BIND. The Lifetime field is set to be
MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the
message. The Address field is set to the address(es) to confirm. An message. The Address field is set to the address(es) to confirm. An
example of the entries is illustrated in Figure 6. example of the entries is illustrated in Figure 6.
+---------+--------+---------+-----------------------+-------+ +--------+-------+---------+-----------------------+-----+----------+
| Anchor | Address| State | Lifetime |TID | | Anchor |Address| State | Lifetime | TID | Timeouts |
+---------+--------+---------+-----------------------+-------+ +--------+-------+---------+-----------------------+-----+----------+
| Port_1 | Addr1 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | | Port_1 | Addr1 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 0 |
+---------+--------+---------+-----------------------+-------+ +--------+-------+---------+-----------------------+-----+----------+
| Port_1 | Addr2 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | | Port_1 | Addr2 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 0 |
+---------+--------+---------+-----------------------+-------+ +--------+-------+---------+-----------------------+-----+----------+
Figure 6: Binding entry in BST on Confirm triggered initialization Figure 6: Binding entry in BST on Confirm triggered initialization
Resulting state: INIT_BIND - A potential binding has been set up Resulting state: INIT_BIND - A potential binding has been set up
6.4.1.5. Events that cannot happen in the NO_BIND state 6.4.1.5. Events that cannot happen in the NO_BIND state
o EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires o EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires
o EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is o EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is
skipping to change at page 22, line 16 skipping to change at page 23, line 35
received received
o EVE_DHCP_REPLY: A DHCPv4 ACK or a DHCPv6 Reply message is received o EVE_DHCP_REPLY: A DHCPv4 ACK or a DHCPv6 Reply message is received
o EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is o EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is
received received
o EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is o EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is
received received
o EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY_REPLY is o EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY-REPLY is
received received
These cannot happen because they are each something that happens These cannot happen because they are each something that happens
AFTER a binding has been created. AFTER a binding has been created.
6.4.2. Initial State: INIT_BIND - A potential binding has been set up 6.4.2. Initial State: INIT_BIND - A potential binding has been set up
6.4.2.1. Event: EVE_DHCP_REPLY - A DHCPv4 ACK or a DHCPv6 Reply message 6.4.2.1. Event: EVE_DHCP_REPLY - A DHCPv4 ACK or a DHCPv6 Reply message
is received is received
skipping to change at page 23, line 37 skipping to change at page 25, line 7
the LEASEQUERY message, a pre-configured lifetime the LEASEQUERY message, a pre-configured lifetime
DHCP_DEFAULT_LEASE MUST be set on the corresponding entry. DHCP_DEFAULT_LEASE MUST be set on the corresponding entry.
(Note: it is RECOMMENDED to use T1 configured on DHCP servers (Note: it is RECOMMENDED to use T1 configured on DHCP servers
as the DHCP_DEFAULT_LEASE.) as the DHCP_DEFAULT_LEASE.)
Note: the SAVI devices do not check if the assigned addresses are Note: the SAVI devices do not check if the assigned addresses are
duplicated because in SAVI-DHCP scenarios, the DHCP servers are the duplicated because in SAVI-DHCP scenarios, the DHCP servers are the
only source of valid addresses. However, the DHCP servers should be only source of valid addresses. However, the DHCP servers should be
configured to make sure no duplicated addresses are assigned. configured to make sure no duplicated addresses are assigned.
+---------+----------+-------+------------------------+-------+ +--------+-------+-------+------------------------+-----+----------+
| Anchor | Address | State | Lifetime |TID | | Anchor |Address| State | Lifetime | TID | Timeouts |
+---------+----------+-------+------------------------+-------+ +--------+-------+-------+------------------------+-----+----------+
| Port_1 | Addr1 | BOUND | 2*MAX_LEASEQUERY_DELAY |TID | | Port_1 | Addr1 | BOUND | 2*MAX_LEASEQUERY_DELAY | TID | 0 |
+---------+----------+-------+------------------------+-------+ +--------+-------+-------+------------------------+-----+----------+
| Port_1 | Addr2 | BOUND | 2*MAX_LEASEQUERY_DELAY |TID | | Port_1 | Addr2 | BOUND | 2*MAX_LEASEQUERY_DELAY | TID | 0 |
+---------+----------+-------+------------------------+-------+ +--------+-------+-------+------------------------+-----+----------+
Figure 7: From INIT_BIND to BOUND on DHCP Reply in response to Figure 7: From INIT_BIND to BOUND on DHCP Reply in response to
Confirm Confirm
+---------+----------+-------+------------------------+-------+ Transition
| Anchor | Address | State | Lifetime |TID | +--------+-------+-------+------------------------+-----+----------+
+---------+----------+-------+------------------------+-------+ | Anchor |Address| State | Lifetime | TID | Timeouts |
| Port_1 | Addr1 | BOUND |Lease time+ |TID | +--------+-------+-------+------------------------+-----+----------+
| | | |MAX_DHCP_RESPONSE_TIME | | | Port_1 | Addr1 | BOUND |Lease time+ | TID | 0 |
+---------+----------+-------+------------------------+-------+ | | | |MAX_DHCP_RESPONSE_TIME | | |
| Port_1 | Addr2 | BOUND |Lease time+ |TID | +--------+-------+-------+------------------------+-----+----------+
| | | |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 Figure 8: From INIT_BIND to BOUND on DHCP Reply in response to
Request Request
Resulting state: BOUND - The binding has been set up Resulting state: BOUND - The binding has been set up
6.4.2.2. Event: EVE_ENTRY_EXPIRE - The lifetime of a binding entry 6.4.2.2. Event: EVE_ENTRY_EXPIRE - The lifetime of a binding entry
expires expires
The entry MUST be deleted from BST. The entry MUST be deleted from BST.
skipping to change at page 25, line 14 skipping to change at page 26, line 27
o EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with Rapid o EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with Rapid
Commit option is received Commit option is received
o EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is o EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is
received received
o EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is o EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is
received received
o EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY_REPLY is o EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY-REPLY is
received received
In each case, the message MUST be forwarded. In each case, the message MUST be forwarded.
Resulting state: INIT_BIND - A potential binding has been set up Resulting state: INIT_BIND - A potential binding has been set up
6.4.3. Initial State: BOUND - The binding has been set up 6.4.3. Initial State: BOUND - The binding has been set up
6.4.3.1. Event: EVE_ENTRY_EXPIRE - The lifetime of a binding entry 6.4.3.1. Event: EVE_ENTRY_EXPIRE - The lifetime of a binding entry
expires expires
skipping to change at page 27, line 24 skipping to change at page 28, line 36
6.4.3.7. Event: EVE_DHCP_LEASEQUERY - A successful DHCPv6 6.4.3.7. Event: EVE_DHCP_LEASEQUERY - A successful DHCPv6
LEASEQUERY_REPLY is received LEASEQUERY_REPLY is received
The message MUST be forwarded. The message MUST be forwarded.
The message should be in response to the Lease query message sent in The message should be in response to the Lease query message sent in
Section 6.4.2. The related binding entry can be determined based on Section 6.4.2. The related binding entry can be determined based on
the address in the IA Address option in the Lease query-reply the address in the IA Address option in the Lease query-reply
message. The Lifetime field of the corresponding binding entry is message. The Lifetime field of the corresponding binding entry is
set to the sum of the lease time in the LEASEQUERY_REPLY message and set to the sum of the lease time in the LEASEQUERY-REPLY message and
MAX_DHCP_RESPONSE_TIME. MAX_DHCP_RESPONSE_TIME.
Resulting state: BOUND: The binding has been set up Resulting state: BOUND: The binding has been set up
6.4.3.8. Events not processed in the state BOUND 6.4.3.8. Events not processed in the state BOUND
The following events are ignored if received while the indicated The following events are ignored if received while the indicated
entry is in the state BOUND. Any required action will be the result entry is in the state BOUND. Any required action will be the result
of the next message in the client/server exchange. of the next message in the client/server exchange.
skipping to change at page 27, line 41 skipping to change at page 29, line 4
The following events are ignored if received while the indicated The following events are ignored if received while the indicated
entry is in the state BOUND. Any required action will be the result entry is in the state BOUND. Any required action will be the result
of the next message in the client/server exchange. of the next message in the client/server exchange.
o EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is o EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is
received received
o EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received o EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received
o EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received o EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received
o EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with Rapid o EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with Rapid
Commit option is received Commit option is received
6.4.4. Table of State Machine 6.4.4. Table of State Machine
The main state transits are listed as follows. Note that not all the The main state transits are listed as follows. Note that not all the
details are specified in the table and the diagram. details are specified in the table and the diagram.
State Event Action Next State State Event Action Next State
NO_BIND RQ/RC/CF/RE Generate entry INIT_BIND NO_BIND RQ/RC/CF/RE Generate entry INIT_BIND
INIT_BIND RPL Record lease time BOUND INIT_BIND RPL Record lease time BOUND
(send lease query if no lease) (send lease query if no lease)
INIT_BIND EVE_ENTRY_EXPIRE Remove entry NO_BIND INIT_BIND EVE_ENTRY_EXPIRE Remove entry NO_BIND
BOUND RLS/DCL Remove entry NO_BIND BOUND RLS/DCL Remove entry NO_BIND
BOUND EVE_ENTRY_EXPIRE Remove entry NO_BIND BOUND EVE_ENTRY_EXPIRE Remove entry NO_BIND
BOUND RPL Set new lifetime BOUND BOUND RPL Set new lifetime BOUND
BOUND LQR Record lease time BOUND BOUND LQR Record lease time BOUND
Figure 9: Table of Transit Figure 9: State Transition Table
RQ: EVE_DHCP_REQUEST RQ: EVE_DHCP_REQUEST
CF: EVE_DHCP_CONFIRM CF: EVE_DHCP_CONFIRM
RC: EVE_DHCP_SOLICIT_RC RC: EVE_DHCP_SOLICIT_RC
RE: EVE_DHCP_REBOOT RE: EVE_DHCP_REBOOT
RPL: EVE_DHCP_REPLY RPL: EVE_DHCP_REPLY
DCL: EVE_DHCP_DECLINE DCL: EVE_DHCP_DECLINE
RLS: EVE_DHCP_RELEASE RLS: EVE_DHCP_RELEASE
LQR: EVE_DHCP_LEASEQUERY LQR: EVE_DHCP_LEASEQUERY
+-------------+ +-------------+
| | | |
/---------| NO_BIND |<----------\ /--------+ NO_BIND |<--------\
| ------>| | | | ----->| | |
| | +-------------+ |EVE_DHCP_RELEASE | | +-------------+ |EVE_DHCP_RELEASE
EVE_DHCP_REQUEST | | |EVE_DHCP_DECLINE EVE_DHCP_REQUEST | | |EVE_DHCP_DECLINE
EVE_DHCP_CONFIRM | |EVE_ENTRY_EXPIRE |EVE_ENTRY_EXPIRE EVE_DHCP_CONFIRM | |EVE_ENTRY_EXPIRE |EVE_ENTRY_EXPIRE
EVE_DHCP_SOLICIT_RC| | | EVE_DHCP_SOLICIT_RC| | |
EVE_DHCP_REBOOT | | | EVE_DHCP_REBOOT | | |
| | | | | |
| | | | | |
v | | v | |
+-------------+ +------------+ +-------------+ +------------+
| | EVE_DHCP_REPLY | | | | EVE_DHCP_REPLY | |
| INIT_BIND ------------------------>| BOUND |<-\ | INIT_BIND --------------------->| BOUND |<-\
| | | | | | | | | |
+-------------+ +------------+ | +-------------+ +------------+ |
| | | |
\--------/ \--------/
EVE_DHCP_REPLY EVE_DHCP_REPLY
EVE_DHCP_LEASEQUERY EVE_DHCP_LEASEQUERY
Figure 10: Diagram of Transit Figure 10: Diagram of Transit
7. Data Snooping Process 7. Data Snooping Process
7.1. Scenario 7.1. Scenario
The rationale of the DHCP Snooping Process specified in Section 6 is The rationale of the DHCP Snooping Process specified in Section 6 is
that if a DHCP client's use of a DHCP address is legitimate, the that if a DHCP client's use of a DHCP address is legitimate, the
corresponding DHCP address assignment procedure must have been corresponding DHCP address assignment procedure must have been
finished on the attachment of the DHCP client. This is the case finished during the attachment of the DHCP client. This is the case
stands when the SAVI device is persistently on the path(s) from the when the SAVI device is continuously on the path(s) from the DHCP
DHCP client to the DHCP server(s)/relay(s). However, there are two client to the DHCP server(s)/relay(s). However, there are two cases
case when this does not work: in which this does not work:
o Multiple paths: there is more than one feasible link-layer paths o Multiple paths: there is more than one feasible link-layer path
from the client to the DHCP server/relay, and the SAVI device is from the client to the DHCP server/relay, and the SAVI device is
not on everyone of them. The client may get its address through not on every one of them. The client may get its address through
one of the paths not passing by the SAVI device, but packets from one of the paths does not pass through the SAVI device, but
the client can travel through paths that pass through the SAVI packets from the client can travel on paths that pass through the
device. Because the SAVI device could not snoop the DHCP packet SAVI device, such as when the path through the link layer network
exchange procedure, the DHCP snooping procedure cannot set up the changes. Because the SAVI device could not snoop the DHCP packet
exchange procedure, the DHCP Snooping Process cannot set up the
corresponding binding. corresponding binding.
o Dynamic path: there is only one feasible link-layer path from the o Dynamic path: there is only one feasible link-layer path from the
client to the DHCP server/relay, but the path is dynamic due to client to the DHCP server/relay, but the path is dynamic due to
topology change (for example, some link turns broken due to topology change (for example, some link becomes broken due to
failure or as planned) or link-layer path change. This situation failure or some planned change) or link-layer path change. This
also covers the local-link movement of clients without address situation also covers the local-link movement of clients without
confirm/re-configuration process. For example, a host changes its address confirm/re-configuration process. For example, a host
attached switch port in a very short time. In such cases, the changes its attached switch port in a very short time. In such
DHCP snooping process will not set up the corresponding binding. cases, the DHCP Snooping Process will not set up the corresponding
binding.
Data Snooping Process prevents permanently blocking legitimate The Data Snooping Process can avoid the permanent blocking of
traffic in case of these two exceptions. This process is performed legitimate traffic in case one of these two exceptions occurs. This
on attachments with the Data-Snooping attribute. Data packets process is performed on attachments with the Data-Snooping attribute.
without matching binding entry may trigger this process to set up Data packets without a matching binding entry may trigger this
bindings. process to set up bindings.
Snooping data traffic introduces considerable burden on the processor Snooping data traffic introduces considerable burden on the processor
and ASIC-to-Processor bandwidth of SAVI devices. Because of the and ASIC-to-Processor bandwidth of SAVI devices. Because of the
overhead of this process, the implementation of this process is a overhead of this process, the implementation of this process is
conditional SHOULD. This function SHOULD be enabled unless the OPTIONAL. This function SHOULD be enabled unless the implementation
implementation is known to be used in the scenarios without the above is known to be used in the scenarios without the above exceptions.
exceptions. For example, if the implementation is to be used in For example, if the implementation is to be used in networks with
networks with tree topology and without host local-link movement, tree topology and without host local-link movement, there is no need
there is no need to implement this process in such scenarios. to implement this process in such scenarios.
This process is not intended to set up a binding whenever a data This process is not intended to set up a binding whenever a data
packet without matched binding entry is received. Instead, unmatched packet without a matched binding entry is received. Instead,
data packets trigger this process probabilistically and generally a unmatched data packets trigger this process probabilistically and
number of unmatched packets will be discarded before the binding is generally a number of unmatched packets will be discarded before the
set up. binding is set up. The parameter(s) of this probabilistic process
SHOULD be configurable, defaulting to a situation where data snooping
is disabled.
7.2. Rationale 7.2. Rationale
This process makes use of NS/ARP and DHCP LEASEQUERY to set up This process makes use of NS/ARP and DHCP LEASEQUERY to set up
bindings. If an address is not used by another client in the bindings. If an address is not used by another client in the
network, and the address has been assigned in the network, the network, and the address has been assigned in the network, the
address can be bound with the binding anchor of the attachment from address can be bound with the binding anchor of the attachment from
which the unmatched packet is received. which the unmatched packet is received.
The security issues about this process is discussed is Section 11.1. The Data Snooping Process provides an alternative path for binding
entries to reach the BOUND state in the exceptional cases explained
in Section 7.1 when there are no DHCP messages that can be snooped by
the SAVI device.
In some of the exceptional cases (especially the dynamic topology
case), by the time the binding has reached the BOUND state the DHCP
messages may be passing through the SAVI device. In this case the
events driven by DHCP messages that are expected in the BOUND state
in the DHCP Snooping Process may occur and the binding can be handled
by the DHCP Snooping Process state machine.
In any event, the lease expiry timeout event will occur even if no
others do. This will cause the binding to be deleted and the state
to logically return to NO_BIND state. Either the DHCP or the Data
Snooping Process will be reinvoked if the lease is still place. If
DHCP messages are still not passing through the SAVI device, there
will be a brief disconnection during which data packets passing
through the SAVI device will be dropped. The probabilistic
initiation of the Data Snooping Process can then take over again and
return the binding state to BOUND in due course.
The security issues concerning this process are discussed is
Section 11.1.
7.3. Additional Binding States Description 7.3. Additional Binding States Description
In addition to NO_BIND and BOUND from Section 6.2, two new states In addition to NO_BIND and BOUND from Section 6.2, three new states
used in this process are listed here. The INIT_BIND state is not used in this process are listed here. The INIT_BIND state is not
used, as it is entered by observing a DHCP message. used, as it is entered by observing a DHCP message.
DETECTION: The address in the entry is under local duplication DETECTION: The address in the entry is undergoing local duplication
detection. detection.
RECOVERY: The SAVI device is querying the assignment and lease time RECOVERY: The SAVI device is querying the assignment and lease time
of the address in the entry through DHCP Lease query. of the address in the entry through DHCP lease query.
VERIFY: The SAVI device is verifying that the device connected to the
attachment point has a hardware address that matches the one returned
in the DHCP lease query.
Because the mechanisms used for the operations carried out while the
binding is in these three states operate over unreliable protocols,
each operation is carried out twice with a timeout that is triggered
if no response is received.
7.4. Events 7.4. Events
In addition to EVE_DATA_LEASEQUERY and EVE_DHCP_REBIND, these To handle the Data Snooping Process, five extra events, described
additional events are described here. If an event will trigger the here, are needed in addition to those used by the DHCP Snooping
creation of a new binding entry, the binding entry limit on the Process (see Section 6.3). If an event will trigger the creation of
binding anchor MUST NOT be exceeded. a new binding entry, the binding entry limit on the binding anchor
MUST NOT be exceeded.
EVE_DATA_UNMATCH: A data packet without matched binding is received. EVE_DATA_UNMATCH: A data packet without a matched binding is
received.
EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message
against an address in DETECTION state is received from a host other against an address in DETECTION state is received from a host other
than the one for which the entry was added. than the one for which the entry was added (i.e., a host attached at
another point than the one on which the triggering data packet was
received).
EVE_DATA_LEASEQUERY: EVE_DATA_LEASEQUERY:
o IPv4: A DHCPLEASEACTIVE message with IP Address Lease Time option o IPv4: A DHCPLEASEACTIVE message with IP Address Lease Time option
is received. is received.
o IPv6: A successful LEASEQUERY-REPLY is received. o IPv6: A successful LEASEQUERY-REPLY is received.
EVE_DATA_VERIFY: An ARP Reply/Neighbor Advertisement(NA) message has
been received in the VERIFY state from the device connected to the
attachment point on which the data packet was received.
The triggering packet should pass the following checks to trigger a The triggering packet should pass the following checks to trigger a
valid event: valid event:
o Attribute check: the data packet should be from attachments with o Attribute check: the data packet should be from attachments with
Data-Snooping attribute; the DHCPLEASEACTIVE/LEASEQUERY_REPLY Data-Snooping attribute; the DHCPLEASEACTIVE/LEASEQUERY-REPLY
messages should be from attachments with DHCP-Snooping attribute. messages should be from attachments with DHCP-Snooping attribute.
o Binding limitation check: the DHCP messages must not cause new o Binding limitation check: the data messages must not cause new
binding setup on an attachment whose binding entry limitation has binding setup on an attachment whose binding entry limitation has
been reached. (refer to Section 11.5). been reached. (refer to Section 11.5).
o Address check: For EVE_DATA_LEASEQUERY, the source address of the o Address check: For EVE_DATA_LEASEQUERY, the source address of the
DHCP Lease query messages must pass the check specified in DHCP Lease query messages must pass the check specified in
Section 8.2. For EVE_DATA_CONFLICT, the source address and target Section 8.2. For EVE_DATA_CONFLICT and EVE_DATA_VERIFY, the
address of the ARP or NA messages must pass the check specified in source address and target address of the ARP or NA messages must
Section 8.2. pass the check specified in Section 8.2.
o Interval check: the interval between two successive o Interval check: the interval between two successive
EVE_DATA_UNMATCH events triggered by an attachment MUST be no EVE_DATA_UNMATCH events triggered by an attachment MUST be no
smaller than DATA_SNOOPING_INTERVAL. smaller than DATA_SNOOPING_INTERVAL.
o TID check: the DHCPLEASEACTIVE/LEASEQUERY-REPLY messages must have o TID check: the DHCPLEASEACTIVE/LEASEQUERY-REPLY messages must have
matched TID with the corresponding entry. matched TID with the corresponding entry.
o Prefix check: the source address of the data packet should be of a o Prefix check: the source address of the data packet should be of a
valid local prefix, as specified in section 7 of [RFC7039]. valid local prefix, as specified in section 7 of [RFC7039].
EVE_ENTRY_EXPIRE: A timer expires. EVE_DATA_EXPIRE: A timer expires indicating that a response to a
hardware address verification message sent in the VERIFY state has
not been received within the specified DETECTION_TIMEOUT period.
7.5. Initial State: state NO_BIND - No binding has been set up 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.1. Event: EVE_DATA_UNMATCH: A data packet without matched binding 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 twice since
they are sent over unreliable transports and are sent in different
states. The functions defined in this section specify the messages
to be sent in the three cases. In each case the message to be sent
depends on whether the triggering data packet is an IPv4 or an IPv6
packet.
7.5.1. Duplicate Detection Message Sender
Send a message to check if the source address in the data packet that
triggered the data snooping process has a local conflict (that is, it
uses an address that is being used by another node):
IPv4 address: broadcast an Address Resolution Protocol (ARP) Request
[RFC0826] 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 on which the triggering data
packet was received. 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.
As both the ARP and DAD processes are unreliable (either the packet
to or from the other system may be lost in transit, see [RFC6620]),
if there is no response after the DETECTION_TIMEOUT an
EVE_ENTRY_EXPIRE is generated.
7.5.2. Lease Query Message Sender
Send a DHCP lease query message to the DHCP server(s) to determine if
it has given out a lease for the source address in the triggering
data packet. A list of authorized DHCP servers is kept by the SAVI
device. The list should be either pre-configured with the IPv4 and/
or IPv6 addresses or dynamically discovered: For networks using IPV4
this can be done by sending DHCPv4 Discover messages and parsing the
returned DHCPv4 Offer messages; for networks using IPv6 discovery can
be done by sending DHCPv6 SOLICIT messages and parsing the returned
ADVERTISE messages. See Section 11.2 regarding the securing of the
process and the advisability of using the DHCPv6
All_DHCP_Relay_Agents_and_Servers or All_DHCP_Servers multicast
addresses. The same TID should be used for all lease query messages
sent in response to a triggering data message on an attachment point.
The TID is generated if the TID field in the BST entry is empty and
recorded in the TID field of the BST entry when the first message is
sent. Subsequent messages use the TID from the BST entry.
(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 will be returned 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 will be returned 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.
As DHCP lease queries are an unreliable process (either the packet to
or from the server may be lost in transit), if there is no response
after the MAX_LEASEQUERY_DELAY an EVE_DATA_EXPIRE is generated. Note
that multiple response messages may be received if the list of
authorized servers contains more than one address of the appropriate
type and, in the case of DHCPv6, the responses may contain additional
addresses for which leases have been allocated.
7.5.3. Address Verification Message Sender
Send a message to verify that the link layer address in the attached
device that sent the triggering data packet matches the link layer
address contained in the lease query response:
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 that can be compared with the lease query
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, a Neighbor Announcement (NA)
should be received indicating that the attached device has the
IP address configured on the interface.
As both the ARP and NS/NA processes are unreliable (either the packet
to or from the other system may be lost in transit, see [RFC6620]),
if there is no response after the DETECTION_TIMEOUT an
EVE_DATA_EXPIRE is generated.
7.6. Initial State: state NO_BIND - No binding has been set up
7.6.1. Event: EVE_DATA_UNMATCH: A data packet without a matched binding
is received is received
Make a probabilistic determination whether to act on this event. The Make a probabilistic determination as to whether to act on this
probability may be configured or calculated based on the state of the event. The probability may be configured or calculated based on the
SAVI device. This probability should be low enough to mitigate the state of the SAVI device. This probability should be low enough to
damage from DoS attack against this process. mitigate the damage from DoS attack against this process.
Create a new entry in the BST. Set the Binding Anchor field to the Create a new entry in the BST. Set the Binding Anchor field to the
corresponding binding anchor of the attachment. Set the Address corresponding binding anchor of the attachment. Set the Address
field to the source address of the packet. Set the State field to field to the source address of the packet.
DETECTION. Set the Lifetime of the created entry to
2*DETECTION_TIMEOUT.
Check if the address has a local conflict (it violates an address
being used by another node):
(1) IPv4 address: send an Address Resolution Protocol (ARP) Request Address conflicts MUST be detected and prevented.
[RFC0826] or an ARP probe [RFC5227] on the address; if there is
no response message after DETECTION_TIMEOUT, send another ARP
Request or ARP probe;
(2) IPv6 address: send a Duplicate Address Detection message If local address detection is performed:
[RFC4861] targeting the address; ideally, only the host on that Set the State field to DETECTION. Set the Lifetime of the
point of attachment responds with a Neighbor Advertisement; if created entry to DETECTION_TIMEOUT. Set the Timeouts field to
more than one Neighbor Advertisement is observed, the BST entry 0. Start the detection of any local address conflicts by
should be removed. sending a Duplicate Address Detection Message (Section 7.5.1)).
Transition to state DETECTION.
As Duplicate Address Detection is an unreliable process (either the If local address detection is not performed:
packet to or from the other system may be lost in transit), if there Set the State field to RECOVERY. Set the Lifetime of the
is no response, it should be repeated, as described in [RFC6620]. created entry to LEASEQUERY_DELAY. Set the Timeouts field to
0. Start the recovery of any DHCP lease associated with the
source IP address by sending one or more lease query messages
(Section 7.5.2)). Transition to state RECOVERY.
The packet that triggers this event SHOULD be discarded. The packet that triggers this event SHOULD be discarded.
This local conflict process SHOULD be performed. If it is not An example of the BST entry during duplicate address detection is
performed, the state of the entry is set to RECOVERY, the lifetime is illustrated in Figure 11.
set to 2*MAX_LEASEQUERY_DELAY, and the lease query process specified
in the following section will be performed directly.
An example of the entry is illustrated in Figure 11.
+---------+-------+---------+-----------------------+-------+ +--------+-------+---------+-----------------------+-----+----------+
| Anchor |Address| State | Lifetime |TID | | Anchor |Address| State | Lifetime | TID | Timeouts |
+---------+-------+---------+-----------------------+-------+ +--------+-------+---------+-----------------------+-----+----------+
| Port_1 | Addr1 |DETECTION|2*DETECTION_TIMEOUT | | | Port_1 | Addr1 |DETECTION| DETECTION_TIMEOUT | | 0 |
+---------+-------+---------+-----------------------+-------+ +--------+-------+---------+-----------------------+-----+----------+
Figure 11: Binding entry in BST on data triggered initialization Figure 11: Binding entry in BST on data triggered initialization
Resulting state: DETECTION - The address in the entry is under local Resulting state: DETECTION - The address in the entry is undergoing
duplication detection local duplication detection - or RECOVERY - DHCP lease(s) associated
with the address are being queried.
7.5.2. Events not observed in NO_BIND 7.6.2. Events not observed in NO_BIND for data snooping
EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message
received from unexpected system received from unexpected system
EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received
EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or LEASEQUERY-REPLY is EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or LEASEQUERY-REPLY is
received received
EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is EVE_DATA_VERIFY: A valid ARP Reply or NA message received from the
received attached device
All EVE_DHCP_* events defined in Section 6.3.2 are treated as
described in the DHCP Snooping Process (Section 6.4.1) and may result
in that process being triggered.
EVE_ENTRY_EXPIRE EVE_ENTRY_EXPIRE:
7.6. Initial State: state DETECTION - The address in the entry is under EVE_DATA_EXPIRE:
local duplication detection
7.6.1. Event: EVE_ENTRY_EXPIRE 7.7. Initial State: state DETECTION - The address in the entry is
undergoing local duplication detection
(1) IPv4 address: Send a DHCPLEASEQUERY [RFC4388] message querying 7.7.1. Event: EVE_ENTRY_EXPIRE
by IP address to each DHCPv4 server with IP Address Lease Time
option (option 51). A list of authorized DHCP servers are kept
by the SAVI device. The list should be pre-configured or
discovered by sending DHCPv4 Discover messages and parsing the
replied DHCPv4 Offer messages. Change the state of the
corresponding entry to RECOVERY. Change the lifetime of the
entry to be 2*MAX_LEASEQUERY_DELAY. The TID field is set to the
TID used in the DHCPLEASEQUERY message. If there is no response
message after MAX_LEASEQUERY_DELAY, send a DHCPLEASEQUERY to each
DHCPv4 server again.
(2) IPv6 address: Send a LEASEQUERY [RFC5007] message querying by IP When this event occurs, no address conflict has been detected during
address to All_DHCP_Relay_Agents_and_Servers multicast address or the previous DETECTION_TIMEOUT period.
a list of pre-configured DHCPv6 server addresses. Change the
state of the corresponding entry to RECOVERY. Change the If the Timeouts field in the BST entry is 0:
lifetime of the entry to be 2*MAX_LEASEQUERY_DELAY. The TID Set the Lifetime of the BST entry to DETECTION_TIMEOUT. Set
field is set to the TID used in the LEASEQUERY message. If there the Timeouts field to 1. Restart the detection of any local
is no response message after MAX_LEASEQUERY_DELAY, send the address conflicts by sending a second Duplicate Address
LEASEQUERY message again. Detection Message (Section 7.5.1)). Remain in state DETECTION.
If the Timeouts field in the BST entry is 1:
Assume that there is no local address conflict. Set the State
field to RECOVERY. Set the Lifetime of the BST entry to
LEASEQUERY_DELAY. Set the Timeouts field to 0. Start the
recovery of any DHCP lease associated with the source IP
address by sending one or more lease query messages
(Section 7.5.2)). Transition to state RECOVERY.
An example of the entry is illustrated in Figure 12. An example of the entry is illustrated in Figure 12.
+---------+-------+---------+-----------------------+-------+ +--------+-------+----------+----------------------+-----+----------+
| Anchor |Address| State | Lifetime |TID | | Anchor |Address| State | Lifetime | TID | Timeouts |
+---------+-------+---------+-----------------------+-------+ +--------+-------+----------+----------------------+-----+----------+
| Port_1 | Addr1 |RECOVERY |2*MAX_LEASEQUERY_DELAY |TID | | Port_1 | Addr1 | RECOVERY | MAX_LEASEQUERY_DELAY | TID | 0 |
+---------+-------+---------+-----------------------+-------+ +--------+-------+----------+----------------------+-----+----------+
Figure 12: Binding entry in BST on Lease Query Figure 12: Binding entry in BST on Lease Query
Resulting state: RECOVERY - The SAVI device is querying the Resulting state: DETECTION - If a second local conflict period is
assignment and lease time of the address in the entry through DHCP required - or RECOVERY - The SAVI device is querying the assignment
Leasequery and lease time of the address in the entry through DHCP Leasequery
7.6.2. Event: EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) 7.7.2. Event: EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA)
message received from unexpected system message received from unexpected system
Remove the entry. Remove the entry.
Resulting state: NO_BIND - No binding has been set up Resulting state: NO_BIND - No binding has been set up
7.6.3. Events not observed in DETECTION 7.7.3. Events not observed in DETECTION
EVE_DATA_UNMATCH: A data packet without matched binding is received EVE_DATA_UNMATCH: A data packet without matched binding is received
EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received All EVE_DHCP_* events defined in Section 6.3.2
EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or LEASEQUERY-REPLY is
received
EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is
received received
7.7. Initial State: state RECOVERY - The SAVI device is querying the 7.8. Initial State: state RECOVERY - The SAVI device is querying the
assignment and lease time of the address in the entry through DHCP assignment and lease time of the address in the entry through DHCP
Leasequery Leasequery
7.7.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or 7.8.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or
LEASEQUERY-REPLY is received successful LEASEQUERY-REPLY is received
IPv4 address: Set the State in the BST entry to VERIFY. Depending on the type of
triggering source IP address, process the received DHCP lease query
response:
(1) Send an ARP Request with the Target Protocol Address set to the IPv4 address: Update the Lifetime field in the BST entry to the sum
IP address in the corresponding entry. The ARP Request is only of the value encoded in IP Address Lease Time option of the
sent to the attachment which triggers the binding. If there is DHCPLEASEACTIVE message and MAX_DHCP_RESPONSE_TIME. Record the
no response after DETECTION_TIMEOUT, send another ARP Request. value of the "chaddr" field (hardware address) in the message
If there is still no response, remove the entry. for checking against the hardware address received during
verification in the next state. Set the Timeouts field to 0.
Start the verification process by sending an Address
Verification Message (see Section 7.5.3). Transition to state
VERIFY. Start an additional verification timer with a duration
of DETECTION_TIMEOUT. When this expires an EVE_DATA_EXPIRE
event will be generated.
(2) If there is only one identical response, get the sender hardware IPv6 address: Update the Lifetime field in the BST entry to the sum
address. Check if the 'chaddr' field (hardware address) of the of the valid lifetime extracted from OPTION_CLIENT_DATA option
DHCPLEASEACTIVE message matches the sender hardware address. If in the LEASEQUERY-REPLY message and MAX_DHCP_RESPONSE_TIME.
the two addresses do not match, the following actions will not be Set the Timeouts field to 0. Start the verification process by
performed. If there is more than one response, if any of the sending an Address Verification Message (see Section 7.5.3).
sender hardware addresses matches the 'chaddr' field (hardware Transition to state VERIFY. Start an additional verification
address) of the DHCPLEASEACTIVE message, timer with a duration of DETECTION_TIMEOUT. When this expires
an EVE_DATA_EXPIRE event will be generated.
* Set life time to the sum of the value encoded in IP Address If multiple addresses are received in the LEASEQUERY-REPLY, new
Lease Time option of the DHCPLEASEACTIVE message and BST entries MUST be created for the additional addresses using
MAX_DHCP_RESPONSE_TIME. the same binding anchor. The entries are created with State
set to VERIFY and the other fields set as described in this
section for the triggering source IP address. Also start the
verification process and start verification timers for each
additional address.
* Erase the TID field. Resulting state: VERIFY - awaiting verification or otherwise of the
association of the IP address with the connected interface.
IPv6 address: 7.8.2. Event: EVE_ENTRY_EXPIRE
(1) Send a Neighbor Solicitation message with the target address set Depending on the value of the Timeouts field in the BST entry, either
to the IP address in the corresponding entry. The Neighbor send repeat lease query messages or discard the binding:
Solicitation is only sent to the attachment which triggers the
binding. If there is no response after DETECTION_TIMEOUT, send
another Neighbor Solicitation. If there is still no response,
remove the entry.
(2) On receipt of a valid Neighbor Announcement, If the Timeouts field in the BST entry is 0:
No responses to the lease query message(s) sent have been
received 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
associated with the source IP address by sending one or more
lease query messages (Section 7.5.2)). Remain in state
RECOVERY.
* Set the lifetime to the sum of the valid lifetime extracted If the Timeouts field in the BST entry is 1:
from OPTION_CLIENT_DATA option in the LEASEQUERY-REPLY No responses to the lease query messages sent during two
message and MAX_DHCP_RESPONSE_TIME. LEASEQUERY_DELAY periods were received. Assume that no leases
exist and hence that the source IP address is bogus. Delete
the BST entry. Transition to state NO_BIND.
* Erase the TID field. Resulting state: RECOVERY - if repeat lease queries are sent - or
NO_BIND - if no successful responses to lease query messages have
been received.
* After the above checks, if multiple addresses are specified 7.8.3. Events not observed in RECOVERY
in the LEASEQUERY-REPLY message and there are no
corresponding binding entries, new entries MUST also be
created correspondingly on the same binding anchor.
In the event that responses are received from multiple DHCP servers, EVE_DATA_UNMATCH: A data packet without matched binding is received
the conflict resolution mechanisms specified in section 6.8 of
[RFC4388] and section 4.3.4 of [RFC5007] will be used to determine
which message should be used.
Resulting state: if ARP or ND succeeds (there is a valid response), EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message
BOUND - The binding has been set up. Otherwise, the resulting state received from unexpected system
is NO_BIND - No binding has been set up
7.7.2. Event: EVE_ENTRY_EXPIRE EVE_DATA_VERIFY: A valid ARP Reply or NA message received from the
attached device
Remove the entry. All EVE_DHCP_* events defined in Section 6.3.2
EVE_DATA_EXPIRE:
7.9. Initial State: state VERIFY - Verification of the use of the
source IP address by the device interface attached to the SAVI
device
7.9.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or
successful LEASEQUERY-REPLY is received
If lease query messages were sent to more than one DHCP server during
RECOVERY state, additional successful lease query responses may be
received relating to the source IP address. The conflict resolution
mechanisms specified in Section 6.8 of [RFC4388] and Section 4.3.4 of
[RFC5007] can be used to determine the message from which values are
used to update the BST Lifetime entry and the hardware address
obtained from DHCP, as described in Section 7.8.1. In the case of
DHCPv6 queries, the LEASEQUERY-REPLY may contain additional addresses
as described in Section 7.8.1. If so additional BST entries MUST be
created or ones previously created updated as described in that
section.
Resulting state: VERIFY (no change).
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 may
indicate that the device attached via the binding anchor in the BST
entry is configured by DHCP using the IP address:
IPv4 address: Check that the value of sender hardware address in the
ARP Reply matches the saved "chaddr" field (hardware address)
from the previously received DHCPLEASEACTIVE message. If not,
ignore this event; a subsequent retry may provide verification.
If the hardware addresses match, the binding entry has been
verified.
IPv6 address: Simple receipt of 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.
Resulting state: VERIFY (no change) - if IPv4 DHCPLEASEQUERY "chaddr"
address does not match ARP Reply hardware address - or BOUND -
otherwise.
7.9.3. Event: EVE_ENTRY_EXPIRE
The DHCP lease lifetime has expired before the entry could be
verified. Remove the entry. Transition to NO_BIND state.
Resulting state: NO_BIND - No binding has been set up Resulting state: NO_BIND - No binding has been set up
7.7.3. Events not observed in RECOVERY 7.9.4. Event: EVE_DATA_EXPIRE
Depending on the value of the Timeouts field in the BST entry, 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 sent has been received
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
this expires an EVE_DATA_EXPIRE event will be generated.
Remain in state VERIFY.
If the Timeouts field in the BST entry is 1:
No responses to the verification messages sent during two
DETECTION_TIMEOUT periods were received. Assume that the
configuration of the triggering source IP address cannot be
verified and hence that the source IP address is bogus. Delete
the BST entry. Transition to state NO_BIND.
Resulting state: VERIFY - additional verification message sent - or
NO_BIND - No binding has been set up
7.9.5. Events not observed in VERIFY
EVE_DATA_UNMATCH: A data packet without matched binding is received EVE_DATA_UNMATCH: A data packet without matched binding is received
EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message
received from unexpected system received from unexpected system
EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message 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: state BOUND - The binding has been set up 7.10. Initial State: state BOUND - The binding has been set up
Upon entry to the state BOUND, control the system continues as if a Upon entry to the state BOUND, control the system continues as if a
DHCP message assigning the address has been observed, as in DHCP message assigning the address has been observed, as in
Section 6.4.3. The BST entry has been restored. Section 6.4.3. The BST entry has been restored.
Note that the TID field contains no value after the binding state Note that the TID field contains no value after the binding state
changes to BOUND. The TID field is recovered from snooping DHCP changes to BOUND. The TID field is recovered from snooping DHCP
Renew/Rebind messages. Because TID is used to associate binding Renew/Rebind messages if these are observed as described in the DHCP
entries with messages from DHCP servers, it must be recovered; or Snooping Process. Because TID is used to associate binding entries
else a number of state transits of this mechanism will be not with messages from DHCP servers, it must be recovered; or else a
executed normally. number of state transitions of this mechanism will be not executed
normally.
7.9. Table of State Machine
The main state transits are listed as follows.
State Event Action Next State
NO_BIND EVE_DATA_UNMATCH Duplication detection DETECTION
DETECTION EVE_ENTRY_EXPIRE Send Leasequery RECOVERY
DETECTION EVE_DATA_CONFLICT Remove entry NO_BIND
RECOVERY EVE_DATA_LEASEQUERY Set lease time BOUND or NO_BIND
RECOVERY EVE_ENTRY_EXPIRE Remove entry NO_BIND
BOUND RENEW/REBIND Record TID BOUND
Figure 13: Table of Transit 7.11. Table of State Machine
RENEW: EVE_DHCP_RENEW The main state transitions are listed as follows.
REBIND: EVE_DHCP_REBIND State Event Action Next State
NO_BIND EVE_DATA_UNMATCH Start duplicate detect DETECTION
DETECTION EVE_ENTRY_EXPIRE 1 Repeat duplicate detect DETECTION
DETECTION EVE_ENTRY_EXPIRE 2 Start lease query RECOVERY
DETECTION EVE_DATA_CONFLICT Remove entry NO_BIND
RECOVERY EVE_ENTRY_EXPIRE 1 Repeat lease query RECOVERY
RECOVERY EVE_ENTRY_EXPIRE 2 No lease found; remove entry NO_BIND
RECOVERY EVE_DATA_LEASEQUERY Set lease time; Start verify VERIFY
VERIFY EVE_ENTRY_EXPIRE Lease expiry; remove entry NO_BIND
VERIFY EVE_DATA_LEASEQUERY Resolve lease conflict(s) VERIFY
VERIFY EVE_DATA_VERIFY Finish validation BOUND or NO_BIND
VERIFY EVE_DATA_EXPIRE 1 Repeat verify VERIFY
VERIFY EVE_DATA_EXPIRE 2 Verify failed; remove entry NO_BIND
BOUND EVE_ENTRY_EXPIRE Lease expiry; remove entry NO_BIND
BOUND RENEW/REBIND Record TID BOUND
+-------------+ Figure 13: State Transition Table
| | +-------------+ EVE_ENTRY_EXPIRE
/---------| NO_BIND |<--------\ /---------+ |<------------------------\
| ------>| | | EVE_ENTRY_EXPIRE | | NO_BIND | EVE_DATA_EXPIRE |
| | +-------------+ |(2nd LQ_DELAY) EVE_DATA_UNMATCH | /----->| |<----\ (2nd VRF_DELAY) |
EVE_DATA_UNMATCH | | | | | +-------------+ | |
| | | | | EVE_ENTRY_EXPIRE | |
1st | | | | | (2nd LQ_DELAY) | |
DETECTION_TIMEOUT | | | 1st LQ_DELAY EVE_ENTRY_EXPIRE | | | EVE_ENTRY_EXPIRE |
/------\ | | | /---------\ (1st DAD_DELAY) | | | (1st LQ_DELAY) |
| | | | EVE_DATA_CONFLICT | | | /------\ | | | /--------\ |
| v v | | v | | | | | EVE_DATA_CONFLICT \---\ | | |
| +-------------+ EVE_ENTRY_EXPIRE +------------+ | | v v | | v | |
| | |(2nd DETECTION_TIMEOUT) | | | | +-------------+ EVE_ENTRY_EXPIRE +------------+ | |
\----| DETECTION ------------------------>| RECOVERY ----/ | | | (2nd DAD_DELAY) | | | |
| | | | \----+ DETECTION ------------------------>| RECOVERY +--/ |
+-------------+ +------------+ | | | | |
EVE_DATA_LEASEQUERY| +-------------+ (To NO_BIND) +------------+ |
/----------\ (+ 2x DETECTION) | ^ | |
EVE_DHCP_RENEW| | | | EVE_DATA_LEASEQUERY | |
EVE_DHCP_REBIND| +-----v-------+ | /----------\ | | |
| | | | | | | EVE_ENTRY_EXPIRE | |
\----| BOUND |<----------/ EVE_DHCP_RENEW| v | v |
| | EVE_DHCP_REBIND| +-------------+ +-------------+ |
+-------------+ | | | | +--/
\----+ BOUND |<---------------+ VERIFY |
| | EVE_DATA_VERIFY| |<-\
+-------------+ +-------------+ |
| |
\----------/
EVE_DATA_LEASEQUERY
EVE_DATA_EXPIRE
(1st VRF_DELAY)
Figure 14: Diagram of Transit Figure 14: Diagram of Transit
LQ_DELAY: MAX_LEASEQUERY_DELAY LQ_DELAY: MAX_LEASEQUERY_DELAY
VRF_DELAY: DETECTION_TIMEOUT
8. Filtering Specification 8. Filtering Specification
This section specifies how to use bindings to filter out packets with This section specifies how to use bindings to filter out packets with
spoofed source addresses. spoofed source addresses.
Filtering policies are different for data packets and control Filtering policies are different for data packets and control
packets. DHCP, ARP, and NDP (Neighbor Discovery Protocol) [RFC4861] packets. DHCP, ARP, and NDP (Neighbor Discovery Protocol) [RFC4861]
messages are classified as control packets. All other packets are messages are classified as control packets. All other packets are
classified as data packets. classified as data packets.
8.1. Data Packet Filtering 8.1. Data Packet Filtering
Data packets from attachments with the Validating attribute TRUE MUST Data packets from attachments with the Validating attribute TRUE MUST
be checked. There is one exception to this rule. have their source addresses validated. There is one exception to
this rule.
A packet whose source IP address is a link-local address cannot be A packet whose source IP address is a link-local address cannot be
checked against DHCP assignments, as it is not assigned using DHCP. checked against DHCP assignments, as it is not assigned using DHCP.
Note: as explained in Section 1, a SAVI solution for link-local Note: as explained in Section 1, a SAVI solution for link-local
addresses, e.g., the SAVI-FCFS [RFC6620], can be enabled to check addresses, e.g., the SAVI-FCFS [RFC6620], can be enabled to check
packets with a link-local source address. packets with a link-local source address.
If the source IP address of a packet is not a link-local address, but If the source IP address of a packet is not a link-local address, but
there is not a matching entry in BST with state BOUND, this packet there is not a matching entry in BST with state BOUND, this packet
MUST be discarded. However, the packet may trigger the Data Snooping MUST be discarded. However, the packet may trigger the Data Snooping
Process Section 7 if the Data-Snooping attribute is set on the Process Section 7 if the Data-Snooping attribute is set on the
attachment. attachment.
Data packets from an attachment with the VALIDATING attribute set Data packets from an attachment with the Validating attribute set
FALSE will be forwarded without being validated. FALSE will be forwarded without having their source addresses
validated.
The SAVI device MAY log packets that fail source address validation. The SAVI device MAY log packets that fail source address validation.
8.2. Control Packet Filtering 8.2. Control Packet Filtering
For attachments with the Validating attribute: For attachments with the Validating attribute:
DHCPv4 Client-Server messages in which the source IP address is DHCPv4 Client-Server messages in which the source IP address is
neither all zeros nor bound with the corresponding binding anchor in neither all zeros nor bound with the corresponding binding anchor in
the BST MUST be discarded. the BST MUST be discarded.
skipping to change at page 39, line 44 skipping to change at page 46, line 36
9.1. Attribute Configuration Restoration 9.1. Attribute Configuration Restoration
The loss of attribute configuration will not break the network: no The loss of attribute configuration will not break the network: no
action will be performed on traffic from attachments with no action will be performed on traffic from attachments with no
attribute. However, the loss of attribute configuration makes this attribute. However, the loss of attribute configuration makes this
SAVI function unable to work. SAVI function unable to work.
To avoid the loss of binding anchor attribute configuration, the To avoid the loss of binding anchor attribute configuration, the
configuration MUST be able to be stored in non-volatile storage. configuration MUST be able to be stored in non-volatile storage.
After the reboot of SAVI device, if the configuration of binding After the reboot of SAVI device, if the configuration of binding
anchor attribute can be found in non-volatile storage, the anchor attributes is found in non-volatile storage, the configuration
configuration MUST be used. MUST be used.
9.2. Binding State Restoration 9.2. Binding State Restoration
The loss of binding state will cause the SAVI devices discard The loss of binding state will cause the SAVI devices to discard
legitimate traffic. Purely using the Data Snooping Process to legitimate traffic. Simply using the Data Snooping Process to
recover a large number of bindings is of heavy overhead and recover a large number of bindings is a heavy overhead and may cause
considerable delay. Thus, to recover bindings from non-volatile considerable delay. Thus, to recover bindings from non-volatile
storage, as specified below, is RECOMMENDED. storage, as specified below, is RECOMMENDED.
Binding entries MAY be saved into non-volatile storage whenever a new Binding entries MAY be saved into non-volatile storage whenever a new
binding entry changes to BOUND state. If a binding with BOUND state binding entry changes to BOUND state. If a binding with BOUND state
is removed, the saved entry MUST be removed correspondingly. The is removed, the saved entry MUST be removed correspondingly. The
time when each binding entry is established is also saved. time when each binding entry is established is also saved.
Immediately after reboot, the SAVI device SHOULD restore binding If the BST is stored in non-volatile storage, the SAVI device SHOULD
states from the non-volatile storage. The system time of save restore binding state from the non-volatile storage immediately after
process MUST be stored. After rebooting, the SAVI device MUST check reboot. Using the time when each binding entry was saved, the SAVI
whether each entry has been obsolete by comparing the saved lifetime device should check whether the entry has become obsolete by
and the difference between the current time and time when the binding comparing the saved lifetime and the difference between the current
entry is established. time and time when the binding entry was established. Obsolete
entries which would have expired before the reboot MUST be removed.
10. Constants 10. Constants
The following constants are recommended for use in this context: The following constants are recommended for use in this context:
o MAX_DHCP_RESPONSE_TIME 120s (SOL_MAX_RT from [RFC3315]) o MAX_DHCP_RESPONSE_TIME 120s Maximum Solicit timeout value
(SOL_MAX_RT from [RFC3315])
o MAX_LEASEQUERY_DELAY 10s (LQ_MAX_RT from [RFC5007]) o MAX_LEASEQUERY_DELAY 10s Maximum LEASEQUERY timeout value
(LQ_MAX_RT from [RFC5007])
o DETECTION_TIMEOUT 0.5s (TENT_LT from [RFC6620]) o DETECTION_TIMEOUT 0.5s Maximum duration of a hardware address
verification step in the VERIFY state (TENT_LT from [RFC6620])
o DATA_SNOOPING_INTERVAL 60s and configurable (recommendation) o DATA_SNOOPING_INTERVAL Minimum interval between two successive
EVE_DATA_UNMATCH events triggered by an attachment. 60s and
configurable (recommendation)
o OFFLINK_DELAY 30s (recommendation) o OFFLINK_DELAY 30s Period after a client is last detected before
the binding anchor being removed. (recommendation)
11. Security Considerations 11. Security Considerations
11.1. Security Problems about the Data Snooping Process 11.1. Security Problems about the Data Snooping Process
There are two security problems about the Data Snooping Process There are two security problems about the Data Snooping Process
Section 7: Section 7:
(1) The Data Snooping Process is costly, but an attacker can trigger (1) The Data Snooping Process is costly, but an attacker can trigger
it simply through sending a number of data packets. To avoid it simply through sending a number of data packets. To avoid
Denial of Services attack against the SAVI device itself, the Denial of Services attack against the SAVI device itself, the
Data Snooping Process MUST be rate limited. A constant Data Snooping Process MUST be rate limited. A constant
DATA_SNOOPING_INTERVAL is used to control the frequency. Two DATA_SNOOPING_INTERVAL is used to control the frequency. Two
Data Snooping Processes on one attachment MUST be separated by a Data Snooping Processes on one attachment MUST be separated by a
minimum interval time DATA_SNOOPING_INTERVAL. If this value is minimum interval time DATA_SNOOPING_INTERVAL. If this value is
changed, the value needs to be large enough to minimize denial of changed, the value needs to be large enough to minimize denial of
service attacks. service attacks.
(2) The Data Snooping Process may set up incorrect bindings if the (2) The Data Snooping Process may set up incorrect bindings if the
clients do not reply to the detection probes Section 7.5.1. An clients do not reply to the detection probes Section 7.6.1. An
attack will pass the duplicate detection if the client assigned attack will pass the duplicate detection if the client assigned
the target address does not reply to the detection probes. The the target address does not reply to the detection probes. The
DHCP Lease query procedure performed by the SAVI device just DHCP Lease query procedure performed by the SAVI device just
tells whether the address is assigned in the network or not. tells whether the address is assigned in the network or not.
However, the SAVI device cannot determine whether the address is However, the SAVI device cannot determine whether the address is
just assigned to the triggering attachment from the DHCP just assigned to the triggering attachment from the DHCP
LEASEQUERY Reply. LEASEQUERY Reply.
11.2. Client departure issues 11.2. Securing Lease Query Operations
In [RFC4388] and [RFC5007] the specific case of DHCP lease queries
originated by "access concentrators" is addressed extensively. SAVI
devices are very similar to access concentrators in that they snoop
on DHCP traffic and seek to validate source addresses based on the
results. Accordingly the recommendations for securing lease query
operations for access concentrators in Section 7 of [RFC4388] and
Section 5 of [RFC5007] MUST be followed when lease queries are made
from SAVI devices. [RFC5007] RECOMMENDS that communications between
the querier and the DHCP server are protected with IPsec. It is
pointed out that there are relatively few devices involved in a given
administrative domain (SAVI devices, DHCP relays and servers) so that
manual configuration of keying material would not be overly
burdensome.
11.3. Client departure issues
After a binding is set up, the corresponding client may leave its After a binding is set up, the corresponding client may leave its
attachment point. It may depart temporarily due to signal fade, or attachment point. It may depart temporarily due to signal fade, or
permanently by moving to a new attachment point or leaving the permanently by moving to a new attachment point or leaving the
network. In the signal fade case, since the client may return network. In the signal fade case, since the client may return
shortly, the binding should be kept momentarily, lest legitimate shortly, the binding should be kept momentarily, lest legitimate
traffic from the client be blocked. However, if the client leaves traffic from the client be blocked. However, if the client leaves
permanently, keeping the binding can be a security issue. If the permanently, keeping the binding can be a security issue. If the
binding anchor is a property of the attachment point rather than the binding anchor is a property of the attachment point rather than the
client, e.g., the switch port but not incorporating the MAC Address, client, e.g., the switch port but not incorporating the MAC Address,
skipping to change at page 42, line 7 skipping to change at page 49, line 23
OFFLINK_DELAY. In case of link flapping, the client will not be OFFLINK_DELAY. In case of link flapping, the client will not be
blocked. If the client leaves permanently, the bindings will be blocked. If the client leaves permanently, the bindings will be
removed after OFFLINK_DELAY. removed after OFFLINK_DELAY.
SAVI-DHCP does not handle the departure of indirect clients, because SAVI-DHCP does not handle the departure of indirect clients, because
it will not be notified of such events. Switches supporting indirect it will not be notified of such events. Switches supporting indirect
attachment (e.g., through a separate non-SAVI switch) SHOULD use attachment (e.g., through a separate non-SAVI switch) SHOULD use
information specific to the client such as its MAC address as part of information specific to the client such as its MAC address as part of
the binding anchor. the binding anchor.
11.3. Duplicate Bindings to the Same Address
The same address may be bound to multiple binding anchors only if the
binding setup processes successfully complete for each binding
anchor. This mechanism is designed to address the case where a
client moves on the local link, and the case where a client has
multiple attachments to a SAVI device.
There are two security issues with such a design:
First, by allowing one address to be bound to multiple binding
anchors, the traceability of the address is weakened. An address can
be traced to multiple attachments.
Second, in the local link movement scenario, the former binding may
not be removed and it can be used by an attacker sharing the same
binding anchor. For example, when a switch port is used as binding
anchor and the port is shared by an attacker and a client with a hub,
the attacker can make use of the address assigned to the client after
the client leaves.
11.4. Compatibility with DNA (Detecting Network Attachment) 11.4. Compatibility with DNA (Detecting Network Attachment)
DNA [RFC4436][RFC6059] is designed to decrease the handover latency DNA [RFC4436][RFC6059] is designed to decrease the handover latency
after re-attachment to the same network. DNA mainly relies on after re-attachment to the same network. DNA mainly relies on
performing reachability test by sending unicast Neighbor Solicitation performing reachability test by sending unicast Neighbor
/Router Solicitation/ARP Request message to determine whether a Solicitation/Router Solicitation/ARP Request message to determine
previously configured address is still valid. whether a previously configured address is still valid.
Although DNA provides optimization for clients, there is insufficient Although DNA provides optimization for clients, there is insufficient
information for this mechanism to migrate the previous binding or information for this mechanism to migrate the previous binding or
establish a new binding. If a binding is set up only by snooping the establish a new binding. If a binding is set up only by snooping the
reachability test message, the binding may be invalid. For example, reachability test message, the binding may be invalid. For example,
an attacker can perform reachability test with an address bound to an attacker can perform reachability test with an address bound to
another client. If binding is migrated to the attacker, the attacker another client. If binding is migrated to the attacker, the attacker
can successfully obtain the binding from the victim. Because this can successfully obtain the binding from the victim. Because this
mechanism wouldn't set up a binding based on snooping the DNA mechanism wouldn't set up a binding based on snooping the DNA
procedure, it cannot achieve perfect compatibility with DNA. procedure, it cannot achieve perfect compatibility with DNA.
skipping to change at page 44, line 5 skipping to change at page 50, line 42
11.6. Privacy Considerations 11.6. Privacy Considerations
A SAVI device MUST delete binding anchor information as soon as 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 possible (i.e., as soon as the state for a given address is back to
NO_BIND), except where there is an identified reason why that NO_BIND), except where there is an identified reason why that
information is likely to be involved in the detection, prevention, or information is likely to be involved in the detection, prevention, or
tracing of actual source address spoofing. Information about the tracing of actual source address spoofing. Information about the
majority of hosts that never spoof SHOULD NOT be logged. majority of hosts that never spoof SHOULD NOT be logged.
11.7. Fragmented DHCP Messages
This specification does not preclude reassembly of fragmented DHCP
messages, but it also does not require it. If DHCP fragmentation
proves to be an issue, that will need to be specified.
12. IANA Considerations 12. IANA Considerations
This memo asks the IANA for no new parameters. This memo asks the IANA for no new parameters.
13. Acknowledgment 13. Acknowledgment
Special thanks to Jean-Michel Combes, Christian Vogt, Joel M. Special thanks to Jean-Michel Combes, Christian Vogt, Joel M.
Halpern, Eric Levy-Abegnoli, Marcelo Bagnulo Braun, Jari Arkko, Elwyn Halpern, Eric Levy-Abegnoli, Marcelo Bagnulo Braun, Jari Arkko, Elwyn
Davies, Barry Leiba, Ted Lemon, Leaf Yeh, Ralph Droms and Alberto Davies, Barry Leiba, Ted Lemon, Leaf Yeh, Ralph Droms and Alberto
Garcia for careful review and valuation comments on the mechanism and Garcia for careful review and valuation comments on the mechanism and
skipping to change at page 45, line 25 skipping to change at page 52, line 25
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
SAVI: First-Come, First-Served Source Address Validation SAVI: First-Come, First-Served Source Address Validation
Improvement for Locally Assigned IPv6 Addresses", RFC Improvement for Locally Assigned IPv6 Addresses", RFC
6620, May 2012. 6620, May 2012.
14.2. Informative References 14.2. Informative References
[I-D.ietf-opsec-dhcpv6-shield] [I-D.ietf-opsec-dhcpv6-shield]
Gont, F., Will, W., and G. Velde, "DHCPv6-Shield: Gont, F., Will, W., and G. Velde, "DHCPv6-Shield:
Protecting Against Rogue DHCPv6 Servers", draft-ietf- Protecting Against Rogue DHCPv6 Servers", draft-ietf-
opsec-dhcpv6-shield-04 (work in progress), July 2014. opsec-dhcpv6-shield-05 (work in progress), January 2015.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004. (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt,
"Source Address Validation Improvement (SAVI) Framework", "Source Address Validation Improvement (SAVI) Framework",
 End of changes. 170 change blocks. 
581 lines changed or deleted 876 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/