Network Working Group M. Bagnulo
Internet-Draft A. Garcia-Martinez
Intended status: Standards Track UC3M
Expires: April 24, 2010 October 21, 2009
SEND-based Source-Address Validation Implementationdraft-ietf-savi-send-01
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 24, 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
This memo describes SEND SAVI, a mechanism to provide source address
validation using the SEND protocol. The proposed mechanism is
intended to complement ingress filtering techniques to provide a
Bagnulo & Garcia-Martinez Expires April 24, 2010 [Page 1]

Internet-Draft SEND SAVI October 20091. Introduction
This memo describes SEND SAVI, a mechanism to provide source address
validation for IPv6 networks using the SEND protocol. 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 considerations2.1. Scope of SEND SAVI
In a 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 is the so-called transit traffic.
SEND SAVI allows the validation of the source address of the local-
traffic, i.e. it allows to verify that the source address of the
packets generated by the hosts attached to the local link have not
been spoofed. In addition, since SEND does provide the means to
verify that a node claiming to act as a router is indeed authorized
to act as one, SEND SAVI also provides the means to verify that
packets containing off-link prefixes in the source address are
generated by authorized routers. However, SEND SAVI does not provide
the means to verify if a given (authorized) router is actually
authorized to forward packets containing a specific (off-link) source
address. Other techniques, like ingress filtering [RFC2827], are
recommended to validate transit traffic. In that sense, SEND SAVI
complements ingress filtering. Hence, the security level is
increased by the use of both SAVI and ingress filtering.
SEND SAVI applicability is limited to IPv6 hosts and IPv6 routers
using the SEND protocol [RFC3971].
SEND SAVI validation can be performed in different type of devices,
including a router or a layer-2 bridge. The SEND SAVI function
should be located in the points of the topology in which the correct
usage of source address can be enforced by dropping the non-compliant
packets.
2.2. Constraints for SEND SAVI
SEND SAVI is designed to be deployed in existing networks requiring a
minimum set of changes. In particular, SEND SAVI does not require
Bagnulo & Garcia-Martinez Expires April 24, 2010 [Page 3]

Internet-Draft SEND SAVI October 2009
any changes in the hosts whose source address is to be verified. Any
verification must solely rely in the usage of already available
protocols. This means that SEND SAVI does neither 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. SEND SAVI relies on the usage of the SEND protocol as defined
in [RFC3971] and the usage of CGA addresses as defined in [RFC3972].
No changes to SEND or CGAs are required by SEND SAVI.
2.3. Address ownership proof for SEND SAVI
The main function performed by SEND SAVI is to verify that the source
address used in data packets actually belongs to the originator of
the packet. In SEND SAVI the address ownership proof is based in the
tools provided by SEND, namely CGAs and certificates. CGAs are used
to verify that the generator of a packet containing an on-link source
address is actually the owner of the address. Certificates are used
to verify that a node sending packets with off-link source address is
an authorized router. By using these two tools, SEND SAVI devices
can verify that the source address used in any packet flowing through
the local link is either generated by the host owner of the on-link
source address or that it is generated by an authorized router.
In both cases, the verification performed applies to a layer-2 anchor
associated to the IPv6 address used as source address in the data
packets. This anchor can be a layer-2 address, or the port of the
layer-2 switch through which a packet containing the IPv6 address as
source address should be received. SEND provides means to securely
associate IPV6 addresses with layer-2 addresses. However, unless an
additional mechanism (such as IEEE 802.1AE) is used, the fact that
layer-2 addresses can be spoofed suggest the use of ports as layer-2
anchors. For the rest of the document we assume the use of ports as
layer-2 anchors.
3. SEND SAVI topology and port configuration3.1. SEND SAVI enforcement perimeter
SEND SAVI is designed to provide perimetrical protection. This
deployment model is similar to the one presented in FCFS SAVI
[I-D.bagnulo-savi-fcfs]. This design allows reducing computing and
state requirements in SAVI devices by performing the cryptographic
validations required to create the binding only in the SEND SAVI
device through which a packet first enters in the secured perimeter.
Once the packet is inside the perimeter, no further validations are
performed in general. An exception to this is when a binding existed
in the local SEND SAVI device, in which case a local check for that
Bagnulo & Garcia-Martinez Expires April 24, 2010 [Page 4]

