[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-bagnulo-savi-send) 00 01 02 03 04 05 06 07 08 09 10 11 RFC 7219

Network Working Group                                         M. Bagnulo
Internet-Draft                                        A. Garcia-Martinez
Intended status: Standards Track                                    UC3M
Expires: April 28, 2011                                 October 25, 2010


          SEND-based Source-Address Validation Implementation
                        draft-ietf-savi-send-04

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 April 28, 2011.

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 April 28, 2011               [Page 1]

Internet-Draft                  SEND SAVI                   October 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Non-normative Background to SEND SAVI  . . . . . . . . . . . .  3
     2.1.  Address Validation Scope . . . . . . . . . . . . . . . . .  3
     2.2.  SEND SAVI Enforcement Perimeter  . . . . . . . . . . . . .  4
     2.3.  Binding Creation for SEND SAVI . . . . . . . . . . . . . .  5
   3.  Perimeter Configuration Guidelines for SEND SAVI . . . . . . .  6
   4.  SEND SAVI Specification  . . . . . . . . . . . . . . . . . . .  9
     4.1.  SEND SAVI Data Structures  . . . . . . . . . . . . . . . .  9
     4.2.  SEND SAVI Device Configuration . . . . . . . . . . . . . . 11
     4.3.  SEND SAVI Algorithm  . . . . . . . . . . . . . . . . . . . 11
       4.3.1.  Traffic Processing . . . . . . . . . . . . . . . . . . 11
     4.4.  VLAN Support . . . . . . . . . . . . . . . . . . . . . . . 22
     4.5.  Protocol Constants . . . . . . . . . . . . . . . . . . . . 22
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 25
   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 25
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
































Bagnulo & Garcia-Martinez  Expires April 28, 2011               [Page 2]

Internet-Draft                  SEND SAVI                   October 2010


1.  Introduction

   This memo describes SEND SAVI (Source-Address Validation
   Implementation), a mechanism to provide source address validation for
   IPv6 networks using the SEND protocol [RFC3971].  The proposed
   mechanism is intended to complement ingress filtering techniques to
   provide a higher granularity on the control of the source addresses
   used.

   SEND SAVI uses DAD_NSOL (Duplicate Address Detection Neighbor
   Solicitation), DAD_NADV (DAD Neighbor Advertisement), NUD_NSOL
   (Neighbor Unreachability Detection NSOL) and NUD_NADV (NUD Neighbor
   Advertisement) messages to validate the address ownership claim of a
   node.  Ports and other layer-2 binding anchors can be associated to
   the IPv6 address of the neighbor, so that source address validation
   could be performed.

   Scalability of a distributed SAVI system comprised of multiple SEND
   SAVI devices is preserved by means of a deployment scenario in which
   SEND SAVI devices form a "protection perimeter" and validation is
   only performed when the packet ingress to the protection perimeter.

   The SEND SAVI specification, as defined in this document, is limited
   to links in which every IPv6 host and every IPv6 router uses the SEND
   protocol [RFC3971] to protect the exchange of Neighbor Discovery
   information.  However, SEND SAVI is designed to be deployed in
   existing SEND 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.

   An overview of the general framework about Source Address Validation
   Implementation is presented in [I-D.ietf-savi-framework].


2.  Non-normative Background to SEND SAVI

2.1.  Address Validation Scope

   The application scenario of SEND SAVI is limited to the local link.
   This means that the goal of SEND SAVI is to verify that the source
   address of the packets generated by the hosts attached to the local
   link have not been spoofed.

   In a link there usually are hosts and routers attached.  Hosts



Bagnulo & Garcia-Martinez  Expires April 28, 2011               [Page 3]

Internet-Draft                  SEND SAVI                   October 2010


   generate packets with their own addresses 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 has 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
   forwarded by authorized routers.  However, SEND SAVI does not provide
   the means to verify if a given 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.  Hence, the security level is increased by
   the use of both SAVI and ingress filtering.

2.2.  SEND SAVI Enforcement Perimeter

   SAVI devices prevent address spoofing by verifying that a layer-2
   anchor is associated to the IPv6 address used as source address for
   the packets being exchanged.  The layer-2 anchor, which must be
   difficult to spoof can be the port of the layer-2 switch through
   which a packet containing a given IPv6 address is received, or a
   layer-2 address.  In this document we assume that MAC-specific
   mechanisms to secure data packets, such as IEEE 802.1AE, are not
   generally available, so SEND SAVI is defined to operate with ports as
   the only available layer-2 anchor.

   In order to reduce computing and state requirements in SEND SAVI
   devices, SEND SAVI is designed according to the perimetrical
   protection deployment model presented in the SAVI framework document
   [I-D.ietf-savi-framework].  In this model, source address validation
   is performed only when packets enter in a protected realm defined
   through the protection perimeter.  This perimeter must be deployed in
   such a way that packets for which validation must be performed can
   only enter in the protected realm through a port belonging to the
   border performing the validation.  The perimeter is defined by
   appropriate configuration of the roles of each port, which can be
   Validating ports and Trusted ports.  Validating ports are the ports
   forming the protection perimeter, so they are the ports in which
   validation for incoming packets is performed.  Trusted ports (TPs)
   are those in which SEND SAVI filtering is not performed.





Bagnulo & Garcia-Martinez  Expires April 28, 2011               [Page 4]

Internet-Draft                  SEND SAVI                   October 2010


