One document matched: draft-ietf-savi-send-03.txt
Differences from draft-ietf-savi-send-02.txt
Network Working Group M. Bagnulo
Internet-Draft A. Garcia-Martinez
Intended status: Standards Track UC3M
Expires: November 14, 2010 May 13, 2010
SEND-based Source-Address Validation Implementation
draft-ietf-savi-send-03
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
higher granularity on the control of the source addresses used.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on November 14, 2010.
Copyright Notice
Copyright (c) 2010 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Bagnulo & Garcia-Martinez Expires November 14, 2010 [Page 1]
Internet-Draft SEND SAVI May 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Design considerations . . . . . . . . . . . . . . . . . . . . 3
2.1. Scope of SEND SAVI . . . . . . . . . . . . . . . . . . . . 3
2.2. Constraints for SEND SAVI . . . . . . . . . . . . . . . . 4
2.3. Address ownership proof for SEND SAVI . . . . . . . . . . 4
3. SEND SAVI topology and port configuration . . . . . . . . . . 4
3.1. SEND SAVI enforcement perimeter . . . . . . . . . . . . . 4
3.2. SEND SAVI port configuration guidelines . . . . . . . . . 7
4. SEND SAVI specification . . . . . . . . . . . . . . . . . . . 7
4.1. SEND SAVI Data structures . . . . . . . . . . . . . . . . 8
4.2. Obtaining Certification Paths . . . . . . . . . . . . . . 9
4.3. Authorized Router Discovery and On-link prefix
discovery . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4. SEND SAVI algorithm . . . . . . . . . . . . . . . . . . . 10
4.4.1. Traffic processing . . . . . . . . . . . . . . . . . . 10
5. Performance benefits of the SEND SAVI perimetrical
deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
8. Normative References . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Bagnulo & Garcia-Martinez Expires November 14, 2010 [Page 2]
Internet-Draft SEND SAVI May 2010
1. 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 considerations
2.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.
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.
Bagnulo & Garcia-Martinez Expires November 14, 2010 [Page 3]
Internet-Draft SEND SAVI May 2010
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
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 configuration
3.1. SEND SAVI enforcement perimeter
SEND SAVI is designed to provide perimetrical protection. This
deployment model is similar to the one presented in the SAVI
framework document[I-D.vogt-savi-framework]. This design allows
reducing computing and state requirements in SEND SAVI devices by
performing the cryptographic validations required to create the
Bagnulo & Garcia-Martinez Expires November 14, 2010 [Page 4]
Internet-Draft SEND SAVI May 2010
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 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 maily 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
certificates, router information and Neighbor Advertisements for
Duplicate Address Detection (DAD NADV).
The following figure shows a typical topology involving trusted and
untrusted infrastructure.
Bagnulo & Garcia-Martinez Expires November 14, 2010 [Page 5]
Internet-Draft SEND SAVI May 2010
+--+ +--+ +--+ +--+
|H1| |H2| |H3| |R1|
+--+ +--+ +--+ +--+
| | | |
+----------SEND SAVI-ENFORCEMENT-PERIMETER------------+
| | | | | |
| +-1-----2-+ +-1-----2-+ |
| | SEND- | | SEND- |
| | SAVI1 | | SAVI2 | |
| +-3--4----+ +--3------+ |
| | | +--------------+ | |
| | +----------| |--------+ |
| | | SWITCH-A | |
| | +----------| |--------+ |
| | | +--------------+ | |
| +-1--2----+ +--1------+ |
| | SEND- | | SEND- | |
| | SAVI3 | | SAVI4 | |
| +-3---4---+ +----4----+ |
| | | | |
+----------SEND SAVI-ENFORCEMENT-PERIMETER------------+
| | |
+--+ +--+ +---------+
|R2| |H4| |SWICTH-B |
+--+ +--+ +---------+
| |
+--+ +--+
|H5| |H6|
+--+ +--+
Trusted ports are used for connections with trusted infrastructure,
including the communication between SEND SAVI devices and the
communication with other switches which are not SEND SAVI devices,
but they are only connected to trusted infrastructure. (i.e. other
SEND SAVI devices, routers or other trusted nodes).
Port 3 of SEND-SAVI1 and port 1 of SEND-SAVI3 are trusted because the
connect two SAVI devices. Port 4 of SEND-SAVI1, port 3 of SEND-
SAVI2, port 2 of SEND-SAVI3 and port 1 of SEND-SAVI4 are trusted
because they connect to SWITCH-A to which only trusted nodes are
connected.
Validating ports are used for connection with non-trusted
infrastructure. Therefore, hosts are normally connected to
validating ports. Non-SEND SAVI switches that are outside of the
SAVI enforcement perimeter also are connected through validating
port. In particular, non-SEND SAVI devices which connect directly to
Bagnulo & Garcia-Martinez Expires November 14, 2010 [Page 6]
Internet-Draft SEND SAVI May 2010
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 (Router Advertisement),
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 specification
Bagnulo & Garcia-Martinez Expires November 14, 2010 [Page 7]
Internet-Draft SEND SAVI May 2010
4.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 with the
currently used IPv6 source addresses. The SEND SAVI DB is populated
with the contents of successfully validated SEND messages. So each
entry contains the following information:
o IP source address
o Layer-2 Validating port to which the host is connected.
o Timeout_Valid
SEND SAVI also needs the trust anchors (see [RFC3971]) 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. 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
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. 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
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 Lifetime
SEND SAVI keeps a list of the authorized routers, only for those
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 to which the router is connected.
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
Bagnulo & Garcia-Martinez Expires November 14, 2010 [Page 8]
Internet-Draft SEND SAVI May 2010
secured NSOL (Neighbor Solicitation), RSOL (Router Solicitation) or
CPS (Certificate Path Solicitation) messages. Note that when the
SEND SAVI device configures this address, it must follow the same
rules as regular SEND hosts (such as using secured NSOL messages to
perform DAD, etc.).
4.2. 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].
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.3. 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
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.
Bagnulo & Garcia-Martinez Expires November 14, 2010 [Page 9]
Internet-Draft SEND SAVI May 2010
4.4. SEND SAVI algorithm
4.4.1. Traffic processing
In this section we describe how packets - with the exceptions
considered in the previous sections, such as RADV, CPS or CPA
(Certificate Path Advertisement) 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.4.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
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
Bagnulo & Garcia-Martinez Expires November 14, 2010 [Page 10]
Internet-Draft SEND SAVI May 2010
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 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_DAD
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 (Optional) 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.
Protection against DoS is provided by blocking temporarily ports for
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.
Bagnulo & Garcia-Martinez Expires November 14, 2010 [Page 11]
Internet-Draft SEND SAVI May 2010
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 If a validated DAD NSOL message is received from a Validating port
VP, the SEND SAVI device forwards this message to all appropriate
ports (including other Validating ports), sets Timeout_DAD timer
to TIMEOUT_DAD, includes VP in the Tested Port list, stores all
the information required for future validation of the
corresponding DAD NADV message (such as the nonce of the message)
and changes the state to TENTATIVE_DAD.
o Upon the reception of any other 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_DAD
In this state, the host at VP has issued a secured DAD NSOL. While
it is waiting for a possible DAD NADV, and therefore its address is
tentative, the host does not response to NSOL messages, as it is
mandated by [RFC4862], so validation of the address by means of a NUD
NSOL/NADV exchange is not possible. In this state the SEND SAVI
device waits until the host has configured its address to check later
(by moving to TESTING state), with a NUD NSOL, if the host is the
legitimate user of the address. The check performed in the TESTING
state provides protection against reply attacks.
o If a validated DAD NADV is received from any port, the binding
cannot be configured for port VP. Therefore, the port VP is
included in the Port Blocking table, with Blocking Timeout equal
to BLOCKING_TIMEOUT, and the state is changed to NO_BIND. Note
that protection against reply attacks come from requiring the SEND
SAVI device to check for the DAD NSOL nonce in the DAD NADV
message received.
Bagnulo & Garcia-Martinez Expires November 14, 2010 [Page 12]
Internet-Draft SEND SAVI May 2010
o If Timeout_DAD expires, then it is assumed that no other host has
configured this address. Therefore, the Validating port VP could
be bound to this IPv6 address. However, to provide additional
protection against reply attacks, the SEND SAVI device issues a
secured NUD NSOL to the Validating port, Timeout_NUD is set to
TIMEOUT_NUD, and the state is changed to TESTING. During the IPv6
address is in the TESTING state, packets sent from port VP are
forwarded. If the NUD test fails, the state is moved to NO_BIND.
Note that a reply attack can success in this case in allowing
packets to be sent from a port for TIMEOUT_NUD time.
o If a packet different from DAD NADV is received from any port, the
packet is discarded.
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.
* 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
Bagnulo & Garcia-Martinez Expires November 14, 2010 [Page 13]
Internet-Draft SEND SAVI May 2010
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
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
Bagnulo & Garcia-Martinez Expires November 14, 2010 [Page 14]
Internet-Draft SEND SAVI May 2010
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.
* 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,
Bagnulo & Garcia-Martinez Expires November 14, 2010 [Page 15]
Internet-Draft SEND SAVI May 2010
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
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.
Bagnulo & Garcia-Martinez Expires November 14, 2010 [Page 16]
Internet-Draft SEND SAVI May 2010
6. 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.
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 aims to enforce 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
Bagnulo & Garcia-Martinez Expires November 14, 2010 [Page 17]
Internet-Draft SEND SAVI May 2010
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
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.ietf-savi-fcfs], in which newer entries are overwritten instead
of older ones, in the case that memory is exhausted, could be
enforced.
7. 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.
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.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Bagnulo & Garcia-Martinez Expires November 14, 2010 [Page 18]
Internet-Draft SEND SAVI May 2010
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[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.
[I-D.vogt-savi-framework]
Vogt, C., "Source Address Validation Improvement Protocol
Framework", draft-vogt-savi-framework-01 (work in
progress), October 2009.
[I-D.ietf-savi-fcfs]
Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS-
SAVI: First-Come First-Serve Source-Address Validation for
Locally Assigned Addresses", draft-ietf-savi-fcfs-03 (work
in progress), May 2010.
Authors' Addresses
Marcelo Bagnulo
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
SPAIN
Phone: 34 91 6248814
Email: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es
Alberto Garcia-Martinez
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
SPAIN
Phone: 34 91 6248782
Email: alberto@it.uc3m.es
URI: http://www.it.uc3m.es
Bagnulo & Garcia-Martinez Expires November 14, 2010 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 08:45:30 |