Internet-Draft SEND SAVI October 2009
device is performed. It is worth to note that the deployment model
allows connectivity to legitimate hosts even if the perimeter is not
properly built, although in this case protection against spoofing
cannot be provided.
The proposed mechanism assures that coherency among the information
available in the different SEND SAVI devices is preserved, if the
perimeter is configured appropriately. In particular, it avoids to
have a binding in different SAVI devices for the same source address.
Should that occur, it would mean that two hosts are allowed to send
packets with the same source address, which is undesirable according
to the goals of SAVI.
Ports in SEND SAVI devices may assume two roles according to its
behavior when filtering and validating SEND messages: Validating
ports and Trusted ports.
o Validating ports are those in which SEND SAVI filtering is
performed. This means that when a packet is received through one
of the Validating ports, SEND SAVI filtering will be executed.
Additionally, the validation of host identities by SEND SAVI is
performed only through Validating ports.
o Trusted ports are those in which SEND SAVI filtering is not
performed. So, packets received through Trusted ports are not
filtered by SEND SAVI. The only SEND messages received through a
Trusted port which are processed are those related with
certificate and router information.
The following figure shows a typical topology involving trusted and
untrusted infrastructure.
Bagnulo & Garcia-Martinez Expires April 24, 2010 [Page 5]

Internet-Draft SEND SAVI October 2009
hosts or which have no SEND SAVI capable device between themselves
and the hosts are connected through a validating port. So, in the
figure above, ports 1 and 2 of SEND-SAVI1, port 1 of SEND-SAVI2, port
4 of SEND-SAVI3 are validating ports because they connect to hosts.
Port 4 of SEND-SAVI4 is also a validating port because it is
connected to SWITCH-B which is a non- SEND SAVI capable switch which
is connected to hosts H5 and H6. Note that port 2 of SEND-SAVI2 and
port 3 of SEND-SAVI3 are validating ports, although they connect to
routers, since in SEND SAVI routers must use the appropriate SEND
message exchange to create an appropriate binding.
3.2. SEND SAVI port configuration guidelines
The guidelines for port configuration in SEND SAVI devices are:
o Ports that are connected to another SEND SAVI device SHOULD be
configured as Trusted ports. Not doing so will at least increase
significantly the CPU time, memory consumption and signaling
traffic due to SEND SAVI validation, in both the SEND SAVI devices
and the host or router whose address is being validated.
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 Validating
ports. In this way, secured RADV, informing of the routing role
of the node and about on-line prefixes, are validated according to
SEND validation rules.
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 SEND 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 SEND SAVI devices and increase the signaling
traffic due to SEND SAVI validation.
o Ports connected to a chain of one or more legacy switches that
have a mix of SEND 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.
4. SEND SAVI specificationBagnulo & Garcia-Martinez Expires April 24, 2010 [Page 7]

Internet-Draft SEND SAVI October 20094.1. SEND SAVI Data structures
The SEND SAVI function relies on state information binding the source
IPv6 address used in data packets to the port through which the
legitimate host connects. Such information is stored in SEND SAVI
Data Base (DB). The SEND SAVI DB contains a set of entries about the
currently used IPv6 source addresses. Each binding must be unique
for a given VLAN (although the same address may appear in different
VLANs, eg. two IPv6 link-local addresses). The SEND SAVI DB is
populated with the contents of successfully validated SEND messages.
So each entry will contain the following information:
o IP source address
o VLAN
o Layer-2 port Validating port to which the host is connected.
o Timeout_Valid
SEND SAVI also needs the anchor information (see [RFC3971]) required
to validate the information generated by routers. Consequently, a
SEND SAVI Trust Anchor table, containing the certificates that can be
used as starting point for a certification path. Different trust
anchors can be associated to different VLANs. The contents of this
table are populated with other means than SEND operation, i.e. manual
configuration, etc. The information contained in the SEND SAVI Trust
Anchor table is the following:
o Trust Anchor
o VLAN
To be able to validate RADV messages, a SEND SAVI Router
Certification Path Table is required. This table contains sequences
of certificates that certify the authority of the routers. As
[RFC3971] states, the Certification Paths should start from an anchor
(contained in the SEND SAVI Trust Anchor table) to be stored in the
SEND SAVI Router Certification Path Table. Different trust anchors
can be associated to different VLANs. This table is populated as a
result of the reception of validated Certification Path Solicitation
messages. The contents of the table are:
o Certification Path
o VLAN
In addition to this, SEND SAVI need to know which are the link
prefixes. This information is obtained from validated RADV messages.
The corresponding data structure is called the SEND SAVI prefix list,
and contains:
o Prefix
o VLAN
o Lifetime
SEND SAVI keeps a list of the authorized routers, only for those
Bagnulo & Garcia-Martinez Expires April 24, 2010 [Page 8]