2.3.  Binding Creation for SEND SAVI

   Filtering is performed according to the bindings existing between a
   layer-2 anchor and an IPv6 address.  These bindings should allow
   legitimate nodes to use the binding IPv6 address as source address,
   and prevent illegitimate nodes to do so.  When a protection perimeter
   is defined, the binding must be created for a port of the border to
   which a legitimate node is attached to, and must not be created in
   other case.

   SEND provides tools to assure that a ND message containing a CGA
   option and signed by a RSA option has been generated by the
   legitimate owner of the CGA IPv6 address.  It also provides tools to
   verify that a RADV message signed by a RSA option with a key bounded
   to a CGA or a certificate has been generated by a legitimate router.

   SEND SAVI benefits from SEND ability to prove address ownership and
   router authorization to create SAVI bindings.  SEND SAVI assumes that
   a successfully validated SEND message ingressing to the protection
   perimeter from a validating port guarantees that the host
   legitimatelly issuing the message is connected to that port.  In this
   case, a binding for the host to this layer-2 port is created.

   The events that trigger the binding creation process in a Validating
   port of a SEND SAVI device are:
   o  The reception from a Validating port of a DAD_NSOL message,
      indicating the attempt of a node to configure an address.  This
      may occur when a node configure an address after being idle for
      sometime, or because the node has changed the physical attachment
      point to the layer-2 infrastructure.
   o  The reception from a Validating port of any other packet
      (including data packets) with a source address for which no
      binding exists.  This would occur if a DAD_NSOL message was lost
      before arriving to the Validating port, or if a node has changed
      the physical attachment point to the layer-2 infrastructure
      without issuing a DAD_NSOL message.

   When the binding creation process is triggered, the SEND SAVI device
   has to assure that the host for which the binding is to be created is
   the legitimate owner of the address.  For a binding creation process
   initiated by a DAD_NSOL exchange, the messages to consider for
   address ownership validation are other DAD_NSOL messages arriving
   from other locations or a DAD_NADV message indicating that other host
   has configured the address before.  For other packets initiating the
   creation of the binding, the SEND SAVI device asks the host to prove
   address ownership by issuing a NUD_NSOL which has to be answered by a
   NUD_NADV by the probed node.  Note that it is not required to ask
   other SEND SAVI devices, as it is done in the non-SEND FCFS



Bagnulo & Garcia-Martinez  Expires April 28, 2011               [Page 5]

Internet-Draft                  SEND SAVI                   October 2010


   specification [I-D.ietf-savi-fcfs], since in this case a SEND host
   can prove authoritatively the ownership of its address.

   Bindings are refreshed periodically by means of a NUD_NSOL message
   issued by the SEND SAVI device through the bounded port which has to
   be answered by a valid NUD_NADV message by the node for which the
   binding exist.

   SEND SAVI could be sensible to replay attacks, i.e. situations in
   which a secured SEND message is replayed by a non-legitimate node.
   For example, a node could immediatelly re-inject a valid SEND message
   being received from other node, to force the creation of a binding
   for which it is not authorized.  SEND provides some means to prevent
   the replaying of ND messages, in particular, the use of nonces to
   validate advertisements that were previously solicited, and the use
   of timestamps to validate solicitation messages and unsolicited
   advertisements.  However, the emphasis for SEND anti-replay
   protection is to assure that confidence in some information (for
   example, the relationship between an IPv6 address and a layer-2
   address) is not hold for more time than reasonable, while in SEND
   SAVI truthful information (in SEND sense, like the relationship of an
   IPv6 address and a layer-2 address) can be used to create a SAVI
   binding in a time span shorter than the time reasonable to consider
   the information aged.  As a consequence, SEND SAVI relies only in
   messages with a low chance of being replayed from different ports to
   the legitimate one and still being considered valid by SEND.  The
   messages being used by SEND SAVI to create bindings are:
   o  Unsolicited DAD_NSOL messages.  According to the SEND SAVI
      specification Section 4.3.1.1 These messages can only be forwarded
      to ports through which a previous binding for the same IPv6
      address existed.
   o  NUD_NADV messages in response to a NUD_NSOL sent by the SEND SAVI
      device, both exchanged through the same Validating port.  In this
      case, anti-replay protection is assured by nonce exchange.  This
      message exchange is also used to refresh the binding.

   Any validated RADV can be used to determine that a node for which a
   binding exists in a Validating port is a router, since the
   topological part of the binding has been assured before.  In
   addition, the acquisition of prefix information, required to
   determine local and transit traffic, is not tied to topological
   considerations too, so for this case regular SEND validating rules
   are applied.


3.  Perimeter Configuration Guidelines for SEND SAVI

   As it has been discussed before, the perimeter is defined by



Bagnulo & Garcia-Martinez  Expires April 28, 2011               [Page 6]

Internet-Draft                  SEND SAVI                   October 2010


   appropriate port configuration.  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 (VPs) are those in which SEND SAVI filtering and
      binding creation is performed.
   o  Trusted ports (TPs) are those in which neither SEND SAVI filtering
      nor binding creation are 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, prefix information and Neighbor
      Advertisements for Duplicate Address Detection (DAD_NADV).

   The following figure shows a typical topology involving trusted and
   untrusted infrastructure.


                                                   +--------+
         +--+   +--+                          +--+ | +--+   |
         |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|                          |SWITCH-B |
      |  +--+ | +--+                          +---------+
      |       |                                 |    |
      +-------+                               +--+  +--+
                                              |H5|  |H6|
                                              +--+  +--+





Bagnulo & Garcia-Martinez  Expires April 28, 2011               [Page 7]

