One document matched: draft-bi-savi-cps-01.txt
Differences from draft-bi-savi-cps-00.txt
SAVI J. Bi, J. Wu, G. Yao
Internet Draft CERNET
Intended status: Standard Tracks F. Baker
Expires: December 2009 Cisco
July 29, 2009
Control Packet Snooping Based Binding
draft-bi-savi-cps-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 29, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your
rights and restrictions with respect to this document.
Abstract
Bi Expires December 29,2009 [Page 1]
Internet-Draft Control Packet Snooping Based Binding July 2009
This document specifies the Control Packet Snooping (CPS) mechanism
for IP version 4 and IP version 6. This mechanism is used to set up
binding between "authorized" source IP address of host and
corresponding anchor on the access network device, including switch
and wireless access point. The bindings are used to perform source
address validation on packets sent by host.
Table of Contents
1. Introduction ................................................ 3
2. Conventions used in this document............................ 3
3. Terminology ................................................. 3
4. Mechanism Overview .......................................... 4
5. Related Protocols ........................................... 4
6. Definition of Anchor......................................... 5
7. Conceptual Data Structures................................... 5
8. Scenarios ................................................... 7
8.1. Switch scenario......................................... 7
8.1.1. Port Attributes.................................... 7
8.1.1.1. SAVI-Host Attribute........................... 8
8.1.1.2. SAVI-DHCP-Trust Attribute .................... 8
8.1.1.3. SAVI-RA-Trust Attribute ...................... 8
8.1.1.4. SAVI-Trunk-Default Attribute ................. 9
8.1.1.5. SAVI-Trunk-Snooping Attribute ................ 9
8.2. Wireless Scenario....................................... 9
9. Prefix Configuration......................................... 9
10. Binding Set Up ............................................ 10
10.1. DHCPv4 Snooping....................................... 10
10.1.1. Process of DHCPv4 Snooping ...................... 10
10.1.2. State Machine of DHCPv4 Snooping ................ 11
10.2. DHCPv6 Snooping....................................... 11
10.2.1. Process of DHCPv6 Snooping ...................... 11
10.2.2. State Machine of DHCPv6 Snooping ................ 12
10.3. ND Snooping .......................................... 13
10.3.1. Process of ND Snooping........................... 13
10.3.2. State Machine of ND Snooping .................... 13
10.4. ARP Snooping ......................................... 14
10.4.1. Process of ARP Snooping.......................... 14
10.4.2. State Machine of ARP Snooping ................... 14
10.5. Manually Binding...................................... 15
11. Clear Binding ............................................. 15
12. Filtering Specification.................................... 15
12.1. Filter Data Packet.................................... 15
12.2. Filter Control Packet................................. 16
13. Solution for Special Situations............................ 16
13.1. Multiple Interfaces................................... 17
Bi Expires January 29, 2010 [Page 2]
Internet-Draft Control Packet Snooping Based Binding July 2009
13.2. Port Movement ........................................ 17
14. Considerations on Security Risks........................... 18
14.1. Operating system support.............................. 18
14.2. Malicious replier..................................... 19
14.3. Inactive node ........................................ 19
15. About Risk of Dropping Legal Packets ...................... 19
16. Compatible Mode ........................................... 21
17. Binding State Lost Problem................................. 22
18. Incremental Deployment Suggestion.......................... 22
19. Constants ................................................. 22
20. Security Considerations.................................... 23
21. IANA Considerations........................................ 23
22. References ................................................ 23
22.1. Normative References.................................. 23
22.2. Informative References................................ 23
23. Acknowledgments ........................................... 23
Appendix A. Operating System Support Situation ................ 25
Authors' Addresses ............................................ 26
1. Introduction
This specification defines the Control Packet Snooping (CPS)
mechanism for Internet Protocol version 4 (IPv4) and Internet
Protocol version 6 (IPv6). Access devices (including access switches,
and wireless access point/controller, etc) can use this mechanism to
set up bindings between source IP addresses of hosts and
corresponding anchors, in accordance with the appointed address
assignment method. These bindings can be used to validate the source
IP address in the packets received from directly attached hosts.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Terminology
Anchor - The entity to bind source IP address with.
SAVI switch - A switch deployed this mechanism.
Non-SAVI switch - A switch not deployed any SAVI mechanism.
Bi Expires January 29, 2010 [Page 3]
Internet-Draft Control Packet Snooping Based Binding July 2009
4. Mechanism Overview
This mechanism is designed to provide a host level source IP address
validation granularity, as a supplement of BCP38. This mechanism is
deployed on the access device (including access switch, wireless
access point/controller, etc), and performs control packet snooping
to set up bindings between "authorized" source IP address and
corresponding anchors. It also allows manually configured binding.
The bindings are then used to check the source address in the
packets from the directly attached hosts.
This mechanism requires no change on host, and no new protocol is
designed. The deployed device can work with non-deployed device to
support incrementally deployment (named non-SAVI device). Only the
deployed area is protected. This mechanism can work with all the
standard address allocation methods, including DHCP (RFC2131),
DHCPv6 (RFC3315), SLAAC (RFC4862), and manual configuration for both
IPv4 and IPv6.
The binding entries generally are not permanent. Each binding has a
lifetime, and some event may trigger the binding deletion. When
their lifetime expires, or the event happens, this mechanism will
delete the corresponding entry, or perform some process.
The binding process based on DHCPv4 is inspired by the work of IP
source guard. Our work is different from IP source guard on the
requirement of collision detection, which is quite useful in a
multiple address assignment methods environment.
5. Related Protocols
All the protocols related with the IP address assignment are the in
the scope of this mechanism, including:
Dynamic Host Configuration Protocol version 4 (DHCPv4) - A host may
use this protocol to get an IPv4 address.
Dynamic Host Configuration Protocol version 6 (DHCPv6) - A host may
use this protocol to get an IPv6 address.
Neighbor Discovery Protocol (NDP) - Whenever a host wants to assign
an IPv6 address to its interface, it must perform Duplicate Address
Detection first, which is composed of NDP packets. The NDP is also
used to detect whether a host is still reachable. Such NDP packets
can be used to determine whether to delete a binding or not. Other
kinds of NDP packets will be used in Compatible Mode to trigger
bindings.
Bi Expires January 29, 2010 [Page 4]
Internet-Draft Control Packet Snooping Based Binding July 2009
Address Resolution Protocol (ARP) - Whenever a host wants assign an
IPv4 address to its interface, it will send a gratuitous ARP to make
sure this address is not being used. However, this function may not
be supported by all the operating systems. ARP is also used to
determine whether a host is still reachable. Such ARP packets can be
used to determine whether to delete a binding or not. Other kinds of
ARP packets will be used in Compatible Mode to trigger bindings.
Secure Neighbor Discovery Protocol (SeND) - SeND is a special case
of NDP. If a ND packet is also a SeND packet, the validity of the
source address must be checked first before this packet is taken
into the process of this mechanism. There is no other difference for
the mechanism to process plain ND packet and SeND packet.
6. Definition of Anchor
Anchor is an important concept for this mechanism. In this document,
anchor is the entity to bind source address with. To make the
binding secure, the anchor itself must be unspoofable. Generally,
following entities can be used as anchor:
Exclusive switch port - When a switch port is exclusive for a
host, this port is unspoofable for other hosts.
MAC address in 802.1ae/af and 802.11i - 802.1ae/af and 802.11i
protect the security of MAC address. When such technology is
deployed in the network, MAC address can be used as anchor.
However, when strict secure anchor is not achievable in the network,
loose secure anchor can be used. Generally, shared switch port and
MAC address are loose secure anchors. Loose secure anchor may cause
false negative, thus it is not recommended to use such anchors.
This document doesn't specify which entities can be used as anchor,
and how secure these anchors.
7. 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 are redundancy between the two structures,
for the consideration of separation of data plane and control plane.
Binding State Table (BST)
Bi Expires January 29, 2010 [Page 5]
Internet-Draft Control Packet Snooping Based Binding July 2009
- This table contains this state of binding
between source address and anchor. Entries are
keyed on the anchor and source IP address. Each
entry has a lifetime item which records the
remaining lifetime of this entry, an item which
records the state of this binding and an item
record other information. Whenever the lifetime
expires, the entry should be deleted, except for
the entries with DHCPv4_DETECTION/
DHCPv4_DETECTION/SAC_START/MANUALv4_START state.
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
used to filter packet. Access Control List can
be regarded as an instance of this table.
The states of binding in Binding State Table are as follows:
DHCPv4_START A DHCPv4 request is received from host, and it may
trigger a new binding.
DHCPv4_LIVE The DHCPv4 address is acknowledged by DHCP server.
DHCPv4_DETECTION A gratuitous ARP has been sent by the host and
it is waiting for the reply.
DHCPv4_BOUND The address has passed duplicate detection and
it is bound with the anchor.
DHCPv6_START A DHCPv6 request or confirm is received from host.
DHCPv6_LIVE A DCHPv6 reply is received from server, and an
address is suggested.
DHCPv6_DETECTION A Duplicate Address Detection (DAD) Neighbor
Solicitation has been sent by the host, and it
is waiting for the reply.
DHCPv6_BOUND The address has passed DAD and it is bound with
the anchor.
SAC_START A DAD NS has been sent by the host. The target
address is neither got from DHCP nor static.
Bi Expires January 29, 2010 [Page 6]
Internet-Draft Control Packet Snooping Based Binding July 2009
SAC_BOUND The address has passed DAD and it is bound with
anchor.
SAC_QUERY The bound address is being queried by another node.
If there is no response in a time constant, the
binding should be deleted.
MANUALv4_START A gratuitous ARP has been sent by the host. The
target address is neither got from DHCP nor
static.
MANUALv4_BOUND The address has passed DAD and it is bound with
anchor.
MANUALv4_QUERY The bound address is being queried by another
node. If there is no response in a time constant,
the binding should be deleted.
STATIC The address is static and the binding should not
be change.
8. Scenarios
This section specifies the deployment scenarios. Two basic scenarios
are discussed here: switch scenario and wireless scenario.
8.1. Switch scenario
Switch scenario means a switched network composed by a number of
switches. This mechanism is deployed on one or more of them.
In a switch scenario, always port is used as anchor. This section
specifies the attributes of switch port, and the process on each
kind. The method of distinguishing each kind of port in management
is through manual configuration. The port attribute is just
conceptual.
8.1.1. Port Attributes
The attribute of port depends on the role of the port.
A port on a SAVI switch can be set to have none or more of all the
attributes. If a port has an attribute, the corresponding snooping
and filtering policy will be used on this port. If a port has
Bi Expires January 29, 2010 [Page 7]
Internet-Draft Control Packet Snooping Based Binding July 2009
multiple attributes, all the corresponding policies will be used.
Conflict attributes MUST not be set to the same port.
8.1.1.1. SAVI-Host Attribute
If and only if a port is directly connected with a host, this port
can be set to have SAVI-Host attribute. Trunk port cannot be set to
have this attribute.
If a port has SAVI-Host attribute, control packet snooping MUST be
performed on this port to set up bindings, and then the data packets
from this port MUST be verified based on these bindings.
8.1.1.2. SAVI-DHCP-Trust Attribute
If and only if a port is directly connected with a trustable DHCP
server, or is a trunk port from which the DHCP reply should arrive,
it can be set to have this attribute.
When a port is configured to have SAVI-DHCP-Trust attribute, the
switch trusts the DHCP reply messages from this port to establish
bindings.
If DHCP is used to assign address in the network, there should be at
least one port has this attribute. DHCP reply message not from such
ports MUST be dropped.
In the situation DHCP-PD is used to configure prefix of the network,
the switch also trust the Prefix Delegation message from port with
this attribute.
8.1.1.3. SAVI-RA-Trust Attribute
If and only if a port is directly connected with a trustable router,
or is a trunk port from which the Router Advertisement should arrive,
it can be set to have this attribute.
When a port is configured to have a SAVI-RA-Trust attribute, the
switch trusts the Router Advertisement messages from this port to
learn the prefixes used on the link.
There may be no SAVI-RA-Trust port in the network, even if only
SLAAC is used to configure address.
Router Advertisement received not from SAVI-RA-Trust port MUST be
discarded.
Bi Expires January 29, 2010 [Page 8]
Internet-Draft Control Packet Snooping Based Binding July 2009
8.1.1.4. SAVI-Trunk-Default Attribute
If and only if a port is a trunk port, it can be set to have this
attribute. This attribute is a conflict attribute of SAVI-Host
attribute and SAVI-Trunk-Snooping attribute.
No packet snooping will be performed on port with this attribute.
Packet from port with such attribute will be forwarded if its source
address doesn't conflict existing local bindings.
8.1.1.5. SAVI-Trunk-Snooping Attribute
If and only if a port is a trunk port, it can be set to have this
attribute. This attribute is a conflict attribute of SAVI-Host
attribute and SAVI-Trunk-Default attribute.
Control packet snooping MUST be performed on port with this
attribute. The filtering policy on port with such attribute is based
on "default-forwarding" principle, which means packets from this
port can be forwarded if its source address doesn't conflict local
bindings.
It is not SUGGESTED to set a trunk port to have this attribute,
unless it is found that only to set a port to have this attribute
will achieve the spoofing mitigation goal. Setting a port to have
this attribute will possibly result in forwarding performance
problem.
8.2. Wireless Scenario
In a wireless scenario, usually MAC address is used as anchor.
Currently there is nothing to specify in wireless scenario.
9. Prefix Configuration
Before setting up a host-level granularity binding table, it is
important to configure correct prefixes on the SAVI device. At least
two prefix scopes must be set: the IPv4 prefix and IPv6 prefixes.
This document suggests set 3 prefix scopes:
IPv4 Prefix:
The allowed scope of any kind of IPv4 addresses. It can be set
manually.
IPv6 SLAAC Prefixes:
Bi Expires January 29, 2010 [Page 9]
Internet-Draft Control Packet Snooping Based Binding July 2009
The allowed scope of SLAAC and manually configured IPv6
addresses. It can be set through snooping RA message from port
with SAVI-RA-Trust attribute, or manual configuration.
FE80::/64 MUST be set to a feasible prefix.
IPv6 DHCPv6 Prefixes:
The allowed scope of DHCPv6 addresses. It can be set through
DHCP-PD protocol, or manual configuration.
If some of the prefix scope is set to have non prefix, it implies
corresponding address assignment method is not allowed in the
network.
There is no need to explicitly present these prefix scopes. But
these restrictions MUST be used as premier check in binding set up.
10. Binding Set Up
This section specifies how to set up bindings based on control
packet snooping. Control packet snooping is only performed on the
ports with SAVI-Host attribute or SAVI-Trunk-Snooping attribute.
10.1. DHCPv4 Snooping
10.1.1. Process of DHCPv4 Snooping
This process is designed for DHCPv4 assigned address.
Whenever a DHCPv4 request is received from attaching host, and the
requested IP address does not exist in the binding table, the device
will generate an entry in the Binding State Table (BST), set the
state field to be DHCPv4_START. The lifetime of this entry is set to
be MAX_DHCP_RESPONSE_TIME. The TID field of the request packet is
also recorded in the entry. If an entry is already in the BST and
the state of the entry is DHCPv4_START, set the lifetime field to be
MAX_DHCP_RESPONSE_TIME.
Whenever a DHCPv4 acknowledgement is received from the DHCP server,
if the TID is in BST, and the state of the entry is DHCPv4_START,
set the state of the entry to be DHCPv4_LIVE. The lifetime of the
entry is set to be MAX_ARP_PREPARE_DELAY. The lease time is also
recorded in the entry.
Whenever a gratuitous ARP request is received from the host, if the
state of the entry is DHCPv4_LIVE, set the state of the entry to be
Bi Expires January 29, 2010 [Page 10]
Internet-Draft Control Packet Snooping Based Binding July 2009
DHCPv4_DETECTION. The lifetime of the entry is set to be MAX_ARP
_DELAY. If an ARP response for the address is received from other
nodes, delete the entry. If the lifetime expires, set the state of
the entry to be DHCPv4_BOUND. The lifetime of this entry is set to
the lease time of the entry. An entry is added into the Filter Table.
Whenever a DHCPv4 decline is received from the host, if the state of
the entry is DHCPv4_LIVE, delete the entry in BST.
Whenever a DHCPv4 release is received from the host, if the state of
the entry is DHCPv4_BOUND, delete the entry in BST and Filter Table.
If a DHCPv4 acknowledgement 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 DHCPv4_BOUND expires, delete
the entry in BST and Filter Table.
10.1.2. State Machine of DHCPv4 Snooping
State Packet/Event Action Next State
Start DHCPv4 REQ Set up new entry DHCPv4_START
DHCPv4_START DHCPv4 ACK Record lease time DHCPv4_LIVE
DHCPv4_LIVE Gra ARP REQ - DHCPv4_DETECTION
DHCPv4_LIVE DHCPv4 DEC Remove entry Start
DHCPv4_DETECTION Timeout Insert into FT DHCPv4_BOUND
DHCPv4_DETECTION Gra ARP RPL Remove entry Start
DHCPv4_DETECTION DHCPv4 DEC Remove entry Start
DHCPv4_BOUND DHCPv4 REL Remove entry Start
DHCPv4_BOUND DHCPv4 REN/REB Set new lifetime DHCPv4_BOUND
10.2. DHCPv6 Snooping
10.2.1. Process of DHCPv6 Snooping
This process is designed for DHCPv6 assigned address.
Bi Expires January 29, 2010 [Page 11]
Internet-Draft Control Packet Snooping Based Binding July 2009
Whenever a DHCPv6 request or confirm is received from attaching host,
and the requested IP address does not exist in the binding table,
the device will generate an entry in the BST, set the state field to
be DHCPv6_START. The lifetime of this entry is set to be
MAX_DHCP_RESPONSE_TIME. The source address of the request packet is
also recorded in the entry. If an entry is already in the BST and
the state of the entry is DHCPv6_START, set the lifetime field to be
MAX_DHCP_RESPONSE_TIME.
Whenever a DHCPv6 reply is received from the DHCP server, if the TID
is in BST, and the state of the entry is DHCPv6_START, set the state
of the entry to be DHCPv6_LIVE. The lifetime of the entry is set to
be MAX_DAD_PREPARE_DELAY. The lease time is also recorded in the
entry.
Whenever a DAD NS is received from the host, if the state of the
entry is DHCPv6_LIVE, set the state of the entry to be
DHCPv6_DETECTION. The lifetime of the entry is set to be MAX_DAD
_DELAY. If an NA response for the address is received from other
nodes, delete the entry. If the lifetime expires, set the state of
the entry to be DHCPv6_BOUND. The lifetime of this entry is set to
the lease time of the entry. An entry is added into the Filter Table.
Whenever a DHCPv6 decline is received from the host, if the state of
the entry is DHCPv6_LIVE, delete the entry in BST.
Whenever a DHCPv6 release is received from the host, if the state of
the entry is DHCPv6_BOUND, delete the entry in BST and Filter Table.
If a 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 DHCPv6_BOUND expires, delete
the entry in BST and Filter Table.
10.2.2. State Machine of DHCPv6 Snooping
State Packet/Event Action Next State
Start DHCPv6 REQ/CON Set up new entry DHCPv6_START
DHCPv6_START DHCPv6 RLY Record lease time DHCPv6_LIVE
DHCPv6_LIVE DAD NS - DHCPv6_DETECTION
DHCPv6_DETECTION Timeout Insert into FT DHCPv6_BOUND
Bi Expires January 29, 2010 [Page 12]
Internet-Draft Control Packet Snooping Based Binding July 2009
DHCPv6_DETECTION DAD NA RLY Remove entry Start
DHCPv6_LIVE DHCPv6 DEC Remove entry Start
DHCPv6_BOUND DHCPv6 REL Remove entry Start
DHCPv6_BOUND DHCPv4 REN/REB Set new lifetime DHCPv6_BOUND
10.3. ND Snooping
10.3.1. Process of ND Snooping
This process is designed for stateless auto-configuration assigned
IPv6 address and manually configured IPv6 address.
Whenever a DAD NS is received from the host, if the address is not
in BST and has a permitted prefix, generate a new entry in BST and
set the state of the entry to be SAC_START. The lifetime of the
entry is set to be MAX_DAD _DELAY. If an NA response for the address
is received from other nodes, delete the entry. If the lifetime
expires, set the state of the entry to be SAC_BOUND. The lifetime of
this entry is set to MAX_SAC_LIFETIME. An entry is added into the
Filter Table.
If the lifetime of an entry with state SAC_BOUND expires, set the
lifetime to be MAX_DAD_PREPARE_DELAY and send a NS for the address.
If there is no response before the lifetime expires, delete the
entry in BST and Filter Table. Else set the lifetime to be
MAX_SAC_LIFETIME.
Whenever a NS with target address set to one of the addresses with
state SAC_BOUND, the state of the entry is set to SAC_QUERY, and the
lifetime is set to MAX_DAD_PREPARE_DELAY. If there is no response
from the host before the lifetime expires, delete the entry in BST
and Filter Table. If a response is received from the host, set the
lifetime of the corresponding entry to be MAX_SAC_LIFETIME.
10.3.2. State Machine of ND Snooping
State Packet/Event Action Next State
Start DAD NS Set up new entry SAC_START
SAC_START Timeout Insert into FT SAC_BOUND
SAC_START DAD NA RLY Remove entry Start
Bi Expires January 29, 2010 [Page 13]
Internet-Draft Control Packet Snooping Based Binding July 2009
*SAC_BOUND NS for bound addr - SAC_QUERY
*SAC_QUERY NA Set lifetime to maximum SAC_BOUND
*SAC_QUERY Timeout Remove binding Start
(* denotes optional process.)
10.4. ARP Snooping
10.4.1. Process of ARP Snooping
This process is designed for manually configured IPv4 address.
Whenever a gratuitous ARP is received from the host, if the address
is not in BST and has a permitted prefix, generate a new entry in
BST and set the state of the entry to be MANUALv4_START. The
lifetime of the entry is set to be MAX_ARP_DELAY. If an ARP response
for the address is received from other nodes, delete the entry. If
the lifetime expires, set the state of the entry to be
MANUALv4_BOUND. The lifetime of this entry is set to
MAX_MANUAL_LIFETIME. An entry is added into the Filter Table.
If the lifetime of an entry with state MANUALv4_BOUND expires, set
the lifetime to be MAX_ARP_PREPARE_DELAY and send an ARP request for
the address. If there is no response before the lifetime expires,
delete the entry in BST and Filter Table. Else set the lifetime to
be MAX_MANUAL_LIFETIME.
Whenever an ARP response with target address set to one of the
addresses with state ARP_BOUND, the state of the entry is set to
MANUALv4_QUERY, and the lifetime is set to MAX_ARP_PREPARE_DELAY. If
there is no response from the host before the lifetime expires,
delete the entry in BST and Filter Table. If a response is received
from the host, set the lifetime of the corresponding entry to be
MAX_MANUAL_LIFETIME.
10.4.2. State Machine of ARP Snooping
State Packet/Event Action Next State
Start Gra ARP REQ Set up new entry MANUALv4_START
MANUALv4_START Timeout Insert into FT MANUALv4_BOUND
MANUALv4_START Gra ARP RLY Remove entry Start
Bi Expires January 29, 2010 [Page 14]
Internet-Draft Control Packet Snooping Based Binding July 2009
*MANUALv4_BOUND ARP for bound addr MANUALv4_QUERY
*MANUALv4_QUERY ARP RLY Set lifetime to maximum MANUALv4_BOUND
*MANUALv4_QUERY Timeout Remove binding Start
(* denotes optional process.)
10.5. Manually Binding
To be compatible with manually configured static address, the BST is
allowed to be configured manually. The configured binding has state
STATIC and has an infinite lifetime.
11. Clear Binding
Whenever the lifetime of DHCP assigned entry in the BST expires, it
MUST be removed from the BST. If this binding has been inserted in
to Filtering Table, this binding also MUST be removed.
Whenever the lifetime of an address not assigned by DHCP expires,
the switch MUST send a NS or NUD or ARP request to detect whether
this address is still in use. If there is no response from the
corresponding node, this binding MUST be deleted; or else, set to
lifetime of this entry to be the corresponding maximum value.
Whenever a node is disconnected at link layer, the corresponding
bindings in BST and Filtering Table MUST be removed unless the state
of the entry is STATIC.
12. Filtering Specification
This section specifies how to use bindings to filtering packets.
12.1. Filter Data Packet
In a switch scenario, data packets are filtered only on port with
SAVI-Host attribute, SAVI-Trunk-Default attribute, or SAVI-Trunk-
Snooping attribute. There can be port with none of these attributes.
Filtering on port with SAVI-Host attribute strictly complies with
the Filtering Table set up on the port. If the source of the packet
is in the binding table of the port, this packet will be forwarded;
or else the packet MUST be discarded.
Filtering on port with SAVI-Trunk-Default attribute is based on
checking whether the source is in the Filtering Table. If it is not
Bi Expires January 29, 2010 [Page 15]
Internet-Draft Control Packet Snooping Based Binding July 2009
in the filtering table, the packet can be forwarded; or else, the
packet MUST be discarded.
Filtering on port with SAVI-Trunk-Snooping attribute is based on
checking whether the source is bound on this port or conflicted with
bindings on the other ports. If the address has been bound with the
port, the packet can be forwarded; if the address is not bound with
the port, but neither bound with any other port, the packet can be
forwarded; if the address is bound with another port, the packet
MUST be discarded.
In a wireless scenario, all the filtering MUST be strictly complying
with Filtering Table.
12.2. Filter Control Packet
The source address of the control packet is always all zero (DHCPv4,
IPv6 Stateless auto-configuration for link-local address) or unbound
address (gratuitous ARP). Such packets don't have to pass the check
on Filter Table. However, the source address of DHCPv6 request and
IPv6 DAD NS for global address must pass the check on Filter Table,
for always a unique link-local address is used.
All Router Advertisement packets MUST be from port with SAVI-RA-
Trust attribute. All DHCP Reply packets MUST be from port with SAVI-
DHCP-Trust attribute.
The target address in all the Neighbor Advertisement packets and the
sender's address in all ARP relies should also pass the checks on
Filter Table.
The Target address in Neighbor Advertisement packet and DHCP Reply
packet MUST be in the corresponding prefix scope.
For control packet from port with SAVI-Trunk-Default attribute, the
field in the packet is checked whether there is a local conflict.
For control packet from port with SAVI-Trunk-Snooping attribute,
checking whether the source is bound on this port or conflicted with
bindings on the other ports.
13. Solution for Special Situations
Two situations described in the charter of SAVI working group may
cause this mechanism filter packets improperly: multiple interfaces
and port movement. The following is the proper solution for each
situation.
Bi Expires January 29, 2010 [Page 16]
Internet-Draft Control Packet Snooping Based Binding July 2009
13.1. Multiple Interfaces
If a host has multiple interfaces to the same LAN, generally this
situation can be treated as multiple hosts with single interface
because each interface will only use the address assigned to itself
as source IP address. However, a host may configure the same address
on multiple interfaces for the purpose of load balance. In this
situation, the SAVI device may find an address bound with an anchor
appears with another anchor, just as spoofing. This is the only
multiple interfaces situation that troubles this mechanism.
When this situation happens, the corresponding binding is seldom
changed. Thus, manual configuration is enough for this situation.
All the anchors with the host can be configured to be used by the
same host and share the same entries in BST and Filtering Table.
Other mechanisms can also be used to handle this situation, such as
[SAVI-SeND] and [SAVI-HIP]. These mechanisms can be used to test
whether two anchors are belonging to the same host and thus
distinguish multiple interfaces from spoofing. However, all the
mentioned mechanisms bring overhead to data packet process, and are
not recommended. Currently, the only recommended mechanism is manual
configuration.
However, for the consideration that in the future, a host with
multiple interfaces to the same network may become very common (for
example, a host has a wired network interface and a wireless network
interface attached to the same network, and they are configured to
use the same address), an extension mechanism is still needed. The
design of such mechanism is temporarily out of the scope of this
document.
13.2. Port Movement
DHCP assigned address and stateless address don't have the problem
of port movement. If an address is assigned through DHCP, the
address must be confirmed by DHCP server after port movement, and
the control packets will used to set up new binding. For a stateless
address, a duplicate detection must be performed when the interface
is re-initialized, just as the process of address assignment.
However, if an interface configured a static address changes port,
because the corresponding is manually configured, this movement will
conflict previous binding.
The situation that a host with static address changes from one port
to another can be handled through one of the following ways:
Bi Expires January 29, 2010 [Page 17]
Internet-Draft Control Packet Snooping Based Binding July 2009
- Manual configuration. If the host configured with static address
seldom changes its port, the administrator can manually change the
binding after each movement.
- Changing anchor. If the anchor is not switch port, port movement
will not cause any trouble. Thus an alternate way is choosing
another entity as anchor, for example, the secure MAC address.
- Access control mechanisms based on user account. Static address is
always associated with specified user, thus the access control
mechanism based on user account can be used to handle frequent port
movements. 802.1x, PPPoE, and Portal are optional mechanisms.
Whenever the user account is authenticated by there mechanisms, the
corresponding address can be bound on the switch. The related
protocol must be extended to enable such function.
- Host identifier related mechanisms. [SAVI-SeND] and [SAVI-HIP]
have a secure host identifier associated with the host, and this
identifier can be used to handle port movement. The problem of such
solutions is that they are based on immature techniques.
14. Considerations on Security Risks
This mechanism has some potential risks. Some operating systems
assign an address to interface without any duplicate detection.
Other risks are due to the sync problem between host and SAVI device.
14.1. Operating system support
The duplicate detection for IPv4 address has been prescribed in
[RFC5227], but currently not all the operating systems perform
duplicate detection on IPv4 address. Because the number of available
IPv4 addresses in a LAN is small, a simplest solution is that
whenever a new IPv4 address appears, the deployed device can perform
duplicate detection instead of the host. However, this function will
take data packet into control panel and would bring additional cost.
A suggestion for the network administrator is IPv4 address should be
assigned through DHCP or static. The supported operating systems are
listed in Appendix A. For the operating system that cannot be
updated, it is suggested to only use static address and set up
binding manually, or only DHCPv4 is allowed to assign address.
The duplicate detection for IPv6 address has been prescribed in
[RFC4862]. However, some operating systems not supporting IPv6 well
will not perform DAD when assigning IPv6 address.
Bi Expires January 29, 2010 [Page 18]
Internet-Draft Control Packet Snooping Based Binding July 2009
It is suggested that the operating systems should be able to update
to support [RFC5227] and [RFC4862]. For the operating system that
cannot be updated, it is suggested to only use static address and
set up binding manually, or only DHCPv6 is allowed to assign address.
An optional mode, named Compatible Mode, is designed to handle these
situations.
14.2. Malicious replier
Another risk is that the detection packet can be replied by a
malicious attacker, and the host will be prevented from getting a
proper address. This problem cannot be easily handled for it is
caused by non-deployed nodes. The deployed device must filter
Neighbor Advertisement packets, not only by source address, but also
by target address. The sender's address in ARP replies should also
be checked.
A practical solution for this problem is as follows:
1. Divide the address space of SAVI nodes and non-SAVI nodes;
2. Partition SAVI nodes and non-SAVI nodes to different VLANs.
Then the SAVI nodes don't have to ask the non-SAVI nodes whether an
address has been used by some of them.
14.3. Inactive node
The false negative may be caused by the situation that the detection
packet is not replied by the assigned node. This is a troublesome
situation. It is reasonable for a node to get such address because
it is in accordance with the standard, unless the address is a
static address. A simple process is removing the previous binding
and setting up new binding for the requesting node. A more tolerant
process is the SAVI device can perform ARP/ND proxy for the inactive
node, and reduce the lifetime of binding to 1/4.
15. About Risk of Dropping Legal Packets
If an address is used without binding set up on the switch, the
packets with that address will be discarded by the switch.
There are two situations when this happens:
1. No DAD is ever performed.
Bi Expires January 29, 2010 [Page 19]
Internet-Draft Control Packet Snooping Based Binding July 2009
In this situation, the packet cannot be regarded as "legal packet",
because without previous DAD, neither the host nor the switch has
the ability to determine whether it is a duplicated address. The
conflict of this solution and some other solutions is whether to
discard the packets without previous DAD, or forward them.
Forwarding the packets has some secure problems. In case the
address has been used by another host, the behavior of using
duplicated address will harm the legitimate user and forwarding
such packet is spoiling spoofing. Actually, it is very suspect
that a host may use addresses without previous DAD to launch some
kind of DoS attack.
Discarding the suspect packets will possibly block a suspect host
from the network, however, will never block a host whose behaviors
comply with the standards. A mechanism should be designed on
existing standards, and give benefit to those who comply with
standards.
The auxiliary mechanism that let the switch perform DAD instead of
the host is a feasible solution but not suggested. This mechanism
is more complex and with heavy overhead.
2. DAD is performed, but the DAD NS packet is lost before it is
received by the switch.
The DAD NS message may get lost before snooped by the switch
because of link error. When this happens, there will be a sync
problem between the host and the switch. The host will configure
that address because it doesn't receive a NA for the tentative
address. However, the switch would set up a binding for that
address. As a result, the packets with the address will be
discarded by the switch.
Although today the link quality has been quite good, the packet
lost problem still exists. The best solution is to configure the
re-transmit time of DAD NS to be more than 1. 3 is a reasonable
number.
An optional mode, named Compatible Mode, is designed to handle these
situations.
Bi Expires January 29, 2010 [Page 20]
Internet-Draft Control Packet Snooping Based Binding July 2009
16. Compatible Mode
This mode is designed to let this mechanism be more tolerant to
possible duplication detection packet lost, and non-standard-
compliance operating system. This is an optional mode. When this
mode is enabled, the switch will set up bindings based on NDP or ARP
packets other than DAD packets and Gratuitous ARP packets.
This section specifies how to use other kinds of control packets to
set up bindings. If the address in these packets are not bound with
other anchor and are in allowed prefix scope, the switch will
perform duplicate detection instead of the sender of the packet to
make sure the source address in the packet is unique in the local
link. If the address is found to be not duplicated, it will be added
into the Binding State Table and Filtering Table. If duplicate is
found, the address SHOULD not be added into the Binding State Table
and Filtering Table.
Following packets will trigger the switch to set up bindings:
ARP request: Source IPv4 address;
ARP reply: Source IPv4 address;
NA: Source address and target address;
NS: Source address.
The prefix of all the address MUST be in the scope of IPv4 Prefix or
IPv6 SLAAC Prefixes.
This mode can reduce the risk of dropping legitimate packets,
because host will always use NDP or ARP to find other nodes on the
link before sending any data traffic.
The cost of the mode is still reasonable, because only control
packets are used to trigger bindings. The data packets are still
filtered based on Filtering Table.
If duplicate is found after detection, the host would still send
packet using the duplicated address because of sync problem. In this
case, it is reasonable to filter the traffic from the host.
This mode may be disturbed by a malicious node in non-SAVI area
which sends NA on each DAD NS. Currently the best solution is
dividing the non-SAVI area to different VLANs.
Bi Expires January 29, 2010 [Page 21]
Internet-Draft Control Packet Snooping Based Binding July 2009
17. DHCP-only Mode
If only DHCP is used to assign address, the duplicate detection
phase in binding set up can be omitted. However, if this mode is
enabled, there must be confidence that the DHCP server wouldn't lose
state. Or else, the duplicate detection phase still cannot be
omitted.
18. Binding State Lost Problem
When the SAVI switch reboots, the bindings on the switch will get
lost for generally they are kept in volatile memory.
Whenever the switch reboots, the interfaces of all the directly
connected hosts will also be re-initialized. Then, if an address is
assigned through DHCPv6, a CONFIRM message will be sent to the DHCP
server. This message can be used to trigger re-binding of the
previous address. For SLAAC address, the DAD procedure will be
performed again, and a new binding will be set up.
The bindings set up on port with SAVI-Trunk-Snooping attribute,
cannot be recovered immediately. However, because "default-
forwarding" policy is used on such ports, there is no risk of
dropping legitimate traffic. The bindings on such ports can be
recovered through snooping NDP and ARP packets using Compatible Mode.
19. Incremental Deployment Suggestion
Because by default this mechanism doesn't set up bindings on trunk
port, it may happen that a host connected to a downstream non-SAVI
device can forge an address bound in SAVI area.
To avoid this situation, it is suggested to separate SAVI area and
non-SAVI areas into different VLANs, and assign different prefixes
in these VLANs. Then the spoofing from non-SAVI area can be blocked
through prefix check.
And another way is to set the trunk ports to have SAVI-TRUNK-
Snooping attribute. Then bindings can be set up on trunk port, and
the bindings can be used to prevent spoofing from another trunk port.
Because of the cost of this solution, it's better to carefully
choose the trunk ports to be set this attribute.
20. Constants
MAX_DHCP_RESPONSE_TIME 10s
Bi Expires January 29, 2010 [Page 22]
Internet-Draft Control Packet Snooping Based Binding July 2009
MAX_ARP_PREPARE_DELAY 1s
MAX_ARP_DELAY 1s
MAX_DAD_PREPARE_DELAY 1s
MAX_DAD_DELAY 1s
MAX_SAC_LIFETIME 2h
MAX_MANUAL_LIFETIME 4h
21. Security Considerations
There are no security considerations currently.
22. IANA Considerations
There is no IANA consideration currently.
23. References
23.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4862] Thomson, S., Narten, T. and Jinmei, T., "IPv6 Stateless
Autoconfiguration", RFC4862, September, 2007.
[RFC5227] S. Cheshire, "IPv4 Address Conflict Detection", RFC5227,
July 2008.
[SAVI-SeND] M. Bagnulo, draft-ietf-savi-send-00.txt.
[SAVI-HIP] D. Kuptsov, A. Gurtov and J. Bi, draft-kuptsov-sava-hip-
01.txt.
23.2. Informative References
24. Acknowledgments
Thanks to Christian Vogt, Eric Nordmark, Marcelo Bagnulo Braun, Jari
Arkko, David Harrington, Pekka Savola, Xing Li, Lixia Zhang, Robert
Raszuk, Greg Daley, Joel M. Halpern and Tao Lin for their valuable
contributions. In particular the usage of unsolicited NA and NS
prior to sending data packets to create binding table (in addtional
Bi Expires January 29, 2010 [Page 23]
Internet-Draft Control Packet Snooping Based Binding July 2009
to DAD packet) was suggested by Eric Levy-Abegnoli in response to an
attack described by Marcelo Bagnulo Braun.
Bi Expires January 29, 2010 [Page 24]
Internet-Draft Control Packet Snooping Based Binding July 2009
Appendix A. Operating System Support Situation
Supported systems: Windows XP SP2, Windows XP SP3, Windows Vista,
Windows 7, Sun Solaris.
Not supported systems: Ubuntu 8.10, Fedora 10.
Bi Expires January 29, 2010 [Page 25]
Internet-Draft Control Packet Snooping Based Binding July 2009
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 January 29, 2010 [Page 26]
| PAFTECH AB 2003-2026 | 2026-04-24 04:15:28 |