Internet-Draft SEND SAVI October 2009
routers attached to Validating ports. In the SEND SAVI Router List,
the following information is stored:
o Router IPv6 address
o Layer-2 Validating port at which the router is connected.
o VLAN
o Lifetime
Finally, a SEND SAVI device must be configured with a valid CGA
address. This address is used when the SEND SAVI needs to issue
secured NSOL, RSOL or CPS messages.
4.2. Address configuration of SEND SAVI devices
Each SEND SAVI device must have a valid CGA address to use it for
secured ND operations. To configure this address, the usual
processes involved in address configuration, according to the SEND
specification [RFC3971], must be honored, such as performing DAD.
Different addresses may be used for different VLANs.
4.3. Obtaining Certification Paths
SEND SAVI devices MAY issue a Certification Path Solicitation message
to request a certification path from any router in the link, as it is
specified in the SEND specification [RFC3971]. This message MAY be
sent in all VLANs configured in the switch.
Alternatively, SEND SAVI devices may be configured not to request
this information, in which case the public key certificate used by
each router in the link must be available by other means (eg. manual
configuration).
4.4. Authorized Router Discovery and On-link prefix discovery
In order to be able to distinguish local from transit traffic, all
SEND SAVI devices MUST listen and process RADV containing the SEND
extensions. A SEND SAVI device receiving a secured RADV from a
Validating port for a router not included in the SEND SAVI prefix
list SHOULD validate the message, and if successful, issue a RSOL
message to the router to receive a new RADV in which the nonce send
by the SAVI SEND device is included and secured. If this check is
successful, then the SEND SAVI device MUST forward the initial
unsolicited RADV to the rest of the layer-2 network. After the
successful validation of the RADV message, the advertised prefixes
are included in the SEND SAVI Prefix List table.
SEND SAVI devices receiving RADV messages through Trusted ports MAY
trust that other SEND SAVI switches have validated the router
information, and include the prefix information in the SEND SAVI
Bagnulo & Garcia-Martinez Expires April 24, 2010 [Page 9]

Internet-Draft SEND SAVI October 2009
Prefix List table. Lifetime for prefixes and routerare updated
according to the information included in the RADV message. Note that
routers only have to prove liveliness through nonce response for the
first SEND SAVI device in the SEND SAVI perimeter. The reception of
a RADV message through a Trusted port MUST not trigger the generation
of a secured RSOL.
A SEND SAVI device MAY send secured RSOL messages including the SEND
extensions when needed to keep the Router list and/or the Prefix list
up to date.
4.5. SEND SAVI algorithm4.5.1. Traffic processing
In this section we describe how packets (with the exceptions
considered in the previous sections, such as RADV or CPA/CPS
messages) are processed.
First, the source address of packet is analysed to determine if it is
local or transit traffic, by checking if the prefix of the source
address is included in the SEND SAVI Prefix List (local traffic) or
not (transit traffic).
Transit traffic processing occurs as follows:
o If the transit traffic packet is received through a Trusted port,
the data packet is forwarded and no SAVI processing performed.
o If the transit traffic packet is received through a Validating
port, the is only accepted if the port appears in the SEND SAVI
Router List, indicating that a router has been validated through
SEND procedures at this port.
We next consider how local traffic is processed.
4.5.1.1. Processing of local traffic
If the verification of the source address of a packet shows that it
belongs to local traffic, this packet is processed using the state
machine described in this section.
For the rest of the section, the following assumptions hold:
o When it is stated that a secured NUD NSOL message is issued by a
SEND SAVI device through a given port, this means the following:
the SEND SAVI device performs a Neighbor Unreachability Detection
procedure as described in [RFC4861] with SEND secured messages as
defined in [RFC3971] addressed to the IPv6 target address (source
address of the packet triggering the procedure). The source
address used for issuing the NUD NSOL is the source address of the
Bagnulo & Garcia-Martinez Expires April 24, 2010 [Page 10]