Internet-Draft                  SEND SAVI                   October 2010


   Trusted ports are used for connections with trusted infrastructure,
   including the communication between SEND SAVI devices, the
   communication with other switches which are not 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.  Port 2 of SEND-SAVI2 and port 3 of SEND-SAVI3 are trusted
   ports, because they connect to routers.

   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
   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.

   SEND SAVI requires all devices performing SAVI function to implement
   SEND SAVI (for example, coexistence with non-SEND aware FCFS SAVI
   [I-D.ietf-savi-fcfs] switches is not allowed).

   The detailed 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 node 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.  However, the SEND SAVI specification also allows the
      routers to be connected to Trusted ports, as they are assumed to
      be part of the trusted infrastructure.  When connected through a
      trusted port, a router can generate traffic with any source
      address, even those belonging to the link, while when connected
      through a Validating port it can only send traffic using off-link
      source addresses, or its own source addresses.  When routers are
      connected to Validating, authorization for the routing function is



Bagnulo & Garcia-Martinez  Expires April 28, 2011               [Page 8]

Internet-Draft                  SEND SAVI                   October 2010


      bound to the router itself, instead of being bound to a port
      configured in a switch.
   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

4.1.  SEND SAVI Data Structures

   The following data structures are defined for SEND SAVI operation:

   SEND SAVI Port list.  This structure defines an entry per port in the
   SAVI device.  Each entry indicates the role configured for the port
   (Trusted port or Validating port).  In addition, only for Validating
   ports, the entry indicates the presence or absence of a router
   connected through the port has been stated by successful validation
   of a RADV message received from this port.  This data structure is
   used to determine the filtering behavior for each port when local-
   link and off-link traffic is received.  If the port is a Trusted
   Port, both local-link and off-link traffic coming from the port is
   accepted.  If the port is a Validating port but not a Routing port,
   then only local-link traffic coming from the port for which a binding
   exists is accepted.  If the port is a Validating port and a Routing
   port, then off-link traffic coming from the port is accepted, but
   only local-link traffic coming from the port for which a binding
   exists is accepted.

   Each entry of the SEND SAVI Port list contains the following
   information:
   o  Layer-2 Validating port
   o  Configured port role (either Trusted port or Validating port).
      The default configuration is Validating port.





Bagnulo & Garcia-Martinez  Expires April 28, 2011               [Page 9]

Internet-Draft                  SEND SAVI                   October 2010


   o  Router port bit.  This value is only meaningful for ports with a
      configured port role set to Validating port.  It indicates whether
      a RADV message received from the port has been successfully
      validated, indicating that a router is connected to the port.  For
      this bit to be set, an entry containing this layer-2 port MUST
      exist in the SEND SAVI Address table for an IP address of an entry
      in the SEND SAVI Router table.

   SEND SAVI Address list.  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 Address table.  The SEND SAVI
   Address table contains one entry for each of the IPv6 source
   addresses in use on a Validating port of the SEND SAVI device.  The
   SEND SAVI Address list is populated with the contents of successfully
   validated SEND messages.  Each entry contains the following
   information:
   o  IP source address
   o  Layer-2 Validating port to which the host is connected.
   o  Lifetime
   o  Status: TENTATIVE_DAD, TENTATIVE_NUD, VALID, TESTING_VP,
      TESTING_VP'.

   SEND SAVI Prefix list.  In addition to this, a SEND SAVI device needs
   to know which are the link prefixes in order to identify local and
   off-link traffic.  This information is obtained from validated RADV
   messages.  This information is not specific to a given port.  Note
   that the information in this table is equivalent to the Prefix List
   conceptual data structure defined in [RFC4861].  The SEND SAVI Prefix
   list contains one entry per prefix in use, as follows:
   o  Prefix
   o  Lifetime

   SEND SAVI Router list.  SEND SAVI keeps a table with one entry for
   each authorized router in use connected to a Validating port of the
   SAVI device.  In particular, it contains the address for which a
   successfully validated RADV has been received.  The information in
   this table is used to populate the SEND SAVI port table when at least
   one router has been validated in a layer-2 Validating port (the
   layer-2 port can be obtained by looking-up for the IPv6 address of
   the router in the SEND SAVI Address list).  It can also be used to
   issue a RSOL in case the entry is about to expire, in order to ensure
   that the node is still performing as a router.  Note that the
   information in this table is equivalent to the Default Router List
   conceptual data structure defined in [RFC4861].  The information
   stored in the table is the following:





Bagnulo & Garcia-Martinez  Expires April 28, 2011              [Page 10]

Internet-Draft                  SEND SAVI                   October 2010


   o  Router IPv6 address
   o  Lifetime

4.2.  SEND SAVI Device Configuration

   In order to perform SEND SAVI operation, some basic parameters of a
   SEND SAVI device have to be configured.

   A SEND SAVI device operates as a full-fledged SEND node in some
   cases: it may generate NUD_NSOL, RSOL or CPS messages.  Therefore, a
   SEND SAVI device
   o  MUST be configured with a valid CGA address.  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.)
   o  MUST be configured with at least one Trust anchor to validate the
      Certification Paths that authorizes route operation.
   o  MUST be configured with Certification Paths, either manually or by
      means of issuing Certification Path Solicitation messages, as
      detailed in the SEND specification [RFC3971].

   In addition, the port role for each port of the SEND SAVI Port list
   SHOULD be configured.  Otherwise, every port would be labeled as
   Validating port, and performance may be degraded, as discussed in
   [I-D.ietf-savi-framework].

4.3.  SEND SAVI Algorithm

