|
Dear Erik，Marcelo, and Eric, A merge proposal based on FCFS-02 and
slaac-cps-00(as attachments): Basic frame: FCFS-02. 1.
Sections to Add 1.1 Add a section for IPv4(Section 10.1.2 in slaac-cps may
contribute) Add a section to handle IPv4 address using the similar mechanism.
This section specifies the procedure to set up binding for manually
configured(but not static) IPv4 address, as described in [RFC5227].
This mechanism can handle the situation in which users can configure
their address manually so long as the address belongs to an allowed
prefix. This situation is different from that any interface can only
configure a fixed address, and manually configuration on the SAVI device
wouldn’t handle it. 1.2 Add a port type: host port, as a complement of
port-validation For a port directly attached to a single host, mechanism mainly based
on control packet snooping(Section 10.1.1 in slaac-cps may contribute) would be
more lightweight and secure. As described in RFC4862, DAD must be performed before assigning any
address. It’s the reasonability basis of control packet snooping only. For a
savi-host port, it is rarely necessary for the savi device to trigger a
detection on behavior of the attached host, unless in the case that detection
packets are got lost(with an extremely little
possibility). In slaac-cps00, the savi device should snoop a wide scope of control
packet, to avoid dropping valid packet as much as possible. Will a host send
data packet directly without performing any resolution? Even in an extreme bad situation, the savi device can send probes
whenever a new address appears(but this function is turned off by default.).
Although this seems the same as FCFS, there is a benefit the savi device can
control the rate to prevent DoS attack. The security aspect: (1) A clear entry number limit can be set for each host and avoid
binding entry exhaustion.(This limit can never be set on a port accessed by a
number of hosts.) (2) A rate limit of sending probes can be set to avoid DoS. (This
limit cannot be set on other types of ports, either.) (3) A more strict filtering policy(e.g., default dropping) can be set
on such port, to stop one packet attack and DoS against the savi device itself.
(Default dropping policy cannot be set on other kinds of
ports.) (4) A host level granularity trace ability can be
enabled. 1.3 Add a section to specify the procedure of check a packet(Section 12
in slaac-cps can contribute). 1.4 Add a section to specify the procedure to remove a binding(Section 11
in slaac-cps can contribute). 1.5 Add a section to clearly specify the details on special
situations(Section 13,14,15 in slaac-cps can contribute). 1.6 Add a section to specify the related constants, especially the time
related constants, e.g, TENT_LT. 2.
Sections to be moved to
framework 2.1, 2.2, 2.4, 2.5 These sections are great analysis work on
SAVI solutions in common. They should be moved to savi-framework or another
informational draft for clarity. 3.
Open issues: 3.1 Whether to build a perimeter based on SAVI
functions? Benefits: 1. An attacker cannot spoof any
address in SAVI area; 2. Spoofing
packets will be dropped on reaching the perimeter; 3. Spoofing
packets from non-SAVI area will be filtered at a “anchor”
level. Cost: 1.
Control plane cost: A SAVI device will
potentially keep a record of all the addresses on the link. It is unconvinced
that the storage distribution mechanism will work indeed. More details of this
mechanism should be specified. 2.
Additional communication cost: using NDP
as a BDP to distribute bindings; 3.
Data plane cost: whenever check a packet,
the SAVI device must go through an extremely huge deny
list. Possible error: 1.
Whether is it reasonable to set up
bindings for hosts out of SAVI area based on FCFS? -The owner of an address is
never necessary to send a packet first to the SAVI area. Then another host can
set up a binding before it and make the perimeter to drop the traffic of the
address owner. Alterative:
Make it an optional function, or use mature
techniques:
-Separate the prefix scope of SAVI area and non-SAVI area. Using ingress
filter the perform prefix level check. This is
sure to work. |
SAVI
Internet Draft
Intended status: Standard Tracks
Expires: December 2009
August 3, 2009
SAVI Solution for IPv6 SLAAC and IPv4 Manual Configuration
draft-bi-slaac-cps-00.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 February 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
Expires December 3,2009 [Page 1]
Internet-Draft Control Packet Snooping Based Binding August 2009
This document specifies a SAVI mechanism for IP version 4 manually
configured addresses and IP version 6 stateless auto-configuration
addresses.
Table of Contents
1. Introduction ................................................ 3
2. Conventions used in this document............................ 3
3. Terminology ................................................. 3
4. Mechanism Overview .......................................... 3
5. Related Protocols ........................................... 4
6. Definition of Anchor......................................... 4
7. Conceptual Data Structures................................... 5
8. Scenarios ................................................... 6
8.1. Switch scenario......................................... 6
8.1.1. Port Attributes.................................... 6
8.1.1.1. SAVI-Host Attribute........................... 7
8.1.1.2. SAVI-SAVI Attribute........................... 7
8.1.1.3. SAVI-UCA (Uncontrollable area) Attribute...... 7
8.1.1.4. SAVI-DHCP-PD-Trust Attribute ................. 7
8.1.1.5. SAVI-RA-Trust Attribute ...................... 8
8.2. Wireless Scenario....................................... 8
9. Prefix Configuration......................................... 8
10. Binding Setup .............................................. 9
10.1. Address Assignment Protocol Snooping .................. 9
10.1.1. DAD Snooping...................................... 9
10.1.1.1. Process of DAD Snooping ..................... 9
10.1.1.2. State Machine of ND Snooping ............... 10
10.1.2. Gratuitous ARP Snooping.......................... 10
10.1.2.1. Process of Gratuitous ARP Snooping ......... 10
10.1.2.2. State Machine of Gratuitous ARP Snooping.... 11
10.2. Probe Trigger ........................................ 11
10.2.1. NDP/ARP Triggered DAD Probe and Binding ......... 11
10.2.2. Data Packet Triggered DAD Probe and Bindings..... 11
10.3. Other Considerations on Binding Setup ................ 12
10.4. Upper Bound and Minimum of Binding Number ............ 12
11. Clear Binding ............................................. 12
11.1. Clear-on-Query mode................................... 12
11.2. Clear-on-Demand mode.................................. 13
12. Filtering Specification.................................... 13
12.1. Filter Data Packet.................................... 13
12.2. Filter Control Packet................................. 13
13. Solution for Special Situations............................ 14
13.1. Multiple Interfaces................................... 14
13.2. Port Movement ........................................ 15
14. Considerations on Security Risks........................... 15
Expires February 29, 2010 [Page 2]
Internet-Draft Control Packet Snooping Based Binding August 2009
14.1. Operating system support.............................. 15
14.2. Malicious replier..................................... 16
14.3. Inactive node ........................................ 16
15. Incremental Deployment Suggestion.......................... 17
16. Constants ................................................. 17
17. Security Considerations.................................... 17
18. IANA Considerations........................................ 17
19. References ................................................ 18
19.1. Normative References.................................. 18
19.2. Informative References................................ 18
20. Acknowledgments ........................................... 18
Authors' Addresses ............................................ 19
1. Introduction
This document specifies a SAVI mechanism for IP version 4 manually
configured addresses and IP version 6 stateless auto-configuration
addresses.
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.
SLAAC - Stateless Auto-configuration described in [RFC4862].
SAVI switch - A switch deployed this mechanism.
Non-SAVI switch - A switch not deployed any SAVI mechanism.
SAVI device - An unspecified device possesses SAVI function.
Probe - The NS/ARP Request/NUD packet sent by SAVI device on the
behavior of hosts.
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). It works in IPv6 SLAAC only scenario
Expires February 29, 2010 [Page 3]
Internet-Draft Control Packet Snooping Based Binding August 2009
and IPv4 manual configuration scenarios. This mechanism requires no
change on host, and no new protocol is designed.
This document mainly focuses on 1: When and how to set up initial
bindings; 2: When and how to remove bindings; 3: The filtering
policy on access port of SAVI switch; 4: The policy on other kinds
of ports.
5. Related Protocols
Snooping address assignment related protocols is the main part of
this mechanism.
Duplicate address detection (DAD) - The procedure to detect whether
an IPv6 address is duplicated before assigning it to an interface,
described in [RFC4862]. DAD packets can be used to set up bindings.
Gratuitous Address Resolution Protocol (Gratuitous ARP) - The
procedure to detect whether an IPv4 address is duplicated.
Gratuitous ARP packets can be used to set up bindings.
Unsolicited Neighbor Advertisement (Unsolicited NA) - Unsolicited NA
can be used to trigger the SAVI device to send DAD probes.
Neighbor Solicitation (NS) - Neighbor Solicitation packets can be
used to trigger the SAVI device to send DAD probes.
ARP Request - ARP Request can be used to trigger the SAVI device to
send ARP probes.
ARP Response - ARP Response can be used to trigger the SAVI device
to send ARP probes.
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.
Expires February 29, 2010 [Page 4]
Internet-Draft Control Packet Snooping Based Binding August 2009
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 and potential false positive, thus it is not
recommended to use such kind of anchors.
The work to specify which entities can be used as anchor, and how
secure these anchors is beyond the scope of the document.
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)
- 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:
SAC_START A DAD NS has been sent by the host. The target
address is neither got from DHCP nor static.
SAC_BOUND The address has passed DAD and it is bound with
anchor.
Expires February 29, 2010 [Page 5]
Internet-Draft Control Packet Snooping Based Binding August 2009
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.
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
multiple attributes, all the corresponding policies will be used.
Conflict attributes MUST not be set to the same port.
Expires February 29, 2010 [Page 6]
Internet-Draft Control Packet Snooping Based Binding August 2009
8.1.1.1. SAVI-Host Attribute
If a port is directly connected with a host, this port MUST be set
to have SAVI-Host attribute. If a port is connected with a limited
number of hosts, it MAY be set this attribute.
If a port has SAVI-Host attribute, control packet snooping MUST be
performed on this port to set up bindings and data packet triggered
DAD SHOULD be performed on this port.
Data packets from this port will be processed with different choices.
8.1.1.2. SAVI-SAVI Attribute
If and only if a port is connected with port on another SAVI switch,
it can be set to have this attribute.
This attribute is a conflict attribute of SAVI-Host attribute and
SAVI-UCA attribute.
No packet snooping will be performed on port with this attribute.
Packet from port with such attribute will be forwarded directly.
8.1.1.3. SAVI-UCA (Uncontrollable area) Attribute
If a port is connected to an uncontrollable area with unspecified
number of host, it SHOULD be set to have this attribute. This
attribute is a conflict attribute of SAVI-Host attribute and SAVI-
SAVI attribute.
The network administrator SHOULD avoid using this attribute. It is
SUGGESTED to use VLAN to reduce the scale of a single SAVI area and
avoid using this attribute.
The binding setup procedure and filtering policy are still not
specified. It is SUGGESTED not to set up bindings on port with this
attribute. The packet from this port SHOULD be checked whether
conflict with current bindings. If bindings are set up on port with
this attribute, it is SUGGESTED either the data packet MUST be used
to trigger DAD, or using "default-forwarding" policy.
8.1.1.4. SAVI-DHCP-PD-Trust Attribute
If and only if trustable DHCP-PD messages are received from a port,
it can be set to have this attribute.
Expires February 29, 2010 [Page 7]
Internet-Draft Control Packet Snooping Based Binding August 2009
In the situation DHCP-PD is used to configure prefix of the network,
there must be a port configured to have this attribute. The switch
should learn reliable DHCP-PD prefix from this port if DHCP-PD is
configured.
8.1.1.5. 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.
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:
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.
Expires February 29, 2010 [Page 8]
Internet-Draft Control Packet Snooping Based Binding August 2009
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 Setup
This section specifies how to set up bindings. Currently bindings
are only required to be set up on the ports with SAVI-Host attribute.
The binding setup procedures have two main types: address assignment
protocol snooping and probe trigger.
10.1. Address Assignment Protocol Snooping
This section specifies how to set up bindings based on address
assignment protocol snooping. It is composed by DAD snooping and
gratuitous ARP snooping.
10.1.1. DAD Snooping
10.1.1.1. Process of DAD Snooping
This process is designed for stateless auto-configuration assigned
IPv6 address and manually configured IPv6 address. If SLAAC is
enabled in the network, this procedure MUST be performed.
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
Expires February 29, 2010 [Page 9]
Internet-Draft Control Packet Snooping Based Binding August 2009
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.1.1.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
10.1.2. Gratuitous ARP Snooping
10.1.2.1. Process of Gratuitous ARP Snooping
This process is designed for manually configured IPv4 address. If
manually configured IPv4 address is used in the network, this
procedure MUST be performed.
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.
Expires February 29, 2010 [Page 10]
Internet-Draft Control Packet Snooping Based Binding August 2009
10.1.2.2. State Machine of Gratuitous 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
10.2. Probe Trigger
This section specifies how to set up bindings through sending probe
packets.
This kind of procedure is triggered by either control or data packet
not matching current bindings in the Filtering Table.
The procedures and state machines are much the same as the
procedures described in section [10.1], except that the first DAD
NS/Gratuitous ARP request is sent by the switch, not host itself.
10.2.1. NDP/ARP Triggered DAD Probe and Binding
If SLAAC or manually configured IPv4 address is used, this procedure
MUST be performed.
This procedure performs snooping on unsolicited NA, NS and ARP
Request, checks whether their source addresses are in reasonable
scope, and send DAD or ARP probes for these source addresses. If
there is no response for the probes from other ports, it will insert
the corresponding binding into the Binding State Table and Filtering
Table.
The reasonableness of this procedure is relying on the fact that
before sending data packet to a destination, the host will perform
the resolve from layer 3 address to layer 2 address. Using these
packets to trigger duplicate detection can eliminate (or reduce) the
risk of DAD loss, and handle incompatible operating systems.
10.2.2. Data Packet Triggered DAD Probe and Bindings
This procedure SHOULD be performed on SAVI-Host port.
In this procedure, whenever the source address of a data packet
isn't in the filtering table, the switch will send DAD/ARP probes to
check whether this address is duplicated. If there is no response
Expires February 29, 2010 [Page 11]
Internet-Draft Control Packet Snooping Based Binding August 2009
from other ports (or anchors), a binding will be inserted into the
Binging State Table and Filtering Table.
In this procedure, the rate of data packets to trigger binding is
limited.
This optional procedure is the most robust in some extreme situation.
However, the overhead is relative high.
10.3. Other Considerations on Binding Setup
If all the hosts in the link are complying with RFC4862 and RFC5227,
and the DAD retransmit number is set to be no less than 2, actually
basic binding is enough to handle all the situations(except for some
extreme situations). The trigger of DAD probe has heavier cost than
procedures without sending DAD probe.
It is SUGGESTED to enforce this configuration instead of using probe
trigger procedure.
10.4. Upper Bound and Minimum of Binding Number
To avoid the storage of binding state table and filtering table
exhausted by some malicious node, the upper bound binding number on
a port MUST be set.
And to avoid a host cannot possess enough binding entries, the
minimum binding number of a port MUST also be set.
11. Clear Binding
This section specifies when and how to clear bindings. Two modes can
be used here: clear-on-query and clear-on-demand.
11.1. Clear-on-Query mode
In this mode, the switch will send a NS or NUD or ARP request to
detect whether a binding address is still in use every
MAXIMUM_LIFETIME. If there is no response from the corresponding
node, this binding MUST be deleted; or else, set to lifetime of this
entry to be MAXIMUM_LIFETIME.
Whenever a node is disconnected at link layer, the corresponding
bindings in BST and Filtering Table will be remain for a FLAPPY_TIME.
Expires February 29, 2010 [Page 12]
Internet-Draft Control Packet Snooping Based Binding August 2009
11.2. Clear-on-Demand mode
In this mode, the switch would send any probe to detect whether an
address is still in use; instead, it will perform snooping on
NS/NUD/ARP request for the binding addresses, and decide whether to
delete the corresponding entry.
12. Filtering Specification
This section specifies how to use bindings to filtering packets on
port with SAVI-Host attribute. Filtering will not be performed on
port with SAVI-SAVI. The filtering on SAVI-UCA has not been defined
yet.
12.1. Filter Data Packet
In a switch scenario, if data packet is not enabled to trigger DAD
probe, 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.
In a switch scenario in which data packet is enabled to trigger DAD
probe, if the source of the packet is in the binding table of the
port, this packet will be forwarded; or else the packet will trigger
the switch to perform data packet triggered DAD procedure.
In a wireless scenario, all the filtering MUST be strictly complying
with Filtering Table; or if optional procedure 3 is chosen, packet
not match any binding will be process by that procedure.
12.2. Filter Control Packet
The source address of the control packet is always all zero (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 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.
Expires February 29, 2010 [Page 13]
Internet-Draft Control Packet Snooping Based Binding August 2009
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 MUST be in the
corresponding prefix scope.
If any check fails, the control packet triggered DAD probe procedure
will be performed by switch.
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.
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
Expires February 29, 2010 [Page 14]
Internet-Draft Control Packet Snooping Based Binding August 2009
design of such mechanism is temporarily out of the scope of this
document.
13.2. Port Movement
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:
- 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
There is no security consideration currently.
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
Expires February 29, 2010 [Page 15]
Internet-Draft Control Packet Snooping Based Binding August 2009
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.
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
Expires February 29, 2010 [Page 16]
Internet-Draft Control Packet Snooping Based Binding August 2009
process is the SAVI device can perform ARP/ND proxy for the inactive
node, and reduce the lifetime of binding to 1/4.
15. 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.
16. Constants
MAX_ARP_PREPARE_DELAY 1s
MAX_ARP_DELAY 1s
MAX_DAD_PREPARE_DELAY 1s
MAX_DAD_DELAY 1s
MAX_LIFETIME 2h
MAX_MANUAL_LIFETIME 4h
17. Security Considerations
There are no security considerations currently.
18. IANA Considerations
There is no IANA consideration currently.
Expires February 29, 2010 [Page 17]
Internet-Draft Control Packet Snooping Based Binding August 2009
19. References
19.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.
19.2. Informative References
20. Acknowledgments
Expires February 29, 2010 [Page 18]
Internet-Draft Control Packet Snooping Based Binding August 2009
Authors' Addresses
Expires February 29, 2010 [Page 19]
Network Working Group E. Nordmark
Internet-Draft Sun
Intended status: Standards Track M. Bagnulo
Expires: April 29, 2010 UC3M
E. Levy-Abegnoli
Cisco Systems
October 26, 2009
FCFS-SAVI: First-Come First-Serve Source-Address Validation for Locally
Assigned Addresses
draft-ietf-savi-fcfs-02
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 April 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.
Nordmark, et al. Expires April 29, 2010 [Page 1]
Internet-Draft FCFS SAVI October 2009
Abstract
This memo describes FCFS SAVI a mechanism to provide source address
validation for IPv6 networks using the First-Come First-Serve
approach. The proposed mechanism is intended to complement ingress
filtering techniques to provide a higher granularity on the control
of the source addresses used.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Design considerations . . . . . . . . . . . . . . . . . . . . 3
2.1. Scope of FCFS SAVI . . . . . . . . . . . . . . . . . . . . 3
2.2. Constraints for FCFS SAVI . . . . . . . . . . . . . . . . 4
2.3. Address ownership proof . . . . . . . . . . . . . . . . . 4
2.4. Layer-2 Anchor considerations . . . . . . . . . . . . . . 5
2.5. Special cases . . . . . . . . . . . . . . . . . . . . . . 5
3. SAVI topology and port configuration . . . . . . . . . . . . . 5
3.1. SAVI enforcement perimeter . . . . . . . . . . . . . . . . 6
3.2. SAVI port configuration guidelines . . . . . . . . . . . . 9
3.3. VLAN support . . . . . . . . . . . . . . . . . . . . . . . 10
4. FCFS SAVI specification . . . . . . . . . . . . . . . . . . . 10
4.1. FCFS SAVI Data structures . . . . . . . . . . . . . . . . 10
4.2. FCFS SAVI algorithm . . . . . . . . . . . . . . . . . . . 10
4.2.1. Processing of transit traffic . . . . . . . . . . . . 10
4.2.2. Processing of local traffic. . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
8. Normative References . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Nordmark, et al. Expires April 29, 2010 [Page 2]
Internet-Draft FCFS SAVI October 2009
1. Introduction
This memo describes FCFS SAVI, a mechanism to provide source address
validation for IPv6 networks using the First-Come First-Serve
approach. The proposed mechanism is intended to complement ingress
filtering techniques to provide a higher granularity on the control
of the source addresses used.
2. Design considerations
2.1. Scope of FCFS SAVI
The application scenario for FCFS SAVI is limited to the local-link.
This means that the goal of FCFS SAVI is verify that the source
address of the packets generated by the hosts attached to the local
link have not been spoofed.
In any link there usually are hosts and routers attached. Hosts
generate packets with their own address as the source address. This
is the so-called local traffic. while routers send packets containing
a source address other than their own, since they are forwarding
packets generated by other hosts (usually located in a different
link). This what the so-called transit traffic.
The applicability of FCFS SAVI is limited to the local traffic i.e.
to verify if the traffic generated by the hosts attached to the local
link contains a valid source address. The verification of the source
address of the transit traffic is out of the scope of FCFS SAVI.
Other techniques, like ingress filtering [RFC2827], are recommended
to validate transit traffic. In that sense, FCFS SAVI complements
ingress filtering, since it relies on ingress filtering to validate
transit traffic but is provides validation of local traffic, which is
not provided by ingress filtering. Hence, the security level is
increased by using these two techniques.
In addition, FCFS SAVI is designed to be used with locally assigned
addresses, in particular with address configured through stateless
address autoconfiguration [RFC4862]. Manually configured addresses
can be supported by FCFS SAVI, but manual configuration of the
binding on the SAVI device provides higher security and seems
compatible with manual address management. Additional considerations
about how to use FCFS SAVI depending on the type of address
management used and the nature of the addresses is discussed in the
framework document (add reference when available).
Nordmark, et al. Expires April 29, 2010 [Page 3]
Internet-Draft FCFS SAVI October 2009
2.2. Constraints for FCFS SAVI
FCFS SAVI is designed to be deployed in existing networks requiring a
minimum set of changes. For that reason, FCFS SAVI does not require
any changes in the hosts which source address is to be verified. Any
verification must solely rely in the usage of already available
protocols. This means that FCFS SAVI cannot define a new protocol
nor define any new message on existing protocols nor require that a
host uses an existent protocol message in a different way. In other
words, the requirement is no host changes.
FCFS SAVI validation is performed by the FSFC SAVI function. Such
function can be placed in different type of devices, including a
router or a layer-2 bridge. The basic idea is that the FCFS SAVI
function is located in the points of the topology that can enforce
the correct usage of source address by dropping the non-compliant
packets.
2.3. Address ownership proof
The main function performed by FCFS SAVI is to verify that the source
address used in data packets actually belongs to the originator of
the packet. Since FCFS SAVI scope is limited to the local link, the
originator of the packet is attached to the local link. In order to
define any source address validation solution, we need to define some
address ownership proof concept i.e. what it means to be able to
proof that a given host owns a given address in the sense that the
host is entitled to send packet with that source address.
Since no host changes are acceptable, we need to find the means to
proof address ownership without requiring a new protocol. In FCFS
SAVI the address ownership proof is based in the First-Come first
Serve approach. This means that the first host that claims a given
source address is the owner of the address until further notice.
More precisely, whenever a source address is used for the first time,
a state is created in the device that is performing the FCFS SAVI
function binding the source address to the layer-2 information that
the FCFS SAVI box has available (e.g. the port in a switched LAN).
Following data packets containing that IP source address must use the
same layer-2 information in order to be compliant.
There are however additional considerations to be taken into account.
For instance, consider the case of a host that moves from one segment
of a LAN to another segment of the same subnetwork and it keeps the
same IP address. In this case, the host is still the owner of the IP
address, but the associated layer-2 information has changed. In
order to cope with this case, the defined FCFS SAVI behaviour implies
the verification whether the host is still reachable using the
Nordmark, et al. Expires April 29, 2010 [Page 4]
Internet-Draft FCFS SAVI October 2009
previous layer-2 information. In order to do that FCFS SAVI uses ND
protocol. If the host is no longer reachable at the previously
recorded layer-2 information, FCFS SAVI assumes that the new location
is valid and creates a new binding using the new layer-2 information.
In case the host is still reachable using the previously recorded
information, the packets coming from the new layer-2 information are
dropped.
Note that this only applies to local traffic. Transit traffic
generated by a router would be verified using alternative techniques,
such as ingress filtering. SAVI checks would not be fulfilled by the
transit traffic, since the router is not the owner of the source
address contained in the packets.
2.4. Layer-2 Anchor considerations
Any SAVI solution is not stronger than the Layer-2 anchor it uses.
If the Layer-2 anchor is easily spoofable (e.g. a MAC address), then
the resulting solution will be weak. The treatment of non-compliant
packets needs to be tuned accordingly. In particular, if the Layer-2
anchor is easily spoofable and the SAVI device is configured to drop
no compliant packets, then the usage of SAVI may open a new vector of
Denial of Service attacks, based on spoofed Layer-2 anchors. For
that reason, in this document, we assume that the Layer-2 anchors
used by the SAVI solution are not easily spoofable (e.g. ports of a
switched network) and that the SAVI device MAY be configured to drop
non- compliant packets. If the SAVI solution proposed in this
document is to be used with weaker Layer-2 anchors (such as MAC
addresses), logging is RECOMMENDED instead of dropping non-compliant
packets. For the rest of the document, we will assume that the
Layer-2 anchors are ports of a switched network.
2.5. Special cases
The following special cases that need to be considered
o Hosts with multiple physical interfaces connected to the same
link.
o Anycast i.e. multiple hosts using the same source address to send
packets.
o Proxy ND i.e. host sending packets on behalf of other, in a
layer-3 transparent manner.
3. SAVI topology and port configuration
Nordmark, et al. Expires April 29, 2010 [Page 5]
Internet-Draft FCFS SAVI October 2009
3.1. SAVI enforcement perimeter
SAVI provides perimetrical security. This means that the SAVI
devices form what can be called a SAVI enforcement perimeter and they
verify that any packet that crosses the perimeter is compliant (i.e.
the source address related information is validated). Once the
packet is inside the perimeter, no further validations are performed
to the packet. This model has implications both on how SAVI devices
are deployed in the topology and on the configuration of the SAVI
boxes.
The implication of this perimetrical security approach, is that there
is part of the topology that is inside the perimeter and part of the
topology that is outside the perimeter. This means that while
packets coming from interfaces connected to the external part of the
topology need to be validated by the SAVI device, packets coming from
interfaces connected to the the internal part of the topology do not
need to be validated. This significantly reduces the processing
requirements of the SAVI device. It also implies that each SAVI
device that is part of the perimeter, must be able to verify the
source addresses of the packets coming from the interfaces connected
to the external part of the perimeter. In order to do so, the SAVI
device binds the source address to a layer-2 anchor.
One possible approach would be for every SAVI device to store binding
information about every source addresses in the subnetwork This means
that every SAVI device would store binding for each source address to
the local layer-2 anchor through packets with that source address can
be received through. The problem with this approach is that it
imposes significant memory burden on the SAVI devices. In order to
reduce the memory requirements imposed to each device, the SAVI
solution described in this specification distributes the storage of
SAVI binding information among the multiple SAVI devices of a
subnetwork. The SAVI binding state is distributed across the SAVI
devices according to the following criteria: each SAVI device will
store binding information about the source addresses bound to layer-2
anchors corresponding to the interfaces that connect to the part of
the topology that is outside of the SAVI enforcement perimeter.
Since all the untrusted packet sources are by definition in the
external part of the perimeter, this means that the packets generated
by each of the untrusted sources will reach the perimeter through one
interface of a SAVI device. The binding information for that
particular source address will be stored in this first SAVI device
the packet reaches to.
This means the SAVI binding information will be distributed across
multiple devices. In order to provide proper source address
validation, it is critical that the information distributed among the
Nordmark, et al. Expires April 29, 2010 [Page 6]
Internet-Draft FCFS SAVI October 2009
different SAVI devices is coherent. In particular, it is important
to avoid that the same source address is bound to different layer-2
anchors in different SAVI devices. Should that occur, then it would
mean that two hosts are allowed to send packets with the same source
address, which is what we are trying to prevent. In order to
preserve the coherency of the SAVI bindings distributed among the
SAVI devices within a realm, the Neighbour Discovery (ND) protocol is
used, in particular the Neighbour Solicitation (NSOL) and Neighbour
Advertisement (NADV) messages. Before creating a SAVI binding in the
local SAVI database, the SAVI device will send a NSOL message
querying for the address involved. Should any host reply to that
message with a NADV message, the SAVI device that sent the NADV will
infer that a binding for that address exists in another SAVI device
and will not create a local binding for it. If no NADV message is
received as a reply to the NSOL, then the local SAVI device will
infer that no binding for that address exists in other SAVI device
and will create the local SAVI binding for that address. (NOTE that
the description included here is overly simplified to illustrate the
mechanism used to preserve the coherency of the binding databases of
the different SAVI devices. The actual SAVI mechanism as described
below varies in the fact that in some cases it is the SAVI device
that generates the NSOL while in other cases it simply forwards the
NSOL generated by the end host, and that the SAVI device will send
multiple copies of the NSOL in order to improve the reliability of
the message exchange).
So, summarizing, the proposed SAVI approach relies on the following
design choices:
o SAVI provides perimetrical security, so some interfaces of a SAVI
device will connect to the internal (trusted) part of the topology
and other interfaces will connect to the external (untrusted) part
of the topology.
o A SAVI device only verifies packets coming though one interface
connected to the untrusted part of the topology.
o A SAVI device only stores binding information for the source
addresses that are bound to layer-2 anchors that correspond to
interfaces that connect to the untrusted part of the topology.
o SAVI uses the NSOL and NADV messages to preserve the coherency of
the SAVI binding state distributed among the SAVI devices within a
realm.
So, in a link that is constituted of multiple L2 devices, some of
which are SAVI capable and some of which are not, the SAVI capable
devices SHOULD be deployed forming a connected perimeter (i.e. that
no data packet can get inside the perimeter without passing through a
SAVI device). Packets that cross the perimeter will be validated
while packets that do no cross the perimeter are not validated (hence
SAVI protection is not provided for these packets). Consider the
Nordmark, et al. Expires April 29, 2010 [Page 7]
Internet-Draft FCFS SAVI October 2009
deployment of SAVI in the topology depicted in the following picture:
+--+ +--+ +--+ +--+
|H1| |H2| |H3| |R1|
+--+ +--+ +--+ +--+
| | | |
+-------------SAVI-ENFORCEMENT-PERIMETER--------------+
| | | | | |
| +-1-----2-+ +-1-----2-+ |
| | SAVI1 | | SAVI2 | |
| +-3--4----+ +--3------+ |
| | | +--------------+ | |
| | +----------| |--------+ |
| | | SWITCH-A | |
| | +----------| |--------+ |
| | | +--------------+ | |
| +-1--2----+ +--1------+ |
| | SAVI3 | | SAVI4 | |
| +-3---4---+ +----4----+ |
| | | | |
+-------------SAVI-ENFORCEMENT-PERIMETER--------------+
| | |
+--+ +--+ +---------+
|R2| |H4| |SWICTH-B |
+--+ +--+ +---------+
| |
+--+ +--+
|H5| |H6|
+--+ +--+
In the figure above, the SAVI enforcement perimeter is provided by 4
SAVI devices, namely SAVI1, SAVI2, SAVI3 and SAVI4. These devices
verify information related to the source address both in data and in
ND packets and filter packets accordingly.
SAVI devices then have two types of ports: trusted ports and
validating ports.
o Validating ports (VPs) are those in which SAVI processing is
performed. This means that when a packet is received through one
of the validating ports, the SAVI processing and filtering will be
executed.
o Trusted ports (TPs) are those in which SAVI processing is not
performed. So, packets received through trusted ports are not
validated and no SAVI processing is performed in them.
Trusted ports are used for connections with trusted infrastructure,
including the communication between SAVI devices, the communication
Nordmark, et al. Expires April 29, 2010 [Page 8]
Internet-Draft FCFS SAVI October 2009
with routers and the communication of other switches that while they
are not SAVI devices, they only connect to trusted infrastructure
(i.e. other SAVI devices, routers or other trusted nodes). So, in
the figure above, Port 3 of SAVI1 and port 1 of SAVI3 are trusted
because the connect two SAVI devices. Port 4 of SAVI1, port 3 of
SAVI2, port 2 of SAVI3 and port 1 of SAVI4 are trusted because the
connect to SWITCH-A to which only trusted nodes are connected. In
the figure above, port 2 of SAVI2 and port 3 of SAVI3 are trusted
ports because they connect to routers.
Validating ports are used for connection with non-trusted
infrastructure. In particular, hosts are normally connected to
validating ports. Non-SAVI switches that are outside of the SAVI
enforcement perimeter also are connected through validating port. In
particular, non-SAVI devices that connect directly to hosts or that
have no SAVI capable device between themselves and the hosts are
connected through a validating port. So, in the figure above, ports
1 and 2 of SAVI1, port 1 of SAVI2, port 4 of SAVI 3 are validating
ports because they connect to hosts. Port 4 of SAVI4 is also a
validating port because it is connected to SWITCH-B which is a non-
SAVI capable switch which is connected to hosts H5 and H6.
3.2. SAVI port configuration guidelines
The guidelines for port configuration in SAVI devices are:
o Ports that are connected to another SAVI device SHOULD be
configured as Trusted ports. Not doing so will at least
significantly increase the memory consumption in the SAVI devices.
o Ports connected to hosts SHOULD be configured as Validating ports.
Not doing so will allow the host connected to that port to send
packets with spoofed source address.
o Ports connected to routers SHOULD be configured as Trusted ports.
Configuring them as Validating ports would increase the signaling
due to SAVI. The implication is that a router can generate
traffic with any source address as they are assumed to be part of
the trusted infrastructure.
o Ports connected to a chain of one or more legacy switches that
have hosts connected SHOULD be configured as Validating ports.
Not doing so will allow the host connected to any of these
switches to send packets with spoofed source address.
o Ports connected to a chain of one or more legacy switches that
have other SAVI devices and/or routers connected but had no hosts
attached to them SHOULD be configured as Trusted ports. Not doing
so will at least significantly increase the memory consumption in
the SAVI devices and increase the signaling traffic due to SAVI
validation.
Nordmark, et al. Expires April 29, 2010 [Page 9]
Internet-Draft FCFS SAVI October 2009
o Ports connected to a chain of one or more legacy switches that
have a mix of SAVI devices and/or routers with hosts, SHOULD be
configured as Validating ports. Not doing so will allow the host
connected to that port to send packets with spoofed source
address. Nevertheless, this topology will result in increased
SAVI signaling and memory consumption compared to a topology where
SAVI-hosts communications and inter SAVI communications are kept
through different legacy switches.
3.3. VLAN support
In the case the SAVI device is a switch that supports VLANs, the SAVI
implementation will behave as if there was one SAVI process per VLAN.
The SAVI process of each VLAN will store the binding information
corresponding the the nodes attached to that particular VLAN.
4. FCFS SAVI specification
4.1. FCFS SAVI Data structures
FCFS SAVI function relies on state information binding the source
address used in data packets to the layer-2 information that
contained the first packet that used that source IP address. Such
information is stored in FCFS SAVI Data Base (DB). The FCFS SAVI DB
will contain a set of entries about the currently used IP source
addresses. So each entry will contain the following information:
o IP source address
o Layer-2 information, such as Layer-2 address, port through which
the packet was received, etc
o Lifetime
o Status:either tentative or valid
o Creation time: the value of the local clock when the entry was
firstly created
In addition to this, FCFS SAVI need to know what are the prefixes
that are directly connected, so it maintains a data structure called
the the FCFS SAVI prefix list, which contains:
o Prefix
o Interface where prefix is directly connected
4.2. FCFS SAVI algorithm
4.2.1. Processing of transit traffic
The FCFS SAVI function is located in a forwarding device, such as a
router or a layer-2 bridge. The following processing is performed
depending on the type of port the packet has been received through:
Nordmark, et al. Expires April 29, 2010 [Page 10]
Internet-Draft FCFS SAVI October 2009
o If the data packet is received through a Trusted port, the data
packet is forwarded and no SAVI processing performed to the
packet.
o If the data packet is received through a Validating port, then the
SAVI function checks whether the received data packet is local
traffic or transit traffic. It does so by verifying if the source
address of the packet belongs to one of the directly connected
prefixes available in the receiving interface. It does so by
searching the FCFS SAVI Prefix List.
* If the IP source address does not belong to one of the local
prefixes of the receiving interface, this means that the dat
packet is transit traffic and the packet SHOULD be discarded.
The FCFS SAVI function MAY send an ICMP Destination Unreachable
Error back to the source address of the data packet. (ICMPv6,
code 5 (Source address failed ingress/egress policy) should be
used).
* If the source address of the packet does belong to one of the
prefixes available in the the receiving port, then the SAVI
local traffic validation processes is executed as described
below.
4.2.2. Processing of local traffic.
We describe next how the local traffic, including both control and
data packets are processed by the SAVI device using a state machine
approach.
The state machine described is for the binding of a given source IP
address in a given SAVI device. So this means that all the packets
described as inputs in the state machine above refer to that given IP
address. The key attribute is the IP address. The full state
information is:
o IP ADDRESS: IPAddr
o LAYER_2 ANCHOR: P
o LIFETIME: LT
The possible states are:
o NO_BIND
o TENTATIVE
o VALID
o TESTING_TP
o TESTING_VP
o TESTING_LIFETIME
We will use VP for Validating Port and TP for Trusted Port.
After bootstrapping (when no binding exists), the state for all
source IP address is NO-BIND i.e. there is no binding for the IP
Nordmark, et al. Expires April 29, 2010 [Page 11]
Internet-Draft FCFS SAVI October 2009
address to any Layer-2 anchor.
NO_BIND: The binding for a source IP address entry is in this state
when it does not have any binding to a Layer 2 anchor. All addresses
are in this state by default after bootstrapping, unless bindings
were created for it.
TENTATIVE: The binding for a source address is in this state during
the waiting period during which the DAD procedure is being executed
(either directly by the host itself or by the SAVI device on its
behalf).
VALID: The binding for the source address has been verified, it is
valid and usable for filtering traffic.
TESTING_TP: A binding for a source address enters in this sate when a
DAD_NSOL has been received through a Trusted port. this implies that
another host is performing the DAD procedure for that source address
in another switch. this may due to an attack or to the fact that the
host may have moved. The binding in this state is then being tested
to determine which is the situation.
TESTING_TP: A binding for a source address enters in this sate when a
DAD_NSOL or a data packet has been received through a Validating
port. this implies that another host is performing the DAD procedure
for that source address in another switch. this may due to an attack
or to the fact that the host may have moved. The binding in this
state is then being tested to determine which is the situation.
TESTING_LIFETIME: A binding for a source address is in this state
cause the lifetime of the entry is about to expire. this is due to
the fact that no packets has been seen by the SAVI device for the
LIFETIME period. this may be due to the host simply being silent or
because the host has left the location. In order to determine which
is the case, a test is performed, in order to determine if the
binding information should be discarded.
We describe next how the different inputs are processed depending on
the state of the binding of the IP address.
A simplified figure of the state machine can be found at
http://www.it.uc3m.es/~marcelo/SAVI_state_machine.pdf
NO_BIND
o Upon the reception through a Validating Port (VP) of a Neighbour
Solicitation (NSOL) generated by the Duplicate Address Detection
(DAD) procedure (hereafter named DAD_NSOL) containing Target
Nordmark, et al. Expires April 29, 2010 [Page 12]
Internet-Draft FCFS SAVI October 2009
Address IPAddr, or after the reception of a DATA packet containing
IPAddr as the source address, the SAVI device will execute the
process of sending Neighbour Solicitation (NSOL) messages of the
Duplicate Address Detection process as described in section 5.4.2
of [RFC4862] for the IPAddr using the following default
parameters: DupAddrDetectTransmits set to 2 (i.e. 2 Neighbour
Solicitation messages for that address will be sent by the SAVI
device) and RetransTimer set to 500 milliseconds (i.e. the time
between two Neighbour Solicitation messages is 500 millisecs and
also the wait time for replies in the form of Neighbour
Advertisement for the queried address). The NSOL messages are not
sent through any of the ports configured as Validating Ports. The
NSOL messages are sent through the proper Trusted Ports (as
defined by the switch behaviour that will depend on whether it
performs MLD snooping or not) The SAVI device MAY discard the data
packet while the DAD procedure is being executed.
* EDITOR NOTE: We need to rate limit the emission of NSOL of the
SAVI device as a whole.
* EDITOR NOTE 2: should we send the NSOL through the port the
packet was received through?
The state is moved to TENTATIVE. The LIFETIME is set to TENT_LT
(i.e. LT==TENT_LT) and the LAYER_2 ANCHOR is set to VP (i.e.
P==VP)
o Data packets containing IPAddr as the source address received
through Trusted ports are processed and forwarded as usual (i.e.
no special SAVI processing)
o DAD_NSOL packets containing IPAddr as the target address received
through a Trusted port are NOT forwarded through any of the
Validating ports but they are sent through the proper Trusted
Ports (as defined by the switch behaviour that will depend on
whether it performs MLD snooping or not)
o Neighbor Advertisement packets sent to all nodes as a reply to the
DAD_NSOL (hereafter called DAD_NADV) containing IPAddr as the
target address coming through a Validating port are discarded.
o Other signaling packets are processed and forwarded as usual (i.e.
no SAVI processing)
TENTATIVE
o If the LIFETIME times out, the state is moved to VALID. The
LIFETIME is set to DEFAULT_LT (i.e. LT== DEFAULT_LT). Stored
data packets are forwarded (if any).
o If a Neighbour Advertisement (NADV) is received through a Trusted
Port with Target Address set to IPAddr, then state is set to
NO_BIND and the LAYER_2 ANCHOR and the LIFETIME are cleared. Data
packets stored corresponding to this binding are discarded.
Nordmark, et al. Expires April 29, 2010 [Page 13]
Internet-Draft FCFS SAVI October 2009
o If a NADV is received through a Validating Port with Target
Address set to IPAddr, the NADV packet is discarded
o If a data packet with source address IPAddr is received with
Layer_2 anchor equal to P, then the packet is either stored or
discarded.
* EDITOR NOTE: we need to define a maximum storage space for the
data packets. Having a single default value may be hard since
it will heavily depend on the capability of the device. Maybe
it would be enough that the device has a maximum and that the
value can be configured?
o If a data packet with source address IPAddr is received through a
Trusted port, the data packet is forwarded. the state is
unchanged. ( waiting for the NADV?)
o If a data packet with source address IPAddr is received through a
Validating port other than P, the data packet is discarded.
o Other signaling packets are processed and forwarded as usual (i.e.
no SAVI processing)
* EDITOR NOTE: this may need more thought
VALID
o If a data packet containing IPAddr as a source address arrives
from Validating port P, then the LIFETIME is set to DEFAULT_LT and
the packet is forwarded as usual.
* EDITOR NOTE: Is this feasible? i.e. to reset a timer each time
a data packet arrives? We could just have a long lifetime and
actively check for the host when the lifetime is about to
expire.
o If a DAD_NSOL is received from a Trusted port, then the DAD_NSOL
message is forwarded to port P and it is also forwarded to the
proper Trusted Ports (as defined by the switch behaviour that will
depend on whether it performs MLD snooping or not). The state is
changed to TESTING_TP. The LIFETIME is set to TENT_LT.
o If a data packet containing source address IPAddr or a DAD_NSOL
packet with target address set to IPAddr is received through a
Validating port P' other than P, then the SAVI device will execute
the process of sending DAD_NSOL messages as described in section
5.4.2 of [RFC4862] for the IPAddr using the following default
parameters: DupAddrDetectTransmits set to 2 (i.e. 2 NSOL messages
for that address will be sent by the SAVI device) and RetransTimer
set to 500 milliseconds (i.e. the time between two NSOL messages
is 500 millisecs and also the wait time for replies in the form of
Neighbour Advertisement for the queried address). The DAD_NSOL
message will be forwarded to the port P.
* EDITOR NOTE: should we also forward it though the TP?
Theoretically, there shouldn't be another binding in any other
SAVI device, so there should not be a need for this.
The state is moved to TESTING_VP. The LIFETIME is set to TENT_LT.
Nordmark, et al. Expires April 29, 2010 [Page 14]
Internet-Draft FCFS SAVI October 2009
The SAVI device MAY discard the data packet while the DAD
procedure is being executed.
o If the LIFETIME expires, then the SAVI device will execute the
process of sending DAD_NSOL messages as described in section 5.4.2
of [RFC4862] for the IPAddr using the following default
parameters: DupAddrDetectTransmits set to 2 (i.e. 2 NSOL messages
for that address will be sent by the SAVI device) and RetransTimer
set to 500 milliseconds (i.e. the time between two NSOL messages
is 500 millisecs and also the wait time for replies in the form of
Neighbour Advertisement for the queried address). The DAD_NSOL
messages will be forwarded to the port P. The state is changed to
TESTING_LIFETIME and the LIFETIME is set to TENT_LT.
o If a data packet containing IPAddr as a source address arrives
from Trusted port, the packet is discarded.
* EDITOR NOTE: receiving such a packet means that another SAVI
device has created a binding for this address, or that the
perimeter has been breached. This should be logged?
o Other signaling packets are processed and forwarded as usual (i.e.
no SAVI processing). In particular DAD_NADV containing IPAddr as
the target address are forwarded as usual.
TESTING_TP
o If the LIFETIME expires, the LAYER_2 ANCHOR is cleared and the
state is changed to NO_BIND
o If a NADV message containing the IPAddr as target address is
received through the Validating port P as a reply to the DAD_NSOL
message, then the NADV is forwarded as usual and the state is
changed to VALID. The LIFETIME is set to DEFAULT_LT
o If a data packet containing IPAddr as the source address is
received through port P, then the packet is forwarded.
* EDITOR NOTE: should we move back to VALID?
o If a data packet is received through a port that is other than
port P, then the packet is discarded.
TESTING_VP
o If the LIFETIME expires, the LAYER_2 ANCHOR set to P' (i.e.
P==P'), the LIFETIME is set to DEFAULT_LT and the state is changed
to VALID. Data packet stored coming from P' are forwarded.
o If a NADV message containing the IPAddr as target address is
received through the Validating port P as a reply to the DAD_NSOL
message, then the NADV is forwarded as usual and the state is
changed to VALID. The LIFETIME is set to DEFAULT_LT
o If a data packet containing IPAddr as the source address is
received through port P, then the packet is forwarded.
Nordmark, et al. Expires April 29, 2010 [Page 15]
Internet-Draft FCFS SAVI October 2009
* EDITOR NOTE: should we move back to VALID?
o If a data packet is received through a port that is other than
port P, then the packet is discarded.
TESTING_LIFETIME
o If the LIFETIME expires, the LAYER_2 ANCHOR is cleared and the
state is changed to NO_BIND
o If a NADV message containing the IPAddr as target address is
received through the Validating port P as a reply to the DAD_NSOL
message, then the NADV is forwarded as usual and the state is
changed to VALID. The LIFETIME is set to DEFAULT_LT
o If a data packet containing IPAddr as the source address is
received through port P, then the packet is forwarded and the
state is changed to VALID. The LIFETIME is set to DEFAULT_LT
Rate limiting of messages: TBD
MLD considerations
The SAVI device must join the Solicited Node Multicast group for all
the addresses which state is other than NO_BIND. this is needed to
make sure that the SAVI device will receive the DAD_NSOL for those
addresses. Please note that it may not be enough to relay on the
host behind the Validating port doing so, since the node may move and
after a while, the packets for that particular solicited node
multicast group will no longer be forwarded to the SAVI device. So,
the SAVI device SHOULD join the solicited node multicast groups for
all the addresses that are in a state other than NO_BIND
5. Security Considerations
First of all, it should be noted that any SAVI solution will be as
strong as the lower layer anchor that it uses. In particular, if the
lower layer anchor is forgeable, then the resulting SAVI solution
will be weak. For example, if the lower layer anchor is a MAC
address that can be easily spoofed, then the resulting SAVI will not
be stronger than that. On the other hand, if we use switch ports as
lower layer anchors (and there is only one host connected to each
port) it is likely that the resulting SAVI solution will be
considerably more secure.
Denial of service attacks
There are two types of DoS attacks that can be envisaged in a SAVI
environment. On one hand, we can envision attacks against the SAVI
device resources. On the other hand, we can envision DoS attacks
Nordmark, et al. Expires April 29, 2010 [Page 16]
Internet-Draft FCFS SAVI October 2009
against the hosts connected to the network where SAVI is running.
The attacks against the SAVI device basically consist on making the
SAVI device to consume its resource until it runs out of them. For
instance, a possible attack would be to send packets with different
source addresses, making the SAVI device to create state for each of
the addresses and waste memory. At some point the SAVI device runs
out of memory and it needs to decide how to react in this situation.
The result is that some form of garbage collection is needed to prune
the entries. It is recommended that when the SAVI device runs out of
the memory allocated for the SAVI DB, it creates new entries by
deleting the entries which Creation Time is higher. This implies
that older entries are preserved and newer entries overwrite each
other. In an attack scenario where the attacker sends a batch of
data packets with different source address, each new source address
is likely to rewrite another source address created by the attack
itself. It should be noted that entries are also garbage collected
using the LIFETIME, which is updated using data packets. The result
is that in order for an attacker to actually fill the SAVI DB with
false source addresses, it needs to continuously send data packets
for all the different source addresses, in order for the entries to
grow old and compete with the legitimate entries. The result is that
the cost of the attack for the attacker is highly increased.
The other type of attack is when an attacker manages to create state
in the SAVI device that will result in blocking the data packets sent
by the legitimate owner of the address. In IPv6 these attacks are
not an issue thanks to the 2^64 addresses available in each link.
Compare with Threat analysis and identify residual threats: TBD
6. Contributors
Jun Bi
CERNET
Network Research Center, Tsinghua University
Beijing 100084
China
Email: junbi at cernet.edu.cn
Guang Yao
CERNET
Network Research Center, Tsinghua University
Beijing 100084
China
Nordmark, et al. Expires April 29, 2010 [Page 17]
Internet-Draft FCFS SAVI October 2009
Email: yaog at netarchlab.tsinghua.edu.cn
Fred Baker
Cisco Systems
Email: fred at cisco.com
Alberto Garcia Martinez
University Carlos III of Madrid
Email: alberto at it.uc3m.es
7. Acknowledgments
This draft benefited from the input from: Christian Vogt, Dong Zhang,
Frank Xia and Lin Tao.
Marcelo Bagnulo is partly funded by Trilogy, a research project
supported by the European Commission under its Seventh Framework
Program.
8. Normative References
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
Authors' Addresses
Erik Nordmark
Sun Microsystems, Inc.
17 Network Circle
Menlo Park, CA 94025
USA
Phone: +1 650 786 2921
Email: Erik.Nordmark at Sun.COM
Nordmark, et al. Expires April 29, 2010 [Page 18]
Internet-Draft FCFS SAVI October 2009
Marcelo Bagnulo
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
SPAIN
Phone: 34 91 6248814
Email: marcelo at it.uc3m.es
URI: http://www.it.uc3m.es
Eric Levy-Abegnoli
Cisco Systems
Village d'Entreprises Green Side - 400, Avenue Roumanille
Biot-Sophia Antipolis - 06410
France
Email: elevyabe at cisco.com
Nordmark, et al. Expires April 29, 2010 [Page 19]
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.