Internet-Draft SEND SAVI October 2009
SEND SAVI device.
o When it is stated that a validated NUD NADV message is received by
a SEND SAVI device through a port P, this means that: a SEND
secured NUD NADV message has been received by the appropriate port
P, and the NUD NADV message has been validated according to
[RFC3971] to prove ownership for the IPv6 address under
consideration, and being a response for the previous NUD NSOL
message issued by the SEND SAVI device (containing the same nonce
value as the NUD NSOL message to which it answers). Note that NUD
NADV messages that were not generated as response to a secured NUD
NSOL issued by the SEND SAVI device are not valid for updating the
SEND SAVI state machine, in order to provide greater protection
against reply attacks
The state machine is defined for a binding of a given source IP
address in a given VLAN and in a given SAVI device. In the
transitions considered, packets described as inputs refer to the IPv6
address associated to the state machine.
The possible states are
o NO_BIND
o TENTATIVE
o VALID
o TESTING
For deploying the state machine, two additional elements are
required: the Pending NUD NADV Messages table, and the Pending NUD
NADVs Counter (which counts the number of rows in the Pending NUD
NADV Messages table). One entry can be created per port (and per
source address to check) in the SEND SAVI device. The Pending NUD
NADV Messages table contains the following elements:
o Port: Port through which the secured NUD NSOL message was sent.
o Timeout_NUD: Time remaining until the timeout for receiving the
NUD NADV expires, in which case the entry is removed from the
table.
o Any SEND-specific information required to validate the NUD NADV
message, such as the nonce used in the NUD NSOL message.
o (Optionally) Buffer of Pending Packets: packets received while
this port is in validation process. The availability of this
buffer is implementation-dependant. If the buffer does not
exists, packets are discarded until the port is validated.
NOTE: THE FOLLOWING PARAGRAPH IS FOR DEPLOYING A PER-SOURCE-ADDRESS
RATE LIMITING MECHANISM FOR PROTECTION AGAINST DoS. MAYBE A SIMILAR
MECHANISM COULD BE DEPLOYED IN A GENERAL (NON PER-SOURCE-ADDRESS)
BASIS. We can delete the stuff related with this.
Protection against DoS is provided by blocking temporarily ports for
Bagnulo & Garcia-Martinez Expires April 24, 2010 [Page 11]

Internet-Draft SEND SAVI October 2009
which NUD detection has been issued, but no response has been
obtained. This is to protect from an attack in which SEND SAVI
device is forced to spend significant CPU resources in generating a
secured NUD NSOL after receiving a data packet. Protection is
enforced by means of the Port Blocking table: packets received from a
port included in that table are discarded. Entries are removed from
the table when the Blocking Timeout expires. The Port Blocking table
contains the following information:
o Blocked Port
o Blocking Timeout
A Tested Ports list is used to keep trace of the ports from which
sending activity has been probed by the SEND SAVI deice with a NUD
NSOL, while the SEND SAVI device was in a given state. This list is
used to populate the Port Blocking table.
When no binding exists, the state for all source IPv6 addresses is
NO_BIND.
We next describe how different inputs are processed depending on the
state of the binding of the IP address. A simplified version can be
found at http://www.it.uc3m.es/~alberto/SEND_SAVI_state_machine.pdf.
NO_BIND
o Upon the reception of any packet through a Validating port VP, the
SEND SAVI device:
* Issues a secured NUD NSOL through port VP.
* Creates an entry associated to VP is created in the Pending NUD
NADV Messages table. The packet that triggered the SEND SAVI
validation process could be stored in the Buffer of Pending
Packets of VP. Timeout_NUD is set to TIMEOUT_NUD, and the
state is moved to TENTATIVE.
* Includes VP in the Tested Port list.
o Packets received from a Trusted port are forwarded to its
destination. These packets may come from a SEND SAVI device that
has securely validated the attachment of the host to its
Validating port according to SEND SAVI rules (unless the SEND SAVI
perimeter has been breached).
TENTATIVE
o If a validated NUD NADV message is successfully received through a
port registered in the Pending NUD NADV Messages table:
* The state is moved to VALID, with the port through which the
message has been received associated to the binding.
Timeout_valid is set to LIFETIME_VALID. Packets stored in the
Buffer of Pending Packets associated to the entry are
forwarded.
Bagnulo & Garcia-Martinez Expires April 24, 2010 [Page 12]