4.3.1.  Traffic Processing

   In this section we describe how packets 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 included (transit traffic).  A special case of local traffic is
   the traffic destined to the SEND SAVI device itself, either
   specifically, or through a multicast address to which the SEND SAVI
   device is registered (such as the all-nodes address, ff02::1).

   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 packet is only forwarded if the port appears with the
      Routing bit set in the SEND SAVI Port list, indicating that a
      router has been validated through SEND procedures at this port.
      If transit traffic is received from a Validating port, and the



Bagnulo & Garcia-Martinez  Expires April 28, 2011              [Page 11]

Internet-Draft                  SEND SAVI                   October 2010


      port does not appear with the Routing bit set in the SEND SAVI
      Port list, the SAVI SEND device SHOULD send a RSOL message through
      the considered port.

   Processing of traffic addressed to the SEND SAVI device itself occurs
   as follows:
   o  Packets received from Trusted ports are not filtered.  In
      particular, if a successfully validated CPA message is received
      through a Trusted port, the certificate information is accepted by
      the SEND SAVI device.  If a successfully validated RADV message is
      received through a Trusted port, the SEND SAVI Prefix list in the
      SEND SAVI device is updated accordingly.
   o  NUD_NADV messages corresponding to SEND SAVI operation are
      processed according to the specification of Section 4.3.1.1.
   o  Packets received from Validating ports are only processed by the
      SEND SAVI device if a binding exists for the source IPv6 address
      of the packet, and the state for the binding is VALID or TESTING
      (see next section).  In particular, If a successfully validated
      RADV message is received through a Trusted port, the SEND SAVI
      Prefix list in the SEND SAVI device is updated accordingly.  The
      Router bit of the SEND SAVI Port list is set only if the
      destination address of the RADV message is not a multicast
      address.  If a SEND SAVI device receives a RADV sent to a
      multicast address, it SHOULD issue a RSOL message to the port
      through which this message has been received.

   We next consider how local traffic is processed.

4.3.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 same port
      through which the corresponding NUD_NSOL message was issued, and
      the NUD_NADV message has been validated according to [RFC3971] to



Bagnulo & Garcia-Martinez  Expires April 28, 2011              [Page 12]

