< draft-ietf-savi-dhcp-27.txt   draft-ietf-savi-dhcp-28.txt >
SAVI J. Bi SAVI J. Bi
Internet-Draft J. Wu Internet-Draft J. Wu
Intended status: Standards Track G. Yao Intended status: Standards Track G. Yao
Expires: December 28, 2014 Tsinghua Univ. Expires: January 6, 2015 Tsinghua Univ.
F. Baker F. Baker
Cisco Cisco
June 26, 2014 July 5, 2014
SAVI Solution for DHCP SAVI Solution for DHCP
draft-ietf-savi-dhcp-27 draft-ietf-savi-dhcp-28
Abstract Abstract
This document specifies the procedure for creating a binding between This document specifies the procedure for creating a binding between
a DHCPv4/DHCPv6 assigned IP address and a binding anchor on a SAVI a DHCPv4/DHCPv6 assigned IP address and a binding anchor on a SAVI
(Source Address Validation Improvements) device. The bindings set up (Source Address Validation Improvements) device. The bindings set up
by this procedure is used to filter out packets with forged source IP by this procedure is used to filter out packets with forged source IP
address in DHCP scenario. This mechanism is proposed as a complement address in DHCP scenario. This mechanism is proposed as a complement
to ingress filtering to provide finer-grained source IP address to ingress filtering to provide finer-grained source IP address
validation. validation.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 28, 2014. This Internet-Draft will expire on January 6, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 40 skipping to change at page 2, line 40
4.2.1. Trust Attribute . . . . . . . . . . . . . . . . . . . 10 4.2.1. Trust Attribute . . . . . . . . . . . . . . . . . . . 10
4.2.2. DHCP-Trust Attribute . . . . . . . . . . . . . . . . 10 4.2.2. DHCP-Trust Attribute . . . . . . . . . . . . . . . . 10
4.2.3. DHCP-Snooping Attribute . . . . . . . . . . . . . . . 11 4.2.3. DHCP-Snooping Attribute . . . . . . . . . . . . . . . 11
4.2.4. Data-Snooping Attribute . . . . . . . . . . . . . . . 11 4.2.4. Data-Snooping Attribute . . . . . . . . . . . . . . . 11
4.2.5. Validating Attribute . . . . . . . . . . . . . . . . 11 4.2.5. Validating Attribute . . . . . . . . . . . . . . . . 11
4.2.6. Table of Mutual Exclusions . . . . . . . . . . . . . 12 4.2.6. Table of Mutual Exclusions . . . . . . . . . . . . . 12
4.3. Perimeter . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3. Perimeter . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3.1. SAVI-DHCP Perimeter Overview . . . . . . . . . . . . 13 4.3.1. SAVI-DHCP Perimeter Overview . . . . . . . . . . . . 13
4.3.2. SAVI-DHCP Perimeter Configuration Guideline . . . . . 13 4.3.2. SAVI-DHCP Perimeter Configuration Guideline . . . . . 13
4.3.3. On the Placement of DHCP Server/Relay . . . . . . . . 14 4.3.3. On the Placement of DHCP Server/Relay . . . . . . . . 14
4.3.4. An alternative deployment . . . . . . . . . . . . . . 15 4.3.4. An Alternative Deployment . . . . . . . . . . . . . . 15
4.3.5. Considerations on Binding Anchor . . . . . . . . . . 16 4.3.5. Considerations on Binding Anchor . . . . . . . . . . 16
4.4. Address Configuration . . . . . . . . . . . . . . . . . . 17
5. Binding State Table (BST) . . . . . . . . . . . . . . . . . . 17 5. Binding State Table (BST) . . . . . . . . . . . . . . . . . . 17
6. DHCP Snooping Process . . . . . . . . . . . . . . . . . . . . 18 6. DHCP Snooping Process . . . . . . . . . . . . . . . . . . . . 18
6.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2. Binding States Description . . . . . . . . . . . . . . . 19 6.2. Binding States Description . . . . . . . . . . . . . . . 19
6.3. Events . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.3. Events . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.3.1. Timer Expiration Event . . . . . . . . . . . . . . . 19 6.3.1. Timer Expiration Event . . . . . . . . . . . . . . . 19
6.3.2. Control Message Arriving Events . . . . . . . . . . . 19 6.3.2. Control Message Arriving Events . . . . . . . . . . . 19
6.4. The State Machine of DHCP Snooping Process . . . . . . . 21 6.4. The State Machine of DHCP Snooping Process . . . . . . . 21
6.4.1. From NO_BIND to INIT_BIND . . . . . . . . . . . . . . 21 6.4.1. From NO_BIND to INIT_BIND . . . . . . . . . . . . . . 21
6.4.2. From INIT_BIND to Other States . . . . . . . . . . . 22 6.4.2. From INIT_BIND to Other States . . . . . . . . . . . 22
skipping to change at page 4, line 32 skipping to change at page 4, line 32
address, SAVI-FCFS [RFC6620] should be enabled. Besides, this address, SAVI-FCFS [RFC6620] should be enabled. Besides, this
mechanism is primarily designed for pure DHCP scenarios in which only mechanism is primarily designed for pure DHCP scenarios in which only
addresses assigned through DHCP are allowed. However, it does not addresses assigned through DHCP are allowed. However, it does not
block any link-local address. It is because link-local addresses are block any link-local address. It is because link-local addresses are
used by DHCPv6 clients before the clients are assigned a DHCPv6 used by DHCPv6 clients before the clients are assigned a DHCPv6
address. Considering that link-local addresses are generally self- address. Considering that link-local addresses are generally self-
generated, and the spoofing of link local address may disturb this generated, and the spoofing of link local address may disturb this
mechanism, it is RECOMMENDED to enable a SAVI solution for link-local mechanism, it is RECOMMENDED to enable a SAVI solution for link-local
addresses, e.g., the SAVI-FCFS [RFC6620]. addresses, e.g., the SAVI-FCFS [RFC6620].
This mechanism works with DHCPv4 and DHCPv6. However, the DHCP This mechanism works for DHCPv4-only, DHCPv6-only, or both DHCPv4 and
address assignment mechanims in IPv4/IPv6 transition scenarios, e.g., DHCPv6. However, the DHCP address assignment mechanims in IPv4/IPv6
[I-D.ietf-dhc-dhcpv4-over-dhcpv6], are beyond the scope of this transition scenarios, e.g., [I-D.ietf-dhc-dhcpv4-over-dhcpv6], are
document. beyond the scope of this document.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Terminology 3. Terminology
Binding anchor: A "binding anchor" is defined to be a link layer Binding anchor: A "binding anchor" is defined to be a link layer
skipping to change at page 14, line 38 skipping to change at page 14, line 38
Such a requirement is due to the limitation of this binding based Such a requirement is due to the limitation of this binding based
mechanism. This document makes no assumption that the DHCP server- mechanism. This document makes no assumption that the DHCP server-
client messages arriving the perimeter from the outside can be client messages arriving the perimeter from the outside can be
trusted. The binding anchor of a trusted remote DHCP server can be trusted. The binding anchor of a trusted remote DHCP server can be
shared by a bogus DHCP server. Thus, the SAVI device cannot shared by a bogus DHCP server. Thus, the SAVI device cannot
distinguish bogus and valid DHCP messages only based on the distinguish bogus and valid DHCP messages only based on the
associated binding anchor of DHCP messages in such case. associated binding anchor of DHCP messages in such case.
Note that even if a DHCP server is valid, it may be not contained in Note that even if a DHCP server is valid, it may be not contained in
the perimeter based on the guideline. For example, in Figure 1, DHCP the perimeter based on the guideline. For example, in Figure 1, DHCP
server A is valid, but it is attached to a Non-SAVI device. The Non- server A is valid, but it is attached to the Non-SAVI device 1. The
SAVI device may be attached by attackers which generate forged DHCP Non-SAVI device 1 is attached by a bogus DHCP server. This binding
messages. This binding based mechanism may not have the ability to based mechanism may not have the ability to distinguish whether a
distinguish whether a message received from the attachment of the message received from the port of the Non-SAVI device 1 is from DHCP
Non-SAVI device 1 is from DHCP server A or the attackers. If the server A or the bogus DHCP server. If the DHCP server A is contained
DHCP server A is contained in the perimeter, the Non-SAVI device 1 in the perimeter, the Non-SAVI device 1 will also be contained in the
will also be contained in the perimeter. However, the Non-SAVI perimeter. However, the Non-SAVI device 1 can introduce forged DHCP
device 1 can introduce forged DHCP messages into the perimeter. messages into the perimeter. Thus, the DHCP server A cannot be
Thus, the DHCP server A cannot be contained in the perimeter. contained in the perimeter.
In this case, the SAVI devices can set up bindings for addresses In this case, the SAVI devices can set up bindings for addresses
assigned by DHCP server A through snooping the messages relayed by assigned by DHCP server A through snooping the messages relayed by
trusted relay in the network. For example, the DHCP relay may relay trusted relay in the network. For example, the DHCP relay may relay
messages between DHCP server A and the clients in the network, and messages between DHCP server A and the clients in the network, and
the SAVI devices can snoop messages from the DHCP relay which is the SAVI devices can snoop the last hop messages from the DHCP relay,
inside the perimeter. The authentication mechanism (i.e., IPsec, as which is inside the perimeter. The authentication mechanism (i.e.,
specified in section 21.1 of [RFC3315]) enforced between the DHCP IPsec, as specified in section 21.1 of [RFC3315]) enforced between
relay and the DHCP server outside the perimeter can compensate this the DHCP relay and the DHCP server outside the perimeter can
binding based mechanism. It is SUGGESTED to configure IPsec between compensate this binding based mechanism. It is SUGGESTED to
the DHCP relay and the DHCP server in such case. If source address configure IPsec between the DHCP relay and the DHCP server in such
validation is enforced in the whole network, which makes the source case. If source address validation is enforced in the whole network,
IP address trustable, the DHCP relay and the DHCP server can simply which makes the source IP address trustable, the DHCP relay and the
authenticate the messages from each other based on the source IP DHCP server can simply authenticate the messages from each other
address. Nevertheless, it should be noted that the integrity of the based on the source IP address. Nevertheless, it should be noted
messages is not ensured. that the integrity of the messages is not ensured.
Another consideration on the placement is that if the DHCP server/ Another consideration on the placement is that if the DHCP server/
relay is not inside the perimeter, the SAVI devices may not be able relay is not inside the perimeter, the SAVI devices may not be able
to set up bindings correctly, because the SAVI devices may not be on to set up bindings correctly, because the SAVI devices may not be on
the path between the clients and the server/relay, or the DHCP the path between the clients and the server/relay, or the DHCP
messages are encapsulated (e.g., Relay-reply and Relay-forward). messages are encapsulated (e.g., Relay-reply and Relay-forward).
4.3.4. An alternative deployment 4.3.4. An Alternative Deployment
In a number of deployment practices, the traffic from the upstream In a number of deployment practices, the traffic from the upstream
network are all treated as trustable. In such a case, Trust network are all treated as trustable. In such a case, Trust
attribute can be set on the upstream link; and if a Non-SAVI device, attribute can be set on the upstream link; and if a Non-SAVI device,
or a number of connected Non-SAVI devices, have only attachments from or a number of connected Non-SAVI devices, have only attachments from
SAVI devices and upstream devices, their attachment to SAVI devices SAVI devices and upstream devices, their attachment to SAVI devices
can be set Trust attribute. Then an unclosed perimeter will be can be set Trust attribute. Then an unclosed perimeter will be
formed, as illustrate in Figure 3. formed, as illustrate in Figure 3.
| . . Protection | | . . Protection |
skipping to change at page 16, line 44 skipping to change at page 16, line 44
of the binding anchor. If the binding anchor is spoofable, e.g., of the binding anchor. If the binding anchor is spoofable, e.g.,
plain MAC address, an attacker can use forged binding anchor to send plain MAC address, an attacker can use forged binding anchor to send
packet which will not be regarded as spoofing by SAVI device. packet which will not be regarded as spoofing by SAVI device.
Indeed, using binding anchor that can be easily spoofed can lead to Indeed, using binding anchor that can be easily spoofed can lead to
worse outcomes than allowing IP spoofing traffic. For example, an worse outcomes than allowing IP spoofing traffic. For example, an
attacker can use the binding anchor of another client to bind a large attacker can use the binding anchor of another client to bind a large
number of addresses, and the SAVI device will refuse to set up new number of addresses, and the SAVI device will refuse to set up new
binding for the client whenever the binding number limitation has binding for the client whenever the binding number limitation has
been reached; as a result, even the legitimate clients cannot access been reached; as a result, even the legitimate clients cannot access
the network. Thus, it is RECOMMENDED to use unspoofable binding the network. Thus, it is RECOMMENDED to use unspoofable binding
anchor, e.g., switch port. This document only focuses on switch port anchor, e.g., switch port. By default,t his document assumes the
as binding anchor. The implications of using other forms of binding binding anchor is switch port. The implications of using other forms
anchors should be properly analyzed. of binding anchors should be properly analyzed.
If the binding anchor is shared by more than one clients, the clients If the binding anchor is shared by more than one clients, the clients
can spoof each other addresses. For example, if a switch port is can spoof each other addresses. For example, if a switch port is
used as binding anchor, a number of clients can attach to the same used as binding anchor, a number of clients can attach to the same
switch port of a SAVI device through a hub. The SAVI device cannot switch port of a SAVI device through a hub. The SAVI device cannot
distinguish packets from different clients and thus the spoofing distinguish packets from different clients and thus the spoofing
between them will not be detected. A number of the above security between them will not be detected. A number of the above security
problems are caused by sharing binding anchors. For example, an problems are caused by sharing binding anchors. For example, an
attacker can send a DHCP Release message to remove the binding of a attacker can send a DHCP Release message to remove the binding of a
client sharing the same binding anchor. Thus, it is RECOMMENDED to client sharing the same binding anchor. Thus, it is RECOMMENDED to
use exclusive binding anchor. use exclusive binding anchor.
4.4. Address Configuration
If the implementation of this SAVI mechanism does not support the
DHCP Leasequery process specified in Section 6.4.1.2 and the Data
Snooping Process, it actually requires no address configuration. To
support the full features of this mechanism, an implementation has
the following address configuration requirements:
(1) For DHCPv4: the SAVI device needs an IPv4 address.
(2) For DHCPv6: the SAVI device needs a local address; when the
DHCPv6 server is not on the same link as the SAVI device, the
SAVI device needs also a global IPv6 address.
5. Binding State Table (BST) 5. Binding State Table (BST)
Binding State Table is used to contain the bindings between the IP Binding State Table is used to contain the bindings between the IP
addresses assigned to the attachments and the corresponding binding addresses assigned to the attachments and the corresponding binding
anchors of the attachments. Each entry of the table, i.e., binding anchors of the attachments. Each entry of the table, i.e., binding
entry, has 5 fields: entry, has 5 fields:
o Binding Anchor(Anchor): the binding anchor, i.e., a link-layer o Binding Anchor(Anchor): the binding anchor, i.e., a link-layer
property of the attachment. property of the attachment.
skipping to change at page 41, line 12 skipping to change at page 41, line 12
sent by the client will not be discarded, because the source IP sent by the client will not be discarded, because the source IP
address field should be all zero as required by [RFC2131]. Thus, if address field should be all zero as required by [RFC2131]. Thus, if
the address is still valid, the binding will be recovered from the the address is still valid, the binding will be recovered from the
DHCP Snooping Process. DHCP Snooping Process.
11.5. Authentication in DHCPv6 Leasequery 11.5. Authentication in DHCPv6 Leasequery
As required in section 5 of [RFC5007], DHCPv6 Leasequery 'Should' use As required in section 5 of [RFC5007], DHCPv6 Leasequery 'Should' use
IPsec-based authentication specified in the section 21.1 of IPsec-based authentication specified in the section 21.1 of
[RFC3315]. However, IPsec is generally considered heavyweight. With [RFC3315]. However, IPsec is generally considered heavyweight. With
the deployment of this mechanism, the source IP address can be the deployment of this mechanism, the source IP address may be
authenticated without enforcing IPsec. authenticated without enforcing IPsec.
By containing the DHCP servers in the protection perimeter, the DHCP By containing the DHCP servers in the protection perimeter, the DHCP
servers can be protected from spoofing based attacks. Then by servers can be protected from spoofing based attacks. Then by
checking the source IP address of Leasequery messages, the DHCP maintaining a list of SAVI device addresses, the DHCP server can
server can identify if the messages are from SAVI devices or not. identify if the Leasequery messages are from SAVI devices or not.
For the SAVI devices, because the perimeter filters out bogus DHCP For the SAVI devices, because the perimeter filters out bogus DHCP
messages, they can trust the DHCP Leasequery responses. messages, they can trust the DHCP Leasequery replies.
Again, it should be noted that although SAVI-DHCP can help Again, it should be noted that although SAVI-DHCP can help
authenticate the origin, it does not protect the integrity of the authenticate the origin, it does not protect the integrity of the
messages. If DHCPv6 Leasequery is performed without enforcing IPsec, messages. If DHCPv6 Leasequery is performed without enforcing IPsec,
this threat must be taken into account. this threat must be taken into account.
11.6. Binding Number Limitation 11.6. Binding Number Limitation
A binding entry will consume a certain high-speed memory resources. A binding entry will consume a certain high-speed memory resources.
In general, a SAVI device can afford only a quite limited number of In general, a SAVI device can afford only a quite limited number of
 End of changes. 15 change blocks. 
37 lines changed or deleted 52 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/