One document matched: draft-ietf-savi-dhcp-04.txt
Differences from draft-ietf-savi-dhcp-03.txt
SAVI J. Bi, J. Wu
Internet Draft CERNET
Intended status: Standard Tracks G. Yao
Expires: January 2011 Tsinghua Univ.
F. Baker
Cisco
July 5, 2010
SAVI Solution for DHCP
draft-ietf-savi-dhcp-04.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 January 5, 2011 [Page 1]
Internet-Draft savi-dhcp July 2010
This Internet-Draft will expire on December 5, 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 source IP address.
Table of Contents
Copyright Notice ............................................... 2
Abstract ....................................................... 2
1. Introduction ................................................ 4
2. Conventions used in this document............................ 4
3. Mechanism Overview .......................................... 4
4. Terminology ................................................. 4
5. Conceptual Data Structures................................... 5
5.1. Control Plane Data Structure: Binding State Table(BST).. 5
5.2. Data Plane Data Structure: Filtering Table(FT).......... 5
6. Binding States Description................................... 6
7. DHCP Scenario ............................................... 6
8. Binding Anchor Attributes.................................... 7
8.1. No Attribute ........................................... 7
8.2. SAVI-Validation Attribute............................... 7
8.3. SAVI-DHCP-Trust Attribute............................... 7
8.4. SAVI-SAVI Attribute..................................... 8
8.5. SAVI-BindRecovery Attribute............................. 8
8.6. SAVI-ExtSnooping Attribute.............................. 8
9. Binding Set Up .............................................. 8
Bi Expires January 5, 2011 [Page 2]
Internet-Draft savi-dhcp July 2010
9.1. Rationale .............................................. 8
9.2. Process of Control Packet Snooping...................... 9
9.2.1. Initialization..................................... 9
9.2.1.1. Trigger Event................................. 9
9.2.1.2. Event Validation............................. 10
9.2.1.3. Following Actions............................ 10
9.2.2. From START to LIVE................................ 11
9.2.2.1. Trigger Event................................ 11
9.2.2.2. Event Validation............................. 11
9.2.2.3. Following Actions............................ 12
9.2.3. From LIVE to DETECTION............................ 12
9.2.3.2. Event Validation............................. 12
9.2.3.3. Following Actions............................ 12
9.2.4. From DETECTION to BOUND........................... 13
9.2.4.1. Trigger Event................................ 13
9.2.4.2. Following Actions............................ 13
9.2.5. Binding Deletion in DETECTION State............... 13
9.2.5.1. Trigger Event................................ 13
9.2.5.2. Following Actions............................ 14
9.2.6. After BOUND....................................... 14
9.3. State Machine of DHCP Snooping......................... 15
10. Supplemental Binding Process:Handling Link Topology Change. 16
10.1. Binding Recovery Process.............................. 17
10.2. External Control Packet Snooping Process.............. 18
11. Filtering Specification.................................... 18
11.1. Data Packet Filtering................................. 19
11.2. Control Packet Filtering.............................. 19
12. Format and Delivery of Probe Messages...................... 19
12.1. Duplicate Detection................................... 20
13. Binding Remove ............................................ 20
14. Handle Binding Anchor Off-link Event....................... 20
15. About Collision in Detection............................... 21
16. Binding Number Limitation.................................. 21
17. MLD Consideration ......................................... 22
18. State Restoration ......................................... 22
19. Confirm Triggered Binding.................................. 22
20. Consideration on Link Layer Routing Complexity............. 23
21. Duplicate Bindings of Same Address......................... 23
22. Constants ................................................. 23
23. Security Considerations.................................... 24
24. IANA Considerations........................................ 24
25. References ................................................ 24
25.1. Normative References.................................. 24
25.2. Informative References................................ 24
26. Acknowledgments ........................................... 25
27. Change Log ................................................ 26
Bi Expires January 5, 2011 [Page 3]
Internet-Draft savi-dhcp July 2010
1. Introduction
This document describes the procedure for creating bindings between
DHCP assigned addresses and a binding 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 address.
Section 12 suggests usage of these bindings for common practice.
[savi-framework] may specify different usages of binding, depending
on the environment and configuration. The definition and examples of
binding anchor is 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.
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.
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 an
address 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 binding anchors. The
bindings can be used to validate the source address in the packets.
4. Terminology
Main terms used in this document are described in [savi-framework],
[RFC2131] and [RFC3315].
Bi Expires January 5, 2011 [Page 4]
Internet-Draft savi-dhcp July 2010
5. 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.
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 in DHCP request. Before a binding is
finished, the lease time of the address is also 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 1 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.
Bi Expires January 5, 2011 [Page 5]
Internet-Draft savi-dhcp July 2010
+---------+----------+
| Anchor |Address |
+---------+----------+
|A |IP_1 |
+---------+----------+
|A |IP_2 |
+---------+----------+
Figure 2 Instance of FT
6. 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 binding anchor.
7. 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 January 5, 2011 [Page 6]
Internet-Draft savi-dhcp July 2010
+--------+
| DHCP |
| Server |
+--------+
|
|
|
+----'-----+
| SAVI |
| Device |
+-/------/-+
| |
+----\-+ +\-----+
|DHCP | |Client|
|Relay | | |
+------+ +------+
Figure 3 DHCP Scenario
8. Binding Anchor Attributes
This section specifies the binding anchor attributes involved in this
mechanism.
Binding anchor is defined in the [savi-framework]. Attribute of each
binding anchor is configurable. In default, binding anchor has no
attribute. A binding anchor MAY be configured to have one or more
compatible attributes. However, a binding anchor MAY have no
attribute.
8.1. No Attribute
By default, a binding anchor has no attribute. Server type DHCP
message from binding anchor with no attribute MUST be dropped.
However, other packets SHOULD NOT be dropped.
8.2. SAVI-Validation Attribute
SAVI-Validation attribute is used on binding anchor on which the
source addresses are to be validated. The filtering process on
binding anchor with such attribute is described in section 13.
8.3. SAVI-DHCP-Trust Attribute
SAVI-DHCP-Trust Attribute is used on binding anchor on the path to a
trustable DHCP server/relay.
Bi Expires January 5, 2011 [Page 7]
Internet-Draft savi-dhcp July 2010
DHCP server/relay message coming from binding anchor with this
attribute will be forwarded.
8.4. SAVI-SAVI Attribute
This attribute is used on binding anchor from which the traffic is
not to be checked. All traffic from binding anchor with this
attribute will be forwarded without check. Note that DHCP server
message and router message will also be trusted.
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 [savi-framework]. Since
no binding entry is needed on such binding anchor, the binding entry
resource requirement can be reduced greatly.
This attribute can also be set on other binding anchors if the
administrator decides not to validate the traffic from the binding
anchor.
This attribute is mutually exclusive with SAVI-Validation.
8.5. SAVI-BindRecovery Attribute
This attribute is used on binding anchor that requires binding
recovery described in section 10.1.
This attribute is mutually exclusive with SAVI-SAVI.
8.6. SAVI-ExtSnooping Attribute
This attribute is used on binding anchor that requires external
control packet snooping described in section 10.2.
This attribute is mutually exclusive with SAVI-SAVI.
9. 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 binding anchor with SAVI-Validation
attribute.
9.1. Rationale
The rationale of this mechanism is that if a node attached to a
binding anchor intends to use a valid DHCP address, the DHCP
Bi Expires January 5, 2011 [Page 8]
Internet-Draft savi-dhcp July 2010
procedure which assigns the address to the node goes first on the
same binding anchor. This basis stands when the link layer routing is
stable. However, unstable link layer routing may result in that data
packet is received from a different binding anchor with the DHCP
messages. Infrequent link layer path change can be handled (but not
perfectly) by the mechanism described in section 10. Section 20
discusses the situation that link layer routing is naturedly unstable.
To handle this situation is above the scope of this document.
This mechanism is mainly composed by 1: DHCP snooping; 2: Duplicate
Address Detection (DAD) snooping. DHCP snooping alone is not
sufficient to finish a binding. Three reasons are listed to support
this point:
(1) The assigned address may be already configured on another
host through SLAAC or manual configuration.
(2) If multiple DHCP servers exist in the network, or the
server(s) loses state, an assigned address may be assigned
again before withdraw.
(3) Bogus/misconfigured DHCP server may also assign an already
assigned address.
For the above reasons, set up a binding solely on DHCP snooping may
violate existing binding or address assignment. Thus, DAD snooping is
necessary for finishing a binding.
Due to DAD may not be performed by host (especially for IPv4 address)
or the DAD NS may get lost, SAVI devices are required to perform DAD
on behavior of the host.
9.2. Process of Control Packet Snooping
9.2.1. Initialization
A binding entry is initialized in this step.
9.2.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 binding anchor with SAVI-DHCP-Trust
attribute. 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
Bi Expires January 5, 2011 [Page 9]
Internet-Draft savi-dhcp July 2010
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 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 SUGGESTED not to initialize a binding based on DHCP Reply,
until the associated mechanism is also implemented.
9.2.1.2. Event Validation
The SAVI device checks current BST as follows:
1. Whether the limitation on binding entry number of this binding
anchor will be exceeded if a new entry is triggered.
9.2.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:
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 binding 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 MUST be recorded in the entry,
except that the mapping from link layer address to binding anchor is
secure as specified in section 9.2.1.1.
+---------+----------+-------+-----------------------+-------+
| Anchor | Address | State | Lifetime |Other |
+---------+----------+-------+-----------------------+-------+
| A | | START |MAX_DHCP_RESPONSE_TIME | TID |
+---------+----------+-------+-----------------------+-------+
Figure 4 Binding entry in BST on client triggered initialization
Bi Expires January 5, 2011 [Page 10]
Internet-Draft savi-dhcp July 2010
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 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 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 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
+---------+----------+
| Anchor |Address |
+---------+----------+
|A |Addr |
+---------+----------+
Figure 6 Binding entry in FT on Reply triggered initialization
9.2.2. From START to LIVE
9.2.2.1. Trigger Event
A DHCPv4 DHCPACK or DHCPv6 REPLY message is received from SAVI-DHCP-
Trust binding anchor.
9.2.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.
Bi Expires January 5, 2011 [Page 11]
Internet-Draft savi-dhcp July 2010
9.2.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.
9.2.3. From LIVE to DETECTION
9.2.3.1. Trigger Event
A gratuitous ARP Request or Duplicate Address Detection Neighbor
Solicitation is received from binding anchor. Or a timeout event of
an entry with state LIVE happens.
9.2.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 binding anchor
in BST or FT, and the state in BST must be LIVE.
9.2.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:
Bi Expires January 5, 2011 [Page 12]
Internet-Draft savi-dhcp July 2010
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 triggered by timeout event on an entry in state LIVE, 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.
9.2.4. From DETECTION to BOUND
9.2.4.1. Trigger Event
A timeout event of an entry with state DETECTION occurs.
9.2.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.
9.2.5. Binding Deletion in DETECTION State
9.2.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 binding anchor.
Bi Expires January 5, 2011 [Page 13]
Internet-Draft savi-dhcp July 2010
9.2.5.2. Following Actions
If ARP Response or NA is received from binding anchor with SAVI-
Validation attribute, but the address is not bound with the binding
anchor, the packet MUST be dropped. If DAD NS is received from
binding 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 binding anchor with SAVI-Validation
attribute, and the address is bound with binding anchor, the message
MUST be delivered to the detecting node, and the binding MUST be
removed.
If the message is received from binding anchor without SAVI-
Validation attribute, the message MUST be delivered to the detecting
node. The binding SHOULD be removed.
9.2.6. After BOUND
Once a binding entry is set up for a binding anchor, the binding will
be used to filter packet with the binding anchor, as specified in
section 13. On the other hand, DHCP messages with the binding anchor
will affect the binding. The binding is also affected by DHCP server
message toward the binding anchor.
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, binding
anchor turns off-link) will change the corresponding entry, as
described in section 16.
Bi Expires January 5, 2011 [Page 14]
Internet-Draft savi-dhcp July 2010
9.3. 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 -
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
Bi Expires January 5, 2011 [Page 15]
Internet-Draft savi-dhcp July 2010
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
10. Supplemental Binding Process: Handling Link Topology Change
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, which
can be regarded as a special case of link topology change. In DHCP
scenario, till this document is finished, link topology change is the
only two events that must be handled through this supplemental
binding 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.
For implementations that will face the above problem:
1. Binding Recovery Process is a conditional SHOULD. This process
SHOULD be implemented, unless the managed nodes are directly
attached to the SAVI device. If the mechanism is not implemented
and managed nodes are not directly attached, permanent blocking
will happen until the node is re-configured.
2. Extended Control Packet Snooping Process is a MUST.
Bi Expires January 5, 2011 [Page 16]
Internet-Draft savi-dhcp July 2010
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.
10.1. Binding Recovery Process
Refer to [draft-baker-savi-one-implementation-approach] for a
detailed implementation suggestion. The process specified here can
only be enabled in condition that implementation can meet the
specified hardware requirements described in [draft-baker-savi-one-
implementation-approach].
If a binding anchor is set to have SAVI-BindRecovery attribute, a
FIFO queue or register MUST be used to save recently filtered packets.
The SAVI device will fetch packet from the queue/register to check
the source address can be used by corresponding 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.
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 based processes on one
binding anchor must have a minimum interval time
Bi Expires January 5, 2011 [Page 17]
Internet-Draft savi-dhcp July 2010
BIND_RECOVERY_INTERVAL. This constant SHOULD be configured prudently
to avoid Denial of Services.
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 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.
This process may fail if any DHCP server doesn't support LEASEQUERY.
10.2. External Control Packet Snooping Process
In this snooping process, other than DHCP initialization messages,
other types of control packets processed by processor of SAVI device,
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.
11. 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
Bi Expires January 5, 2011 [Page 18]
Internet-Draft savi-dhcp July 2010
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.
11.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.
11.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.
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.
12. 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
Bi Expires January 5, 2011 [Page 19]
Internet-Draft savi-dhcp July 2010
address is duplicated. Currently no other probes are designed in this
solution.
12.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.
13. Binding Remove
If the lifetime of an entry with state BOUND expires, the entry MUST
be removed.
14. 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,
the bindings with the binding 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 binding 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 binding anchor got off by a
previous node, and then it can use the address assigned to the
Bi Expires January 5, 2011 [Page 20]
Internet-Draft savi-dhcp July 2010
previous node. However, this situation is very rare in reality.
Authors decide not to handle this situation.
15. About Collision in Detection
The SAVI device may find a collision in detection. Some related
details are specified here.
Whether to notify the DHCP server:
To conform to current standard, the host should send a Decline
message to refuse the collision address. If the host doesn't do it,
it is still improper for the SAVI device to decline the address.
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.
16. 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, using the bound entry
number of each binding anchor as reverse indicator.
Bi Expires January 5, 2011 [Page 21]
Internet-Draft savi-dhcp July 2010
17. MLD Consideration
The SAVI device MUST join the solicited-node multicast address of the
tentative address whenever perform duplicate detection on behavior of
host.
18. 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 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.
The possible alternatives proposed but not suitable for general cases
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.
19. 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.
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.
Bi Expires January 5, 2011 [Page 22]
Internet-Draft savi-dhcp July 2010
20. Consideration on Link Layer Routing Complexity
An implicit assumption of this solution is that data packet must
arrive at the same binding anchor of the control packet. If this
assumption is not valid, this control packet based solution may fail
or at least discard legitimate packet. Unfortunately, if the link
layer routing between host and SAVI device is inconsistent from time
to time, this assumption doesn't stand. Time consistency of link
layer routing is not assured by link layer routing protocol. 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.
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.
21. Duplicate Bindings of Same Address
Note that 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.
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.
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
Bi Expires January 5, 2011 [Page 23]
Internet-Draft savi-dhcp July 2010
BIND_RECOVERY_INTERVAL Device capacity depended and 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.
25.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.
Bi Expires January 5, 2011 [Page 24]
Internet-Draft savi-dhcp July 2010
[IP Source Guard] Cisco, "Network Security Technologies and
Solutions", chapter 7, Cisco Press, May 20, 2008.
[draft-baker-savi-one-implementation-approach] F. Baker, "An
implementation approach to Source Address Validation",
draft-baker-savi-one-implementation-approach-00.
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, John Kaippallimalil and Tao
Lin for their valuable contributions.
Bi Expires January 5, 2011 [Page 25]
Internet-Draft savi-dhcp July 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
27. 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."
Main changes from 03 to 04:
- Section "Prefix configuration" is removed.
Bi Expires January 5, 2011 [Page 26]
Internet-Draft savi-dhcp July 2010
- 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.
Bi Expires January 5, 2011 [Page 27]
| PAFTECH AB 2003-2026 | 2026-04-24 05:35:20 |