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

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

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]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/