Internet-Draft                  SEND SAVI                   October 2010


      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).

   We use VP to refer to a Validating port, and TP for Trusted port.

   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 IPaddr IPv6 address
   associated to the state machine.

   The possible states are
   o  NO_BIND.  This state represents that no binding exists for the
      address.  This is the state for all addresses unless a binding is
      explicitly created.
   o  TENTATIVE_DAD.  This state is reached when the SEND SAVI device
      has received a validated DAD_NSOL message.  The SEND SAVI device
      waits for a possible DAD_NADV.  Packets with the source address of
      the binding are not forwarded.
   o  TENTATIVE_NUD.  A packet different from a valid DAD_NSOL message
      has been received from port VP and the SEND SAVI device has sent a
      NUD_NSOL message to the port.  Packets with the source address of
      the binding are not forwarded.
   o  VALID.  The binding for the source address has been verified.
      Packets with the source address of the binding are forwarded.
   o  TESTING_VP.  The lifetime of the binding has expired so SEND SAVI
      device has sent a NUD_NSOL message to the port, or a DAD_NSOL
      coming from other SEND SAVI device has been received.  The SEND
      SAVI device waits for a validated NADV.  Packets with the source
      address of the binding are allowed to be forwarded.
   o  TESTING_VP'.  A validated DAD_NSOL message has been received from
      a Validating port of the SEND SAVI device.  The device waits for a
      DAD_NADV coming from port VP, or changes the binding to port VP'
      if no response is received after TENT_LT milliseconds.  Packets
      coming from port VP with the source address of the binding are
      allowed to be forwarded.

   The states can be classified into forwarding states, i.e. states in
   which packets coming for the port associated to the IPv6 address
   different to the ones used for signalling are forwarded (VALID,
   TESTING_VP and TESTING_VP'), and non-forwarding states, i.e. states
   in which packets coming from the port associated to the IPv6 address
   different to the ones used for signalling are not forwarded (NO_BIND,
   TENTATIVE_DAD and TENTATIVE_NUD).

   The state machine defined for SEND SAVI operation adheres to the
   following design guidelines:



Bagnulo & Garcia-Martinez  Expires April 28, 2011              [Page 13]

Internet-Draft                  SEND SAVI                   October 2010


   o  The only events which triggers state changes from forwarding to
      non-forwarding states and vice versa are the reception of
      DAD_NSOL, DAD_NADV and NUD_NADV, or the expiration of a timer.
      Besides, DAD_NADV and NUD_NADV are only processed when expected as
      a response to a DAD_NSOL or a NUD_NSOL message.  The other
      possible input to consider is 'any other packet', which could
      generate changes to states belonging to the same class as the
      original state (i.e. when 'any other packet' is received, the
      state cannot move from being forwarding to non-forwarding and vice
      versa).  Note that non-validated SEND messages always belong to
      the 'any other packet' cathegory.  The reduced set of messages
      being able to trigger a change simplifies the processing at SEND
      SAVI devices.  It is also convenient for defining a comprehensive
      model regarding to anti-replay protection.
   o  The SEND SAVI device is only required to generate NUD_NSOL
      messages for SEND SAVI operation.  This also simplifies the state
      machine.
   o  Well-behaved hosts are expected to initiate communication by
      sending secured DAD_NSOL messages.  The SEND SAVI state machine is
      designed to process these events in an optimal way.  The reception
      of other packet types without receiving previously validated
      DAD_NSOL messages is assumed to be the result of either bad-
      behaving hosts or the lost of packets.  While these events may
      occur and a binding will ultimately be created for such hosts, the
      case in which data packets are received without receiving
      previously a DAD_NSOL message is not always optimized, for the
      sake of simplicity of the state machine.  It is also worth to note
      that a validated DAD_NSOL provides a reliable hint about the
      address ownership of a host attached to a given port, while this
      is not the case for data packets, for example.
   o  If a host has an address configured, and it can prove the
      ownership of this address, the state is preserved regardless of
      any indication that a binding for the same source address could be
      configured in other SEND SAVI device.  Bindings for the same
      source address in two (or more) SEND SAVI devices may occur due to
      several reasons, for example when a host moves (the two bindings
      exist just for a short period of time), if accidentally two hosts
      generate the same address and the DAD procedure has failed.  In
      these unfrequent cases, connectivity is honored over security.

   The SEND 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 SEND 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 SEND SAVI device.
   So, the SAVI device SHOULD join the solicited node multicast groups



Bagnulo & Garcia-Martinez  Expires April 28, 2011              [Page 14]

Internet-Draft                  SEND SAVI                   October 2010


   for all the addresses that are in a state other than NO_BIND.

   We next describe how different inputs are processed depending on the
   state of the binding of the IP address 'IPaddr'.  A Waiting_lifetime
   timer is associated to each binding.

   A simplified version is depicted in the next figure:












































Bagnulo & Garcia-Martinez  Expires April 28, 2011              [Page 15]

Internet-Draft                  SEND SAVI                   October 2010


                          +-------------+
                          |             |
                          | TESTING_VP' |
                          |             |
                          +-------------+
                             |    ^
            Timeout / VP=VP' |    |
                VP_NUD_NADV  |    |  VP'_DAD_NSOL/
                             |    |    NUD_NSOL
                             |    |
                             v    |
          VP_DAD_NSOL      +--------+
            +------------- |        |
            |              | VALID  |< -------------------+
            |   +-------- >|        |                     |
            |   |          +--------+                     |
            |   |            ^    |                       |
            |   |    VP_NUD_ |    | Timeout,              |
            |   |     NADV/- |    | TP_DAD_NSOL/NUD_NSOL  |
            |   |            |    v                       |
            |   |         +------------+                  |
            |   |         |            |                  |
            |   |         | TESTING_VP |                  |
            |   |         |            |                  |
            |   |         +------------+                  |
            |   |              |                          |
            |   |              | Timeout                  |
            |   | VP*,         |                          |
            |   | Timeout/-    |              VP_NUD_NADV |
            v   |              |                          |
         +---------------+     |           +---------------+
         |               |     |           |               |
         | TENTATIVE_DAD |     |           | TENTATIVE_NUD |
         |               |     |           |               |
         +---------------+     |           +---------------+
            ^  |               |             |         ^
            |  |               |   Timeout/- |         |
            |  | TP_DAD_NSOL,  |             |         |
            |  | TP_DAD_NADV/- |             |         |
            |  |               v             |         |
            |  |           +---------+       |         |
            |  +--------- >|         |< -----+         |
            |              | NO_BIND |                 |
            +--------------|         |-----------------+
            VP_DAD_NSOL/-  +---------+    VP*/VP_NUD_NSOL


   NO_BIND



Bagnulo & Garcia-Martinez  Expires April 28, 2011              [Page 16]

Internet-Draft                  SEND SAVI                   October 2010


   Relevant inputs for this state: When the node is in this state, there
   are no unresolved DAD_NSOL or NUD_NSOL messages (generated by SEND
   SAVI), so the only relevant inputs are DAD_NSOL messages coming
   either from VP or TP, or any packet other than DAD_NSOL coming from
   VP or TP.  There are no timers too.
   o  If a validated DAD_NSOL message is received from a Validating port
      VP, the SEND SAVI device forwards this message to all appropriate
      Trusted ports (the subset of Trusted ports which belong to the
      forwarding layer-2 topology, and with the restrictions imposed by
      the MLD snooping mechanism, if applied).  The DAD_NSOL messages
      are not sent through any of the ports configured as Validating
      Ports.  The SEND SAVI device sets the Waiting_timer to TENT_LT,
      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.  Note that in this case it
      is not possible to check address ownership by sending a NUD_NSOL
      because while the host is waiting for a possible DAD_NADV its
      address is in tentative state and it cannot respond to NSOL
      messages ([RFC4862]).
   o  If any packet other than a DAD_NSOL is received through a
      Validating port VP, the SEND SAVI device issues a secured NUD_NSOL
      through port VP.  The SEND SAVI device sets the Waiting_timer to
      TENT_LT.  The state is changed to TENTATIVE_NUD.
   o  Validated DAD_NSOL message 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 behavior that will depend on
      whether it performs MLD snooping or not).  The SEND SAVI device
      MAY assume that any DAD_NSOL message received from a Trusted port
      has been successfully validated by other SEND SAVI device, so that
      no additional validation is required.  The state is not changed.
   o  Any packet other than a DAD_NSOL received from a Trusted port is
      forwarded to its destination.  This packet is assumed to 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 state is
      not changed.

   TENTATIVE_DAD

   To arrive to this state, the SEND SAVI device has received a
   validated DAD_NSOL coming from port VP and forwarded to TP.  The
   possible events occuring in this state are: the reception of a
   DAD_NADV message from a TP (the corresponding DAD_NSOL was forwarded
   to this port), a DAD_NSOL message from VP, other validating port VP'
   or TP, and the expiration of the timer initiated when the DAD_NSOL
   was received at port VP.




Bagnulo & Garcia-Martinez  Expires April 28, 2011              [Page 17]

