< draft-ietf-savi-dhcp-28.txt   draft-ietf-savi-dhcp-29.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: January 6, 2015 Tsinghua Univ. Expires: January 23, 2015 Tsinghua Univ.
F. Baker F. Baker
Cisco Cisco
July 5, 2014 July 22, 2014
SAVI Solution for DHCP SAVI Solution for DHCP
draft-ietf-savi-dhcp-28 draft-ietf-savi-dhcp-29
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 January 6, 2015. This Internet-Draft will expire on January 23, 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 42 skipping to change at page 2, line 42
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 4.4. Other Device 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 3, line 30 skipping to change at page 3, line 30
8.2. Control Packet Filtering . . . . . . . . . . . . . . . . 36 8.2. Control Packet Filtering . . . . . . . . . . . . . . . . 36
9. State Restoration . . . . . . . . . . . . . . . . . . . . . . 37 9. State Restoration . . . . . . . . . . . . . . . . . . . . . . 37
9.1. Attribute Configuration Restoration . . . . . . . . . . . 37 9.1. Attribute Configuration Restoration . . . . . . . . . . . 37
9.2. Binding State Restoration . . . . . . . . . . . . . . . . 37 9.2. Binding State Restoration . . . . . . . . . . . . . . . . 37
10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 38
11. Security Considerations . . . . . . . . . . . . . . . . . . . 38 11. Security Considerations . . . . . . . . . . . . . . . . . . . 38
11.1. Security Problems about the Data Snooping Process . . . 38 11.1. Security Problems about the Data Snooping Process . . . 38
11.2. Issues about Leaving Clients . . . . . . . . . . . . . . 38 11.2. Issues about Leaving Clients . . . . . . . . . . . . . . 38
11.3. Duplicate Bindings to the Same Address . . . . . . . . . 39 11.3. Duplicate Bindings to the Same Address . . . . . . . . . 39
11.4. Compatibility with DNA (Detecting Network Attachment) . 40 11.4. Compatibility with DNA (Detecting Network Attachment) . 40
11.5. Authentication in DHCPv6 Leasequery . . . . . . . . . . 41 11.5. Binding Number Limitation . . . . . . . . . . . . . . . 41
11.6. Binding Number Limitation . . . . . . . . . . . . . . . 41 11.6. Privacy Considerations . . . . . . . . . . . . . . . . . 41
11.7. Privacy Considerations . . . . . . . . . . . . . . . . . 41 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 13. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 41
13. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 42
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
14.1. Normative References . . . . . . . . . . . . . . . . . . 42 14.1. Normative References . . . . . . . . . . . . . . . . . . 42
14.2. Informative References . . . . . . . . . . . . . . . . . 43 14.2. Informative References . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
This document describes a fine-grained source IP address validation This document describes a fine-grained source IP address validation
mechanism. This mechanism creates bindings between IP addresses mechanism. This mechanism creates bindings between IP addresses
assigned to network attachment points by DHCP and suitable binding assigned to network attachment points by DHCP and suitable binding
anchors (refer to Section 3) of the attachments. Then the bindings anchors (refer to Section 3) of the attachments. Then the bindings
skipping to change at page 17, line 12 skipping to change at page 17, line 12
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 4.4. Other Device Configuration
If the implementation of this SAVI mechanism does not support the Other than the per binding anchor configuration specified in
DHCP Leasequery process specified in Section 6.4.1.2 and the Data Section 4.2, an implementation has the following configuration
Snooping Process, it actually requires no address configuration. To requirements:
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. (1) Address configuration. For DHCPv4: a SAVI device MUST have an
IPv4 address. For DHCPv6: a SAVI device MUST have a link-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.
(2) For DHCPv6: the SAVI device needs a local address; when the (2) DHCP server address configuration: a SAVI device MUST store the
DHCPv6 server is not on the same link as the SAVI device, the list of the DHCP server addresses that it could contact during a
SAVI device needs also a global IPv6 address. Leasequery process.
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 20, line 42 skipping to change at page 20, line 45
o TID check: the DHCP Server-Client/Client-Server messages which may o TID check: the DHCP Server-Client/Client-Server messages which may
cause modification on existing binding entries must have matched cause modification on existing binding entries must have matched
TID with the corresponding entry. Note that this check is not TID with the corresponding entry. Note that this check is not
performed on Leasequery and Leasequery-reply messages as they are performed on Leasequery and Leasequery-reply messages as they are
exchanged between the SAVI devices and the DHCP servers. Besides, exchanged between the SAVI devices and the DHCP servers. Besides,
this check is not performed on DHCP Renew/Rebind messages this check is not performed on DHCP Renew/Rebind messages
(Section 6.4.3). (Section 6.4.3).
o Binding limitation check: the DHCP messages must not cause new o Binding limitation check: the DHCP messages must not cause new
binding setup on an attachment whose binding entry limitation has binding setup on an attachment whose binding entry limitation has
been reached. (refer to Section 11.6). been reached. (refer to Section 11.5).
o Address check: the source address of the DHCP messages should pass o Address check: the source address of the DHCP messages should pass
the check specified in Section 8.2. the check specified in Section 8.2.
On receiving a DHCP message without triggering a valid event, the On receiving a DHCP message without triggering a valid event, the
state will not transit and actions will not be performed. Note that state will not transit and actions will not be performed. Note that
if a message does not trigger a valid event but it can pass the if a message does not trigger a valid event but it can pass the
checks in Section 8.2, it MUST be forwarded. checks in Section 8.2, it MUST be forwarded.
6.4. The State Machine of DHCP Snooping Process 6.4. The State Machine of DHCP Snooping Process
skipping to change at page 23, line 21 skipping to change at page 23, line 23
message is in response to a Confirm message. The state of the message is in response to a Confirm message. The state of the
binding entries with matched TID is changed to BOUND. Because binding entries with matched TID is changed to BOUND. Because
[RFC3315] does not require lease time of addresses to be contained in [RFC3315] does not require lease time of addresses to be contained in
the Reply message, the SAVI device SHOULD send a LEASEQUERY [RFC5007] the Reply message, the SAVI device SHOULD send a LEASEQUERY [RFC5007]
message querying by IP address to All_DHCP_Servers multicast address message querying by IP address to All_DHCP_Servers multicast address
[RFC3315] or a list of configured DHCP server addresses. The [RFC3315] or a list of configured DHCP server addresses. The
Leasequery message is generated for each IP address if multiple Leasequery message is generated for each IP address if multiple
addresses are confirmed. The Lifetime of corresponding entries is addresses are confirmed. The Lifetime of corresponding entries is
set to 2*MAX_LEASEQUERY_DELAY. If there is no response message after set to 2*MAX_LEASEQUERY_DELAY. If there is no response message after
MAX_LEASEQUERY_DELAY, send the LEASEQUERY message again. An example MAX_LEASEQUERY_DELAY, send the LEASEQUERY message again. An example
of the entries is illustrated in Figure 7. The related security of the entries is illustrated in Figure 7. If the SAVI device does
problem about DHCPv6 LEASEQUERY is discussed in Section 11.5. If the not send the LEASEQUERY message, a pre-configured lifetime
SAVI device does not send the LEASEQUERY message, a pre-configured DHCP_DEFAULT_LEASE MUST be set on the corresponding entry. (Note: it
lifetime DHCP_DEFAULT_LEASE MUST be set on the corresponding entry. is SUGGESUTED to use T1 configured on DHCP servers as the
(Note: it is SUGGESUTED to use T1 configured on DHCP servers as the
DHCP_DEFAULT_LEASE.) DHCP_DEFAULT_LEASE.)
2.2 If there are IA options in the Reply message, the SAVI device 2.2 If there are IA options in the Reply message, the SAVI device
checks each IA option. When the first assigned address is found, the checks each IA option. When the first assigned address is found, the
Address field of the binding entry with matched TID is set to the Address field of the binding entry with matched TID is set to the
address. The Lifetime field is set to the sum of the lease time in address. The Lifetime field is set to the sum of the lease time in
Reply message and MAX_DHCP_RESPONSE_TIME. The State field is changed Reply message and MAX_DHCP_RESPONSE_TIME. The State field is changed
to BOUND. If there are more than one address assigned in the to BOUND. If there are more than one address assigned in the
message, new binding entries are set up for the remaining address message, new binding entries are set up for the remaining address
assigned in the IA options. An example of the entries is illustrated assigned in the IA options. An example of the entries is illustrated
skipping to change at page 29, line 36 skipping to change at page 29, line 36
The triggering packet should pass the following checks to trigger a The triggering packet should pass the following checks to trigger a
valid event: valid event:
o Attribute check: the data packet should be from attachments with o Attribute check: the data packet should be from attachments with
Data-Snooping attribute; the DHCPLEASEACTIVE/LEASEQUERY_REPLY Data-Snooping attribute; the DHCPLEASEACTIVE/LEASEQUERY_REPLY
messages should be from attachments with DHCP-Snooping attribute. messages should be from attachments with DHCP-Snooping attribute.
o Binding limitation check: the DHCP messages must not cause new o Binding limitation check: the DHCP messages must not cause new
binding setup on an attachment whose binding entry limitation has binding setup on an attachment whose binding entry limitation has
been reached. (refer to Section 11.6). been reached. (refer to Section 11.5).
o Address check: For EVE_DATA_LEASEQUERY, the source address of the o Address check: For EVE_DATA_LEASEQUERY, the source address of the
DHCP Leasequery messages must pass the check specified in DHCP Leasequery messages must pass the check specified in
Section 8.2. For EVE_DATA_CONFLICT, the source address and target Section 8.2. For EVE_DATA_CONFLICT, the source address and target
address of the ARP or NA messages must pass the check specified in address of the ARP or NA messages must pass the check specified in
Section 8.2. Section 8.2.
o Interval check: the interval between two successive o Interval check: the interval between two successive
EVE_DATA_UNMATCH events triggered by an attachment MUST be no EVE_DATA_UNMATCH events triggered by an attachment MUST be no
smaller than DATA_SNOOPING_INTERVAL. smaller than DATA_SNOOPING_INTERVAL.
skipping to change at page 41, line 7 skipping to change at page 41, line 7
In DNAv4 [RFC4436], the ARP probe will be discarded because an In DNAv4 [RFC4436], the ARP probe will be discarded because an
unbound address is used as the sender protocol address. As a result, unbound address is used as the sender protocol address. As a result,
the client will regard the address under detection is valid. the client will regard the address under detection is valid.
However, the data traffic will be filtered. The DHCP Request message However, the data traffic will be filtered. The DHCP Request message
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. Binding Number Limitation
As required in section 5 of [RFC5007], DHCPv6 Leasequery 'Should' use
IPsec-based authentication specified in the section 21.1 of
[RFC3315]. However, IPsec is generally considered heavyweight. With
the deployment of this mechanism, the source IP address may be
authenticated without enforcing IPsec.
By containing the DHCP servers in the protection perimeter, the DHCP
servers can be protected from spoofing based attacks. Then by
maintaining a list of SAVI device addresses, the DHCP server can
identify if the Leasequery messages are from SAVI devices or not.
For the SAVI devices, because the perimeter filters out bogus DHCP
messages, they can trust the DHCP Leasequery replies.
Again, it should be noted that although SAVI-DHCP can help
authenticate the origin, it does not protect the integrity of the
messages. If DHCPv6 Leasequery is performed without enforcing IPsec,
this threat must be taken into account.
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
binding entries. In order to prevent an attacker from overloading binding entries. In order to prevent an attacker from overloading
the resource of the SAVI device, a binding entry limit is set on each the resource of the SAVI device, a binding entry limit is set on each
attachment. The binding entry limit is the maximum number of attachment. The binding entry limit is the maximum number of
bindings supported on each attachment with Validating attribute. No bindings supported on each attachment with Validating attribute. No
new binding should be set up after the limit has been reached. If a new binding should be set up after the limit has been reached. If a
DHCP Reply assigns more addresses than the remaining binding entry DHCP Reply assigns more addresses than the remaining binding entry
quota of each client, the message will be discarded and no binding quota of each client, the message will be discarded and no binding
will be set up. will be set up.
11.7. Privacy Considerations 11.6. Privacy Considerations
A SAVI device MUST delete binding anchor information as soon as A SAVI device MUST delete binding anchor information as soon as
possible (i.e., as soon as the state for a given address is back to possible (i.e., as soon as the state for a given address is back to
NO_BIND), except where there is an identified reason why that NO_BIND), except where there is an identified reason why that
information is likely to be involved in the detection, prevention, or information is likely to be involved in the detection, prevention, or
tracing of actual source address spoofing. Information about the tracing of actual source address spoofing. Information about the
majority of hosts that never spoof SHOULD NOT be logged. majority of hosts that never spoof SHOULD NOT be logged.
12. IANA Considerations 12. IANA Considerations
 End of changes. 15 change blocks. 
49 lines changed or deleted 28 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/