Internet-Draft SEND SAVI October 2009
* The rest of the ports included in the Tested Ports list (except
the validated one) are used to create new entries in the Port
Blocking table, with Blocking Timeout equal to
BLOCKING_TIMEOUT. The Tested Port list is cleared.
o If a packet is received from a Validating port VP', different to
any of the ports registered in the Pending NUD NADV Messages
table,
* A secured NUD NSOL is issued through VP', and a new entry is
created in the Pending NUD NADV Messages table for VP' with
Timeout_NUD for the entry set to TIMEOUT_NUD.
* VP' is included in the Tested Port list.
o Packets received from a Trusted port are forwarded. These packets
may come from a SEND SAVI device that has securely validated the
attachment of the host to its Validating port according to SEND
SAVI rules (unless the SEND SAVI perimeter has been breached).
The host could have move to a new location while packets are still
in transit.
o If Pending NUD NADVs Counter arrives to 0 (i.e. all pending NUDs
have expired without receiving any validated NUD NSOL message),
* The state is moved to NO_BIND and all parameters associated to
the binding cleared.
* All ports included in the Tested Ports list are used to create
new entries in the Port Blocking table, with Blocking Timeout
equal to BLOCKING_TIMEOUT. The Tested Port list is cleared.
VALID
o If a packet containing IPaddr as a source address arrives from
Validating port VP, the packet is forwarded. Note that in the
SEND SAVI case Timeout_valid for the entry MUST NOT be set to
LIFETIME_VALID (as occurred for the FCFS SAVI), since regular
sending of packets does not provide the required security, which
is achieved by performing secured NUD periodically with the
sending host.
o If Timeout_valid expires, a secured NUD NSOL message is sent
through port VP to the IPv6 address, and a new entry is created in
the Pending NUD NADV Messages table for VP with Timeout_NUD for
the entry set to TIMEOUT_NUD. The state is changed to TESTING.
o If a packet is received through a Trusted port, a secured NUD NSOL
is sent to VP and a new entry is created in the Pending NUD NADV
Messages table for VP with Timeout_NUD for the entry set to
TIMEOUT_NUD. The state is changed to TESTING. NOTE:In the
TESTING state, it is assumed that packets coming from Trusted
ports have been appropriately validated by a remote SEND SAVI
device, but this assumption is not considered so strong so as to
clear the binding in this SEND SAVI device (by moving the state to
NO_BIND) without an additional check. The check performed is a
NUD NSOL request to VP. In this way, legitimate hosts are
protected from being blocked by malicious hosts taking advantage
Bagnulo & Garcia-Martinez Expires April 24, 2010 [Page 13]

Internet-Draft SEND SAVI October 2009
of possible breaches in the perimeter.
o If a packet is received from a Validating Port VP', different from
the current Validating port for this binding:
* The SEND SAVI device issues two secured NUD NSOL messages, one
through VP', and another through VP. Entries for both ports VP
and VP' are created in the Pending NUD NADV Messages table with
Timeout_NUD for each entry set to TIMEOUT_NUD. The packet or
packets received from port VP' that triggered the SEND SAVI
validation process could be stored in the Buffer of Pending
Packets, to be forwarded when the identity of the sender were
validated. The state is changed to TESTING.
* VP' is included in the Tested Port list.
TESTING
It is worth to note that when the SEND SAVI device enters in the
TESTING state, the current Validating port is always under check
(through a NUD NSOL message). Other Validating ports may also be
tested when entering in this state. While testing, packets from the
current Validating port are forwarded. Packets coming from Trusted
ports are also forwarded. The detailed behavior is as follows:
o If a packet containing IPaddr as a source address arrives from
Validating port VP, the packet is forwarded. As a consequence of
this behavior, packets sent with a given IPv6 source address are
forwarded for a period equal to LIFETIME_VALID + TIMEOUT_NUD after
the state was moved to TENTATIVE, even if the host is no longer
connected to port VP.
o If a packet arrives from a Trusted port, the packet is forwarded.
This may occur because the host has moved to a port in another
SEND SAVI device. However, we still wait for the NUD NADV that
may come from VP, to provide protection against possible perimeter
breaches. Note that if no NUD NADV arrives from a Validating
port, the state moves to NO_BIND (which is the appropriate case
for a host that is connected through a different SEND SAVI
device).
o If a packet arrives from a Validating port VP' different to VP:
* The SEND SAVI device issues a secured NUD NSOL message through
port VP', and creates a new entry in the Pending NUD NADV
Messages table, setting the Timeout_NUD for the entry to
TIMEOUT_NUD. The state is not changed.
* VP' is included in the Tested Port list.
o If a validated NUD NADV message is received from any validating
port for which an entry in the Pending NUD NADV Messages table
exists:
* The Current Port is changed to this port, Timeout_Valid is set
to LIFETIME_VALID, and state is changed to VALID.
Bagnulo & Garcia-Martinez Expires April 24, 2010 [Page 14]