Internet-Draft                  SEND SAVI                   October 2010


   o  If a validated DAD_NADV is received from a Trusted port, the
      binding cannot be configured for port VP.  The state is changed to
      NO_BIND, and the Waiting_timer cleared.
   o  If a validated DAD_NSOL is received from a Trusted port, a host
      connected to another SEND SAVI device may be trying to configure
      the same address at the same time.  The DAD_NSOL message is
      forwarded to port VP, so that the host at port VP will not
      configure the address, as stated in [RFC4862].  The DAD_NSOL
      message is also forwarded to all appropriate Trusted ports.  Then,
      the Waiting_timer is cleared, and the state is changed to NO_BIND.
   o  Any packet other than a validated DAD_NSOL or DAD_NADV received
      from a Trusted port is forwarded to its destination.  This packet
      is assumed to 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 state is not changed.
   o  If a validated DAD_NSOL is received from a Validating port VP'
      different to VP, a host connected to VP' may be trying to
      configure the same address at the same time.  The DAD_NSOL message
      is forwarded to port VP, so that the host at port VP will not
      configure the address, as stated in [RFC4862].  The DAD_NSOL
      message is also forwarded to all appropriate Trusted ports.  Then,
      the Waiting_timer is set to TENT_LT, and the state remains in
      TENTATIVE_DAD, although in this case with VP=VP'.
   o  Any other packet than a validated DAD_NSOL is received from a
      Validating port VP' different from VP is discarded.  The state is
      not changed.
   o  If a validated DAD_NSOL is received from port VP, the
      Waiting_timer is set to TENT_LT, and the state remains in
      TENTATIVE_DAD.
   o  If any packet other than a validated DAD_NSOL is received from VP,
      it is assumed that the host has configured its address, although
      it has done it in less time than expected by the SEND SAVI device
      (less than TENT_LT).  Since the host proved address ownership by
      means of the validated DAD_NSOL message, the binding is created.
      The Waiting_timer is set to DEFAULT_LT, and the state is changed
      to VALID.
   o  If Waiting_timer expires, it is assumed that no other host has
      configured this address.  Therefore, the Validating port VP could
      be bound to this IPv6 address.  The Waiting_timer is set to
      DEFAULT_LT, and the state is changed to VALID.

   VALID

   To arrive to this state, successful validation of address ownership
   has been completed.  Relevant transitions for this state are
   triggered by the reception of DAD_NSOL from ports VP, VP' or TP, and
   any packet other than DAD_NSOL from VP' or TP.  The expiration of



Bagnulo & Garcia-Martinez  Expires April 28, 2011              [Page 18]

Internet-Draft                  SEND SAVI                   October 2010


   Waiting_timer is also relevant to check again for address ownership.
   o  If a validated DAD_NSOL with IPaddr as source address is received
      through Validating port VP, this message is forwarded to the
      appropriate trusted ports.  The Waiting_timer is set to TENT_LT
      and the state is changed to TENTATIVE_DAD.
   o  Any packet other than a validated DAD_NSOL containing IPaddr as a
      source address arriving from Validating port VP is forwarded
      appropriately.  The state is not changed.  Note that in the SEND
      SAVI case Timeout_valid for the entry MUST NOT be set to
      DEFAULT_LT (as occurs for 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 a validated DAD_NSOL with IPaddr as source address is received
      through a Trusted port, the message is forwarded to VP.  The
      Waiting_timer is set to TENT_LT, a secured NUD_NSOL message is
      sent to IPaddr through VP and the state is changed to TESTING_VP.
   o  If any packet other than a DAD_NSOL with IPaddr as source address
      is received through a Trusted port, the packet is forwarded to VP
      and to other appropriate Trusted ports.  A secured NUD_NSOL is
      sent to VP, the Waiting_timer is set to TENT_LT, and the state is
      changed to TESTING_VP.
   o  If a DAD_NSOL packet with IPaddr as source address is received
      through a Validating Port VP' (VP' different from the current
      Validating port for this binding), the message is forwarded to VP.
      In addition, a secured NUD_NSOL is sent to VP, the Waiting_timer
      is set to TENT_LT, and the state is changed to TESTING_VP'.
   o  If any packet other than a DAD_NSOL with IPaddr as source address
      is received from a Validating Port VP', different from the current
      Validating port for this binding, VP, the packet is discarded.
      The SEND SAVI device MAY issue a secured NUD_NSOL through port VP,
      set the Waiting_timer to TENT_LT, and change the state to
      TESTING_VP'.  An alternative to this behavior is that the SEND
      SAVI device MAY not do anything (in this case, the state would
      eventually change after a maximum DEFAULT_LT time, if the node at
      VP does not respond to a NUD_NSOL at TESTING_VP, the state is
      moved to NO_BIND, and a packet arrives from VP'.
   o  If Waiting_timer expires, a secured NUD_NSOL message is sent
      through port VP to the IPv6 address, the Waiting_timer is set to
      TENT_LT, and the state is changed to TESTING_VP.  In the
      TESTING_VP state packets are still being forwarded until the timer
      expires without receiving a NUD_NADV.

   TESTING_VP

   When the SEND SAVI device enters in the TESTING_VP state, the current
   Validating port is under check through a secured NUD_NSOL message
   generated by the SEND SAVI device.  While testing, packets from the
   current Validating port are forwarded.  Packets coming from Trusted



Bagnulo & Garcia-Martinez  Expires April 28, 2011              [Page 19]

Internet-Draft                  SEND SAVI                   October 2010


   ports are also forwarded.  The relevant events for this state are the
   reception of a secured NUD_NADV message from VP, the reception of a
   secured DAD_NSOL message from VP, VP' or TP, the reception of any
   packet other than the previous cases from VP, VP' or TP, and the
   expiration of the timer waiting for NUD_NADV.
   o  If a validated NUD_NADV message is received from VP, the message
      is discarded, the Waiting_timer is changed to DEFAULT_LT, and the
      state is changed to VALID.
   o  If a validated DAD_NSOL message is received from VP, the message
      is forwarded to the appropriate Trusted ports, the Waiting_timer
      is set to DEFAULT_LT, and the state is changed to TENTATIVE_DAD.
   o  Any packet other than DAD_NSOL or NUD_NADV containing IPaddr as a
      source address arriving from Validating port VP is forwarded.
      Neither the Waiting_timer nor the state are changed.
   o  If a DAD_NSOL message is received from a Trusted port, the message
      is forwarded to VP and the appropriate Trusted ports.  Neither the
      Waiting_timer nor the state are changed.  The host at VP port is
      under check: if it still is at port VP, it should answer with a
      NUD_NADV, and also with a DAD_NADV.  If it is not there, neither
      the NUD_NADV nor the DAD_NADV will be received, the timer will
      expire, the local state will move to NO_BIND, and the state at the
      remote node will change to VALID.
   o  If a packet other than a DAD_NSOL arrives from a Trusted port, the
      packet is forwarded.  Neither the Waiting_timer nor the state are
      changed.
   o  If a DAD_NSOL is received from a validating port VP', the message
      is forwarded to VP and the appropriate Trusted ports.  In
      addition, a secured NUD_NSOL is sent to VP, the Waiting_timer is
      set to TENT_LT, and the state is changed to TESTING_VP'.
   o  Any other packet received from a validating port VP' is discarded.
      This may occur because the host has moved but have not issued a
      DAD_NSOL or the DAD_NSOL message has been lost.  The state will
      eventually move to NO_BIND, and then the packets sent from VP'
      will trigger the creation of the binding for VP'.
   o  If the Waiting_timer expires, the Waiting_timer is cleared and the
      state is changed to NO_BIND.

   TESTING_VP'

   To arrive to this state an indication that a host at VP' wants to
   send data with IPaddr as source address while a binding existed for
   VP.  The SEND SAVI device has issued a NUD_NSOL to the host through
   port VP.  The possible events that may occur in this case are the
   reception of a NUD_NADV from port VP, the reception of DAD_NSOL from
   VP, VP', TP and VP" (VP" different from VP and VP'), the reception of
   any other packet from VP, VP', TP or VP", and the expiration of the
   timer.




