SAVI J. Bi, J. Wu, G. Yao
Internet Draft CERNET
Intended status: Standard Tracks F. Baker
Expires: September 2010 Cisco
March 8, 2010
SAVI Solution for DHCP
draft-ietf-savi-dhcp-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to publish it
as an RFC and to translate it into languages other than English.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November 10,
2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 8, 2010.
Bi Expires September 8, 2010 [Page 1]
Internet-Draft savi-dhcp March 2010
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Abstract
This document specifies the procedure for creating bindings between a
DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and an
anchor (refer to [SAVI-framework]) on SAVI (Source Address Validation
Improvements) device. The bindings can be used to filter packets
generated on the local link with forged IP addresses.
Table of Contents
1. Introduction...................................................3
2. Conventions used in this document..............................4
3. Mechanism Overview.............................................4
4. Background and Related Protocols...............................4
5. Terminology....................................................5
6. Conceptual Data Structures.....................................5
6.1. Binding State Table (BST).................................5
6.2. Filtering Table (FT)......................................5
7. Binding States Description.....................................6
8. DHCP Scenario..................................................6
9. Anchor Attributes..............................................7
9.1. SAVI-Validation Attribute.................................7
9.2. SAVI-DHCP-Trust Attribute.................................7
9.3. SAVI-SAVI Attribute.......................................8
10. Prefix Configuration..........................................8
11. Binding Set Up................................................9
11.1. Process of DHCP Snooping.................................9
11.1.1. Initialization......................................9
11.1.1.1. Trigger Event..................................9
11.1.1.2. Event Validation...............................9
11.1.1.3. Following Actions.............................10
Bi Expires September 8, 2010 [Page 2]
Internet-Draft savi-dhcp March 2010
11.1.2. From START to LIVE.................................10
11.1.2.1. Trigger Event.................................10
11.1.2.2. Event Validation..............................10
11.1.2.3. Following Actions.............................10
11.1.3. From LIVE to DETECTION.............................12
11.1.3.2. Event Validation..............................12
11.1.3.3. Following Actions.............................12
11.1.4. From DETECTION to BOUND............................13
11.1.4.1. Trigger Event.................................13
11.1.4.2. Following Actions.............................13
11.1.5. After BOUND........................................13
11.2. State Machine of DHCP Snooping..........................14
12. Filtering Specification......................................15
12.1. Data Packet Filtering...................................16
12.2. Control Packet Filtering................................16
13. Format and Delivery of Probe Messages........................17
13.1. Duplicate detection.....................................17
14. Binding Remove...............................................17
15. Handle Anchor Off-link event.................................18
16. About Collision in Detection.................................18
16.1. Whether to notify the DHCP server.......................18
16.2. The result of detection without host aware..............18
17. Filtering during detection...................................18
18. Binding Number Limitation....................................19
19. Movement without DHCP Procedure..............................19
20. MLD Consideration............................................19
21. State Restoration............................................19
22. Constants....................................................20
23. Security Considerations......................................20
24. IANA Considerations..........................................20
25. References...................................................20
25.1. Normative References....................................20
25.2. Informative References..................................21
26. Acknowledgments..............................................21
1. Introduction
This document describes the procedure for creating bindings between
DHCP assigned addresses and an anchor (refer to [savi-framework]).
Other related details about this procedure are also specified in this
document.
These bindings can be used to filter packets with forged IP addresses.
How to use these bindings is specified in [savi-framework], depending
on the environment and configuration. The definition and examples of
anchor is also specified in [savi-framework].
Bi Expires September 8, 2010 [Page 3]
Internet-Draft savi-dhcp March 2010
The binding process is inspired by the work of IP Source Guard. This
specification differs from IP Source Guard in the specification for
collision detection, which is essential in environments with multiple
address assignment methods.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Mechanism Overview
The mechanism specified in this document is designed to provide a
host level source IP address validation granularity, as a supplement
to BCP38 [BCP38]. This mechanism is deployed on the access device
(including access switch, wireless access point/controller, etc), and
performs mainly DHCP snooping to set up bindings between DHCP
assigned IP addresses and corresponding anchors. The bindings can be
used to validate the source address in the packets.
4. Background and Related Protocols
This mechanism is an instance of a SAVI [savi-framework] solution,
specialized for addresses assigned using the DHCP protocol.
Dynamic Host Configuration Protocol version 4 [RFC2131] and Dynamic
Host Configuration Protocol version 6 [RFC3315] specify the
procedures for providing a client with assigned address and other
configuration information from a DHCP server. If a client gets an
address through the DHCP protocol, the address should be regarded as
a potential "authorized" or "registered" address of the client.
In IPv6, IPv6 Stateless Autoconfiguration [RFC4862] is used as
another address assignment mechanism. A node can use this mechanism
to auto-configure an IPv6 address. A DHCPv6 client may use a
stateless address to send message to DHCP server. Even in a DHCPv6-
only environment, a node must assign its link-local address through
this mechanism. [RFC4862] clearly requires that duplicated address
detection must be performed on any IPv6 address, including DHCPv6
address.
[RFC4861] specifies the Neighbor Discovery protocol, which is an
essential part of IPv6 address assignment.
[RFC5227] specifies the procedure to detect IPv4 address collision.
It is not required currently. However, this feature is useful to
Bi Expires September 8, 2010 [Page 4]
Internet-Draft savi-dhcp March 2010
determine the uniqueness of an IPv4 address on the link. Considering
not all the operating systems support [RFC5227], this solution is
designed to be compatible with operating systems not complying with
[RFC5227].
5. Terminology
Main terms used in this document are described in [savi-framework],
[RFC2131] and [RFC3315].
6. Conceptual Data Structures
This section describes the possible conceptual data structures used
in this mechanism.
Two main data structures are used to record bindings and their states
respectively. There is redundancy between the two structures, for the
consideration of separation of data plane and control plane.
6.1. Binding State Table (BST)
This table contains the state of binding between source address and
anchor. Entries are keyed on the anchor and source IP address. Each
entry has a lifetime field recording the remaining lifetime of the
entry, a state field recording the state of the binding and a field
recording other information.
+---------+----------+-------+-----------+-------+
| Anchor | Address | State | Lifetime |Other |
+---------+----------+-------+-----------+-------+
| A | IP_1 | Bound | 65535 | |
+---------+----------+-------+-----------+-------+
| A | IP_2 | Bound | 10000 | |
+---------+----------+-------+-----------+-------+
| B | IP_3 |_Start | 1 | |
+---------+----------+-------+-----------+-------+
Figure 1 Instance of BST
6.2. Filtering Table (FT)
This table contains the bindings between anchor and address, keyed on
anchor. This table doesn't contain any state of the binding. This
table is only used to filter packets. An Access Control List can be
regarded as a practical instance of this table.
Bi Expires September 8, 2010 [Page 5]
Internet-Draft savi-dhcp March 2010
+---------+----------+
|Anchor |Address |
+---------+----------+
|A |IP_1 |
+---------+----------+
|A |IP_2 |
+---------+----------+
Figure 2 Instance of FT
7. Binding States Description
This section describes the binding states of this mechanism.
START A DHCP request (or a DHCPv6 Confirm, or a DHCPv6
Solicitation with Rapid Commit option) has been received from host,
and it may trigger a new binding.
LIVE A DHCP address has been acknowledged by a DHCP server.
DETECTION A gratuitous ARP or Duplicate Address Detection NSOL
has been sent by the host (or the SAVI device).
BOUND The address has passed duplicate detection and
it is bound with the anchor.
8. DHCP Scenario
Figure 3 shows the main elements in a DHCP enabled network. At least
one DHCP server MUST be deployed in the network, and DHCP relay MAY
be used to relay message between client and server. Other address
assignment mechanisms may be also used in such network.
Bi Expires September 8, 2010 [Page 6]
Internet-Draft savi-dhcp March 2010
+--------+
| DHCP |
| Server |
+-------,+
|
|
|
+----'-----+
| SAVI |
| Device |
+-/------/-+
| |
+----\-+ +\-----+
|DHCP | |Client|
|Relay | | |
+------+ +------+
Figure 3 DHCP Scenario
9. Anchor Attributes
This section specifies the anchor attributes involved in this
mechanism.
Anchor is defined in the [savi-framework]. Attribute of each anchor
is configurable. In default, anchor has no attribute. An anchor MAY
be configured to have one or more compatible attributes. However, an
anchor MAY have no attribute.
If an anchor has no attribute, server type DHCP message from this
anchor MUST be dropped. However, other packets SHOULD NOT be dropped.
9.1. SAVI-Validation Attribute
If and only if source address validation must be performed on the
traffic from an anchor, this anchor MUST be set to have SAVI-
Validation attribute. The filtering process on anchor with such
attribute is described in section 12.
9.2. SAVI-DHCP-Trust Attribute
If and only if an anchor is associated with a trustable DHCP
server/relay, it SHOULD be set to have this attribute.
If DHCP is used to assign address in the network, there MUST be at
least one anchor with this attribute. DHCP Reply message not coming
from such ports MUST be dropped.
Bi Expires September 8, 2010 [Page 7]
Internet-Draft savi-dhcp March 2010
9.3. SAVI-SAVI Attribute
If and only if an anchor is associated with another SAVI device, it
SHOULD be set to have this attribute. All traffic from anchor with
this attribute will be forwarded without check.
This attribute is mutually exclusive with SAVI-Validation.
10. Prefix Configuration
In DHCP scenario, address advertised by DHCP server should be
believed in. However, in this solution, a node shares the same anchor
as the DHCP server can disguise as the DHCP server and offer the
client incorrect configuration information. Without fully deployment
of SAVI, this problem is difficult to solve. Thus, it is SUGGESTED
that correct address prefix should be configured, and DHCP server
message which assigns address out of the scope should be dropped.
This mechanism can ensure the client can at least get an address with
proper prefix.
This document suggests set 3 prefix scopes:
IPv4 Prefix:
The allowed scope of any kind of IPv4 addresses. It can be set
manually.
IPv6 SLAAC Prefixes:
The allowed scope of SLAAC and manually configured IPv6
addresses. It can be set through snooping RA message from port
with SAVI-RA-Trust attribute, DHCP-PD or manual configuration.
FE80::/64 MUST be set to a feasible prefix.
IPv6 DHCPv6 Prefixes:
The allowed scope of DHCPv6 addresses. It can be set through RA
snooping, DHCP-PD protocol, or manual configuration.
There is no need to explicitly present these prefix scopes. But these
restrictions SHOULD be used as premier check in binding set up.
Refer to security consideration for other discussions.
Bi Expires September 8, 2010 [Page 8]
Internet-Draft savi-dhcp March 2010
11. Binding Set Up
This section specifies the procedure of setting up bindings based on
control packet snooping. All binding entries are set up on anchor
with SAVI-Validation attribute.
11.1. Process of DHCP Snooping
11.1.1. Initialization
A binding entry is initialized in this step.
This step MAY NOT be performed if:
1. Option 82 is used to keep anchor in DHCP Request and Reply, or
2. Unspoofable MAC is used as anchor(802.11i,802.1ae/af), or
3. The mapping table from MAC to anchor is secure.
If none of these three requirements are satisfied, this step SHOULD
be performed.
If this step is not performed, then binding entry will be initialized
in the next step.
This step is performed for the consideration that anchor and DHCP
assigned address can be bound with security in the next step.
Otherwise the security of binding setup is based on the mapping
mechanism from MAC to anchor on SAVI device, which may be vulnerable.
This step can also help limit the request rate of client to prevent
Denial of Services attack against DHCP server.
11.1.1.1. Trigger Event
A DHCPv4/v6 Request or a DHCPv6 Confirm or a DHCPv6 Solicitation with
Rapid Commit option is received.
11.1.1.2. Event Validation
The SAVI device checks current BST as follows:
1. Whether the limitation on binding entry number of this anchor will
be exceeded if a new entry is triggered.
Bi Expires September 8, 2010 [Page 9]
Internet-Draft savi-dhcp March 2010
11.1.1.3. Following Actions
If the check is passed:
The SAVI device MUST forward the message.
The SAVI device MUST generate an entry for the anchor in the Binding
State Table (BST) and set the state field to START. The lifetime of
this entry MUST set to be MAX_DHCP_RESPONSE_TIME. The Transaction ID
(Refer to Section 2 in [RFC2131] and Section 4.2 in [RFC3315]) field
of the request packet SHOULD be recorded in the entry.
+---------+----------+-------+-----------------------+-------+
| Anchor | Address | State | Lifetime |Other |
+---------+----------+-------+-----------------------+-------+
| A | | START |MAX_DHCP_RESPONSE_TIME | TID |
+---------+----------+-------+-----------------------+-------+
Figure 4 Binding entry in BST on initialization
The TID is kept for assurance that the assigned address can be bound
with anchor securely. It is suggested to keep TID in entry. However,
TID MAY NOT be contained in the entry.
11.1.2. From START to LIVE
11.1.2.1. Trigger Event
A DHCPv4 DHCPACK or DHCPv6 REPLY message is received.
11.1.2.2. Event Validation
The SAVI device checks the message and BST as follows:
1. Whether the message is received from an anchor which has the SAVI-
DHCP-Trust attribute;
2. Whether the entry in the BST with corresponding TID is in the
START state. Or if the prior step is not performed, check whether
the binding number limitation will be exceeded.
11.1.2.3. Following Actions
If the check is passed:
The SAVI device MUST deliver the message to the destination.
Bi Expires September 8, 2010 [Page 10]
Internet-Draft savi-dhcp March 2010
The SAVI device MUST set the state of the corresponding entry to be
LIVE. If prior step is not performed, a new entry MUST be generated
in the BST. The lifetime of the entry MUST be set to be
MAX_ARP_PREPARE_DELAY or MAX_DAD_PREPARE_DELAY respectively. The
lease time MUST be recorded in the entry.
+---------+----------+-------+------------------------+-------+
| Anchor | Address | State | Lifetime |Other |
+---------+----------+-------+------------------------+-------+
| A | Addr | LIVE |MAX_ARP_PREPARE_DELAY or| Lease |
| | | |MAX_DAD_PREPARE_DELAY | Time |
+---------+----------+-------+------------------------+-------+
Figure 5 Binding entry in BST on assignment
Then, the SAVI device MAY set the state of the corresponding entry to
be DETECTION, and send two or more ARP Request or NSOL for the
assigned address. If the SAVI device sends detection packet directly,
the next step MUST be omitted.
+---------+----------+-----------+-----------------+-------+
| Anchor | Address | State | Lifetime |Other |
+---------+----------+-----------+-----------------+-------+
| A | Addr | DETECTION |MAX_ARP_DELAY or | Lease |
| | | |MAX_DAD_DELAY | Time |
+---------+----------+-----------+-----------------+-------+
Figure 6 Binding entry in BST on assignment: another case
The SAVI device MUST insert an entry into the Filtering Table if the
assigned address is not bound with another anchor in current BST. If
the address has been bound with another anchor in current BST, the
SAVI device MUST check if the node associated with that anchor is
off-line. If yes, bind the address with the new entry and delete the
original binding; if no, keep the original entry and delete the new
entry in BST. This mechanism can handle local link movement, and
avoid attacker grabbing assigned bindings from other nodes. However,
if several hosts share the same anchor, and one of them moves to
another anchor, this mechanism may cause problem.
+---------+----------+
|Anchor |Address |
+---------+----------+
|A |Addr |
+---------+----------+
Figure 7 Binding entry in FT on assignment
The following steps after this step MAY NOT be performed. It is
SUGGESTED to perform following steps unless in some specified
Bi Expires September 8, 2010 [Page 11]
Internet-Draft savi-dhcp March 2010
scenario, e.g., a DHCP-only scenario. If the following steps are not
performed because of implementation or configuration, the state of
the corresponding entry MUST be changed to BOUND, and the lifetime is
set to lease time.
11.1.3. From LIVE to DETECTION
11.1.3.1. Trigger Event
A gratuitous ARP Request or Duplicate Address Detection Neighbor
Solicitation is received from anchor. Or a timeout event of an entry
with state LIVE happens.
11.1.3.2. Event Validation
The SAVI device checks the message and BST as follows:
1. Whether the Target IP Address field of the ARP Request or Neighbor
Solicitation has been bound with the corresponding anchor in BST
or FT.
11.1.3.3. Following Actions
If the check is passed:
If timeout event of an entry with state LIVE happens, the SAVI device
MAY send one or more ARP Request or a DAD NSOL, with Target Address
set to the recorded address in the entry. If detection packets are
sent, the SAVI device MUST set the state of the entry to be DETECTION.
The lifetime of the entry MUST be set to be MAX_ARP_DELAY or
MAX_DAD_DELAY respectively. If no detection packet is sent, the entry
MUST be removed from BST and FT. If the SAVI device chooses not to
send detection packet, valid packets may get dropped because a number
of operating systems don't fully support [RFC4862] and [RFC5227] and
don't send detection packets themselves. Thus, it is SUGGESTED the
SAVI device SHOULD send detection packet in case the client doesn't
send that itself.
+---------+----------+-----------+-----------------+-------+
| Anchor | Address | State | Lifetime |Other |
+---------+----------+-----------+-----------------+-------+
| A | Addr | DETECTION |MAX_ARP_DELAY or| Lease |
| | | |MAX_DAD_DELAY | Time |
+---------+----------+-----------+-----------------+-------+
Figure 8 Binding entry in BST on detection
Bi Expires September 8, 2010 [Page 12]
Internet-Draft savi-dhcp March 2010
11.1.4. From DETECTION to BOUND
11.1.4.1. Trigger Event
A timeout event of an entry with state DETECTION occurs or an ARP
Response or NA for an address in BST with state DETECTION is received.
11.1.4.2. Following Actions
If a timeout event of an entry with state DETECTION occurs, set the
state of the entry to be BOUND. The lifetime of the entry is set to
be the Lease time acknowledged by DHCP server.
+---------+----------+-----------+----------------+-------+
| Anchor | Address | State | Lifetime |Other |
+---------+----------+-----------+----------------+-------+
| A | Addr | BOUND | Lease time | |
+---------+----------+-----------+----------------+-------+
Figure 9 Binding entry in BST on finalization
If an ARP Response or NA for an address in BST with state DETECTION
is received, remove the corresponding entry in BST and FT. The ARP
Response or NA MUST be delivered to the client.
11.1.5. After BOUND
Once a binding entry is set up for an anchor, the binding will be
used to filter packet with the anchor, as specified in section 12. On
the other hand, DHCP messages with the anchor will affect the binding.
The binding is also affected by DHCP server message toward the anchor.
Before a DHCP message is found that it may change the corresponding
binding, its validity MUST be checked as described in section 12.2.
Whenever a DHCP Decline is received, delete the corresponding entry
in BST and FT.
Whenever a DHCP Release is received, if the state of the entry is
BOUND, delete the entry in BST and FT.
If a DHCPv4 Acknowledgement or DHCPv6 Reply with Renew/Rebind sign is
received from the server, set lifetime of the entry in BST to be the
new lease time.
If the lifetime of an entry with state BOUND expires, delete the
entry in BST and Filter Table.
Bi Expires September 8, 2010 [Page 13]
Internet-Draft savi-dhcp March 2010
The binding may also be affected by control messages with or toward
another anchor. The binding MAY be move to another anchor to handle
local link movement, as described in section 11.1.2.3. In this
situation, the node assigned a DCHP address changes to associate with
another anchor, thus the address should be bound with the anchor
which the node migrates to. Other than this situation, the binding
will not be changed, for the consideration of simplicity. Even if an
attached node becomes inactive and doesn't reply to any NS or ARP
Request, the associated bindings will not be removed.
Switch port down event (or more general, anchor turns off-link) will
change the corresponding entry, as described in section 15.
11.2. State Machine of DHCP Snooping
The main state transits are listed as follows. Note that the anchor
migration of binding entry is not included.
State Message/Event Action Next State
- REQ/CFM/SOL+RC Generate entry START
*- ACK/RPL Generate entry with lease LIVE
*- ACK/RPL Generate entry with lease BOUND
**- ACK/RPL Generate entry with lease DETECTION
, send probe
START ACK/RPL Record lease time LIVE
**START ACK/RPL Send probe DETECTION
START Timeout Remove entry -
LIVE Gra ARP REQ/DAD NS - DETECTION
LIVE DECLINE Remove entry -
LIVE Timeout Send probe DETECTION
*LIVE Timeout Remove entry -
DETECTION Timeout - BOUND
DETECTION ARP RES/DAD NA Remove entry -
Bi Expires September 8, 2010 [Page 14]
Internet-Draft savi-dhcp March 2010
DETECTION DECLINE Remove entry -
BOUND RELEASE/DECLINE Remove entry -
BOUND Timeout Remove entry -
BOUND RENEW/REBOUND Set new lifetime BOUND
*: optional but NOT SUGGESTED.
**: optional and MAY conflict other transits
REQ: DHCP REQUEST
CFM: DHCP CONFIRM
SOL: DHCP SOLICITATION
RC: Rapid Commit option
ACK: DHCP ACKNOWLEDGEMENT
RPL: DHCP REPLY
Probe Gratuitous ARP REQUEST or Duplicate Address Detection Neighbor
Solicitation, described in section 13.1
Gra ARP REQ: Gratuitous ARP REQUEST
ARP RES: ARP RESPONSE
DAD NS: Duplicate Address Detection Neighbor Solicitation
DAD NA: Neighbor Advertisement targeting at a tentative address
DECLINE: DHCP DECLINE
RELEASE: DHCP RELEASE
RENEW: DHCP RENEW
REBOUND: DHCP REBOUND
12. Filtering Specification
This section specifies how to use bindings to filter packets. Because
the Filtering Table is an allow-table, packet with source address not
Bi Expires September 8, 2010 [Page 15]
Internet-Draft savi-dhcp March 2010
in the table will be filtered. Considering DHCP may coexist with
other address assignment methods, e.g., Stateless Auto-configuration,
the specification made here is based on the assumption that other
SAVI solutions will also use BST and FT to keep bindings and filter
packets. Otherwise this solution will conflict with other SAVI
solutions.
Filtering policies are different for data packet and control packet.
DHCP and ND messages that may cause state transit are classified into
control packet. Neighbor Advertisement and ARP Response are also
included in control packet, because the Target Address of NA and ARP
Response should be checked to prevent spoofing. All other packets are
considered to be data packets.
12.1. Data Packet Filtering
Data packets with an anchor which has attribute SAVI-Validation MUST
be checked.
If the source of a packet associated with its anchor is in the FT,
this packet SHOULD be forwarded; or else the packet MUST be discarded.
12.2. Control Packet Filtering
For anchors with SAVI-Validation attribute:
The source address of DHCPv4 Discovery SHOULD be set to all zeros.
The source address of DHCPv4 Request SHOULD be set to all zeros or a
bound address in FT.
The source address of DHCPv6 Request MUST be an address associated
with the corresponding anchor in FT. The source address of DHCPv6
Confirm MUST be a link local address associated with the
corresponding anchor in FT. The source address of DHCPv6 Solicit MUST
be a link layer address bound with corresponding anchor. The link
layer address MAY be bound based on SAVI-SLAAC solution or other
solutions.
The source address of other types of DHCP messages MUST be a address
bound with the corresponding anchor.
The source address of IPv6 NS and IPv4 gratuitous ARP MUST pass the
check on FT.
The target address and source address in all the Neighbor
Advertisement packets and ARP replies MUST also pass the checks on FT.
Bi Expires September 8, 2010 [Page 16]
Internet-Draft savi-dhcp March 2010
For other anchors:
All DHCP Reply/Ack packets MUST be from anchor with the SAVI-DHCP-
Trust attribute.
13. Format and Delivery of Probe Messages
As described in section 11.1.2.3 and 11.1.3.3, the SAVI device MAY
send detection probes on behavior of client to determine whether the
assigned address is duplicated. Currently no other probes are
designed in this solution.
13.1. Duplicate detection
Message Type: DAD NS, Gratuitous ARP Request
Format:
Link layer source - link layer address of host;
Link layer destination - For IPv6, use multicast address
specified in [RFC3307]; For IPv4, use broadcast address;
IP source - Unspecified address for IPv6; The tentative
address for IPv4;
IP destination - For IPv6, multicast address specified in
section 5.4.2 of [RFC4861]; For IPv4, the tentative address;
Delivery:
MUST not be delivered to the host which the SAVI device is
performing DAD on behavior of.
14. Binding Remove
If the lifetime of an entry with state BOUND expires, the entry MUST
be removed.
When the SAVI device receives a DAD NS/Gra ARP request target at an
address bound and there is no replies from the anchor, if the anchor
is a SAVI-Validation anchor, hold the binding entry through sending
NA/ARP Reply, or remove the binding.
Bi Expires September 8, 2010 [Page 17]
Internet-Draft savi-dhcp March 2010
15. Handle Anchor Off-link event
Port DOWN event MUST be handled if switch port is used as anchor. In
more general case, if an anchor turns off-link, this event MUST be
handled.
Whenever an anchor with attribute SAVI-Validation turns down, the
bindings with the anchor MUST be kept for a short time.
To handle movement, if receiving DAD NS/Gra ARP request targeting at
the address during the period, remove the entry.
If the anchor turns on-link during the period, recover bindings. It
may result in some security problem, e.g., a malicious node
immediately associates with the anchor got off by a previous node,
then it can use the address assigned to the previous node. However,
this situation is very rare in reality. Authors decide not to handle
this situation.
16. About Collision in Detection
The SAVI device may receive a response in detection. Some related
details are specified here.
16.1. Whether to notify the DHCP server
It is unnecessary for the SAVI device to notify the DHCP server,
because the host will send a DECLINE message to it once it finds the
advertised address is conflict.
16.2. The result of detection without host aware
In case the SAVI device send detection packet instead of the host,
the host will not be aware of the detection result. If the detection
succeeds, there is no problem. However, if the detection fails, the
packets from the host with the assigned address will be filtered out.
This result can be regarded as a reasonable punishment for not
performing duplicate detection and using a collision address. The
SAVI device MAY choose to notice the client that the assigned address
has been used, through a NA message. This mechanism is not required
in this solution.
17. Filtering during detection
In this mechanism, whenever the DHCP server replies an address, this
address will be allowed immediately even before duplicate detection
is completed. This design is in consideration of a host may start to
Bi Expires September 8, 2010 [Page 18]
Internet-Draft savi-dhcp March 2010
send packets straightway without detection. Also this design is to be
compatible with optimistic DAD [RFC4429].
However, this feature may allow an attacker to send quantities of
packets with source addresses already assigned to other nodes. A
practical solution for this vulnerability is configuring the address
pool and allocation algorithm of the DHCP server carefully.
18. Binding Number Limitation
It is suggested to configure some mechanism in order to prevent a
single node from exhausting the binding table entries on the SAVI
device. Either of the following mechanism is sufficient to prevent
such attack.
1. Set the upper bound of binding number for each anchor with SAVI-
Validation.
2. Reserve a number of binding entries for each anchor with SAVI-
Validation attribute and all anchors share a pool of the other
binding entries.
3. Limit DHCP Request rate per anchor, using the bound entry number
of each anchor as reverse indicator.
19. Movement without DHCP Procedure
This mechanism currently doesn't handle any movement without DHCP
procedure, which means the change of anchor without triggering any
DHCP procedure. The scenario includes several hosts are attached a
SAVI-Validation port through a hub, and the hub changes from its
attaching port to another SAVI-Validation port.
For handling this situation will necessarily lead to a data packet
triggering procedure on SAVI device, and may violate the semantic of
DHCP protocol, this situation is not handled in this solution.
20. MLD Consideration
The SAVI device MUST join the tentative address multicast group
whenever perform duplicate detection on behavior of host.
21. State Restoration
If a SAVI device reboots accidentally or designedly, the states kept
in volatile memory will get lost. This may cause hosts indirectly
attached to the SAVI device to be broken away from the network,
Bi Expires September 8, 2010 [Page 19]
Internet-Draft savi-dhcp March 2010
because they can't recover bindings on the SAVI device of themselves.
Thus, it is SUGGESTED that binding entries can be saved into non-
volatile storage manually or regularly. Immediately after reboot, the
SAVI device can restore binding states from the non-volatile storage.
22. Constants
MAX_DHCP_RESPONSE_TIME 120s
MAX_ARP_PREPARE_DELAY Default 1s but configurable
MAX_ARP_DELAY Default 1s but configurable
MAX_DAD_PREPARE_DELAY Default 1s but configurable
MAX_DAD_DELAY Default 1s but configurable
23. Security Considerations
For prefix level granularity filtering is the basis of host level
granularity filtering, to learn and configure correct prefix is of
great importance to this mechanism. Thus, it's important to keep RA
and DHCP-PD secure. [draft-ietf-v6ops-ra-guard-03] describes a
mechanism to improve the security of RA message.
24. IANA Considerations
There is no IANA consideration currently.
25. References
25.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4862] Thomson, S., Narten, T. and Jinmei, T., "IPv6 Stateless
Autoconfiguration", RFC4862, September, 2007.
[RFC5227] S. Cheshire, "IPv4 Address Conflict Detection", RFC5227,
July 2008.
Bi Expires September 8, 2010 [Page 20]
Internet-Draft savi-dhcp March 2010
25.2. Informative References
26. Acknowledgments
Thanks to Christian Vogt, Eric Levy-Abegnoli, Mark Williams, Erik
Nordmark, Marcelo Bagnulo Braun, Alberto Garcia, Jari Arkko, David
Harrington, Pekka Savola, Xing Li, Lixia Zhang, Robert Raszuk, Greg
Daley, Joel M. Halpern, Mikael Abrahamsson and Tao Lin for their
valuable contributions.
Bi Expires September 8, 2010 [Page 21]
Internet-Draft savi-dhcp March 2010
Authors' Addresses
Jun Bi
CERNET
Network Research Center, Tsinghua University
Beijing 100084
China
Email: junbi@cernet.edu.cn
Jianping Wu
CERNET
Computer Science, Tsinghua University
Beijing 100084
China
Email: jianping@cernet.edu.cn
Guang Yao
CERNET
Network Research Center, Tsinghua University
Beijing 100084
China
Email: yaog@netarchlab.tsinghua.edu.cn
Fred Baker
Cisco Systems
Email: fred@cisco.com
Bi Expires September 8, 2010 [Page 22]