Internet-Draft SEND SAVI October 2009
* If the port is different to VP, the packets in the Pending
Packets Buffer are forwarded.
* All ports included in the Tested Ports list, except for the
port for which the NUD NADV was received, are used to create
new entries in the Port Blocking table, with Blocking Timeout
equal to BLOCKING_TIMEOUT. Note that VP (the current
Validating Port when the state was VALID) is never in the list.
* The Tested Port list is cleared.
o If the Pending NUD NADV Messages Counter is set to 0 (i.e. all the
entries in the Pending NUD NADV Messages table have been deleted
because its timers have expired):
* The state is moved to NO_BIND.
* All ports included in the Tested Ports list are used to create
new entries in the Port Blocking table, with Blocking Timeout
equal to BLOCKING_TIMEOUT. Note that VP (the current
Validating Port when the state was VALID) is never in the list.
* The Tested Port list is cleared.
o If Timeout_valid for the Validating port VP expires, no action is
taken
5. Performance benefits of the SEND SAVI perimetrical deployment
It is worth to note that the perimetrical deployment result in much
lower computing, memory and bandwidth requirements, and lower delay
of the validation process, compared to a deployment scenario without
defined borders (i.e. in which all ports are Validating). To
understand this, consider the scenario depicted in the next figure,
in which no perimeter is considered, so all ports behave as
Validating.
+--+ +--+ +--+ +--+
|H1| |H2| |H3| |R1|
+--+ +--+ +--+ +--+
| | | |
| | | |
+-1-----2-+ +---------+ +-1-----2-+
| SEND- | | SEND- | | SEND- |
| SAVI1 | | SAVI2 | | SAVI3 |
+-3--4----+ +-1-----2-+ +--3------+
| | | |
------------------- ---------------
Suppose node H1 wants to communicate with node H3, and no state
exists for H1 in neither of the SEND SAVI switches. H1 sends a data
packet to H3. This packet arrives to port 1 of SEND-SAVI1. SEND-
SAVI1 then issues a secured NUD NSOL message towards H1, with the RSA
Bagnulo & Garcia-Martinez Expires April 24, 2010 [Page 15]

Internet-Draft SEND SAVI October 2009
option signing the message (which cannot be reused, since the nonce
and timestamp should vary for each message). H1 answers to the
received NSOL message issuing a secured NUD NADV message to SEND-
SAVI1. Upon the reception and validation of the NUD NADV, SEND-SAVI1
updates its SEND SAVI DB and forwards subsequent packets (maybe the
initial one, if it implements a Buffer of Pending Packets).
Now a packet arrives to SEND-SAVI2, which does not have a binding for
source address H1, so it generates a secured NUD NSOL message towards
H1, that must be validated by H1, answered with a NUD NADV (with
different nonce, and possibly timestamp, than the NUD NADV for SEND-
SAVI1), and validated by SEND-SAVI2. The same would be required for
SEND-SAVI3.
Therefore H1 will receive and must validate as many NUD NSOL messages
as new SEND SAVI devices being traversed by a packet. Additionally,
it must secure and generate as many NUD NSOL messages as new SEND
SAVI devices being traversed. Initial communication delay depends on
the time to sequentially perform each of this operations.
In a perimetrical deployment, only SEND-SAVI1 performs validation,
and it is the only switch to perform forwarding decisions according
to per-packet inspection of the source address of H1, since the rest
of SEND SAVI devices forwards packets received from Trusted ports
without further analysis. Additionally, interaction with H1 is
reduced to one NUD message exchange.
6. Interaction with non-SEND hosts
TBD
7. 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.
SEND SAVI improves protection compared to conventional SAVI, as a
result of the increased ability of SEND hosts to prove address
ownership.
Bagnulo & Garcia-Martinez Expires April 24, 2010 [Page 16]