Bagnulo & Garcia-Martinez  Expires April 28, 2011              [Page 20]

Internet-Draft                  SEND SAVI                   October 2010


   o  If a validated NUD_NADV is received from port VP, then the host at
      VP is defending its address.  VP is kept as the Validating port,
      the Waiting_timer is set to DEFAULT_LT, and the state is changed
      to VALID.
   o  If a validated DAD_NSOL is received from port VP, the message is
      forwarded to VP'.  The Waiting_timer is set to TENT_LT and the
      state is changed to TENTATIVE_DAD.  If the host at VP is
      reconfiguring its address; when forwarding the DAD_NSOL message,
      the node at VP' is expected to unconfigure its address.
   o  Any packet other than a validated DAD_NSOL or a validated NUD_NADV
      coming from port VP is forwarded, and the state is not changed.
   o  If a validated DAD_NSOL is received from port VP', the message is
      forwarded to VP.  The Waiting_timer is set to DEFAULT_LT, and the
      state is not changed.
   o  Any packet other than a validated DAD_NSOL coming from port VP is
      discarded, and the state is not changed.
   o  If a validated DAD_NSOL is received from port VP", different from
      VP and VP', the message is forwarded to VP and VP'.  VP' is
      expected to unconfigure its address if it was a VP'_DAD_NSOL
      message (and not any other packet) the message triggering the
      transition to this state.  The state remains in TESTING_VP'
      although with VP'=VP".  The Waiting_timer is not changed.
   o  Any packet other than a validated DAD_NSOL received from port VP"
      is discarded and does not affect to the state.
   o  If a validated DAD_NSOL is received from a Trusted port, the
      message is forwarded to ports VP, VP' and other appropriate
      Trusted ports.  The Waiting_timer is left unchanged and the state
      is changed to TESTING_VP.  VP' is expected to unconfigure its
      address if it was a VP'_DAD_NSOL message (and not any other
      packet) the message triggering the transition to this state.
   o  Any packet other than a validated DAD_NSOL coming from a Trusted
      port is forwarded appropriately, but the state is not changed.
   o  If Waiting_timer expires, it is assumed that the host for which
      the binding existed is no longer connected through port VP.
      Therefore, the Validating port VP' could be bound to this IPv6
      address.  The Waiting_timer is set to DEFAULT_LT and the state is
      changed to VALID.

   TENTATIVE_NUD

   To arrive to this state a data packet has been received through port
   VP without any existing binding in the SEND SAVI device.  The SEND
   SAVI device has sent a NUD_NSOL message to VP.  The relevant events
   for this case are the reception of a NUD_NADV from port VP, the
   reception of DAD_NSOL from port VP, VP' or TP, and the reception of
   any packet other than DAD_NSOL and NUD_NADV for port VP, and
   different from DAD_NSOL for VP' or TP.  In addition, the
   Waiting_timer may expire.



Bagnulo & Garcia-Martinez  Expires April 28, 2011              [Page 21]

