SAVI J. Bi, J. Wu
Internet Draft CERNET
Intended status: Standard Tracks G. Yao
Expires: October 2010 Tsinghua Univ.
F. Baker
Cisco
April 16, 2010
SAVI Solution for DHCP
draft-ietf-savi-dhcp-02.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
Bi Expires October 16, 2010 [Page 1]
Internet-Draft savi-dhcp April 2010
This Internet-Draft will expire on October 16, 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 a
binding 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
Copyright Notice ............................................... 2
Abstract ....................................................... 2
1. Introduction ................................................ 4
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).................................... 6
7. Binding States Description................................... 6
8. DHCP Scenario ............................................... 7
9. Anchor Attributes ........................................... 7
9.1. SAVI-Validation Attribute............................... 7
9.2. SAVI-DHCP-Trust Attribute............................... 8
9.3. SAVI-SAVI Attribute..................................... 8
9.4. Optional Attributes..................................... 8
10. Prefix Configuration........................................ 8
11. Binding Set Up ............................................. 9
Bi Expires October 16, 2010 [Page 2]
Internet-Draft savi-dhcp April 2010
11.1. Process of Control Packet 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............................ 9
11.1.2. From START to LIVE............................... 11
11.1.2.1. Trigger Event............................... 11
11.1.2.2. Event Validation............................ 11
11.1.2.3. Following Actions........................... 11
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.......................... 12
11.1.4.1. Trigger Event............................... 12
11.1.4.2. Following Actions........................... 13
11.1.5. Binding Deletion in DETECTION State.............. 13
11.1.5.1. Trigger Event............................... 13
11.1.5.2. Following Actions........................... 13
11.1.6. After BOUND...................................... 13
11.2. State Machine of DHCP Snooping........................ 14
12. Supplemental Binding Process............................... 15
12.1. Rate-limited Data Triggered Binding Process........... 16
12.1.1. SAVI-DataTrigger Attribute....................... 16
12.1.2. Data Triggered Binding Process................... 16
12.2. Counter Triggered Process............................. 17
12.2.1. SAVI-CounterTrigger Attribute.................... 17
12.2.2. Counter Triggered Process........................ 18
12.3. External Control Packet Snooping Process.............. 18
12.3.1. SAVI-ExtSnooping Attribute....................... 18
12.3.2. Extended Control Packet Snooping................. 18
13. Filtering Specification.................................... 19
13.1. Data Packet Filtering................................. 19
13.2. Control Packet Filtering.............................. 20
14. Format and Delivery of Probe Messages...................... 20
14.1. Duplicate detection................................... 20
15. Binding Remove ............................................ 21
16. Handle Anchor Off-link event............................... 21
17. About Collision in Detection............................... 21
17.1. Whether to Notify the DHCP Server..................... 22
17.2. The Result of Detection without Host Aware............ 22
18. Filtering during Detection................................. 22
19. Binding Number Limitation.................................. 22
20. MLD Consideration ......................................... 23
21. State Restoration ......................................... 23
22. Stateless DHCP ............................................ 23
23. Confirm Triggered Binding.................................. 23
24. Handle Layer 2 Path Change................................. 24
Bi Expires October 16, 2010 [Page 3]
Internet-Draft savi-dhcp April 2010
25. Duplicate Bindings on Same Address......................... 24
26. Constants ................................................. 24
27. Security Considerations.................................... 25
28. IANA Considerations........................................ 25
29. References ................................................ 25
29.1. Normative References.................................. 25
29.2. Informative References................................ 25
30. Acknowledgments ........................................... 26
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].
The binding process is inspired by the work of IP Source Guard [IP
Source Guard]. This solution differs from IP Source Guard in the
specification for collision detection, which is essential in
environments with multiple address assignment methods. There are also
other differences in details.
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.
Bi Expires October 16, 2010 [Page 4]
Internet-Draft savi-dhcp April 2010
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
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.
Bi Expires October 16, 2010 [Page 5]
Internet-Draft savi-dhcp April 2010
+---------+----------+-------+-----------+-------+
| 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.
+---------+----------+
|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.
Bi Expires October 16, 2010 [Page 6]
Internet-Draft savi-dhcp April 2010
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.
+--------+
| 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 13.
Bi Expires October 16, 2010 [Page 7]
Internet-Draft savi-dhcp April 2010
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.
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 can also be set on other anchors if the administrator
decides not to validate the traffic from the anchor. Note that DHCP
server message and router message will also be trusted.
This attribute is mutually exclusive with SAVI-Validation.
9.4. Optional Attributes
Section 12 describes some optional attributes. At least one of these
attributes MUST be implemented.
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.
The SAVI device enabled this solution SHOULD set allowed prefix
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 October 16, 2010 [Page 8]
Internet-Draft savi-dhcp April 2010
11. Binding Set Up
This section specifies the procedure of setting up bindings based on
control packet snooping. The binding procedure specified here is
exclusively designed for anchor with SAVI-Validation attribute.
11.1. Process of Control Packet Snooping
11.1.1. Initialization
A binding entry is initialized in this step.
11.1.1.1. Trigger Event
A DHCPv4/v6 Request or a DHCPv6 Confirm or a DHCPv6 Solicitation with
Rapid Commit option is received.
Or a DHCP Reply is received from anchor with SAVI-DHCP-Trust
attribute. Note that vulnerability may be caused by DHCP Reply
triggered initialization. The binding of assigned address and anchor
may be threatened if the binding mechanism between anchor and link
layer address is not secure. If one of the following conditions is
satisfied, the security can be ensured.
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.
It is SUGGESTED not to initialize a binding based on DHCP Reply,
until the associated mechanism is also implemented.
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.
11.1.1.3. Following Actions
If the check fails, the triggering message SHOULD be discarded. This
event MAY be announced on console interface.
If the check is passed:
Bi Expires October 16, 2010 [Page 9]
Internet-Draft savi-dhcp April 2010
If the triggering message is DHCP Request/Confirm/Solicitation with
Rapid Commit Option:
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 client triggered initialization
The TID is kept as a mediator of assigned address and the anchor of
requesting node, to assure that the assigned address can be bound
with anchor secure.
If the triggering message is DHCP Reply:
The SAVI device MUST deliver the message to the destination.
The SAVI device MUST generate a new entry in BST and FT. The anchor
in entry is looked up based on the destination link layer address,
from mapping table from link layer address to anchor (e.g., the MAC-
Port mapping table in case that port is used as anchor). The state of
the corresponding entry is set to be LIVE. 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 Reply triggered initialization
Bi Expires October 16, 2010 [Page 10]
Internet-Draft savi-dhcp April 2010
+---------+----------+
|Anchor |Address |
+---------+----------+
|A |Addr |
+---------+----------+
Figure 6 Binding entry in FT on Reply triggered initialization
11.1.2. From START to LIVE
11.1.2.1. Trigger Event
A DHCPv4 DHCPACK or DHCPv6 REPLY message is received from SAVI-DHCP-
Trust anchor.
11.1.2.2. Event Validation
The SAVI device checks the message and BST as follows:
1. Whether there exists an entry in the BST with corresponding TID in
the START state.
11.1.2.3. Following Actions
If the check fails, the message may be used to trigger binding
initialization, specified in section 11.1.1.
If the check is passed:
The SAVI device MUST deliver the message to the destination.
The state of the corresponding entry is changed to be LIVE. 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 7 From START to LIVE
A corresponding entry MUST also be generated in FT.
Bi Expires October 16, 2010 [Page 11]
Internet-Draft savi-dhcp April 2010
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, and the state in BST must be LIVE.
11.1.3.3. Following Actions
If the check fails because of the Target Address is not in BST, the
packet MUST be discarded. If the entry state is not LIVE, the message
MUST be forwarded.
If the check is passed:
If the event is triggered by client, SAVI device MUST set the state
of the corresponding entry to be DETECTION.
+---------+----------+-----------+-----------------+-------+
| Anchor | Address | State | Lifetime |Other |
+---------+----------+-----------+-----------------+-------+
| A | Addr | DETECTION |MAX_ARP_DELAY or | Lease |
| | | |MAX_DAD_DELAY | Time |
+---------+----------+-----------+-----------------+-------+
Figure 8 From LIVE to DETECTION
If the triggering event is timeout event, the SAVI device MUST send
one or more ARP Request or DAD NSOL, with Target Address set to the
recorded address in the entry. The format of detection packet is
specified in section 14. The state MUST be changed to DETECTION. The
lifetime of the entry MUST be set to be MAX_ARP_DELAY or
MAX_DAD_DELAY respectively.
11.1.4. From DETECTION to BOUND
11.1.4.1. Trigger Event
A timeout event of an entry with state DETECTION occurs.
Bi Expires October 16, 2010 [Page 12]
Internet-Draft savi-dhcp April 2010
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. Binding Deletion in DETECTION State
11.1.5.1. Trigger Event
An ARP Response or NA/DAD NS targeting at an address in BST with
state DETECTION is received from a different anchor.
11.1.5.2. Following Actions
If ARP Response or NA is received from anchor with SAVI-Validation
attribute, but the address is not bound with the anchor, the packet
MUST be dropped. If DAD NS is received from anchor with SAVI-
Validation, the message MUST be delivered to the former detecting
node. The binding SHOULD be removed.
If the message is received from anchor with SAVI-Validation attribute,
and the address is bound with anchor, the message MUST be delivered
to the detecting node, and the binding MUST be removed.
If the message is received from anchor without SAVI-Validation
attribute, the message MUST be delivered to the detecting node. The
binding SHOULD be removed.
11.1.6. 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 13. 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.
Bi Expires October 16, 2010 [Page 13]
Internet-Draft savi-dhcp April 2010
Before a DHCP message is found that it may change the corresponding
binding, its validity MUST be checked as described in section 13.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.
Switch port down event (or in a more general expression, anchor turns
off-link) will change the corresponding entry, as described in
section 16.
11.2. State Machine of DHCP Snooping
The main state transits are listed as follows. Note that precondition
of state transit is not included. Triggering message/event must
satisfy the preconditions before changing the state.
State Message/Event Action Next State
- REQ/CFM/SOL+RC Generate entry START
*- ACK/RPL Generate entry with lease LIVE
START ACK/RPL Record lease time LIVE
START Timeout Remove entry -
LIVE Gra ARP REQ/DAD NS - DETECTION
LIVE DECLINE/RELEASE Remove entry -
LIVE Timeout Send probe DETECTION
DETECTION Timeout - BOUND
DETECTION ARP RES/DAD NS/NA Remove entry -
DETECTION DECLINE/RELEASE Remove entry -
Bi Expires October 16, 2010 [Page 14]
Internet-Draft savi-dhcp April 2010
BOUND RELEASE/DECLINE Remove entry -
BOUND Timeout Remove entry -
BOUND RPL with REN/REB Set new lifetime BOUND
*: optional but NOT SUGGESTED.
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 11.1.3 and section 14.
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
REN: DHCP RENEW
REB: DHCP REBOUND
12. 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 layer-2 path changes
after the binding has been set up, 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. In DHCP
Bi Expires October 16, 2010 [Page 15]
Internet-Draft savi-dhcp April 2010
scenario, till this document is finished, layer-2 path change and
local link movement are the only two events that must be handled
through this supplemental binding process.
This 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 this binding process.
At least one of the following techniques MUST be implemented in SAVI
device which deploys this solution:
1. Rate-limited Data Triggered Binding Process;
2. Counter Triggered Process;
3. Extended Control Packet Snooping Process.
Other techniques may be prudently chosen as alternative if found to
have equivalent or even better function to avoid permanently blocking
after discussion, implementation and deployment.
12.1. Rate-limited Data Triggered Binding Process
12.1.1. SAVI-DataTrigger Attribute
If data trigger binding process is implemented as the supplemental
binding process, an additional anchor attribute, named SAVI-
DataTrigger, MUST be implemented.
This attribute is mutually exclusive with SAVI-SAVI.
Data triggered binding process will be performed on the anchor with
such attribute.
12.1.2. Data Triggered Binding Process
If an anchor is set to have SAVI-DataTrigger attribute, data packet
whose source address is not bound with the anchor, may not be
filtered directly; instead, the SAVI device will check whether the
address can be used by the client on the local link with limited rate:
1. If the address has a local conflict, meaning the DAD on the
address fails, the packet MUST be discarded. If the address is not
being used, go to the next step.
2.
Bi Expires October 16, 2010 [Page 16]
Internet-Draft savi-dhcp April 2010
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.
The data triggered process MUST be rate limited to avoid Denial of
Services attack against the SAVI device itself. A constant
DATA_TRIGGER_INTERVAL is used to control the frequency. Two data
trigger processes on one anchor must have a minimum interval time
DATA_TRIGGER_INTERVAL. This constant SHOULD be configured prudently
to avoid Denial of Services.
Data triggered process is not strict secure. The node with data-
trigger anchor has the ability to use the address of an inactive node,
which doesn't reply to the DAD probe.
In case that the SAVI device is a pure layer-2 device, DHCP Confirm
MAY be used to replace the DHCP LEASEQUERY. The security degree may
degrade for the address may not be assigned by DHCP server.
Data triggered process may fail if any DHCP server doesn't support
LEASEQUERY.
12.2. Counter Triggered Process
12.2.1. SAVI-CounterTrigger Attribute
If counter triggered binding process is implemented as the
supplemental binding process, an additional anchor attribute, named
SAVI-CounterTrigger, MUST be implemented.
This attribute is mutually exclusive with SAVI-SAVI.
Bi Expires October 16, 2010 [Page 17]
Internet-Draft savi-dhcp April 2010
Counter triggered binding process will be performed on the anchor
with such attribute.
12.2.2. Counter Triggered Process
In this process, a counter is used to record the number of filtered
packets by this solution or all the enabled SAVI solutions on anchor
with SAVI-CounterTrigger attribute. A constant TRIGGER_COUNT is set
with the counter.
Whenever the counter reaches TRIGGER_COUNT, this event MUST be
handled by the SAVI device. The SAVI device performs following steps:
1. Set the counter to 0;
2. If the SAVI device is a layer-3 device, it MUST perform LEASEQUERY
to check whether the source address of the triggering packet can
be bound with the triggering anchor. If it is a layer-2 device,
DHCP Confirm can be used to replace LEASEQUERY. The security
degree may degrade for the address may not be assigned by DHCP
server.
3. This event MUST be announced to network administrator. For example,
a SNMP trap may be triggered; or an alert on console interface may
be generated.
The constant TRIGGER_COUNT MUST be prudently configured to fit the
specified deployment scenario. In extreme situation, it can be set to
1.
12.3. External Control Packet Snooping Process
12.3.1. SAVI-ExtSnooping Attribute
If extended control packet snooping is implemented as the
supplemental binding process, an additional anchor attribute, named
SAVI-ExSnooping, MUST be implemented.
This attribute is mutually exclusive with SAVI-SAVI.
Extended control packet snooping process will be performed on the
anchor with such attribute.
12.3.2. Extended Control Packet Snooping
In this snooping process, other than DHCP initialization messages,
other types of control packets processed by processor of SAVI device,
Bi Expires October 16, 2010 [Page 18]
Internet-Draft savi-dhcp April 2010
if the source address is not bound, may trigger the device to perform
binding process.
The control messages that MUST be processed include: (1) address
resolution Neighbor Solicitation; (2) Neighbor Advertisement; (3)
neighbor unreachability detection; (4) Multicast Listener Discovery;
(5) Address Resolution Protocol; (6) DHCP Renew/Rebind. Other ICMP
messages that may be processed by intermediate device may also
trigger the binding process.
The SAVI device MUST first perform DAD to check if the address has a
local conflict, and then send DHCP LEASEQUERY or Confirm to recover
binding based on DHCP server message.
A minimum time interval EXT_SNOOPING_INTERVAL MUST be set to limit
the rate of such triggering process.
Note that this process may not be able to avoid permanent block, in
case that only data packets are sent by node. Generally, this
mechanism is still practical, because data packet sending without
control plane communication is rare and suspicious in reality. Normal
traffic will contain control plane communication packets to help
traffic setup and fault diagnosis.
13. 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
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.
13.1. Data Packet Filtering
Data packets with an anchor which has attribute SAVI-Validation MUST
be checked.
Bi Expires October 16, 2010 [Page 19]
Internet-Draft savi-dhcp April 2010
If the source of a packet associated with its 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.
13.2. Control Packet Filtering
For anchors with SAVI-Validation attribute:
The source address of DHCPv4 Discovery MUST be set to all zeros. The
source address of DHCPv4 Request MUST 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 an 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.
For other anchors:
All DHCP Reply/Ack packets MUST be from anchor with the SAVI-DHCP-
Trust attribute.
14. Format and Delivery of Probe Messages
As described in section 11.1.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.
14.1. Duplicate detection
Message Type: DAD NS, Gratuitous ARP Request
Format:
Bi Expires October 16, 2010 [Page 20]
Internet-Draft savi-dhcp April 2010
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.
15. Binding Remove
If the lifetime of an entry with state BOUND expires, the entry MUST
be removed.
16. 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, the entry MAY be removed.
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,
and 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.
17. About Collision in Detection
The SAVI device may receive a response in detection. Some related
details are specified here.
Bi Expires October 16, 2010 [Page 21]
Internet-Draft savi-dhcp April 2010
17.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.
17.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.
18. 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
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.
19. 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.
Bi Expires October 16, 2010 [Page 22]
Internet-Draft savi-dhcp April 2010
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,
because they can't recover bindings on the SAVI device of themselves.
Thus, binding entries SHOULD be saved into non-volatile storage
whenever a new binding entry changes to BOUND state or a binding with
state BOUND is removed, unless other alternatives specified here is
implemented.
If binding is saved into non-volatile memory, 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.
The possible alternatives are:
If the SAVI device is also the DHCP relay, an alternative mechanism
is fetching the bindings through bulk DHCP LEASEQUERY [RFC5460].
If the network enables 802.1ag, the bindings can be recovered with
the help of the first hop routers through snooping unicast Neighbor
Solicitations sent by routers based on the Neighbor Table.
22. Stateless DHCP
In a stateless DHCP scenario [RFC3736], DHCP is used to configure
other parameters but rather IP address. The address of the client
SHOULD be bound based on other SAVI solutions, but rather this
solution designed for stateful DHCP.
23. Confirm Triggered Binding
If a binding entry is triggered by a CONFIRM message from the client,
no lease time will be contained in the REPLY from DHCP server. The
SAVI device MUST send LEASEQUERY message to get the lease time of the
address to complete the binding entry. If no successful LEASEQUERY-
REPLY is received, the binding entry SHOULD be removed. In this
scenario, the address is not regarded as assigned by DHCP, and it may
be bound through other SAVI solution.
Bi Expires October 16, 2010 [Page 23]
Internet-Draft savi-dhcp April 2010
If the confirmed address has local conflict, the Client-ID field of
Confirm and LEASEQUERY-REPLY MUST be compared. If they are not match,
the new binding entry MUST be deleted.
24. Handle Layer 2 Path Change
Layer 2 path change is an important challenge on this control plane
based solution. The SAVI device MUST be sensitive to any layer 2 path
change. Whenever a layer 2 control protocol frame, including STP,
RSTP, TRILL, is received from some anchor, which announces a layer 2
incoming path is changed to the anchor, data packet trigger process
SHOULD be enabled on the anchor for a period, or alternatively the
device SHOULD forward the packets directly for a period, and set up
bindings from Neighbor Table. Although generally such events can be
handled through pre-configuration of data-trigger attribute, the
future layer 2 protocol may be flexible and hard to handle through
manual configuration.
25. Duplicate Bindings on Same Address
Note that the same address may be bound with multiple anchors, only
if the binding processes are finished on each anchor successfully
respectively.
This mechanism is designed in consideration that a node may move on
the local ink, and a node may have multiple anchors.
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 anchor
of the moving node have the ability to use its address.
26. 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
DATA_TRIGGER_INTERVAL Device capacity depended and configurable
TRIGGER_COUNT Device capacity depended and configurable
Bi Expires October 16, 2010 [Page 24]
Internet-Draft savi-dhcp April 2010
27. 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.
28. IANA Considerations
There is no IANA consideration currently.
29. References
29.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
29.2. Informative References
[RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC2131,
March 1997.
[RFC3307] B. Haberman, "Allocation Guidelines for IPv6 Multicast
Addresses", RFC3307, August 2002.
[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.
[RFC5227] S. Cheshire, "IPv4 Address Conflict Detection", RFC5227,
July 2008.
[IP Source Guard] Cisco, "Network Security Technologies and
Solutions", chapter 7, Cisco Press, May 20, 2008.
Bi Expires October 16, 2010 [Page 25]
Internet-Draft savi-dhcp April 2010
30. 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, John Kaippallimalil, Tao
Lin , and Dong Zhang for their valuable contributions.
Bi Expires October 16, 2010 [Page 26]
Internet-Draft savi-dhcp April 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 October 16, 2010 [Page 27]
