< draft-ietf-savi-dhcp-26.txt   draft-ietf-savi-dhcp-27.txt >
SAVI J. Bi SAVI J. Bi
Internet-Draft J. Wu Internet-Draft J. Wu
Intended status: Standards Track G. Yao Intended status: Standards Track G. Yao
Expires: December 2, 2014 Tsinghua Univ. Expires: December 28, 2014 Tsinghua Univ.
F. Baker F. Baker
Cisco Cisco
May 31, 2014 June 26, 2014
SAVI Solution for DHCP SAVI Solution for DHCP
draft-ietf-savi-dhcp-26 draft-ietf-savi-dhcp-27
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 SAVI a DHCPv4/DHCPv6 assigned IP address and a binding anchor on a SAVI
(Source Address Validation Improvements) device. The bindings set up (Source Address Validation Improvements) device. The bindings set up
by this procedure can be used to filter out packets with forged by this procedure is used to filter out packets with forged source IP
source IP address in DHCP scenario. This mechanism is proposed as a address in DHCP scenario. This mechanism is proposed as a complement
complement to ingress filtering to provide finer-grained source IP to ingress filtering to provide finer-grained source IP address
address validation. validation.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 December 2, 2014. This Internet-Draft will expire on December 28, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 3, line 7 skipping to change at page 2, line 24
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Deployment Scenario and Configuration . . . . . . . . . . . . 8 4. Deployment Scenario and Configuration . . . . . . . . . . . . 7
4.1. Elements and Scenario . . . . . . . . . . . . . . . . . . 8 4.1. Elements and Scenario . . . . . . . . . . . . . . . . . . 7
4.2. Attribute . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Attribute . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Trust Attribute . . . . . . . . . . . . . . . . . . . 11 4.2.1. Trust Attribute . . . . . . . . . . . . . . . . . . . 10
4.2.2. DHCP-Trust Attribute . . . . . . . . . . . . . . . . . 11 4.2.2. DHCP-Trust Attribute . . . . . . . . . . . . . . . . 10
4.2.3. DHCP-Snooping Attribute . . . . . . . . . . . . . . . 12 4.2.3. DHCP-Snooping Attribute . . . . . . . . . . . . . . . 11
4.2.4. Data-Snooping Attribute . . . . . . . . . . . . . . . 12 4.2.4. Data-Snooping Attribute . . . . . . . . . . . . . . . 11
4.2.5. Validating Attribute . . . . . . . . . . . . . . . . . 13 4.2.5. Validating Attribute . . . . . . . . . . . . . . . . 11
4.2.6. Table of Mutual Exclusions . . . . . . . . . . . . . . 13 4.2.6. Table of Mutual Exclusions . . . . . . . . . . . . . 12
4.3. Perimeter . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3. Perimeter . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3.1. SAVI-DHCP Perimeter Overview . . . . . . . . . . . . . 14 4.3.1. SAVI-DHCP Perimeter Overview . . . . . . . . . . . . 13
4.3.2. SAVI-DHCP Perimeter Configuration Guideline . . . . . 14 4.3.2. SAVI-DHCP Perimeter Configuration Guideline . . . . . 13
4.3.3. On the Placement of DHCP Server/Relay . . . . . . . . 15 4.3.3. On the Placement of DHCP Server/Relay . . . . . . . . 14
5. Binding State Table (BST) . . . . . . . . . . . . . . . . . . 16 4.3.4. An alternative deployment . . . . . . . . . . . . . . 15
6. DHCP Snooping Process . . . . . . . . . . . . . . . . . . . . 17 4.3.5. Considerations on Binding Anchor . . . . . . . . . . 16
6.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Binding State Table (BST) . . . . . . . . . . . . . . . . . . 17
6.2. Binding States Description . . . . . . . . . . . . . . . . 18 6. DHCP Snooping Process . . . . . . . . . . . . . . . . . . . . 18
6.3. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 18
6.3.1. Timer Expiration Event . . . . . . . . . . . . . . . . 18 6.2. Binding States Description . . . . . . . . . . . . . . . 19
6.3.2. Control Message Arriving Events . . . . . . . . . . . 18 6.3. Events . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.4. The State Machine of DHCP Snooping Process . . . . . . . . 20 6.3.1. Timer Expiration Event . . . . . . . . . . . . . . . 19
6.4.1. From NO_BIND to INIT_BIND . . . . . . . . . . . . . . 20 6.3.2. Control Message Arriving Events . . . . . . . . . . . 19
6.4.1.1. Trigger Events . . . . . . . . . . . . . . . . . . 20 6.4. The State Machine of DHCP Snooping Process . . . . . . . 21
6.4.1.2. Following Actions . . . . . . . . . . . . . . . . 20 6.4.1. From NO_BIND to INIT_BIND . . . . . . . . . . . . . . 21
6.4.2. From INIT_BIND to Other States . . . . . . . . . . . . 21 6.4.2. From INIT_BIND to Other States . . . . . . . . . . . 22
6.4.2.1. Trigger Events . . . . . . . . . . . . . . . . . . 21 6.4.3. From BOUND to Other States . . . . . . . . . . . . . 24
6.4.2.2. Following Actions . . . . . . . . . . . . . . . . 22 6.5. Table of State Machine . . . . . . . . . . . . . . . . . 26
6.4.3. From BOUND to Other States . . . . . . . . . . . . . . 24 7. Data Snooping Process . . . . . . . . . . . . . . . . . . . . 27
6.4.3.1. Trigger Events . . . . . . . . . . . . . . . . . . 24 7.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . 27
6.4.3.2. Following Actions . . . . . . . . . . . . . . . . 24 7.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 28
6.5. Table of State Machine . . . . . . . . . . . . . . . . . . 25 7.3. Additional Binding States Description . . . . . . . . . . 28
7. Data Snooping Process . . . . . . . . . . . . . . . . . . . . 26 7.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.5. State Machine of Binding Recovery Process . . . . . . . . 30
7.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 27 7.5.1. From NO_BIND to DETECTION . . . . . . . . . . . . . . 30
7.3. Additional Binding States Description . . . . . . . . . . 28 7.5.2. From DETECTION to Other States . . . . . . . . . . . 31
7.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.5.3. From RECOVERY to Other States . . . . . . . . . . . . 32
7.5. State Machine of Binding Recovery Process . . . . . . . . 29 7.5.4. After BOUND . . . . . . . . . . . . . . . . . . . . . 33
7.5.1. From NO_BIND to DETECTION . . . . . . . . . . . . . . 29 7.6. Table of State Machine . . . . . . . . . . . . . . . . . 34
7.5.1.1. Trigger Event . . . . . . . . . . . . . . . . . . 29 8. Filtering Specification . . . . . . . . . . . . . . . . . . . 35
7.5.1.2. Following Actions . . . . . . . . . . . . . . . . 29 8.1. Data Packet Filtering . . . . . . . . . . . . . . . . . . 36
7.5.2. From DETECTION to Other States . . . . . . . . . . . . 30 8.2. Control Packet Filtering . . . . . . . . . . . . . . . . 36
7.5.2.1. Trigger Event . . . . . . . . . . . . . . . . . . 30 9. State Restoration . . . . . . . . . . . . . . . . . . . . . . 37
7.5.2.2. Following Actions . . . . . . . . . . . . . . . . 30 9.1. Attribute Configuration Restoration . . . . . . . . . . . 37
9.2. Binding State Restoration . . . . . . . . . . . . . . . . 37
7.5.3. From RECOVERY to Other States . . . . . . . . . . . . 31 10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.5.3.1. Trigger Event . . . . . . . . . . . . . . . . . . 31 11. Security Considerations . . . . . . . . . . . . . . . . . . . 38
7.5.3.2. Following Actions . . . . . . . . . . . . . . . . 32 11.1. Security Problems about the Data Snooping Process . . . 38
7.5.4. After BOUND . . . . . . . . . . . . . . . . . . . . . 33 11.2. Issues about Leaving Clients . . . . . . . . . . . . . . 38
7.5.4.1. Trigger Event . . . . . . . . . . . . . . . . . . 33 11.3. Duplicate Bindings to the Same Address . . . . . . . . . 39
7.5.4.2. Following Action . . . . . . . . . . . . . . . . . 33 11.4. Compatibility with DNA (Detecting Network Attachment) . 40
7.6. Table of State Machine . . . . . . . . . . . . . . . . . . 33 11.5. Authentication in DHCPv6 Leasequery . . . . . . . . . . 41
8. Filtering Specification . . . . . . . . . . . . . . . . . . . 34 11.6. Binding Number Limitation . . . . . . . . . . . . . . . 41
8.1. Data Packet Filtering . . . . . . . . . . . . . . . . . . 35 11.7. Privacy Considerations . . . . . . . . . . . . . . . . . 41
8.2. Control Packet Filtering . . . . . . . . . . . . . . . . . 35 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
9. State Restoration . . . . . . . . . . . . . . . . . . . . . . 36 13. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 42
9.1. Attribute Configuration Restoration . . . . . . . . . . . 36 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
9.2. Binding State Restoration . . . . . . . . . . . . . . . . 36 14.1. Normative References . . . . . . . . . . . . . . . . . . 42
10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 37 14.2. Informative References . . . . . . . . . . . . . . . . . 43
11. Security Considerations . . . . . . . . . . . . . . . . . . . 37
11.1. Security Problems about the Data Snooping Process . . . . 37
11.2. Issues about Leaving Clients . . . . . . . . . . . . . . . 37
11.3. Duplicate Bindings to the Same Address . . . . . . . . . . 38
11.4. Compatibility with DNA (Detecting Network Attachment) . . 39
11.5. Authentication in DHCPv6 Leasequery . . . . . . . . . . . 40
11.6. Binding Number Limitation . . . . . . . . . . . . . . . . 40
11.7. Residual Threats . . . . . . . . . . . . . . . . . . . . . 40
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
13. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 41
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
14.1. Informative References . . . . . . . . . . . . . . . . . . 41
14.2. Normative References . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
This document describes a fine-grained source IP address validation This document describes a fine-grained source IP address validation
mechanism. This mechanism creates bindings between addresses mechanism. This mechanism creates bindings between IP addresses
assigned to network attachment points by DHCP and suitable binding assigned to network attachment points by DHCP and suitable binding
anchors (refer to Section 3) of the attachments. Then the bindings anchors (refer to Section 3) of the attachments. Then the bindings
are used to identify and filter out packets originated from these are used to identify and filter out packets originated from these
attachments with forged source IP addresses. In this way, this attachments with forged source IP addresses. In this way, this
mechanism can prevent hosts from spoofing IP addresses assigned to mechanism can prevent hosts from spoofing IP addresses assigned to
the other attachment points. Compared with [BCP38], which provides the other attachment points. Compared with [RFC2827], which provides
prefix granularity source IP address validity, this mechanism can prefix granularity source IP address validity, this mechanism can
benefit the network with finer-grained validity and traceability of benefit the network with finer-grained validity and traceability of
source IP addresses. source IP addresses.
This mechanism primarily performs DHCP snooping to set up bindings This mechanism primarily performs DHCP snooping to set up bindings
between IP addresses assigned by DHCP and corresponding binding between IP addresses assigned by DHCP and corresponding binding
anchors. This binding process is inspired by the work of [BA2007]. anchors. This binding process is inspired by the work of [BA2007].
Different from [BA2007], which designs specifications about DHCPv4, Different from [BA2007], which designs specifications about DHCPv4,
this mechanism covers the DHCPv6 snooping process, the Data Snooping this mechanism covers the DHCPv6 snooping process, the Data Snooping
process(refer to Section 7), as well as a number of other technical process (refer to Section 7), as well as a number of other technical
details. Specially, the Data Snooping process is a data-triggered details. Specially, the Data Snooping process is a data-triggered
procedure which snoops the header of data packet to set up bindings. procedure which snoops the header of data packet to set up bindings.
It is designed to avoid permanent block of valid address in case that It is designed to avoid permanent block of valid address in case that
DHCP snooping is insufficient to set up all the valid bindings. 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, because it has nothing to do with IP address allocation. A document, because it has nothing to do with IP address allocation. A
client doing stateless DHCP acquires its IP address(es) using some client doing stateless DHCP acquires its IP address(es) using some
other mechanism. It is through that mechanism the client uses that other mechanism. The appropriate SAVI method must be based on this
SAVI must be accomplished. For example, for hosts using Stateless mechanism. For example, for hosts using Stateless Auto-configuration
Auto-configuration address, SAVI-FCFS [RFC6620] should be enabled. address, SAVI-FCFS [RFC6620] should be enabled. Besides, this
Besides, this mechanism is primarily designed for pure DHCP scenarios mechanism is primarily designed for pure DHCP scenarios in which only
in which only addresses assigned through DHCP are allowed. However, addresses assigned through DHCP are allowed. However, it does not
it does not block any link-local address. It is because link-local block any link-local address. It is because link-local addresses are
addresses are used by DHCPv6 clients before the clients are assigned used by DHCPv6 clients before the clients are assigned a DHCPv6
a DHCPv6 address. Considering that link-local addresses are address. Considering that link-local addresses are generally self-
generally self-generated, and the spoofing of link local address may generated, and the spoofing of link local address may disturb this
disturb this mechanism, it is RECOMMENDED to enable a SAVI solution mechanism, it is RECOMMENDED to enable a SAVI solution for link-local
for link-local addresses, e.g., the SAVI-FCFS [RFC6620]. addresses, e.g., the SAVI-FCFS [RFC6620].
This mechanism works with DHCPv4 and DHCPv6. However, the DHCP
address assignment mechanims in IPv4/IPv6 transition scenarios, e.g.,
[I-D.ietf-dhc-dhcpv4-over-dhcpv6], are 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 link layer Binding anchor: A "binding anchor" is defined to be a link layer
skipping to change at page 6, line 28 skipping to change at page 5, line 18
SAVI device: A network device on which this SAVI function is enabled. SAVI device: A network device on which this SAVI function is enabled.
Non-SAVI device: A network device on which this SAVI function is not Non-SAVI device: A network device on which this SAVI function is not
enabled. enabled.
DHCP Client-Server message: A message that is sent from a DHCP client DHCP Client-Server message: A message that is sent from a DHCP client
to a DHCP server or DHCP servers. Such a message is of one of the to a DHCP server or DHCP servers. Such a message is of one of the
following types: following types:
o DHCPv4 Discover: DHCPDISCOVER [RFC2131] o DHCPv4 Discover: DHCPDISCOVER [RFC2131]
o DHCPv4 Request: DHCPREQUEST generated during SELECTING state o DHCPv4 Request: DHCPREQUEST generated during SELECTING state
[RFC2131] [RFC2131]
o DHCPv4 Renew: DHCPREQUEST generated during RENEWING state o DHCPv4 Renew: DHCPREQUEST generated during RENEWING state
[RFC2131] [RFC2131]
o DHCPv4 Rebind: DHCPREQUEST generated during REBINDING state o DHCPv4 Rebind: DHCPREQUEST generated during REBINDING state
[RFC2131] [RFC2131]
o DHCPv4 Reboot: DHCPREQUEST generated during INIT-REBOOT state o DHCPv4 Reboot: DHCPREQUEST generated during INIT-REBOOT state
[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 DHCPv6 Request: REQUEST [RFC3315] o DHCPv6 Request: REQUEST [RFC3315]
o DHCPv6 Solicit: SOLICIT [RFC3315]
o DHCPv6 Confirm: CONFIRM [RFC3315] o DHCPv6 Solicit: SOLICIT [RFC3315]
o DHCPv6 Decline: DECLINE [RFC3315] o DHCPv6 Confirm: CONFIRM [RFC3315]
o DHCPv6 Release: RELEASE [RFC3315] o DHCPv6 Decline: DECLINE [RFC3315]
o DHCPv6 Rebind: REBIND [RFC3315] o DHCPv6 Release: RELEASE [RFC3315]
o DHCPv6 Renew: RENEW [RFC3315] o DHCPv6 Rebind: REBIND [RFC3315]
o DHCPv6 Renew: RENEW [RFC3315]
o DHCPv6 Information-Request: INFORMATION-REQUEST [RFC3315] o DHCPv6 Information-Request: INFORMATION-REQUEST [RFC3315]
DHCP Server-Client message: A message that is sent from a DHCP server DHCP Server-Client message: A message that is sent from a DHCP server
to a DHCP client. Such a message is of one of the following types: to a DHCP client. Such a message is of one of the following 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 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]
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: An 'permit' rule that defines a valid association Binding entry: An 'permit' rule that defines a valid association
between an IP address and a binding anchor. between an IP address and a binding anchor.
Binding State Table (BST): The data structure that contains all the Binding State Table (BST): The data structure that contains all 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 any one binding anchor. Limiting the number of be associated with any binding anchor. Limiting the number of
binding entries per binding anchor prevents a malicious or binding entries per binding anchor prevents a malicious or
malfunctioning node from overloading the binding table on a SAVI malfunctioning node from overloading the binding table on a SAVI
device. device.
Direct attachment: Ideally, a SAVI device should be an access device Direct attachment: Ideally, a SAVI device should be an access device
which is directly attached by hosts. In such case, the hosts are which is directly attached by hosts. In such case, the hosts are
direct attachments of the SAVI device. direct attachments of the SAVI device.
Indirect attachment: A SAVI device can be an aggregation device which Indirect attachment: A SAVI device can be an aggregation device which
is connected with a number of access devices, which are attached by is connected with a number of access devices, which are attached by
skipping to change at page 8, line 40 skipping to change at page 7, line 30
deployment location of SAVI devices when they only perform the DHCP deployment location of SAVI devices when they only perform the DHCP
snooping process. 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 to
detect a duplicate address by the Data Snooping Process. detect a duplicate address by the Data Snooping Process.
DHCP_DEFAULT_LEASE: default lifetime for DHCPv6 address when the DHCP_DEFAULT_LEASE: default lifetime for DHCPv6 address when the
binding the triggered by CONFIRM but LQ cannot be performed by the binding is triggered by a DHCPv6 Confirm message but a DHCPv6
SAVI device to fetch the lease. leasequery exchange [RFC5007] cannot be performed by the SAVI device
to fetch the lease.
4. Deployment Scenario and Configuration 4. Deployment Scenario and Configuration
4.1. Elements and Scenario 4.1. Elements and Scenario
A list of essential elements in a SAVI-DHCP deployment scenario is A list of essential elements in a SAVI-DHCP deployment scenario is
given as follows: given as follows:
(1) DHCP server (1) DHCP server
skipping to change at page 9, line 17 skipping to change at page 8, line 4
(2) DHCP client (2) DHCP client
(3) SAVI device (3) SAVI device
And there may be following optional elements in a SAVI-DHCP And there may be following optional elements in a SAVI-DHCP
deployment scenario: deployment scenario:
(1) DHCP relay (1) DHCP relay
(2) Non-SAVI device (2) Non-SAVI device
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 be multiple elements, e.g, a switch Note that a physical device can be multiple elements, e.g, a switch
can be both a SAVI device and a DHCP relay. In such cases, the links can be both a SAVI device and a DHCP relay. In such cases, the links
are logic links rather than physical links. are logic links rather than physical links. The "Bogus DHCP Server"
is only used to help illustrate the case in Section 4.3.3, but not a
necessary element.
+--------+ +------------+ +--------+ +------------+ +----------+
|DHCP |-----| Non-SAVI | |DHCP |-----| Non-SAVI |----|Bogus DHCP|
|Server A| | Device 1 | |Server A| | Device 1 | |Server |
+--------+ +-----|------+ +--------+ +-----|------+ +----------+
......................|............................ ......................|............................
. | upstream link . . | upstream link .
. Protection +---|------+ . . Protection +---|------+ .
. Perimeter | SAVI |--------------+ . . Perimeter | SAVI |--------------+ .
. | Device C| | . . | Device C| | .
. +---|------+ | . . +---|------+ | .
. | | . . | | .
. +----------+ +---|------+ +------|---+ . . +----------+ +---|------+ +------|---+ .
downstream . | SAVI | | Non SAVI| | SAVI | . downstream . | SAVI | | Non SAVI| | SAVI | .
link +----.-| Device A|----| Device 3|-------| Device B| . link +----.-| Device A|----| Device 3|-------| Device B| .
skipping to change at page 9, line 49 skipping to change at page 8, line 37
| '.............. | . . | | . | '.............. | . . | | .
| | . | . +--------+ | . | | . | . +--------+ | .
+----|-----+ +--|---+ . +----|-+ . +--|---+ . +---|----+ . +----|-----+ +--|---+ . +----|-+ . +--|---+ . +---|----+ .
| 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
Note: To distinguish upstream/downstream links is essential for SAVI-
DHCP.
Networks are not isolated and traffic from other networks, i.e., Networks are not isolated and traffic from other networks, i.e.,
transit traffic specified in RFC6620, may get into the network with transit traffic specified in [RFC6620], may get into the network with
SAVI-DHCP deployed through the upstream links. Since SAVI solutions SAVI-DHCP deployed through the upstream links. Since SAVI solutions
are limited to check traffic generated from local link, SAVI-DHCP is are limited to check traffic generated from local link, SAVI-DHCP is
not to set up bindings for addresses assigned in other networks. not to set up bindings for addresses assigned in other networks.
Thus, SAVI-DHCP will not set up bindings for addresses appearing on Thus, SAVI-DHCP will not set up bindings for addresses appearing on
upstream links and will not check data traffic from upstream links. upstream links and will not check data traffic from upstream links.
The traffic from upstream links should be checked by a prefix This is why to distinguish upstream/downstream links is essential for
granularity source address validation mechanism to avoid spoofing of SAVI-DHCP. The traffic from upstream links should be checked by a
local addresses from other networks. How to generate and deploy such prefix granularity source address validation mechanism to avoid
a mechanism is out of the scope of this document. spoofing of local addresses from other networks. How to generate and
deploy such a mechanism is beyond the scope of this document.
However, traffic from downstream links are generated from local However, traffic from downstream links are generated from local
network. For example, a hub, which is attached by some DHCP clients, network. For example, a hub, which is attached by some DHCP clients,
is on the downstream link of a SAVI device. The traffic from is on the downstream link of a SAVI device. The traffic from
downstream links should be checked by SAVI-DHCP if possible. downstream links should be checked by SAVI-DHCP if possible.
However, because DHCP clients on the downstream links are indirectly However, because DHCP clients on the downstream links are indirectly
attached, a number of security problems Section 11.7 can be attached, the security problem caused by shared binding anchor, as
introduced. described in Section 4.3.5, can be introduced.
4.2. Attribute 4.2. Attribute
As illustrated in Figure 1, an attachment to a SAVI device can be As illustrated in Figure 1, an attachment to a SAVI device can be
from either a DHCP client, or a DHCP relay/server, or a SAVI device, from either a DHCP client, or a DHCP relay/server, or a SAVI device,
or a non-SAVI device. Different actions are performed on traffic or a non-SAVI device. Different actions are performed on traffic
originated from different elements. To distinguish different types originated from different elements. To distinguish different types
of attachments, an attachment property named 'attribute' is of attachments, an attachment property named 'attribute' is
configured on SAVI devices. This section specifies the attributes configured on SAVI devices. This section specifies the attributes
used by SAVI-DHCP. used by SAVI-DHCP.
Before configuration, an attachment is with no attribute. An Before configuration, an attachment is with no attribute. An
attachment MAY be configured to have one or more compatible attachment MAY be configured to have one or more compatible
attributes(refer to Section 4.2.6). The attributes of each attributes (refer to Section 4.2.6). The attributes of each
attachment MUST be configured before this SAVI-DHCP function is attachment MUST be configured before the SAVI-DHCP function is
enabled on the attachment. The procedure performed by SAVI devices enabled. The procedure performed by SAVI devices on traffic from
on traffic from each attachment is determined by the attribute(s) set each attachment is determined by the attribute(s) set on the
on the attachment. attachment.
Particularly, if an attachment has no attribute, data traffic from Particularly, if an attachment has no attribute, data traffic from
such attachments will not be checked by SAVI-DHCP and will be this attachment will not be checked by SAVI-DHCP and will be
forwarded directly. This prevents SAVI-DHCP from causing a break in forwarded directly. This prevents SAVI-DHCP from causing a break in
the network when it is turned on without any binding anchors the network when it is turned on without any binding anchors
configured. However, if a binding anchor has no attributes, this configured. However, if a binding anchor has no attribute, this
means that the SAVI-DHCP-Trust attribute is not present. Because of means that the SAVI-DHCP-Trust attribute is not present. Because of
this, DHCP server-client messages from that binding anchor will be this, DHCP server-client messages associated to this binding anchor
discarded. This prevents a host from connecting to an unconfigured will be discarded. This prevents a host from connecting to an
binding anchor and acting as a DHCP server. It is SUGGESTED to unconfigured binding anchor and acting as a DHCP server. It is
configure SAVI-DHCP-Trust on necessary binding anchors before turning SUGGESTED to configure SAVI-DHCP-Trust on necessary binding anchors
on the SAVI-DHCP function. before turning on the SAVI-DHCP function.
Binding anchors associated with upstream links MAY have no attribute Binding anchors associated with upstream links MAY have no attribute
after configuration. For example, in Figure 1, the attachment from after configuration. For example, in Figure 1, the attachment from
the Non-SAVI Device 1 to the SAVI Device C should be configured with the Non-SAVI Device 1 to the SAVI Device C should be configured with
no attribute. It means 1) SAVI devices will neither set up bindings no attribute. It means 1) SAVI devices will neither set up bindings
for upstream hosts nor check traffic from upstream hosts; 2) SAVI for upstream hosts nor check traffic from upstream hosts; 2) SAVI
devices will drop DHCP server-client messages from upstream devices devices will drop DHCP server-client messages from upstream devices
unless the DHCP-Trust attribute (refer to Section 4.2.2) is set on unless the DHCP-Trust attribute (refer to Section 4.2.2) is set on
the corresponding attachment. The reason that DHCP messages from the corresponding attachment. The reason that DHCP messages from
upstream devices are not trusted is discussed in Section 4.3.3. upstream devices are not trusted is discussed in Section 4.3.3.
skipping to change at page 12, line 16 skipping to change at page 10, line 51
Server B to the SAVI Device B should be configured with this Server B to the SAVI Device B should be configured with this
attribute. It is NOT RECOMMENDED to configure this attribute on any attribute. It is NOT RECOMMENDED to configure this attribute on any
indirect attachment point of the non-neighboring DHCP servers and indirect attachment point of the non-neighboring DHCP servers and
relays, unless all the elements that can be reached through that relays, unless all the elements that can be reached through that
attachment point can be trusted, i.e., bogus DHCP Server-Client attachment point can be trusted, i.e., bogus DHCP Server-Client
messages will not be generated by these elements. For example, in messages will not be generated by these elements. For example, in
Figure 1, the attachment from the Non-SAVI Device 1 to the SAVI Figure 1, the attachment from the Non-SAVI Device 1 to the SAVI
Device C should not be configured with this attribute. This issue is Device C should not be configured with this attribute. This issue is
discussed in Section 4.3.3. discussed in Section 4.3.3.
The implementation for DHCPv6 can refer to
[I-D.ietf-opsec-dhcpv6-shield] for more details.
4.2.3. DHCP-Snooping Attribute 4.2.3. DHCP-Snooping Attribute
The "DHCP-Snooping Attribute" indicates bindings will be set up based The "DHCP-Snooping Attribute" indicates bindings will be set up based
on DHCP snooping. on DHCP snooping.
DHCP Client-Server messages from attachments with this attribute will DHCP Client-Server messages from attachments with this attribute will
trigger the setup of bindings. SAVI devices will set up bindings on trigger the setup of bindings. SAVI devices will set up bindings on
attachments with this attribute based on the DHCP snooping procedure attachments with this attribute based on the DHCP snooping procedure
described in Section 6. described in Section 6.
DHCP-Snooping attribute is configured on the attachments from DHCP DHCP-Snooping attribute is configured on the attachments from DHCP
clients. This attribute can be also used on the attachments from clients. This attribute can be also used on the attachments from
downstream Non-SAVI devices which are attached by DHCP clients. In downstream Non-SAVI devices which are attached 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 on an attachment, the "Validating
Attribute" MUST be set on the same attachment.
4.2.4. Data-Snooping Attribute 4.2.4. Data-Snooping Attribute
The "Data-Snooping Attribute" indicates data packets from the The "Data-Snooping Attribute" indicates data packets from the
corresponding attachment may trigger binding setup procedure. corresponding attachment may trigger binding setup procedure.
Data packets from attachments with this attribute may trigger the Data packets from attachments with this attribute may trigger the
setup of bindings. SAVI devices will set up bindings on attachments setup of bindings. SAVI devices will set up bindings on attachments
with this attribute based on the data-triggered process described in with this attribute based on the data-triggered process described in
Section 7. Section 7.
If DHCP-Snooping attribute is configured on an attachment, the If DHCP-Snooping attribute is configured on an attachment, the
bindings on this attachment are set up based on DHCP message bindings on this attachment are set up based on DHCP message
snooping. However, in some scenarios, a DHCP address may be used by snooping. However, in some scenarios, a DHCP address may be used by
a DHCP client without DHCP address assignment procedure performed on a DHCP client without DHCP address assignment procedure performed on
its current attachment. For such attachments, the Data-Snooping its current attachment. For such attachments, the Data-Snooping
process, which is described in Section 7, is necessary. This process, which is described in Section 7, is necessary. This
attribute is configured on such attachments. The usage of 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
Attribute" MUST be set on the same attachment.
4.2.5. Validating Attribute 4.2.5. Validating Attribute
The "Validating Attribute" indicates packets from the corresponding The "Validating Attribute" indicates packets from the corresponding
attachment will be checked based on binding entries on the attachment will be checked based on binding entries on the
attachment. attachment.
Packets coming from attachments with this attribute will be checked Packets coming from attachments with this attribute will be checked
based on binding entries on the attachment as specified in Section 8. based on binding entries on the attachment as specified in Section 8.
Validating attribute is configured on the attachments from which the Validating attribute is configured on the attachments from which the
data packets should be checked. For example, the DHCP clients. data packets should be checked. For example, the DHCP clients.
This attribute MUST be used together with "DHCP-Snooping Attribute"
or "Data-Snooping Attribute".
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 packet. Mutually exclusive attributes MUST NOT be set on the same on packet. Mutually exclusive attributes MUST NOT be set on the same
attachment. The compatibility of different attributes is listed in attachment. The compatibility of different attributes is listed in
Figure 2. Note that although Trust and DHCP-Trust are compatible, Figure 2. Note that although Trust and DHCP-Trust are compatible,
there is no need to configure DHCP-Trust on an attachment with Trust there is no need to configure DHCP-Trust on an attachment with Trust
attribute. attribute.
+----------+----------+----------+----------+----------+----------+ +----------+----------+----------+----------+----------+----------+
skipping to change at page 14, line 23 skipping to change at page 13, line 23
encloses the SAVI device. encloses the SAVI device.
The perimeter is primarily designed for scalability. This has two The perimeter is primarily designed for scalability. This has two
implications. First, SAVI devices only need to establish bindings implications. First, SAVI devices only need to establish bindings
for directly attached clients, or clients indirectly attached through for directly attached clients, or clients indirectly attached through
non-SAVI device, rather than all the clients in the network. Second, non-SAVI device, rather than all the clients in the network. Second,
each SAVI device only need to check traffic from clients attached to each SAVI device only need to check traffic from clients attached to
it, without checking all the traffic passing by. 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 Device A, B and C. In this case, SAVI device B doesn't create by SAVI Device A, B and C. In this case, SAVI device B doesn't
a binding for client A. However, because SAVI device A filters create a binding for client A. However, because SAVI device A
spoofing traffic from client A, SAVI device B can avoid receiving filters spoofing traffic from client A, SAVI device B can avoid
spoofing traffic from client A. receiving spoofing traffic from client A.
There is three main differences between the SAVI-DHCP protection
perimeter and SAVI-FCFS protection perimeter:
(1) SAVI-DHCP follows the state announced in DHCP messages, so there
is no need to distribute state using Neighbor Solicitation/
Neighbor Advertisement messages.
(2) The perimeter in SAVI-DHCP is not only a perimeter for data
packets, but also a perimeter for DHCP messages. The placement
of DHCP Relay/Server, which is not involved in SAVI-FCFS , is
related with the construction of the perimeter. The requirement
on the placement and configuration of DHCP Relay/Server are
discussed in Section 4.3.3.
(3) Downstream/upstream links MUST be distinguished when configuring The perimeter in SAVI-DHCP is not only a perimeter for data packets,
the perimeter to avoid establishing binding for addresses of but also a perimeter for DHCP messages. The placement of DHCP Relay/
other networks. Server, which is not involved in [RFC6620] , is related with the
construction of the perimeter. The requirement on the placement and
configuration of DHCP Relay/Server are discussed in Section 4.3.3.
4.3.2. SAVI-DHCP Perimeter Configuration Guideline 4.3.2. SAVI-DHCP Perimeter Configuration Guideline
Through configuring attribute of each attachment properly, a Through configuring attribute of each attachment properly, a
perimeter separating untrusted area and trusted area can be formed: perimeter separating untrusted area and trusted area MUST be formed
as follows:
(1) Configure Validating and DHCP-Snooping attribute on the direct (1) Configure Validating and DHCP-Snooping attribute on the direct
attachments of all the DHCP clients. attachments of all the DHCP clients.
(2) Configure Validating and DHCP-Snooping attribute on the indirect (2) Configure Validating and DHCP-Snooping attribute on the indirect
attachments of all the DHCP clients(i.e., DHCP clients on the attachments of all the DHCP clients (i.e., DHCP clients on the
downstream links). downstream links).
(3) Configure Trust attribute on the attachments of other SAVI (3) Configure Trust attribute on the attachments of other SAVI
devices. devices.
(4) If a Non-SAVI device, or a number of connected Non-SAVI devices, (4) If a Non-SAVI device, or a number of connected Non-SAVI devices,
have only attachments from SAVI devices or upstream devices, set have only attachments from SAVI devices, set their attachments to
their attachments to SAVI devices with Trust attribute. SAVI devices with Trust attribute.
(5) Configure DHCP-Trust attribute on the direct attachments of (5) Configure DHCP-Trust attribute on the direct attachments of
trusted DHCP relays/servers. trusted DHCP relays/servers.
(6) Optional: configure filters on the upstream links to filter out
spoofing of local addresses from other networks. If the
upstream networks are completely trustable, Trust attribute can
be used on the upstream links.
In this way, the points of attachments with Validating attribute (and In this way, the points of attachments with Validating attribute (and
generally together with attachments of upstream devices) on SAVI generally together with attachments of upstream devices) on SAVI
devices can form a perimeter separating DHCP clients and trusted devices can form a perimeter separating DHCP clients and trusted
devices. Data packet check is only performed on the perimeter. The devices. Data packet check is only performed on the perimeter. The
perimeter is also a perimeter for DHCP messages. DHCP-Trust perimeter is also a perimeter for DHCP messages. DHCP-Trust
attribute is only configured on the inside links of the perimeter. attribute is only configured on the inside links of the perimeter.
Only DHCP server-client messages originated in the perimeter is Only DHCP server-client messages originated in the perimeter are
trusted. trusted.
4.3.3. On the Placement of DHCP Server/Relay 4.3.3. On the Placement of DHCP Server/Relay
Based on the configuration guideline, it can be found that the SAVI Based on the configuration guideline, it can be found that the SAVI
devices only trust DHCP Server-Client messages originated inside the devices only trust DHCP Server-Client messages originated inside the
perimeter. It means the trusted DHCP relays/servers must be placed perimeter. It means the trusted DHCP relays/servers must be placed
in the perimeter. DHCP server-client messages will be filtered on in the perimeter. DHCP server-client messages will be filtered on
the perimeter (Note: server-relay messages will not be filtered). In the perimeter (Note: server-relay messages will not be filtered). In
this way, DHCP server-client messages from bogus DHCP servers are this way, DHCP server-client messages from bogus DHCP servers are
filtered on the perimeter, and then the SAVI devices can be protected filtered on the perimeter, and then the SAVI devices can be protected
from fabricated DHCP messages. from forged DHCP messages.
Such a requirement is due to the limitation of this binding based Such a requirement is due to the limitation of this binding based
mechanism. This document makes no assumption that the DHCP server- mechanism. This document makes no assumption that the DHCP server-
client messages arriving the perimeter from the outside can be client messages arriving the perimeter from the outside can be
trusted. The binding anchor of a trusted remote DHCP server can be trusted. The binding anchor of a trusted remote DHCP server can be
shared by a bogus DHCP server. Thus, the SAVI device cannot shared by a bogus DHCP server. Thus, the SAVI device cannot
distinguish bogus and valid DHCP messages only based on the distinguish bogus and valid DHCP messages only based on the
associated binding anchor of DHCP messages in such case. associated binding anchor of DHCP messages in such case.
Note that even if a DHCP server is valid, it may be not contained in Note that even if a DHCP server is valid, it may be not contained in
the perimeter based on the guideline. For example, in Figure 1, DHCP the perimeter based on the guideline. For example, in Figure 1, DHCP
server A is valid, but it is attached to a Non-SAVI device. The Non- server A is valid, but it is attached to a Non-SAVI device. The Non-
SAVI device may be attached by attackers which generate fabricated SAVI device may be attached by attackers which generate forged DHCP
DHCP messages. This binding based mechanism may not have the ability messages. This binding based mechanism may not have the ability to
to distinguish whether a message received from the attachment of the distinguish whether a message received from the attachment of the
Non-SAVI device 1 is from DHCP server A or the attackers. If the Non-SAVI device 1 is from DHCP server A or the attackers. If the
DHCP server A is contained in the perimeter, the Non-SAVI device 1 DHCP server A is contained in the perimeter, the Non-SAVI device 1
will also be contained in the perimeter. However, the Non-SAVI will also be contained in the perimeter. However, the Non-SAVI
device 1 can introduce fabricated DHCP messages into the perimeter. device 1 can introduce forged DHCP messages into the perimeter.
Thus, the DHCP server A cannot be contained in the perimeter. Thus, the DHCP server A cannot be contained in the perimeter.
In this case, the SAVI devices can set up bindings for addresses In this case, the SAVI devices can set up bindings for addresses
assigned by DHCP server A through snooping the messages relayed by assigned by DHCP server A through snooping the messages relayed by
trusted relay in the network. For example, the DHCP relay may relay trusted relay in the network. For example, the DHCP relay may relay
messages between DHCP server A and the clients in the network, and messages between DHCP server A and the clients in the network, and
the SAVI devices can snoop messages from the DHCP relay which is the SAVI devices can snoop messages from the DHCP relay which is
inside the perimeter. The authentication mechanism (i.e., IPSec, as inside the perimeter. The authentication mechanism (i.e., IPsec, as
specified in section 21.1 of [RFC3315]) enforced between the DHCP specified in section 21.1 of [RFC3315]) enforced between the DHCP
relay and the DHCP server outside the perimeter can compensate this relay and the DHCP server outside the perimeter can compensate this
binding based mechanism. It is SUGGESTED to configure IPSec between binding based mechanism. It is SUGGESTED to configure IPsec between
the DHCP relay and the DHCP server in such case. If source address the DHCP relay and the DHCP server in such case. If source address
validation is enforced in the whole network, which makes the source validation is enforced in the whole network, which makes the source
IP address trustable, the DHCP relay and the DHCP server can simply IP address trustable, the DHCP relay and the DHCP server can simply
authenticate the messages from each other based on the source IP authenticate the messages from each other based on the source IP
address without the requirement to deploy IPSec. address. Nevertheless, it should be noted that the integrity of the
messages is not ensured.
Another consideration on the placement is that if the DHCP server/ Another consideration on the placement is that if the DHCP server/
relay is not inside the perimeter, the SAVI devices may not be able relay is not inside the perimeter, the SAVI devices may not be able
to set up bindings correctly, because the SAVI devices may not be on to set up bindings correctly, because the SAVI devices may not be on
the path between the clients and the server/relay, or the DHCP the path between the clients and the server/relay, or the DHCP
messages are encapsulated (e.g., Relay-reply and Relay-forward). messages are encapsulated (e.g., Relay-reply and Relay-forward).
4.3.4. An alternative deployment
In a number of deployment practices, the traffic from the upstream
network are all treated as trustable. In such a case, Trust
attribute can be set on the upstream link; and if a Non-SAVI device,
or a number of connected Non-SAVI devices, have only attachments from
SAVI devices and upstream devices, their attachment to SAVI devices
can be set Trust attribute. Then an unclosed perimeter will be
formed, as illustrate in Figure 3.
| . . Protection |
| | | Perimeter |
| | | |
| Upstream | | Upstream |
| Link | | Link |
| | | |
| | | |
| +--------+ +--------+ +--------+ |
| |SAVI |----|Non-SAVI|----|SAVI | |
| |Device | |Device | |Device | |
| +--------+ +--------+ +--------+ |
| | | |
\________________________________________________/
| |
| |
+--------+ +--------+
|DHCP | |DHCP |
|Client | |Client |
+--------+ +--------+
Figure 3: Alternative Perimeter Configuration
To configure such a perimeter, at least the DHCP messages from
upstream networks MUST be ensured to be trustable. How to achieve
this is beyond the scope of this document.
4.3.5. Considerations on Binding Anchor
The strength of this binding based mechanism depends on the strength
of the binding anchor. If the binding anchor is spoofable, e.g.,
plain MAC address, an attacker can use forged binding anchor to send
packet which will not be regarded as spoofing by SAVI device.
Indeed, using binding anchor that can be easily spoofed can lead to
worse outcomes than allowing IP spoofing traffic. For example, an
attacker can use the binding anchor of another client to bind a large
number of addresses, and the SAVI device will refuse to set up new
binding for the client whenever the binding number limitation has
been reached; as a result, even the legitimate clients cannot access
the network. Thus, it is RECOMMENDED to use unspoofable binding
anchor, e.g., switch port. This document only focuses on switch port
as binding anchor. The implications of using other forms of binding
anchors should be properly analyzed.
If the binding anchor is shared by more than one clients, the clients
can spoof each other addresses. For example, if a switch port is
used as binding anchor, a number of clients can attach to the same
switch port of a SAVI device through a hub. The SAVI device cannot
distinguish packets from different clients and thus the spoofing
between them will not be detected. A number of the above security
problems are caused by sharing binding anchors. For example, an
attacker can send a DHCP Release message to remove the binding of a
client sharing the same binding anchor. Thus, it is RECOMMENDED to
use exclusive binding anchor.
5. Binding State Table (BST) 5. Binding State Table (BST)
Binding State Table is used to contain the bindings between the IP Binding State Table is used to contain the bindings between the IP
addresses assigned to the attachments and the corresponding binding addresses assigned to the attachments and the corresponding binding
anchors of the attachments. Each entry of the table, i.e., binding anchors of the attachments. Each entry of the table, i.e., binding
entry, has 5 fields: entry, has 5 fields:
o Binding Anchor(Anchor): the binding anchor, i.e., a link-layer o Binding Anchor(Anchor): the binding anchor, i.e., a link-layer
property of the attachment. property of the attachment.
o IP Address(Address): the IP address assigned to the attachment by o IP Address(Address): the IP address assigned to the attachment by
DHCP. 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. The Lifetime o Lifetime: the remaining seconds of the binding. The Lifetime
field counts down automatically. field counts down automatically.
o TID: the Transaction ID (TID) (refer to [RFC2131] [RFC3315]) of o TID: the Transaction ID (TID) (refer to [RFC2131] [RFC3315]) of
the corresponding DHCP transaction. TID field is used to the corresponding DHCP transaction. TID field is used to
associate DHCP Server-Client messages with corresponding binding associate DHCP Server-Client messages with corresponding binding
entries. entries.
IA does not present in the BST. On the one hand, IA is not found to IA does not present in the BST because the lease of each address in
be necessary because the lease of each address in one IA is assigned one IA is assigned respectively. Another reason is, when the binding
respectively. On the other hand, when the binding is set up based on is set up based on data-snooping, IA cannot be recovered from the
data-snooping, IA cannot be recovered from the leasequery protocol. leasequery protocol. Last reason is there is no IA for DHCPv4.
Besides, there is no IA for DHCPv4.
An instance of this table is shown in Figure 3. An instance of this table is shown in Figure 4.
+---------+----------+----------+-----------+-------+ +---------+----------+----------+-----------+-------+
| Anchor | Address | State | Lifetime |TID | | Anchor | Address | State | Lifetime |TID |
+---------+----------+----------+-----------+-------+ +---------+----------+----------+-----------+-------+
| Port_1 | IP_1 | BOUND | 65535 |TID_1 | | Port_1 | IP_1 | BOUND | 65535 |TID_1 |
+---------+----------+----------+-----------+-------+ +---------+----------+----------+-----------+-------+
| Port_1 | IP_2 | BOUND | 10000 |TID_2 | | Port_1 | IP_2 | BOUND | 10000 |TID_2 |
+---------+----------+----------+-----------+-------+ +---------+----------+----------+-----------+-------+
| Port_2 | IP_3 |INIT_BIND | 1 |TID_3 | | Port_2 | IP_3 |INIT_BIND | 1 |TID_3 |
+---------+----------+----------+-----------+-------+ +---------+----------+----------+-----------+-------+
Figure 3: Instance of BST Figure 4: Instance of BST
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, named DHCP Snooping Process. This process is DHCP snooping, named DHCP Snooping Process. This process is
illustrated making use of a state machine. illustrated making use of 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
skipping to change at page 19, line 36 skipping to change at page 20, line 15
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.
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-Client messages and o Attribute check: the DHCP Server-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-Client messages should be o Destination check: the DHCP Server-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
have matched binding anchor with the corresponding entry. have matched binding anchor with the corresponding entry.
o TID check: the DHCP Server-Client/Client-Server messages which o TID check: the DHCP Server-Client/Client-Server messages which may
may cause modification on existing binding entries must have cause modification on existing binding entries must have matched
matched TID with the corresponding entry. Note that this check TID with the corresponding entry. Note that this check is not
is not performed on Leasequery and Leasequery-reply messages as performed on Leasequery and Leasequery-reply messages as they are
they are exchanged between the SAVI devices and the DHCP servers. exchanged between the SAVI devices and the DHCP servers. Besides,
Besides, this check is not performed on DHCP Renew/Rebind this check is not performed on DHCP Renew/Rebind messages
messages (Section 6.4.3). (Section 6.4.3).
o Binding limitation check: the DHCP messages must not cause new o Binding limitation check: the DHCP 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.6). been reached. (refer to Section 11.6).
o Address check: the source address of the DHCP messages should o Address check: the source address of the DHCP messages should pass
pass the check specified in Section 8.2. the check specified in Section 8.2.
On receiving a DHCP message without triggering a valid event, the On receiving a DHCP message without triggering a valid event, the
state will not transit and actions will not be performed. Note that state will not transit and actions will not be performed. Note that
if a message does not trigger a valid event but it can pass the if a message does not trigger a valid event but it can pass the
checks in Section 8.2, it MUST be forwarded. checks in Section 8.2, it MUST be forwarded.
6.4. The State Machine of DHCP Snooping Process 6.4. The State Machine of DHCP Snooping Process
This section specifies the transits of each state and the This section specifies the transits of each state and the
corresponding actions. corresponding actions.
skipping to change at page 20, line 47 skipping to change at page 21, line 31
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 or DHCPv4 Reboot, the Address field can be set to the address
to request, i.e., the 'requested IP address'. An example of the to request, i.e., the 'requested IP address'. An example of the
entry is illustrated in Figure 4. entry is illustrated in Figure 5.
+---------+-------+---------+-----------------------+-------+ +---------+-------+---------+-----------------------+-------+
| Anchor |Address| State | Lifetime |TID | | Anchor |Address| State | Lifetime |TID |
+---------+-------+---------+-----------------------+-------+ +---------+-------+---------+-----------------------+-------+
| Port_1 | |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | | Port_1 | |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID |
+---------+-------+---------+-----------------------+-------+ +---------+-------+---------+-----------------------+-------+
Figure 4: Binding entry in BST on Request/Rapid Commit/Reboot Figure 5: Binding entry in BST on Request/Rapid Commit/Reboot
triggered initialization triggered initialization
If the triggering event is EVE_DHCP_CONFIRM: If the triggering event is EVE_DHCP_CONFIRM:
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
all the addresses in each the IA option of the Confirm message. The all the addresses in each the IA option of the Confirm message. The
Binding anchor field is set to the binding anchor of the attachment Binding anchor field is set to the binding anchor of the attachment
from which the message is received. The State field is set to from which the message is received. The State field is set to
skipping to change at page 21, line 23 skipping to change at page 22, line 4
If the triggering event is EVE_DHCP_CONFIRM: If the triggering event is EVE_DHCP_CONFIRM:
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
all the addresses in each the IA option of the Confirm message. The all the addresses in each the IA option of the Confirm message. The
Binding anchor field is set to the binding anchor of the attachment Binding anchor field is set to the binding anchor of the attachment
from which the message is received. The State field is set to from which the message is received. The State field is set to
INIT_BIND. The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. INIT_BIND. The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME.
The TID field is set to the TID of the message. The Address field is The TID field is set to the TID of the message. The Address field is
set to the address(es) to confirm. An example of the entries is set to the address(es) to confirm. An example of the entries is
illustrated in Figure 5. illustrated in Figure 6.
+---------+--------+---------+-----------------------+-------+ +---------+--------+---------+-----------------------+-------+
| Anchor | Address| State | Lifetime |TID | | Anchor | Address| State | Lifetime |TID |
+---------+--------+---------+-----------------------+-------+ +---------+--------+---------+-----------------------+-------+
| Port_1 | Addr1 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | | Port_1 | Addr1 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID |
+---------+--------+---------+-----------------------+-------+ +---------+--------+---------+-----------------------+-------+
| Port_1 | Addr2 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | | Port_1 | Addr2 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID |
+---------+--------+---------+-----------------------+-------+ +---------+--------+---------+-----------------------+-------+
Figure 5: Binding entry in BST on Confirm triggered initialization Figure 6: Binding entry in BST on Confirm triggered initialization
6.4.2. From INIT_BIND to Other States 6.4.2. From INIT_BIND to Other States
6.4.2.1. Trigger Events 6.4.2.1. Trigger Events
Trigger events: EVE_DHCP_REPLY, EVE_ENTRY_EXPIRE. Trigger events: EVE_DHCP_REPLY, EVE_ENTRY_EXPIRE.
Note: If no DHCP Server-Client messages which assign addresses or Note: If no DHCP Server-Client messages which assign addresses or
confirm addresses are received, corresponding entries will expire confirm addresses are received, corresponding entries will expire
automatically. Thus, other DHCP Server-Client messages (e.g., DHCPv4 automatically. Thus, other DHCP Server-Client messages (e.g., DHCPv4
skipping to change at page 22, line 43 skipping to change at page 23, line 21
message is in response to a Confirm message. The state of the message is in response to a Confirm message. The state of the
binding entries with matched TID is changed to BOUND. Because binding entries with matched TID is changed to BOUND. Because
[RFC3315] does not require lease time of addresses to be contained in [RFC3315] does not require lease time of addresses to be contained in
the Reply message, the SAVI device SHOULD send a LEASEQUERY [RFC5007] the Reply message, the SAVI device SHOULD send a LEASEQUERY [RFC5007]
message querying by IP address to All_DHCP_Servers multicast address message querying by IP address to All_DHCP_Servers multicast address
[RFC3315] or a list of configured DHCP server addresses. The [RFC3315] or a list of configured DHCP server addresses. The
Leasequery message is generated for each IP address if multiple Leasequery message is generated for each IP address if multiple
addresses are confirmed. The Lifetime of corresponding entries is addresses are confirmed. The Lifetime of corresponding entries is
set to 2*MAX_LEASEQUERY_DELAY. If there is no response message after set to 2*MAX_LEASEQUERY_DELAY. If there is no response message after
MAX_LEASEQUERY_DELAY, send the LEASEQUERY message again. An example MAX_LEASEQUERY_DELAY, send the LEASEQUERY message again. An example
of the entries is illustrated in Figure 6. The related security of the entries is illustrated in Figure 7. The related security
problem about DHCPv6 LEASEQUERY is discussed in Section 11.5. If the problem about DHCPv6 LEASEQUERY is discussed in Section 11.5. If the
SAVI device does not send the LEASEQUERY message, a pre-configured SAVI device does not send the LEASEQUERY message, a pre-configured
lifetime DHCP_DEFAULT_LEASE MUST be set on the corresponding entry. lifetime DHCP_DEFAULT_LEASE MUST be set on the corresponding entry.
(Note: it is SUGGESUTED to use T1 configured on DHCP servers as the (Note: it is SUGGESUTED to use T1 configured on DHCP servers as the
DHCP_DEFAULT_LEASE.) DHCP_DEFAULT_LEASE.)
2.2 If there are IA options in the Reply message, the SAVI device 2.2 If there are IA options in the Reply message, the SAVI device
checks each IA option. When the first assigned address is found, the checks each IA option. When the first assigned address is found, the
Address field of the binding entry with matched TID is set to the Address field of the binding entry with matched TID is set to the
address. The Lifetime field is set to the sum of the lease time in address. The Lifetime field is set to the sum of the lease time in
Reply message and MAX_DHCP_RESPONSE_TIME. The State field is changed Reply message and MAX_DHCP_RESPONSE_TIME. The State field is changed
to BOUND. If there are more than one address assigned in the to BOUND. If there are more than one address assigned in the
message, new binding entries are set up for the remaining address message, new binding entries are set up for the remaining address
assigned in the IA options. An example of the entries is illustrated assigned in the IA options. An example of the entries is illustrated
in Figure 7. SAVI devices do not specially process IA options with in Figure 8. SAVI devices do not specially process IA options with
NoAddrsAvail status, because there should be no address contained in NoAddrsAvail status, because there should be no address contained in
such IA options. such IA options.
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 |
+---------+----------+-------+------------------------+-------+ +---------+----------+-------+------------------------+-------+
| Port_1 | Addr1 | BOUND | 2*MAX_LEASEQUERY_DELAY |TID | | Port_1 | Addr1 | BOUND | 2*MAX_LEASEQUERY_DELAY |TID |
+---------+----------+-------+------------------------+-------+ +---------+----------+-------+------------------------+-------+
| Port_1 | Addr2 | BOUND | 2*MAX_LEASEQUERY_DELAY |TID | | Port_1 | Addr2 | BOUND | 2*MAX_LEASEQUERY_DELAY |TID |
+---------+----------+-------+------------------------+-------+ +---------+----------+-------+------------------------+-------+
Figure 6: 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
+---------+----------+-------+------------------------+-------+ +---------+----------+-------+------------------------+-------+
| Anchor | Address | State | Lifetime |TID | | Anchor | Address | State | Lifetime |TID |
+---------+----------+-------+------------------------+-------+ +---------+----------+-------+------------------------+-------+
| Port_1 | Addr1 | BOUND |Lease time+ |TID | | Port_1 | Addr1 | BOUND |Lease time+ |TID |
| | | |MAX_DHCP_RESPONSE_TIME | | | | | |MAX_DHCP_RESPONSE_TIME | |
+---------+----------+-------+------------------------+-------+ +---------+----------+-------+------------------------+-------+
| Port_1 | Addr2 | BOUND |Lease time+ |TID | | Port_1 | Addr2 | BOUND |Lease time+ |TID |
| | | |MAX_DHCP_RESPONSE_TIME | | | | | |MAX_DHCP_RESPONSE_TIME | |
+---------+----------+-------+------------------------+-------+ +---------+----------+-------+------------------------+-------+
Figure 7: 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
If the trigger event is EVE_ENTRY_EXPIRE: If the trigger event is EVE_ENTRY_EXPIRE:
The entry MUST be deleted from BST. The entry MUST be deleted from BST.
6.4.3. From BOUND to Other States 6.4.3. From BOUND to Other States
6.4.3.1. Trigger Events 6.4.3.1. Trigger Events
skipping to change at page 25, line 36 skipping to change at page 26, line 20
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 Timeout Remove entry NO_BIND INIT_BIND Timeout Remove entry NO_BIND
BOUND RLS/DCL Remove entry NO_BIND BOUND RLS/DCL Remove entry NO_BIND
BOUND Timeout Remove entry NO_BIND BOUND Timeout 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 8: Table of Transit Figure 9: Table of Transit
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
skipping to change at page 26, line 34 skipping to change at page 27, line 26
+-------------+ +------------+ +-------------+ +------------+
| | 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 9: 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 on the attachment of the DHCP client. This is the case
stands when the SAVI device is persistently on the path(s) from the stands when the SAVI device is persistently on the path(s) from the
DHCP client to the DHCP server(s)/relay(s). However, there are two DHCP client to the DHCP server(s)/relay(s). However, there are two
case when this does not work: case when this does not work:
o Multiple paths: there is more than one feasible layer-2 paths o Multiple paths: there is more than one feasible layer-2 paths from
from the client to the DHCP server/relay, and the SAVI device is the client to the DHCP server/relay, and the SAVI device is not on
not on everyone of them. The client may get its address through everyone of them. The client may get its address through one of
one of the paths not passing by the SAVI device, but packets from the paths not passing by the SAVI device, but packets from the
the client can travel through paths that pass through the SAVI client can travel through paths that pass through the SAVI device.
device. Because the SAVI device could not snoop the DHCP packet Because the SAVI device could not snoop the DHCP packet exchange
exchange procedure, the DHCP snooping procedure cannot set up the procedure, the DHCP snooping procedure cannot set up the
corresponding binding. corresponding binding.
o Dynamic path: there is only one feasible layer-2 path from the o Dynamic path: there is only one feasible layer-2 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 turns broken due to
failure or as planned) or layer-2 path change. This situation failure or as planned) or layer-2 path change. This situation
also covers the local-link movement of clients without address also covers the local-link movement of clients without address
confirm/re-configuration process. For example, a host changes confirm/re-configuration process. For example, a host changes its
its attached switch port in a very short time. In such cases, attached switch port in a very short time. In such cases, the
the DHCP snooping process will not set up the corresponding DHCP snooping process will not set up the corresponding binding.
binding.
Data Snooping Process prevents permanently blocking legitimate Data Snooping Process prevents permanently blocking legitimate
traffic in case of these two exceptions. This process is performed traffic in case of these two exceptions. This process is performed
on attachments with the Data-Snooping attribute. Data packets on attachments with the Data-Snooping attribute. Data packets
without matching binding entry may trigger this process to set up without matching binding entry may trigger this process to set up
bindings. 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 a
skipping to change at page 28, line 42 skipping to change at page 29, line 30
EVE_DATA_LEASEQUERY: EVE_DATA_LEASEQUERY:
IPv4: A DHCPLEASEACTIVE message with IP Address Lease Time option IPv4: A DHCPLEASEACTIVE message with IP Address Lease Time option
is received. is received.
IPv6: A successful LEASEQUERY-REPLY is received. IPv6: A successful LEASEQUERY-REPLY is 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 DHCP 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.6). been reached. (refer to Section 11.6).
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 Leasequery messages must pass the check specified in DHCP Leasequery messages must pass the check specified in
Section 8.2. For EVE_DATA_CONFLICT, the source address and Section 8.2. For EVE_DATA_CONFLICT, the source address and target
target address of the ARP or NA messages must pass the check address of the ARP or NA messages must pass the check specified in
specified in Section 8.2. 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 o TID check: the DHCPLEASEACTIVE/LEASEQUERY-REPLY messages must have
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 o Prefix check: the source address of the data packet should be of a
a valid local prefix, as specified in section 7 of [RFC7039]. valid local prefix, as specified in section 7 of [RFC7039].
7.5. State Machine of Binding Recovery Process 7.5. State Machine of Binding Recovery Process
Through using additional states, the state machine of this process Through using additional states, the state machine of this process
doesn't conflict the regular process described in Section 6. Thus, doesn't conflict the regular process described in Section 6. Thus,
it can be implemented separately without changing the state machine it can be implemented separately without changing the state machine
in Section 6. in Section 6.
7.5.1. From NO_BIND to DETECTION 7.5.1. From NO_BIND to DETECTION
skipping to change at page 29, line 48 skipping to change at page 30, line 35
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 be source address of the packet. Set the State field to field to be source address of the packet. Set the State field to
DETECTION. Set the Lifetime of the created entry to DETECTION. Set the Lifetime of the created entry to
2*DETECTION_TIMEOUT. 2*DETECTION_TIMEOUT.
Check if the address has a local conflict (it violates an address Check if the address has a local conflict (it violates an address
being used by another node): being used by another node):
(1) IPv4 address: send an Address Resolution Protocol (ARP) Request (1) IPv4 address: send an Address Resolution Protocol (ARP) Request
[RFC826]or a ARP probe [RFC5227] on the address; if there is no [RFC0826]or a ARP probe [RFC5227] on the address; if there is no
response message after DETECTION_TIMEOUT, send another ARP response message after DETECTION_TIMEOUT, send another ARP
Request or ARP probe; Request or ARP probe;
(2) IPv6 address: send a Neighbor Solicitation message [RFC4861] (2) IPv6 address: send a Neighbor Solicitation message [RFC4861]
targeting on the address; if there is no response message after targeting on the address; if there is no response message after
DETECTION_TIMEOUT, send another Neighbor Solicitation message. DETECTION_TIMEOUT, send another Neighbor Solicitation message.
Because the delivery of detection message is unreliable, the Because the delivery of detection message is unreliable, the
detection message may fail to reach the targeting node. If there is detection message may fail to reach the targeting node. If there is
a node that has the IP address seen in the Data Snooping Process, it a node that has the IP address seen in the Data Snooping Process, it
may not get the detection messages. This failure mode enables an may not get the detection messages. This failure mode enables an
attack against the Data Snooping Process. Thus, the detection is attack against the Data Snooping Process. Thus, the detection is
performed again if there is no response after the first detection. performed again if there is no response after the first detection.
The messages MUST NOT be sent to the attachment from which the The messages MUST NOT be sent to the attachment from which the
triggering packet is received. triggering packet is received.
The packet which triggers this event SHOULD be discarded. The packet which triggers this event SHOULD be discarded.
This local conflict process SHOULD be performed. If it is not This local conflict process SHOULD be performed. If it is not
performed, the state of the entry is set to RECOVERY, the lifetime is performed, the state of the entry is set to RECOVERY, the lifetime is
set to 2*MAX_LEASEQUERY_DELAY, and the lease query process specified set to 2*MAX_LEASEQUERY_DELAY, and the lease query process specified
in the following section will be performed directly. in the following section will be performed directly.
An example of the entry is illustrated in Figure 10. An example of the entry is illustrated in Figure 11.
+---------+-------+---------+-----------------------+-------+ +---------+-------+---------+-----------------------+-------+
| Anchor |Address| State | Lifetime |TID | | Anchor |Address| State | Lifetime |TID |
+---------+-------+---------+-----------------------+-------+ +---------+-------+---------+-----------------------+-------+
| Port_1 | Addr1 |DETECTION|2*DETECTION_TIMEOUT | | | Port_1 | Addr1 |DETECTION|2*DETECTION_TIMEOUT | |
+---------+-------+---------+-----------------------+-------+ +---------+-------+---------+-----------------------+-------+
Figure 10: Binding entry in BST on data triggered initialization Figure 11: Binding entry in BST on data triggered initialization
7.5.2. From DETECTION to Other States 7.5.2. From DETECTION to Other States
7.5.2.1. Trigger Event 7.5.2.1. Trigger Event
Trigger events: EVE_ENTRY_EXPIRE, EVE_DATA_CONFLICT. Trigger events: EVE_ENTRY_EXPIRE, EVE_DATA_CONFLICT.
7.5.2.2. Following Actions 7.5.2.2. Following Actions
If the trigger event is EVE_ENTRY_EXPIRE: If the trigger event is EVE_ENTRY_EXPIRE:
(1) IPv4 address: Send a DHCPLEASEQUERY [RFC4388] message querying (1) IPv4 address: Send a DHCPLEASEQUERY [RFC4388] message querying
by IP address to each DHCPv4 server with IP Address Lease Time by IP address to each DHCPv4 server with IP Address Lease Time
option (option 51). A list of authorized DHCP servers are kept option (option 51). A list of authorized DHCP servers are kept
by the SAVI device. The list should be pre-configured or by the SAVI device. The list should be pre-configured or
discovered by sending DHCPv4 Discover messages and parsing the discovered by sending DHCPv4 Discover messages and parsing the
replied DHCPv4 Offer messages. Change the state of the replied DHCPv4 Offer messages. Change the state of the
corresponding entry to RECOVERY. Change the lifetime 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 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 TID used in the DHCPLEASEQUERY message. If there is no response
message after MAX_LEASEQUERY_DELAY, send a DHCPLEASEQUERY to message after MAX_LEASEQUERY_DELAY, send a DHCPLEASEQUERY to each
each DHCPv4 server again. DHCPv4 server again.
(2) IPv6 address: Send a LEASEQUERY [RFC5007] message querying by IP (2) IPv6 address: Send a LEASEQUERY [RFC5007] message querying by IP
address to All_DHCP_Relay_Agents_and_Servers multicast address address to All_DHCP_Relay_Agents_and_Servers multicast address or
or a list of pre-configured DHCPv6 server addresses. Change the a list of pre-configured DHCPv6 server addresses. Change the
state of the corresponding entry to RECOVERY. Change the state of the corresponding entry to RECOVERY. Change the
lifetime of the entry to be 2*MAX_LEASEQUERY_DELAY. The TID lifetime of the entry to be 2*MAX_LEASEQUERY_DELAY. The TID
field is set to the TID used in the LEASEQUERY message. If field is set to the TID used in the LEASEQUERY message. If there
there is no response message after MAX_LEASEQUERY_DELAY, send is no response message after MAX_LEASEQUERY_DELAY, send the
the LEASEQUERY message again. LEASEQUERY message again.
An example of the entry is illustrated in Figure 11. An example of the entry is illustrated in Figure 12.
+---------+-------+---------+-----------------------+-------+ +---------+-------+---------+-----------------------+-------+
| Anchor |Address| State | Lifetime |TID | | Anchor |Address| State | Lifetime |TID |
+---------+-------+---------+-----------------------+-------+ +---------+-------+---------+-----------------------+-------+
| Port_1 | Addr1 |RECOVERY |2*MAX_LEASEQUERY_DELAY |TID | | Port_1 | Addr1 |RECOVERY |2*MAX_LEASEQUERY_DELAY |TID |
+---------+-------+---------+-----------------------+-------+ +---------+-------+---------+-----------------------+-------+
Figure 11: Binding entry in BST on Lease Query Figure 12: Binding entry in BST on Lease Query
If the trigger event is EVE_DATA_CONFLICT: If the trigger event is EVE_DATA_CONFLICT:
Remove the entry. Remove the entry.
7.5.3. From RECOVERY to Other States 7.5.3. From RECOVERY to Other States
7.5.3.1. Trigger Event 7.5.3.1. Trigger Event
Trigger events: EVE_ENTRY_EXPIRE, EVE_DATA_LEASEQUERY. Trigger events: EVE_ENTRY_EXPIRE, EVE_DATA_LEASEQUERY.
7.5.3.2. Following Actions 7.5.3.2. Following Actions
If the trigger event is EVE_DATA_LEASEQUERY: If the trigger event is EVE_DATA_LEASEQUERY:
IPv4 address: IPv4 address:
(1) Send an ARP Request with the Target Protocol Address set to the (1) Send an ARP Request with the Target Protocol Address set to the
IP address in the corresponding entry. The ARP Request is only IP address in the corresponding entry. The ARP Request is only
sent to the attachment which triggers the binding. If there is sent to the attachment which triggers the binding. If there is
no response after DETECTION_TIMEOUT, send another ARP Request. no response after DETECTION_TIMEOUT, send another ARP Request.
If there is still no response, the following actions will not be If there is still no response, the following actions will not be
performed. If there is only one identical response, get the performed. If there is only one identical response, get the
sender hardware address. Check if the 'chaddr' field (hardware sender hardware address. Check if the 'chaddr' field (hardware
address) of the DHCPLEASEACTIVE message matches the sender address) of the DHCPLEASEACTIVE message matches the sender
hardware address. If the two addresses do not match, the hardware address. If the two addresses do not match, the
following actions will not be performed. If there is more than following actions will not be performed. If there is more than
one response, if any of the sender hardware addresses matches one response, if any of the sender hardware addresses matches the
the 'chaddr' field (hardware address) of the DHCPLEASEACTIVE 'chaddr' field (hardware address) of the DHCPLEASEACTIVE message,
message, the following actions are to be performed. the following actions are to be performed.
(2) Change the state of the corresponding binding to BOUND. Set (2) Change the state of the corresponding binding to BOUND. Set
life time to the sum of the value encoded in IP Address Lease life time to the sum of the value encoded in IP Address Lease
Time option of the DHCPLEASEACTIVE message and Time option of the DHCPLEASEACTIVE message and
MAX_DHCP_RESPONSE_TIME. Erase the TID field. MAX_DHCP_RESPONSE_TIME. Erase the TID field.
IPv6 address: IPv6 address:
(1) Send a Neighbor Solicitation message with the target address set (1) Send a Neighbor Solicitation message with the target address set
to the IP address in the corresponding entry. The Neighbor to the IP address in the corresponding entry. The Neighbor
Solicitation is only sent to the attachment which triggers the Solicitation is only sent to the attachment which triggers the
binding. If there is no response after DETECTION_TIMEOUT, send binding. If there is no response after DETECTION_TIMEOUT, send
another Neighbor Solicitation. If there is still no response, another Neighbor Solicitation. If there is still no response,
the following actions will not be performed. the following actions will not be performed.
(2) Change the state of the corresponding binding to BOUND. Set the (2) Change the state of the corresponding binding to BOUND. Set the
lifetime to the sum of the valid lifetime extracted from lifetime to the sum of the valid lifetime extracted from
OPTION_CLIENT_DATA option in the LEASEQUERY-REPLY message and OPTION_CLIENT_DATA option in the LEASEQUERY-REPLY message and
MAX_DHCP_RESPONSE_TIME. Erase the TID field. MAX_DHCP_RESPONSE_TIME. Erase the TID field.
(3) After the above checks, if multiple addresses are specified in (3) After the above checks, if multiple addresses are specified in
the LEASEQUERY-REPLY message and there are no corresponding the LEASEQUERY-REPLY message and there are no corresponding
binding entries, new entries MUST also be created binding entries, new entries MUST also be created correspondingly
correspondingly on the same binding anchor. on the same binding anchor.
If responses are received from multiple DHCP servers, the conflict If responses are received from multiple DHCP servers, the conflict
resolution mechanisms specified in section 6.8 of [RFC4388] and resolution mechanisms specified in section 6.8 of [RFC4388] and
section 4.3.4 of [RFC5007] will be used to determine which message section 4.3.4 of [RFC5007] will be used to determine which message
should be used. should be used.
If the trigger event is EVE_ENTRY_EXPIRE: If the trigger event is EVE_ENTRY_EXPIRE:
Remove the entry. Remove the entry.
skipping to change at page 33, line 39 skipping to change at page 34, line 22
The main state transits are listed as follows. The main state transits are listed as follows.
State Event Action Next State State Event Action Next State
NO_BIND EVE_DATA_UNMATCH Duplication detection DETECTION NO_BIND EVE_DATA_UNMATCH Duplication detection DETECTION
DETECTION Timeout Send Leasequery RECOVERY DETECTION Timeout Send Leasequery RECOVERY
DETECTION EVE_DATA_CONFLICT Remove entry NO_BIND DETECTION EVE_DATA_CONFLICT Remove entry NO_BIND
RECOVERY EVE_DATA_LEASEQUERY Set lease time BOUND or NO_BIND RECOVERY EVE_DATA_LEASEQUERY Set lease time BOUND or NO_BIND
RECOVERY Timeout Remove entry NO_BIND RECOVERY Timeout Remove entry NO_BIND
BOUND RENEW/REBIND Record TID BOUND BOUND RENEW/REBIND Record TID BOUND
Figure 12: Table of Transit Figure 13: Table of Transit
RENEW: EVE_DHCP_RENEW RENEW: EVE_DHCP_RENEW
REBIND: EVE_DHCP_REBIND REBIND: EVE_DHCP_REBIND
Timeout: EVE_ENTRY_EXPIRE Timeout: EVE_ENTRY_EXPIRE
+-------------+ +-------------+
| | | |
/---------| NO_BIND |<--------\ /---------| NO_BIND |<--------\
| ------>| | | TIMEOUT | ------>| | | TIMEOUT
skipping to change at page 34, line 30 skipping to change at page 35, line 30
+-------------+ +------------+ +-------------+ +------------+
EVE_DATA_LEASEQUERY| EVE_DATA_LEASEQUERY|
/----------\ (+ 2x DETECTION) | /----------\ (+ 2x DETECTION) |
EVE_DHCP_RENEW| | | EVE_DHCP_RENEW| | |
EVE_DHCP_REBIND| +-----v-------+ | EVE_DHCP_REBIND| +-----v-------+ |
| | | | | | | |
\----| BOUND |<----------/ \----| BOUND |<----------/
| | | |
+-------------+ +-------------+
Figure 13: Diagram of Transit Figure 14: Diagram of Transit
LQ_DELAY: MAX_LEASEQUERY_DELAY LQ_DELAY: MAX_LEASEQUERY_DELAY
8. Filtering Specification 8. Filtering Specification
This section specifies how to use bindings to filter out spoofing This section specifies how to use bindings to filter out spoofing
packets. packets.
Filtering policies are different for data packets and control Filtering policies are different for data packets and control
packets. DHCP and NDP (Neighbor Discovery Protocol) [RFC4861] packets. DHCP and NDP (Neighbor Discovery Protocol) [RFC4861]
skipping to change at page 35, line 30 skipping to change at page 36, line 30
Data packets from attachments with no attribute will forwarded Data packets from attachments with no attribute will forwarded
without checking. without checking.
The SAVI device MAY record any violation. The SAVI device MAY record any violation.
8.2. Control Packet Filtering 8.2. Control Packet Filtering
For attachments with the Validating attribute: For attachments with the Validating attribute:
Discard DHCPv4 Client-Server message messages whose source IP address DHCPv4 Client-Server messages where source IP address is neither all
is neither all zeros nor bound with the corresponding binding anchor zeros nor bound with the corresponding binding anchor in the BST MUST
in the BST. be discarded.
Discard DHCPv6 Client-Server message messages whose source IP address DHCPv6 Client-Server messages where source IP address is neither a
is neither a link-local address nor bound with the corresponding link-local address nor bound with the corresponding binding anchor in
binding anchor in the BST. the BST MUST be discarded.
Discard NDP messages whose source IP address is neither a link-local NDP messages where source IP address is neither a link-local address
address nor bound with the corresponding binding anchor. Especially, nor bound with the corresponding binding anchor MUST be discarded.
discard NA message whose target address is neither a link-local
address nor bound with the corresponding binding anchor.
Discard ARP messages whose protocol is IP and sender protocol address NA messages where target address is neither a link-local address nor
is neither all zeros address nor bound with the corresponding binding bound with the corresponding binding anchor MUST be discarded.
anchor. Especially, discard ARP Reply messages whose target protocol
address is not bound with the corresponding binding anchor. ARP messages where protocol is IP and sender protocol address is
neither all zeros address nor bound with the corresponding binding
anchor MUST be discarded.
ARP Reply messages where target protocol address is not bound with
the corresponding binding anchor MUST be discarded.
For attachments with other attributes: For attachments with other attributes:
Discard DHCP Server-Client message not from attachments with the DHCP Server-Client messages not from attachments with the DHCP-Trust
DHCP-Trust attribute or Trust attribute. attribute or Trust attribute MUST be discarded.
For attachments with no attribute: For attachments with no attribute:
Discard DHCP Server-Client message from such attachments. DHCP Server-Client messages from such attachments MUST be discarded.
The SAVI device MAY record any violation. The SAVI device MAY record any violation.
9. State Restoration 9. State Restoration
If a SAVI device reboots, the information kept in volatile memory If a SAVI device reboots, the information kept in volatile memory
will be lost. This section specifies the restoration of attribute will be lost. This section specifies the restoration of attribute
configuration and BST. configuration and BST.
9.1. Attribute Configuration Restoration 9.1. Attribute Configuration Restoration
skipping to change at page 37, line 25 skipping to change at page 38, line 25
DETECTION_TIMEOUT 0.5s DETECTION_TIMEOUT 0.5s
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 have a minimum Data Snooping Processes on one attachment MUST have a minimum
interval time DATA_SNOOPING_INTERVAL. This constant SHOULD be interval time DATA_SNOOPING_INTERVAL. This constant SHOULD be
configured prudently to avoid Denial of Service attacks. configured prudently to avoid Denial of Service attacks.
(2) The Data Snooping Process may set up wrong bindings if the (2) The Data Snooping Process may set up wrong bindings if the
clients do not reply to the detection probes. An attack will clients do not reply to the detection probes. An attack will
pass the duplicate detection if the client assigned the target pass the duplicate detection if the client assigned the target
address does not reply to the detection probes. The DHCP address does not reply to the detection probes. The DHCP
Leasequery procedure performed by the SAVI device just tells Leasequery procedure performed by the SAVI device just tells
whether the address is assigned in the network or not. However, whether the address is assigned in the network or not. However,
the SAVI device cannot determine whether the address is just the SAVI device cannot determine whether the address is just
assigned to the triggering attachment from the DHCP Leasequery assigned to the triggering attachment from the DHCP Leasequery
Reply. Reply.
11.2. Issues about Leaving Clients 11.2. Issues about Leaving Clients
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 leave temporarily due to link flapping, or attachment point. It may leave temporarily due to link flapping, or
permanently by moving to a new attachment point or leaving the permanently by moving to a new attachment point or leaving the
network. Since the client may return shortly, the binding should be network. Since the client may return shortly, the binding should be
kept, or legitimate traffic from the client will be blocked. kept, or legitimate traffic from the client will be blocked.
However, if the client leaves permanently, it may be insecure to keep However, if the client leaves permanently, it may be insecure to keep
the binding. If the binding anchor is a property of the attachment the binding. If the binding anchor is a property of the attachment
point rather than the client, e.g., the switch port, an attacker point rather than the client, e.g., the switch port, an attacker
which is attached to the attachment point of the leaving client can which is attached to the attachment point of the leaving client can
send spoofing packets with the addresses assigned to the client. send spoofing packets with the addresses assigned to the client.
Even if the binding anchor is a property of the client, it is a waste Even if the binding anchor is a property of the client, it is a waste
of binding resources to keep bindings for departed clients. of binding resources to keep bindings for departed clients.
The following mechanism is designed to handle the leaving of client: SAVI-DHCP handles the leaving of directly attached clients. Whenever
a direct client leaves, a link-down event associated with the binding
anchor will be triggered. SAVI-DHCP monitors such events, and
perform the following mechanism.
(1) Whenever a client with the Validating attribute leaves, a timer (1) Whenever a client with the Validating attribute leaves, a timer
of duration OFFLINK_DELAY is set on the corresponding binding of duration OFFLINK_DELAY is set on the corresponding binding
entries. entries.
(2) If a DAD Neighbor Solicitation/Gratuitous ARP request is (2) If a DAD Neighbor Solicitation/Gratuitous ARP request is
received that targets the address during OFFLINK_DELAY, the received that targets the address during OFFLINK_DELAY, the entry
entry MAY be removed. MAY be removed.
(3) If the client returns on-link during OFFLINK_DELAY, cancel the (3) If the client returns on-link during OFFLINK_DELAY, cancel the
timer. timer.
In this way, the bindings of a departing client are kept for In this way, the bindings of a departing client are kept for
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 leaving of indirect clients, because it
will not be notified of such events. Then the threats illustrated at
the beginning of this section will be introduced. If SAVI-DHCP is
enabled on indirect DHCP clients, this problem should be well
understood.
11.3. Duplicate Bindings to the Same Address 11.3. Duplicate Bindings to the Same Address
The same address may be bound to multiple binding anchors only if the The same address may be bound to multiple binding anchors only if the
binding setup processes successfully complete for each binding binding setup processes successfully complete for each binding
anchor. This mechanism is designed to address the case where a anchor. This mechanism is designed to address the case where a
client moves on the local link, and the case where a client has client moves on the local link, and the case where a client has
multiple attachments to a SAVI device. multiple attachments to a SAVI device.
There are two security issues with such a design: There are two security issues with such a design:
skipping to change at page 40, line 7 skipping to change at page 41, line 9
unbound address is used as the sender protocol address. As a result, unbound address is used as the sender protocol address. As a result,
the client will regard the address under detection is valid. the client will regard the address under detection is valid.
However, the data traffic will be filtered. The DHCP Request message However, the data traffic will be filtered. The DHCP Request message
sent by the client will not be discarded, because the source IP sent by the client will not be discarded, because the source IP
address field should be all zero as required by [RFC2131]. Thus, if address field should be all zero as required by [RFC2131]. Thus, if
the address is still valid, the binding will be recovered from the the address is still valid, the binding will be recovered from the
DHCP Snooping Process. DHCP Snooping Process.
11.5. Authentication in DHCPv6 Leasequery 11.5. Authentication in DHCPv6 Leasequery
As required in section 5 of RFC5007, DHCPv6 Leasequery 'Should' use As required in section 5 of [RFC5007], DHCPv6 Leasequery 'Should' use
IPsec-based authentication specified in the section 21.1 of RFC3315. IPsec-based authentication specified in the section 21.1 of
However, with the deployment of this mechanism, there may be no need [RFC3315]. However, IPsec is generally considered heavyweight. With
to enforce IPSec to perform DHCP Leasequery. the deployment of this mechanism, the source IP address can be
authenticated without enforcing IPsec.
By containing the DHCP servers in the protection perimeter, the DHCP By containing the DHCP servers in the protection perimeter, the DHCP
servers can be protected from spoofing based attacks. Then by servers can be protected from spoofing based attacks. Then by
checking the source IP address of Leasequery messages, the DHCP checking the source IP address of Leasequery messages, the DHCP
server can identify if the messages are from SAVI devices or not. server can identify if the messages are from SAVI devices or not.
For the SAVI devices, because the perimeter filters out bogus DHCP For the SAVI devices, because the perimeter filters out bogus DHCP
messages, they can trust the DHCP Leasequery responses. Thus, there messages, they can trust the DHCP Leasequery responses.
is no need to enforce IPSec to validate the DHCP Leasequery messages
in this mechanism. Again, it should be noted that although SAVI-DHCP can help
authenticate the origin, it does not protect the integrity of the
messages. If DHCPv6 Leasequery is performed without enforcing IPsec,
this threat must be taken into account.
11.6. Binding Number Limitation 11.6. Binding Number Limitation
A binding entry will consume a certain high-speed memory resources. A binding entry will consume a certain high-speed memory resources.
In general, a SAVI device can afford only a quite limited number of In general, a SAVI device can afford only a quite limited number of
binding entries. In order to prevent an attacker from overloading binding entries. In order to prevent an attacker from overloading
the resource of the SAVI device, a binding entry limit is set on each the resource of the SAVI device, a binding entry limit is set on each
attachment. The binding entry limit is the maximum number of attachment. The binding entry limit is the maximum number of
bindings supported on each attachment with Validating attribute. No bindings supported on each attachment with Validating attribute. No
new binding should be set up after the limit has been reached. If a new binding should be set up after the limit has been reached. If a
DHCP Reply assigns more addresses than the remaining binding entry DHCP Reply assigns more addresses than the remaining binding entry
quota of each client, the message will be discarded and no binding quota of each client, the message will be discarded and no binding
will be set up. will be set up.
11.7. Residual Threats 11.7. Privacy Considerations
As described in [RFC7039], this solution cannot strictly prevent
spoofing. There are two scenarios in which spoofing can still
happen:
(1) The binding anchor is spoofable. If the binding anchor is
spoofable, e.g., plain MAC address, an attacker can use forged
binding anchor to send packet which will not be regarded as
spoofing by SAVI device. Indeed, using binding anchor that can
be easily spoofed is more serious than allowing IP spoofing
traffic. For example, an attacker can use the binding anchor of
another client to get a large number of addresses, and the SAVI
device will refuse to set up new binding for the client whenever
the binding number limitation has been reached. Thus, it is
RECOMMENDED to use strong enough binding anchor, e.g., switch
port, secure association in 802.11ae/af and 802.11i.
(2) The binding anchor is shared by more than one clients. If the A SAVI device MUST delete binding anchor information as soon as
binding anchor is shared by more than one clients, the clients possible (i.e., as soon as the state for a given address is back to
can spoof each other addresses. For example, if a switch port NO_BIND), except where there is an identified reason why that
is used as binding anchor, a number of clients can attach to the information is likely to be involved in the detection, prevention, or
same switch port of a SAVI device through a hub. The SAVI tracing of actual source address spoofing. Information about the
device cannot distinguish packets from different clients and majority of hosts that never spoof SHOULD NOT be logged.
thus the spoofing between them will not be detected. A number
of the above security problems are caused by sharing binding
anchors. If binding anchor is shared, TID spoofing based attack
is possible. Thus, it is RECOMMENDED to use exclusive binding
anchor.
12. IANA Considerations 12. IANA Considerations
This memo asks the IANA for no new parameters. This memo asks the IANA for no new parameters.
Note to RFC Editor: This section will have served its purpose if it Note to RFC Editor: This section will have served its purpose if it
correctly tells IANA that no new assignments or registries are correctly tells IANA that no new assignments or registries are
required, or if those assignments or registries are created during required, or if those assignments or registries are created during
the RFC publication process. From the authors' perspective, it may the RFC publication process. From the authors' perspective, it may
therefore be removed upon publication as an RFC at the RFC Editor's therefore be removed upon publication as an RFC at the RFC Editor's
skipping to change at page 41, line 45 skipping to change at page 42, line 33
Thanks to Mark Williams, Erik Nordmark, Mikael Abrahamsson, David Thanks to Mark Williams, Erik Nordmark, Mikael Abrahamsson, David
Harrington, Pekka Savola, Xing Li, Lixia Zhang, Bingyang Liu, Duanqi Harrington, Pekka Savola, Xing Li, Lixia Zhang, Bingyang Liu, Duanqi
Zhou, Robert Raszuk, Greg Daley, John Kaippallimalil and Tao Lin for Zhou, Robert Raszuk, Greg Daley, John Kaippallimalil and Tao Lin for
their valuable contributions. their valuable contributions.
This document was generated using the xml2rfc tool. This document was generated using the xml2rfc tool.
14. References 14. References
14.1. Informative References 14.1. Normative References
[BA2007] Baker, F., "Cisco IP Version 4 Source Guard", IETF
Internet draft (work in progress), November 2007.
[BCP38] Paul, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", RFC 2827, BCP 38, May 2000.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
14.2. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, Match 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt,
RFC 2131, March 1997. "Source Address Validation Improvement (SAVI) Framework",
RFC 7039, October 2013.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
Protocol (DHCP) Leasequery", RFC 4388, February 2006. 2131, March 1997.
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. SAVI: First-Come, First-Served Source Address Validation
Improvement for Locally Assigned IPv6 Addresses", RFC
6620, May 2012.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
"DHCPv6 Leasequery", RFC 5007, September 2007. Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for
Detecting Network Attachment in IPv6", RFC 6059, November
2010.
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982.
[RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227,
July 2008. July 2008.
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
Detecting Network Attachment in IPv6", RFC 6059, "DHCPv6 Leasequery", RFC 5007, September 2007.
November 2010.
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS- [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration
SAVI: First-Come First-Serve Source-Address Validation for Protocol (DHCP) Leasequery", RFC 4388, February 2006.
Locally Assigned Addresses", RFC 6620, May 2012.
[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., [I-D.ietf-opsec-dhcpv6-shield]
"Source Address Validation Improvement Framework", Gont, F., Will, W., and G. Velde, "DHCPv6-Shield:
RFC 7039, October 2013. Protecting Against Rogue DHCPv6 Servers", draft-ietf-
opsec-dhcpv6-shield-03 (work in progress), June 2014.
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or [I-D.ietf-dhc-dhcpv4-over-dhcpv6]
converting network protocol addresses to 48.bit Ethernet Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
address for transmission on Ethernet hardware", RFC 826, Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc-
November 1982. dhcpv4-over-dhcpv6-09 (work in progress), June 2014.
14.2. Informative References
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[BA2007] Baker, F., "Cisco IP Version 4 Source Guard", IETF
Internet draft (work in progress), November 2007.
Authors' Addresses Authors' Addresses
Jun Bi Jun Bi
Tsinghua University Tsinghua University
Network Research Center, Tsinghua University Network Research Center, Tsinghua University
Beijing 100084 Beijing 100084
China China
Email: junbi@tsinghua.edu.cn EMail: junbi@tsinghua.edu.cn
Jianping Wu Jianping Wu
Tsinghua University Tsinghua University
Computer Science, Tsinghua University Computer Science, Tsinghua University
Beijing 100084 Beijing 100084
China China
Email: jianping@cernet.edu.cn EMail: jianping@cernet.edu.cn
Guang Yao Guang Yao
Tsinghua University Tsinghua University
Network Research Center, Tsinghua University Network Research Center, Tsinghua University
Beijing 100084 Beijing 100084
China China
Email: yaoguang@cernet.edu.cn EMail: yaoguang@cernet.edu.cn
Fred Baker Fred Baker
Cisco Systems Cisco Systems
Santa Barbara, CA 93117 Santa Barbara, CA 93117
United States United States
Email: fred@cisco.com EMail: fred@cisco.com
 End of changes. 145 change blocks. 
452 lines changed or deleted 509 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/