Internet-Draft                  SEND SAVI                   October 2010


   o  If a validated NUD_NADV message is received through port VP, the
      message is discarded, the Waiting_timer is set to TENT_LT, and the
      state is changed to VALID.
   o  If a validated DAD_NSOL message is received through port VP, the
      message is forwarded to the appropriate Trusted ports, the
      Waiting_timer is set to TENT_LT and the state is changed to
      TENTATIVE_DAD.
   o  Any packet other than NUD_NADV or DAD_NSOL received through port
      VP is discarded.
   o  If a validated DAD_NSOL message is received through port VP'
      different from port VP, the message is forwarded to the
      appropriate Trusted ports, the Waiting_timer is set to TENT_LT
      with VP=VP', and the state is changed to TENTATIVE_DAD.
   o  Any packets other than DAD_NSOL received through port VP' are
      discarded, and the state is left unchanged.
   o  If a validated DAD_NSOL message is received through a Trusted
      port, the message is forwarded to port VP, and the state is left
      unchanged.
   o  Any other packet received from a Trusted port are forwarded
      appropriately.  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.  The state is left
      unchanged.
   o  If Waiting_timer expires, the Waiting_timer is cleared and the
      state is changed to NO_BIND.

4.4.  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 nodes attached to that particular VLAN.

4.5.  Protocol Constants

   TENT_LT is 500 milliseconds.

   DEFAULT_LT is 5 minutes.


5.  Security Considerations

   It should be noted that any SAVI solution is 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



Bagnulo & Garcia-Martinez  Expires April 28, 2011              [Page 22]

Internet-Draft                  SEND SAVI                   October 2010


   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 does not protect against spoofers being attached to the
   same port as a legitimate host.  For this reason it is RECOMMENDED
   that only one host attaches at the same time to a given port.

   One possible concern about SEND SAVI is its behavior when an attacker
   tries to forge the identity of a legitimate host by replaying
   messages.  Note that information that can be valid for SEND a short
   period after being generated (the binding between an IPv6 address and
   a layer-2 MAC address) is not valid for SEND SAVI if it arrives from
   an non-legitimate port.  We now perform a security analysis of such a
   replay attack for SEND SAVI.  On one hand, there is some information
   for which the security risks are equivalent to those of SEND
   operation, which are situations in which the information received is
   not tied to port-related state in SEND SAVI operation.  Such
   situations are the reception of CPA messages containing certificates,
   or the processing of an unsolicited RADV message, which can be used
   in SEND SAVI to associate the router condition to the IPv6 address of
   an existing binding in the SEND SAVI Port list.  On the other hand,
   all the messages which can be create a SEND SAVI binding may be



Bagnulo & Garcia-Martinez  Expires April 28, 2011              [Page 23]

Internet-Draft                  SEND SAVI                   October 2010


   sensible for the replaying of valid SEND messages.  SEND SAVI creates
   and maintains bindings as a result of the reception of DAD_NSOL
   messages and of the exchange of NUD_NSOL/NUD_NADV messages.
   o  To prevent DAD_NSOL replay attacks, DAD_NSOL messages are not
      forwarded to ports through which an existing binding existed.
      Therefore, to capture a message that could be used to launch a
      replay attack, an attacker must be located either in the port
      through which the legitimate host is (in which case the attack is
      useless), or in a port in which a legitimate host was before and
      for which a binding still exists.  For this latter case, an
      attacker can prevent the configuration of binding for a legitimate
      host in other port (which could have moved from the initial
      location), and the binding would be available for the attacker for
      DEFAULT_LT ms.  The attacker can do this either in the port for
      which a binding existed, or in other port to which it is connected
      or to which it can convey this information for a third node to
      perform this attack.  This risk is inherent to allowing layer-2
      host mobility in an scenario in which many hosts can attach to the
      same port (either at the same time or in instants very close one
      to the other).  Another consideration is that this situation
      reflect the fact that it is impossible to determine the legitimacy
      of a node with a more secure NUD_NSOL/NUD_NADV exchange when the
      nodes claim to be configuring the address.
   o  When a NUD_NSOL/NUD_NADV exchange is used to create or maintain a
      state, the messages are only forwarded to the port in which the
      host claiming to be legitimate is located.  In this case, an
      attacker must be connected to the same port of the legitimate host
      to be able to capture a message which could be replayed.  The
      replay of NUD_NSOL is useless, since it is not used to trigger the
      creation of a binding.  The replay of a NUD_NADV message through
      the same port is useless, since SEND SAVI does not protect against
      spoofers attached to the same port.  The replay of a NUD_NADV
      message through a different port does result neither in the
      creation of a binding in other SEND SAVI device, nor in the
      binding created in the SEND SAVI device originating the NUD_NSOL
      message, since this SEND SAVI device only considers NUD_NADV
      message received from the same port through which the NUD_NSOL
      message was sent.

   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
   validate DAD_NSOL messages or generate a NUD_NSOL and create a state
   in which a NUD_NADV is waited for.  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, a rate-limiting mechanism



Bagnulo & Garcia-Martinez  Expires April 28, 2011              [Page 24]

Internet-Draft                  SEND SAVI                   October 2010


   SHOULD be enforced in a per-port basis.


6.  Acknowledgments

   Thanks to Ana Kukec for her review and comments on this document.
   The text has also benefited from feedback provided by Tony Cheneau.

   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.


7.  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
              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.ietf-savi-framework]
              Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt,
              "Source Address Validation Improvement Protocol
              Framework", draft-ietf-savi-framework-00 (work in
              progress), September 2010.

   [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-05 (work
              in progress), October 2010.





Bagnulo & Garcia-Martinez  Expires April 28, 2011              [Page 25]

Internet-Draft                  SEND SAVI                   October 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 April 28, 2011              [Page 26]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/