SAVI J. Bi, J. Wu, G. Yao
Internet Draft Tsinghua Univ.
Intended status: Standard Tracks F. Baker
Expires: October 2011 Cisco Systems
April 28, 2011
SAVI Solution for DHCP
draft-ietf-savi-dhcp-09.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 October 28, 2011.
Bi Expires October 28, 2011 [Page 1]
Internet-Draft savi-dhcp April 2011
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 a
binding anchor [I-D.ietf-savi-framework] on SAVI (Source Address
Validation Improvements) device. The bindings can be used to filter
packets generated on the local link with forged source IP address.
Table of Contents
Copyright Notice ............................................... 2
Abstract ....................................................... 2
1. Introduction ................................................ 3
2. Conventions used in this document............................ 4
3. Terminology ................................................. 4
4. SAVI-DHCP Scenario .......................................... 4
5. Data Structures ............................................. 5
5.1. Control Plane Data Structure: Binding State Table (BST). 5
5.2. Data Plane Data Structure: Filtering Table (FT)......... 6
6. Binding Anchor Attributes.................................... 6
6.1. No Attribute ........................................... 6
6.2. SAVI-Validation Attribute............................... 7
6.3. SAVI-DHCP-Trust Attribute............................... 7
6.4. SAVI-SAVI Attribute..................................... 7
6.5. SAVI-BindRecovery Attribute............................. 8
7. Binding Set Up .............................................. 8
7.1. Rationale .............................................. 8
7.2. Binding States Description.............................. 8
7.3. Events ................................................. 9
7.3.1. Timer expiration event............................. 9
7.3.2. Control message arriving events ................... 9
Bi Expires October 28, 2011 [Page 2]
Internet-Draft savi-dhcp April 2011
7.4. Process of DHCP Packet Snooping ....................... 10
7.4.1. From NO_BIND to other states ..................... 10
7.4.1.1. Trigger Event................................ 10
7.4.1.2. Following Actions............................ 10
7.4.2. From INIT_BIND to other states ................... 12
7.4.2.1. Trigger Event................................ 12
7.4.2.2. Following Actions............................ 12
7.4.3. From BOUND to other states ....................... 13
7.4.3.1. Trigger Event................................ 13
7.4.3.2. Following Actions............................ 13
7.5. State Machine of DHCP Snooping ........................ 13
8. Supplemental Binding Process................................ 14
8.1. Binding Recovery Process............................... 15
9. Filtering Specification..................................... 16
9.1. Data Packet Filtering.................................. 16
9.2. Control Packet Filtering............................... 16
10. State Restoration ......................................... 17
11. Handle Binding Anchor Off-link Event ...................... 17
12. Constants ................................................. 17
13. Security Considerations.................................... 18
13.1. Binding Number Limitation............................. 18
13.2. Risk from Link Layer Routing Dynamic ................. 18
13.3. Duplicate Bindings of Same Address ................... 19
14. References ................................................ 19
14.1. Normative References.................................. 19
14.2. Informative References................................ 20
15. Acknowledgments ........................................... 20
16. Change Log ................................................ 21
1. Introduction
This document describes the procedure for creating bindings between
DHCP addresses and binding anchor on SAVI device [I-D.ietf-savi-
framework]. The removal and restoration of the bindings are also
specified in this document.
Bindings can be used to filter or identify packets with forged source
IP address. Section 9 suggests usage of these bindings for common
practice.
The mechanism specified in this document is designed to provide a
binding anchor granularity validation, 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 IP addresses assigned
by DHCP and corresponding binding anchors. The binding process is
inspired by the work of IP Source Guard [IP Source Guard].
Bi Expires October 28, 2011 [Page 3]
Internet-Draft savi-dhcp April 2011
This solution is designed for stateful DHCP scenario [RFC2131,
RFC3315]. In stateless DHCP scenarios [RFC3736], a node must have
obtained its IPv6 addresses through some other mechanism and so the
address of the client SHOULD be bound based on other SAVI solutions
This solution is primarily designed for a pure DHCP scenario in which
only DHCP address is legitimate global address. How to use this
mechanism in multiple address assignments scenario is discussed in
[draft-bi-savi-mixed].
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. Terminology
Lease time: Lease time in IPv4 [RFC2131] and valid lifetime in
IPv6 [RFC3315]
4. SAVI-DHCP Scenario
Figure 1 shows the main elements in a DHCP 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. Multiple SAVI devices and
non-SAVI devices can co-exist on link. A SAVI device can be connected
to DHCP client, DHCP relay (even DHCP server), SAVI device and non-
SAVI device.
Other address assignment mechanisms may be also used in such a
network. However, this solution is primarily designed for a pure DHCP
scenario, in which only DHCP servers can assign valid global address.
Note that in IPv6 environment, DHCP procedure cannot be performed on
an interface without a link-local address pre-assigned. Thus, to make
this solution work, a SAVI solution for link-local address MUST be
enabled.
Bi Expires October 28, 2011 [Page 4]
Internet-Draft savi-dhcp April 2011
/------------\
+--------+ | |
| DHCP |-----| Router A |
| Server | | |
+--------+ \------------/
......................|..........
. | .
. Protection | .
. Perimeter | .
. | .
. | .
. | .
. +----------+ +----'-----+ . +----------+
. | SAVI | | SAVI | . | Non SAVI|
. | Device A|----| Device B|------| Device |
. +/---.-----+ +-.------.-+ . +-----.----+
................................. |
| | | |
| | | |
+----/-----+ +----\-+ +\-----+ +--\---+
| Router B | |DHCP | |Client| |Client|
| | |Relay | | A | | B |
+----------+ +------+ +------+ +------+
Figure 1 DHCP Scenario
5. Data Structures
This section describes the 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.
5.1. Control Plane Data Structure: Binding State Table (BST)
This table contains the state of binding between source address and
binding anchor. Entries are keyed on the binding 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. The lifetime field
is used to help remove expired bindings. The state field is used to
identify state. The other field is used to keep temporary information,
e.g., the Transaction ID (TID) [RFC2131][RFC3315] in DHCP request.
Before a binding is finished, the lease time of the address is also
Bi Expires October 28, 2011 [Page 5]
Internet-Draft savi-dhcp April 2011
kept in this field because it is improper to keep it in the lifetime
field which keeps the lifetime of the binding entry but not the
address.
+---------+----------+-------+-----------+-------+
| Anchor | Address | State | Lifetime |Other |
+---------+----------+-------+-----------+-------+
| A | IP_1 | Bound | 65535 | |
+---------+----------+-------+-----------+-------+
| A | IP_2 | Bound | 10000 | |
+---------+----------+-------+-----------+-------+
| B | IP_3 |_Start | 1 | |
+---------+----------+-------+-----------+-------+
Figure 2 Instance of BST
5.2. Data Plane Data Structure: Filtering Table (FT)
This table contains the bindings between binding anchor and address,
keyed on binding anchor and address. 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.
+---------+----------+
| Anchor |Address |
+---------+----------+
|A |IP_1 |
+---------+----------+
|A |IP_2 |
+---------+----------+
Figure 3 Instance of FT
6. Binding Anchor Attributes
This section specifies the binding anchor attributes used in this
mechanism.
Attribute of each binding anchor is configurable. By default, binding
anchor has no attribute. A binding anchor MAY be configured to have
one or more compatible attributes.
6.1. No Attribute
Before configuration, by default, a binding anchor has no attribute.
To filter bogus DHCP server message by default, server type DHCP
message from binding anchor with no attribute MUST be dropped.
Bi Expires October 28, 2011 [Page 6]
Internet-Draft savi-dhcp April 2011
However, to avoid discarding legitimate traffic, other packets SHOULD
NOT be dropped before any binding is setup on such binding anchor.
Generally, each binding anchor is configured to have one or more
attributes after configuration. However, a binding anchor MAY always
have no attribute if it is connected to another link. For example, in
Figure 1, on the binding anchor of SAVI Device A connected to Router
B, it is unreasonable either to set up bindings for host behind
Router B, or filter out traffic from Router B, or allow bogus DHCP
message from Router B. Thus, no attribute should be configured on
this binding anchor.
6.2. SAVI-Validation Attribute
SAVI-Validation attribute is used on binding anchor on which the
source address of data packet and DHCP message is to be validated.
The filtering process on binding anchor with such attribute is
described in section 9. In Figure 1, the binding anchor between SAVI
Device B and Client A, and the binding anchor between SAVI Device B
and Non SAVI Device should be configured to have this attribute.
6.3. SAVI-DHCP-Trust Attribute
SAVI-DHCP-Trust Attribute is used on binding anchor on the path to a
trustable DHCP server/relay. DHCP server/relay message coming from
binding anchor with this attribute will be forwarded. In Figure 1,
the binding anchor between SAVI Device B and DHCP Relay, and the
binding anchor between SAVI Device B and Router A, should be
configured to have this attribute.
6.4. SAVI-SAVI Attribute
This attribute is used on binding anchor from which the data traffic
is not to be checked. Binding will not be set up on binding anchor
with this attribute. All data packets will be allowed directly. In
Figure 1, the binding anchor between SAVI Device A and SAVI Device B
should be configured with this attribute.
Through configuring this attribute on binding anchor that joins two
or more SAVI devices, SAVI-Validation and SAVI-SAVI attributes
implement the security perimeter concept in [I-D.ietf-savi-framework].
Since no binding entry is needed on such binding anchor, the binding
entry resource requirement can be reduced greatly.
Though there is no factual difference in packet process between a
binding anchor with no attribute and a binding anchor only with SAVI-
SAVI attribute, their connotations are different. SAVI-SAVI attribute
is configured on binding anchor between SAVI devices on the same link
Bi Expires October 28, 2011 [Page 7]
Internet-Draft savi-dhcp April 2011
inside the protection perimeter. But only when a binding anchor is on
the protection perimeter and connected to another link, it can have
no attribute after configuration.
This attribute is mutually exclusive with SAVI-Validation.
6.5. SAVI-BindRecovery Attribute
This attribute is used on binding anchor that requires data-triggered
binding recovery described in section 8.1. It can be configured on
any binding anchor with SAVI-Validation attribute, especially, the
binding anchor not directly attached by client. In Figure 1, it is
suggested to configure this attribute on binding anchor between SAVI
Device B and Non SAVI Device.
This attribute is mutually exclusive with SAVI-SAVI.
7. Binding Set Up
This section specifies the procedure of setting up bindings based on
DHCP message snooping. The binding procedure specified here is
exclusively designed for binding anchor with SAVI-Validation
attribute.
7.1. Rationale
The rationale of this mechanism is that if a node attached to a
binding anchor is legitimate to use a DHCP address, the DHCP
procedure which assigns the address to the node must has been
performed on the same binding anchor. This basis stands when the link
layer routing is stable. However, layer-2 mobility and unstable link
layer routing may result in that data packet is received from a
different binding anchor. Infrequent link layer path change can be
handled (but not perfectly) by the mechanism described in section 8.
Section 13.2 discusses the situation that link layer routing is
naturedly unstable. A solution for this issue is outside the scope of
this document.
7.2. Binding States Description
This section describes the binding states of this mechanism.
NO_BIND The state before a binding has been set up.
INIT_BIND 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.
Bi Expires October 28, 2011 [Page 8]
Internet-Draft savi-dhcp April 2011
BOUND The address is authorized to the client.
7.3. Events
7.3.1. Timer expiration event
EVE_ENTRY_EXPIRE: The lifetime of an entry expires
7.3.2. Control message arriving events
Only if a control message can pass the check in section 9.2, the
corresponding event is a valid event.
EVE_DHCP_REQUEST: A DHCP Request message is received from a binding
anchor with SAVI-Validation attribute, and the binding entry limit
(discussed in "Security Considerations") on the binding anchor has
not been reached.
EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received from a binding
anchor with SAVI-Validation attribute, and the binding entry limit on
the binding anchor has not been reached.
EVE_DHCP_OPTION_RC: A DHCPv6 Solicitation message with Rapid Commit
option is received from a binding anchor with SAVI-Validation
attribute, and the binding entry limit on the binding anchor has not
been reached.
EVE_DHCP_REPLY: A DHCPv4 Acknowledgement or DHCPv6 Reply message is
received from a binding anchor with SAVI-DHCP-Trust attribute, and
the message should be forwarded to a binding anchor with SAVI-
Validation attribute.
EVE_DHCP_REPLY_NULL: A DHCPv4 Acknowledgement or DHCPv6 Reply message
is received from a binding anchor with SAVI-DHCP-Trust attribute.
EVE_DHCP_DECLINE: A DHCP Decline message is received from a binding
anchor with SAVI-Validation attribute.
EVE_DHCP_RELEASE: A DHCP Release message is received from a binding
anchor with SAVI-Validation attribute.
EVE_LEASEQUERY_REPLY: A successful DHCP LEASEQUERY_REPLY is received
from a binding anchor with SAVI-DHCP-Trust attribute.
Bi Expires October 28, 2011 [Page 9]
Internet-Draft savi-dhcp April 2011
7.4. Process of DHCP Packet Snooping
7.4.1. From NO_BIND to other states
7.4.1.1. Trigger Event
EVE_DHCP_REQUEST, EVE_DHCP_CONFIRM, EVE_DHCP_OPTION_RC,
EVE_DHCP_REPLY_NULL.
Note that vulnerability may be caused by DHCP Reply triggered
initialization. The binding of assigned address and binding anchor
may be threatened if the binding mechanism between binding anchor and
link layer address is not secure. If one of the following conditions
is satisfied, the security can be ensured.
1. DHCP Option 82 is used to keep binding anchor in DHCP Request and
Reply, or
2. Unspoofable MAC is used as binding anchor(802.11i,802.1ae/af), or
3. The mapping table from MAC to binding anchor is secure.
It is NOT RECOMMENDED to initialize a binding based on DHCP Reply,
until the associated mechanism is also implemented.
7.4.1.2. Following Actions
If the triggering event is EVE_DHCP_REQUEST/EVE_DHCP_OPTION_RC:
The SAVI device MUST forward the message.
The SAVI device MUST generate an entry for the binding anchor in
the Binding State Table (BST) and set the state field to INIT_BIND.
The lifetime of this entry MUST set to be MAX_DHCP_RESPONSE_TIME.
The TID field of the request packet MUST be recorded in the entry,
except that the mapping from link layer address to binding anchor
is secure as specified in section 7.2.1.1.
+---------+-------+---------+-----------------------+-------+
| Anchor |Address| State | Lifetime |Other |
+---------+-------+---------+-----------------------+-------+
| A | |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID |
+---------+-------+---------+-----------------------+-------+
Figure 4 Binding entry in BST on client triggered initialization
Bi Expires October 28, 2011 [Page 10]
Internet-Draft savi-dhcp April 2011
The TID is kept as a mediator of assigned address and the binding
anchor of requesting node, to assure that the assigned address can
be bound with binding anchor secure.
If the triggering event is EVE_DHCP_CONFIRM:
Other than forwarding the message and generating corresponding
entry, the address to be confirmed MUST be recorded in the entry.
Because no lease time will be contained in the REPLY from DHCP
server, the SAVI device MUST send a LEASEQUERY [RFC5007] message
querying by IP address to All_DHCP_Relay_Agents_and_Servers
multicast address [RFC3315] or a configured server address.
+---------+--------+---------+-----------------------+-------+
| Anchor | Address| State | Lifetime |Other |
+---------+--------+---------+-----------------------+-------+
| A | Addr |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID |
+---------+--------+---------+-----------------------+-------+
Figure 5 Binding entry in BST on Confirm triggered initialization
If the triggering event is EVE_DHCP_REPLY_NULL:
The SAVI device MUST deliver the message to the destination.
The SAVI device MUST generate as many new entries in BST and FT as
the number of IADDR found in the message. The binding anchor in
entry is looked up based on the destination link layer address,
from mapping table from link layer address to binding anchor (e.g.,
the MAC-Port mapping table in case that port is used as binding
anchor). The states of the corresponding entries are set to be
BOUND. The lifetime of the entries MUST be set to be the lease time.
The binding entry limit can be exceeded when setting up bindings
for all addresses in a REPLY message. If there is enough binding
entry resource, corresponding new entries MUST be generated even
the binding number limit is exceeded. In case that there is not
enough resource left, as many as possible entries SHOULD be set up.
+---------+----------+-------+------------------------+-------+
| Anchor | Address | State | Lifetime |Other |
+---------+----------+-------+------------------------+-------+
| A | Addr1 | BOUND | Lease time 1 | |
+---------+----------+-------+------------------------+-------+
| A | Addr2 | BOUND | Lease time 2 | |
+---------+----------+-------+------------------------+-------+
Figure 6 Binding entry in BST on Reply triggered initialization
Bi Expires October 28, 2011 [Page 11]
Internet-Draft savi-dhcp April 2011
+---------+----------+
| Anchor |Address |
+---------+----------+
|A |Addr1 |
+---------+----------+
|A |Addr2 |
+---------+----------+
Figure 7 Binding entry in FT on Reply triggered initialization
7.4.2. From INIT_BIND to other states
7.4.2.1. Trigger Event
EVE_DHCP_REPLY, EVE_ENTRY_EXPIRE, EVE_LEASEQUERY_REPLY.
7.4.2.2. Following Actions
If the trigger event is EVE_DHCP_REPLY:
The SAVI device MUST deliver the message to the destination.
If the Address field is null, the lease time in Reply message MUST
be recorded in the entry with matched TID. The state of the entry
is changed to be BOUND. If more than one IADDR is found in the
message, if there is enough binding entry resource, corresponding
new entries MUST be generated even the binding number limit is
exceeded. In case that there is not enough resource left, as many
as possible entries SHOULD be set up.
If the Address field is not null, the Reply is in response to a
Confirm message. If the Reply message is of Status Code Success,
set the Lifetime of corresponding entry to be MAX_LEASEQUERY_DELAY.
The state of the entry is changed to be BOUND.
+---------+----------+-------+------------------------+-------+
| Anchor | Address | State | Lifetime |Other |
+---------+----------+-------+------------------------+-------+
| A | Addr | BOUND | Lease time | |
+---------+----------+-------+------------------------+-------+
Figure 8 From INIT_BIND to BOUND
A corresponding entry MUST also be generated in FT.
If the trigger event is EVE_ENTRY_EXPIRE:
Bi Expires October 28, 2011 [Page 12]
Internet-Draft savi-dhcp April 2011
The entry MUST be deleted from BST.
If the trigger event is EVE_LEASEQUERY_REPLY:
The Lifetime field of entry with corresponding IP address MUST be
set to the lease time in the LEASEQUERY_REPLY.
7.4.3. From BOUND to other states
7.4.3.1. Trigger Event
EVE_ENTRY_EXPIRE, EVE_DHCP_RELEASE, EVE_DHCP_DECLINE,
EVE_DHCP_REPLY_RENEW.
7.4.3.2. Following Actions
If the trigger event is EVE_ENTRY_EXPIRE:
Remove the corresponding entry in BST and FT.
If the trigger event is EVE_DHCP_RELEASE or EVE_DHCP_DECLINE:
Remove the corresponding entry in BST and FT. The Release or
Decline message MUST be forwarded.
If the trigger event is EVE_DHCP_REPLY_RENEW:
Set the lifetime of the address to be the new lease time.
7.5. State Machine of DHCP Snooping
The main state transits are listed as follows.
State Event Action Next State
NO_BIND REQ/RC Generate entry INIT_BIND
NO_BIND CFM Generate entry and send Leasequery INIT_BIND
*NO_BIND RPL Generate entry with lease BOUND
INIT_BIND RPL Record lease time/set LQ_DLY BOUND
INIT_BIND Timeout Remove entry NO_BIND
BOUND LQR Record lease time BOUND
Bi Expires October 28, 2011 [Page 13]
Internet-Draft savi-dhcp April 2011
BOUND RLS/DCL Remove entry NO_BIND
BOUND Timeout Remove entry NO_BIND
BOUND RNW Set new lifetime BOUND
*: optional but NOT RECOMMENDED.
REQ: EVE_DHCP_REQUEST
CFM: EVE_DHCP_CONFIRM
RC: EVE_DHCP_OPTION_RC
RPL: EVE_DHCP REPLY
DCL: DHCP DECLINE
RLS: DHCP RELEASE
RNW: EVE_DHCP_RPL_RENEW
LQR: EVE_LEASEQUERY_REPLY
Timeout: EVE_ENTRY_EXPIRE
LQ_DLY: MAX_LEASEQUERY_DELAY
8. Supplemental Binding Process
Supplemental binding process is designed to cover conditions that
packet is sent by node without previous DHCP procedure sensed by the
SAVI device. A typical situation is that the link topology change
after the binding has been set up, and then the node will send packet
to a different port with the bound port. Another scenario is that a
node moves on the local link without re-configuration process.
Supplemental binding process is designed to avoid permanent
legitimate traffic blocking. It is not supposed to set up a binding
whenever a data packet with unbound source address is received.
Generally, longer time and more packets are needed to trigger
supplemental binding processes.
Binding Recovery Process is a conditional SHOULD. This function
SHOULD be implemented if the vendor has such ability, unless the
implementation is known to be directly attached to host. If the
mechanism is not implemented and managed nodes are not directly
Bi Expires October 28, 2011 [Page 14]
Internet-Draft savi-dhcp April 2011
attached, permanent legitimate traffic blocking can happen until the
node is reconfigured.
8.1. Binding Recovery Process
If a binding anchor is set to have SAVI-BindRecovery attribute,
packet without matched binding can trigger the SAVI device to check
if the source address can be used by corresponding node:
1. Check if the address has a local conflict through sending 2 DAD
NS/ARP on the address. If duplicate detection fails, the packet
MUST be discarded. Otherwise, go to the next step.
2.
IPv4 address:
Send a DHCPLEASEQUERY [RFC4388] message querying by IP address to all
DHCPv4 servers for IPv4 address or a configured server address. The
server addresses may be discovered through DHCPv4 Discovery. If no
DHCPLEASEACTIVE message is received, discard the packet; otherwise
generate a new binding entry for the address.
IPv6 address:
Send a LEASEQUERY [RFC5007] message querying by IP address to
All_DHCP_Relay_Agents_and_Servers multicast address or a configured
server address. If no successful LEASEQUERY-REPLY is received,
discard the packet; otherwise generate a new binding entry for the
address. The SAVI device may repeat this process if a LEASEQUERY-
REPLY with OPTION_CLIENT_LINK is received, in order to set up binding
entries for all the address of the client.
This process MUST be rate limited to avoid Denial of Services attack
against the SAVI device itself. A constant BIND_RECOVERY_INTERVAL is
used to control the frequency. Two data-triggered recovery processes
on one binding anchor MUST have a minimum interval time
BIND_RECOVERY_INTERVAL. This constant SHOULD be configured prudently
to avoid Denial of Service attacks.
This process is not strict secure. The node with SAVI-BindRecovery
binding anchor has the ability to use the address of an inactive node,
which doesn't reply to the detection probes.
In case that SAVI device is pure layer-2 device without IP address,
it is impossible to perform DHCP LEASEQUERY. It is SUGGESTED NOT to
perform this data-triggered process. If binding recovery is still
Bi Expires October 28, 2011 [Page 15]
Internet-Draft savi-dhcp April 2011
required, DHCP Confirm SHOULD be sent instead of DHCP LEASEQUERY. The
security degree will degrade for the address may not be assigned by
DHCP server. A default lifetime DEFAULT_LEASE SHOULD be set with the
entry.
This process may fail if any DHCP server doesn't support DHCP
LEASEQUERY.
9. Filtering Specification
This section specifies how to use bindings to filter packets.
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.
9.1. Data Packet Filtering
Data packets with a binding anchor which has attribute SAVI-
Validation MUST be checked.
If the source of a packet associated with its binding anchor is in
the FT, this packet SHOULD be forwarded; or else the packet SHOULD be
discarded, or alternatively the SAVI SHOULD record this violation.
9.2. Control Packet Filtering
For binding anchors with SAVI-Validation attribute:
Discard/record DHCPv4 Discovery with non-all-zeros source IP address.
Discard/record DHCPv4 Request whose source IP address is neither all
zeros nor a bound address in FT.
Discard/record DHCPv6 Request whose source is not bound with the
corresponding binding anchor in FT. Discard/record DHCPv6 Confirm/
Solicit whose source is not a link local address bound with the
corresponding binding anchor in FT. The link layer address may be
bound based on SAVI-SLAAC solution or other solutions.
Discard/record other types of DHCP messages whose source is not an
address bound with the corresponding binding anchor.
Discard/record IPv6 NS and IPv4 gratuitous ARP whose source is not an
address bound with the corresponding binding anchor.
Bi Expires October 28, 2011 [Page 16]
Internet-Draft savi-dhcp April 2011
Discard/record NA and ARP Replies messages whose target address and
source address are not bound with the corresponding binding anchor.
For other binding anchors:
Discard DHCP Reply/Ack messages not from binding anchor with the
SAVI-DHCP-Trust attribute or SAVI-SAVI attribute.
10. 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,
because they can't recover bindings on the SAVI device of themselves.
Purely using the Binding Recovery Process is of great cost and delay
to recover a large number of bindings. Thus, recovery from non-
volatile storage is designed.
Binding entries MUST be saved into non-volatile storage whenever a
new binding entry changes to BOUND state or a binding with state
BOUND is removed in condition that this function is supported by
hardware. Immediately after reboot, the SAVI device MUST restore
binding states from the non-volatile storage. The lifetime and the
system time of save process MUST be stored. Then the device MUST
check whether the saved entries are obsolete when rebooting.
11. Handle Binding Anchor Off-link Event
Port DOWN event MUST be handled if switch port is used as binding
anchor. In more general case, if a binding anchor turns off-link,
this event MUST be handled.
Whenever a binding anchor with attribute SAVI-Validation turns down,
set a timer with OFFLINK_DELAY. Until the timer becomes zero, the
bindings with the binding anchor SHOULD be kept. As an exception, to
handle movement, if receiving DAD Neighbor Solicitation/Gratuitous
ARP request targeting at the address during OFFLINK_DELAY, the entry
MAY be removed.
If the binding anchor turns on-link during OFFLINK_DELAY, turn off
the timer and keep corresponding bindings.
12. Constants
MAX_DHCP_RESPONSE_TIME 120s
BIND_RECOVERY_INTERVAL 60s and configurable
Bi Expires October 28, 2011 [Page 17]
Internet-Draft savi-dhcp April 2011
MAX_LEASEQUERY_DELAY 10s
DEFAULT_LEASE 2h
OFFLINK_DELAY 2s
13. Security Considerations
13.1. 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 binding anchor with
SAVI-Validation.
2. Reserve a number of binding entries for each binding anchor with
SAVI-Validation attribute and all binding anchors share a pool of
the other binding entries.
3. Limit DHCP Request rate per binding anchor.
13.2. Risk from Link Layer Routing Dynamic
An implicit assumption of this solution is that data packet must
arrive at the same binding anchor with the binding anchor that the
control packets have arrived at. If this assumption is not valid,
this control packet based solution will fail or at least discard
legitimate packet. Unfortunately, the link layer routing between host
and SAVI device can be inconsistent from time to time. Time
consistency of link layer routing is not assured by link layer
routing protocol. For example, TRILL, a recent link layer routing
protocol, is flexible and multiple link layer paths are allowed.
To make the basic assumption stand, the best way is enforcing that
there should be only one topology path from downstream host to the
SAVI device. For example, SAVI device is directly attached by hosts.
If the assumption doesn't stand, a better solution is requiring
inter-operation between SAVI protocol and the link layer routing
protocol to make SAVI protocol sensitive to the link layer routing
change. This solution is above the scope of this document.
Bi Expires October 28, 2011 [Page 18]
Internet-Draft savi-dhcp April 2011
13.3. Duplicate Bindings of Same Address
The same address may be bound with multiple binding anchors, only if
the binding processes are finished on each binding anchor
successfully respectively. This mechanism is designed in
consideration that a node may move on the local ink, and a node may
have multiple binding anchors. However, the traceability of address
is reduced.
Note that the local link movement scenario is not handled perfectly.
The former binding may not be removed, unless the node is directly
attached to the SAVI device. The nodes sharing the same former
binding anchor of the moving node have the ability to use its address.
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-savi-framework]
Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt,
"Source Address Validation Improvement Protocol Framework",
draft-ietf-savi-framework-04 (work in progress), September
2010.
[RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC2131,
March 1997.
[RFC3315] R. Droms, Ed. "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC3315, July 2003.
[RFC4388] R. Woundy and K. Kinnear, "Dynamic Host Configuration
Protocol (DHCP) Leasequery", RFC4388, February 2006.
[RFC4861] T. Narten, E. Nordmark, W. Simpson, and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC4861,
September 2007.
[RFC4862] Thomson, S., Narten, T. and Jinmei, T., "IPv6 Stateless
Autoconfiguration", RFC4862, September, 2007.
[RFC5007] J. Brzozowski, K. Kinnear, B. Volz, S. Zeng, "DHCPv6
Leasequery", RFC5007, September 2007.
Bi Expires October 28, 2011 [Page 19]
Internet-Draft savi-dhcp April 2011
14.2. Informative References
[BCP38] 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.
[RFC3307] B. Haberman, "Allocation Guidelines for IPv6 Multicast
Addresses", RFC3307, August 2002.
[RFC5227] S. Cheshire, "IPv4 Address Conflict Detection", RFC5227,
July 2008.
[IP Source Guard]
Baker, F., "Cisco IP Version 4 Source Guard", IETF Internet
draft (work in progress), November 2007.
[draft-bi-savi-mixed]
Jun Bi, Guang Yao, J. Halpern and E. Levy-Abegnoli, "SAVI
for Mixed Address Assignment Methods Scenario", draft-bi-
savi-mixed-04 (work in progress), March 2011.
15. Acknowledgments
Special thanks to Christian Vogt, Joel M. Halpern, , Eric Levy-Abegnoli,
Jean-Michel Combes and Alberto Garcia for careful review and valuation
comments on the state machine and text.
Thanks to Marcelo Bagnulo Braun, Mark Williams, Erik Nordmark, Mikael
Abrahamsson, Jari Arkko, David Harrington, Pekka Savola, Xing Li, Lixia
Zhang, Robert Raszuk, Greg Daley, John Kaippallimalil and Tao Lin for
their valuable contributions.
Bi Expires October 28, 2011 [Page 20]
Internet-Draft savi-dhcp April 2011
Authors' Addresses
Jun Bi
Tsinghua University
Network Research Center, Tsinghua University
Beijing 100084
China
Email: junbi@tsinghua.edu.cn
Jianping Wu
Tsinghua University
Computer Science, Tsinghua University
Beijing 100084
China
Email: jianping@cernet.edu.cn
Guang Yao
Tsinghua University
Computer Science, Tsinghua University
Beijing 100084
China
Email: yaog@netarchlab.tsinghua.edu.cn
Fred Baker
Cisco Systems
Santa Barbara, CA 93117
United States
Email: fred@cisco.com
16. Change Log
From 02 to 03:
- Section 12, data trigger and counter trigger are combined to
binding recovery process. The expression "one of MUST" is
changed to "conditional MUST. Conditions related with the
implementation are specified. Related constants are changed
in section 26."
Bi Expires October 28, 2011 [Page 21]
Internet-Draft savi-dhcp April 2011
Main changes from 03 to 04:
- Section "Prefix configuration" is removed.
- Section "Supplemental binding process" is modified in
requirement level.
- Sub-section 9.1 "Rationale" is added.
- Section "Filtering during Detection" is removed.
- Section "Handling layer 2 path change" is changed to
"Consideration on Link layer routing complexity"
- Section "Background and related protocols" is removed.
Main changes from 04 to 05:
- Trigger events are listed explicitly in section 8.
- Detection and Live states are deleted, together with
corresponding sections.
Main change from 05 to 06:
- Section 8.1: reference to section 20 is changed to section
15.
Main changes from 06 to 07:
- So many changes in this modification. We suggest to track
http://www.ietf.org/mailarchive/web/savi/current/msg01543.ht
ml. Changes are made according to the comments.
Main changes from 07 to 08,09:
- The modifications are made according to the comments from
Jean-Michel Combes.
Bi Expires October 28, 2011 [Page 22]