Internet-Draft SEND SAVI October 2009
A critical security consideration regarding to SEND SAVI deals with
the need of proper configuration of the roles of the ports in a SEND
SAVI deployment scenario. Regarding to security, the main
requirement is that ports defining the protected perimeter SHOULD be
configured as Validating. Not doing so will generate security
breaches through which an attacker could send packets using any
source address, regardless of the bindings established in other SEND
SAVI devices. However, SEND SAVI is designed to allow even in this
case communication for legitimate users. The worst case for the
misconfiguration of the perimeter is then that two hosts may use the
same source IPv6 address. The reasons for having a misconfigured
perimeter, apart from initial misconfiguration, are the dynamic
operations performed by layer-2 routing mechanisms, for example, as a
result of a failure in a link or switching device. To prevent the
security risks associated, in the case of changes in the topology of
the SEND SAVI devices, all ports of a SEND SAVI device MAY be changed
automatically to Validating. Note that neither connectivity nor the
protection offered are compromised by operating in a mode in which
all ports of the SEND SAVI devices operate in Validating mode (only
performance is affected by this setting).
SEND SAVI design enforces anti-reply protection by relying only in
solicited messages that must honor appropriate nonce treatment
defined in SEND. SEND SAVI devices rely in information received from
Validating ports (i.e. outside the protected domain) only after
performing secured and validated RSOL/RADV exchange for router
information, and NUD NSOL/NADV exchange for host information.
Certificate distribution in SEND (CPS/CPA) is not protected by
neither nonce nor timestamp, but it can be argued that the risk of
replying this information is not relevant for SAVI operation.
It is worth to note that the potential of Denial of Service attacks
against the SEND SAVI network is increased due to the use of costly
cryptographic operations in order to validate the address of the
hosts. An attacker could generate packets using new source addresses
in order to make the closest SEND SAVI device spend CPU time to
generate a NUD NSOL. This attack can be used to drain CPU resources
of SEND SAVI devices with a very low cost for the attacker. In order
to solve this problem, ports for which packets with a given source
address have been sent, but no binding was created, are blocked for
some time (TIMEOUT_BLOCKING). This means that a legitimate user
moving to a new port may have to wait up to TIMEOUT_BLOCKING time
until communication is allowed. Note that a similar mechanism could
be used in a pure port basis (i.e. not related with a specific source
address).
Another alternative for the attacker could be to generate packets
that trigger SEND SAVI validation, and to answer the NUD NSOL with a
Bagnulo & Garcia-Martinez Expires April 24, 2010 [Page 17]

Internet-Draft SEND SAVI October 2009
valid response (provided it has generated private/public key pairs
for the attack), in order to waste memory from the SEND SAVI device.
This attack seems to be less attractive compared to the case in which
the attacker does not need to waste its own CPU power. However, it
should also be protected, since a host can have much more computing
power to perform cryptographic operations than a switching device.
Apart from rate limitation measured to protect SEND SAVI computing
resources, a mechanism similar to the one proposed for
[I-D.bagnulo-savi-fcfs], in which newer entries are overwritten
instead of older ones, in the case that memory is exhausted, could be
enforced.
8. Acknowledgments
Thanks to Ana Kukec for her review and comments on this document.
Marcelo Bagnulo is partly funded by Trilogy, a research project
supported by the European Commission under its Seventh Framework
Program.
Alberto Garcia-Martinez is partly funded by T2C2, a Spanish R&D
project.
9. 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.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[I-D.bagnulo-savi-fcfs]
Nordmark, E. and M. Bagnulo, "First-Come First-Serve
Source-Address Validation Implementation",
draft-bagnulo-savi-fcfs-01 (work in progress),
January 2009.
Bagnulo & Garcia-Martinez Expires April 24, 2010 [Page 18]