[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

SAVI                                                            J. Bi
Internet Draft                                                 CERNET
Intended status: Standard Tracks                               G. Yao
Expires: October 2010                                   Tsinghua Univ.
                                                                J. Wu
                                                               CERNET
                                                           Fred Baker
                                                                CISCO
                                                        April 18, 2010



                    SAVI Solution for Stateless Address
                      draft-bi-savi-stateless-00.txt


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79. This document may not be modified,
   and derivative works of it may not be created, except to publish it
   as an RFC and to translate it into languages other than English.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November 10,
   2008. The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt





Bi                    Expires October 18, 2010                [Page 1]


Internet-Draft             savi-stateless                   April 2010


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on September 18, 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.

Abstract

   This document specifies the procedure for creating bindings between a
   stateless address (including Stateless Autoconfiguration Address,
   manually configured non-static address, etc) and an anchor (refer to
   [SAVI-framework]) on SAVI (Source Address Validation Improvements)
   device. The bindings can be used to filter packets generated on the
   local link with forged IP addresses. Different from other proposed
   solution for stateless address (e.g., SAVI-FCFS), this solution
   follows RFC4862 to arbitrate the ownership of address. Supplemental
   binding processes are also specified to cover conditions that cannot
   be handled by control packet snooping.

Table of Contents


   Copyright Notice ............................................... 2
   Abstract ....................................................... 2
   1. Introduction ................................................ 4
   2. Conventions used in this document............................ 4
   3. Mechanism Overview .......................................... 4
   4. Basic Principle of Address Ownership Arbitration............. 4
   5. Background and Related Protocols............................. 5
   6. Terminology ................................................. 6
   7. Conceptual Data Structures................................... 6
      7.1. Binding State Table (BST)............................... 6
      7.2. Filtering Table (FT).................................... 7


Bi                    Expires October 18, 2010                [Page 2]


Internet-Draft             savi-stateless                   April 2010


   8. Binding States Description................................... 7
   9. Stateless Scenario .......................................... 7
   10. Anchor Attributes .......................................... 8
      10.1. SAVI-Validation Attribute.............................. 8
      10.2. SAVI-RA-Trust Attribute................................ 8
      10.3. SAVI-SAVI Attribute.................................... 9
   11. Prefix Configuration........................................ 9
   12. Binding Set Up ............................................ 10
      12.1. Process of Control Packet Snooping.................... 10
         12.1.1. Initialization................................... 10
            12.1.1.1. Trigger Event............................... 10
            12.1.1.2. Event Validation............................ 10
            12.1.1.3. Following Actions........................... 10
         12.1.2. State Transit from DETECTION..................... 10
            12.1.2.1. Trigger Event............................... 10
            12.1.2.2. Following Actions........................... 11
         12.1.3. After BOUND...................................... 11
      12.2. State Machine of DAD Snooping......................... 11
   13. Supplemental Binding Processes............................. 12
      13.1. Rate-limited Data Triggered Binding Process........... 12
      13.2. Counter Triggered Process............................. 13
      13.3. External Control Packet Snooping Process.............. 14
         13.3.1. SAVI-ExtSnooping Attribute....................... 14
         13.3.2. Extended Control Packet Snooping................. 14
   14. Filtering Specification.................................... 15
      14.1. Data Packet Filtering................................. 15
      14.2. Control Packet Filtering.............................. 15
   15. Format and Delivery of Probe Messages...................... 15
      15.1. Duplicate detection................................... 16
   16. Binding Remove ............................................ 16
   17. Handle Anchor Off-link event............................... 16
   18. About Collision in Detection............................... 17
      18.1. The Result of Detection without Host Aware............ 17
   19. Filtering during Detection................................. 17
   20. Binding Number Limitation.................................. 17
   21. MLD Consideration ......................................... 18
   22. Link Layer Address Binding Toleration...................... 18
   23. Handle Layer 2 Path Change................................. 18
   24. State Restoration ......................................... 18
   25. Constants ................................................. 19
   26. Security Considerations.................................... 19
   27. IANA Considerations........................................ 19
   28. References ................................................ 19
      28.1. Normative References.................................. 19
      28.2. Informative References................................ 19
   29. Acknowledgments ........................................... 20



Bi                    Expires October 18, 2010                [Page 3]


Internet-Draft             savi-stateless                   April 2010


1. Introduction

   This document describes the procedure for creating bindings between
   stateless address and anchor (refer to [savi-framework]). Other
   related details about this procedure are also specified in this
   document.

   These bindings can be used to filter packets with forged IP addresses.
   How to use these bindings is specified in [savi-framework], depending
   on the environment and configuration. The definition and examples of
   anchor is also specified in [savi-framework].

   The binding process is partially inspired by the work of SAVI-FCFS.
   Different from a data trigger based procedure in SAVI-FCFS, this
   specification mainly focuses on control panel triggered process.
   Supplement binding processes are designed to cover deficiency of
   control packet snooping.

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3. Mechanism Overview

   The mechanism specified in this document is designed to provide a
   host level source IP address validation granularity, as a supplement
   to BCP38 [BCP38]. This mechanism is deployed on the access device
   (including access switch, wireless access point/controller, etc), and
   performs mainly NDP/ARP snooping to set up bindings between stateless
   IP addresses and corresponding anchors. The bindings can be used to
   validate the source address in the packets.

4. Basic Principle of Address Ownership Arbitration

   In stateless scenario, nodes can "assign" address to themselves, and
   perform unreliable duplicate detection to check whether the address
   is being used. For IPv6 address, collision happens with very little
   probability because of large address space, thus the unreliable
   nature of DAD is not serious in reality. However, the unreliability
   of DAD troubles source address validation. It is very hard, if not
   impossible, for a SAVI device to determine which node can use one
   address when conflict happens.

   A wise principle, "First Come First Served" is currently used by
   SAVI-FCFS to determine ownership of address. This principle is


Bi                    Expires October 18, 2010                [Page 4]


Internet-Draft             savi-stateless                   April 2010


   correct, however, the problem is, how to determine which node is the
   first to use an address. Because the unreliable nature of DAD, the
   first one assigned itself an address, may not be the one first using
   the address to send traffic sniffed by the SAVI device. SAVI-FCFS
   requires device to send detection probes to determine whether an
   address is being used by another node. However, this effort may be
   vain, because malicious node can reply any probe, and the probe is
   still unreliable to reach the possible target node.

   After a long time attempt, we finally find that because of the
   unreliability of DAD and ND, there is no perfect arbitration policy.
   In another word, if a arbitration policy is perfect, it must rely on
   a reliable DAD. We can prove this through a simple deduction:

   Perfect arbitrate=>

   The one having assigned itself an address first gets the ownership of
   the address=>

   The one having performed DAD first gets the address=>

   The arbitrator must know who is the first to perform DAD=>

   The DAD must be reliable to be sniffed by the SAVI device.

   And the deduction can be reversed.

   In the end, we found we were building tower on the quick sand. It
   concerns nothing about whether choosing data trigger or control
   packet trigger. Unless stateless assignment changes to be reliable,
   no solution can be secure.

   In this document, we decide to follow RFC4862, which is the only
   stand track on stateless address assignment. This means, if a node
   finishes a successful DAD, including the DAD is performed by SAVI
   device in case of data trigger, the address MUST be bound with it.
   Then the ownership conflict is actually handled through allowing one
   address to be bound with multiple anchors. The bindings are only
   removed when the lifetime expires, which equals prefix life time
   learned from RA. Then we achieve a simple solution, whose security is
   based on the reliability of RFC4862.

5. Background and Related Protocols

   This mechanism is an instance of a SAVI [savi-framework] solution,
   specialized for stateless addresses, including IPv6 Stateless



Bi                    Expires October 18, 2010                [Page 5]


Internet-Draft             savi-stateless                   April 2010


   Autoconfiguration address, manually configured non-static IPv6 and
   IPv4 address.

   In IPv6, IPv6 Stateless Autoconfiguration [RFC4862] is a widely
   deployed address assignment mechanism. A node can generate an address
   autonomously, and use Duplicate Address Detection described in
   [RFC4862] to auto-configure this address. [RFC4862] clearly requires
   that duplicated address detection must be performed on any IPv6
   address, including DHCPv6 address. This is the basis of this control
   packet snooping based SAVI solution.

   [RFC4861] specifies the Neighbor Discovery protocol, which is an
   essential part of IPv6 address assignment.

   IPv4 doesn't have stateless auto-configuration mechanism, because of
   the high collision probability of auto-generated address. However, in
   some scenarios, interfaces are allowed to be configured addresses
   with a specified prefix, instead of assigning each interface a static
   address. In such scenarios, the address assignment method is regarded
   as stateless in this document.

   [RFC5227] specifies the procedure to detect IPv4 address collision.
   It is not required currently. However, this feature is useful to
   determine the uniqueness of an IPv4 address on the link. Considering
   not all the operating systems support [RFC5227], this solution is
   designed to be compatible with operating systems not complying with
   [RFC5227].

6. Terminology

   Main terms used in this document are described in [savi-framework],
   [RFC4862], [RFC826] and [RFC5227].

7. Conceptual Data Structures

   This section describes the possible conceptual data structures used
   in this mechanism.

   Two main data structures are used to record bindings and their states
   respectively. There is redundancy between the two structures, for the
   consideration of separation of data plane and control plane.

7.1.  Binding State Table (BST)

   This table contains the state of binding between source address and
   anchor. Entries are keyed on the anchor and source IP address. Each



Bi                    Expires October 18, 2010                [Page 6]


Internet-Draft             savi-stateless                   April 2010


   entry has a lifetime field recording the remaining lifetime of the
   entry, and a state field recording the state of the binding.

                +---------+----------+-------+-----------+
                | Anchor  | Address  | State | Lifetime  |
                +---------+----------+-------+-----------+
                | A       | IP_1     | Bound |  65535    |
                +---------+----------+-------+-----------+
                | A       | IP_2     | Bound |  10000    |
                +---------+----------+-------+-----------+
                | B       | IP_1     |_Bound |      1    |
                +---------+----------+-------+-----------+
                         Figure 1 Instance of BST


7.2.  Filtering Table (FT)

   This table contains the bindings between anchor and address, keyed on
   anchor. This table doesn't contain any state of the binding. This
   table is only used to filter packets. An Access Control List can be
   regarded as a practical instance of this table.

                          +---------+----------+
                          |Anchor   |Address   |
                          +---------+----------+
                          |A        |IP_1      |
                          +---------+----------+
                          |A        |IP_2      |
                          +---------+----------+
                          Figure 2 Instance of FT

8. Binding States Description

   This section describes the binding states of this mechanism.

   DETECTION    A gratuitous ARP or Duplicate Address Detection
                  Neighbor Solicitation has been sent by the host (or
                  the SAVI device).

   BOUND       The address has passed duplicate detection and
             it is bound with the anchor.

9. Stateless Scenario

   Figure 3 shows the main elements in a stateless address allowed
   network. Nodes generate address themselves without the assistance of



Bi                    Expires October 18, 2010                [Page 7]


Internet-Draft             savi-stateless                   April 2010


   any other server. Other address assignment mechanisms may be also
   used in such network.

                               +----------+
                               |  SAVI    |
                               |  Device  |
                               +-/------/-+
                                 |      |
                            +----\-+   +\-----+
                            |Node 1|   |Node 2|
                            |      |   |      |
                            +------+   +------+
                        Figure 3 Stateless Scenario

10. Anchor Attributes

   This section specifies the anchor attributes involved in this
   mechanism.

   Anchor is defined in the [savi-framework]. Attribute of each anchor
   is configurable. In default, anchor has no attribute. An anchor MAY
   be configured to have one or more compatible attributes. However, an
   anchor MAY have no attribute.

   If an anchor has no attribute, in this solution, Router Advertisement
   message from this anchor MUST be dropped. However, other packets
   SHOULD NOT be dropped.

10.1. SAVI-Validation Attribute

   If and only if source address validation must be performed on the
   traffic from an anchor, this anchor MUST be set to have SAVI-
   Validation attribute. The filtering process on anchor with such
   attribute is described in section 12.

10.2. SAVI-RA-Trust Attribute

   If and only if an anchor is associated with a trustable router, it
   SHOULD be set to have this attribute.

   On a SAVI device enabled this solution, there may be no anchor with
   this attribute. This implies only link-local address is allowed, or
   prefix validation is not enabled, or only manually configured prefix
   is allowed. Router Advertisement message not coming from such anchors
   MUST be dropped.




Bi                    Expires October 18, 2010                [Page 8]


Internet-Draft             savi-stateless                   April 2010


10.3. SAVI-SAVI Attribute

   If and only if an anchor is associated with another SAVI device, it
   SHOULD be set to have this attribute. All traffic from anchor with
   this attribute will be forwarded without check.

   This attribute can also be set on other anchors if the administrator
   decides not to validate the traffic from the anchor. Note that DHCP
   server message and Router Advertisement will also be trusted.

   This attribute is mutually exclusive with SAVI-Validation.

11. Prefix Configuration

   Because Duplicate Address Detection doesn't have the function of
   checking the validity of the prefix of address, in this solution, it
   is SUGGESTED that correct address prefix SHOULD be configured. If the
   correct prefix is not configured, the SAVI device may bind anchors
   with addresses using bogus prefixes. Although a prefix level
   filtering mechanism, e.g., ingress filtering may be deployed on the
   layer 3 device of the network, it cannot prevent spoofing in the
   local link.

   This document suggests set 3 prefix scopes:

   IPv4 Prefix:

         The allowed scope of any kind of IPv4 addresses. It can be set
         manually.

   IPv6 Prefixes:

         The allowed scope of SLAAC and manually configured IPv6
         addresses. It can be set through snooping RA message from port
         with SAVI-RA-Trust attribute, DHCP-PD or manual configuration.

       FE80::/64 MUST be set to a feasible prefix.

   There is no need to explicitly present these prefix scopes. But these
   restrictions SHOULD be used as premier check in binding set up.

   Refer to security consideration for other discussions.







Bi                    Expires October 18, 2010                [Page 9]


Internet-Draft             savi-stateless                   April 2010


12. Binding Set Up

   This section specifies the procedure of setting up bindings based on
   control packet snooping. The binding procedure specified here is
   exclusively designed for anchor with SAVI-Validation attribute.

12.1. Process of Control Packet Snooping

12.1.1. Initialization

12.1.1.1. Trigger Event

   A gratuitous ARP Request or Duplicate Address Detection Neighbor
   Solicitation is received from anchor.

12.1.1.2. Event Validation

   The SAVI device checks the BST as follows:

   1. Whether binding number limitation will be exceeded if a new
      binding entry is set up.

12.1.1.3. Following Actions

   If the check is passed:

   The packet MUST be forwarded.

   An new entry MUST be generated, with state set to be DETECTION, and
   lifetime set to be MAX_ARP_DELAY or MAX_DAD_DELAY respectively.

            +---------+----------+-----------+-----------------+
            | Anchor  | Address  | State      | Lifetime       |
            +---------+----------+-----------+-----------------+
            | A       | Addr     | DETECTION  |MAX_ARP_DELAY   |
            |         |          |            |MAX_DAD_DELAY   |
            +---------+----------+-----------+-----------------+
                Figure 4 Binding entry in BST on detection

   A new entry MUST be inserted into the FT.

12.1.2. State Transit from DETECTION

12.1.2.1. Trigger Event

   A timeout event of an entry with state DETECTION occurs or an ARP
   Response or NA for an address in BST with state DETECTION is received.


Bi                    Expires October 18, 2010               [Page 10]


Internet-Draft             savi-stateless                   April 2010


12.1.2.2. Following Actions

   If a timeout event of an entry with state DETECTION occurs, set the
   state of the entry to be BOUND. The lifetime of the entry is set to
   be the lifetime of corresponding prefix, which is learn from RA. If
   the address is link local address, the lifetime of the binding SHOULD
   be set to INFINITE.

        +---------+----------+-----------+------------------------+
        | Anchor  | Address  | State     | Lifetime               |
        +---------+----------+-----------+------------------------+
        | A       | Addr     | BOUND     | prefix lifetime        |
        +---------+----------+-----------+------------------------+
               Figure 5 Binding entry in BST on finalization

   If an ARP Response or NA for an address in BST with state DETECTION
   is received, remove the corresponding entry in BST and FT. The ARP
   Response or NA MUST be delivered to the client.

12.1.3. After BOUND

   Once a binding entry is set up for an anchor, the binding will be
   used to filter packet with the anchor, as specified in section 13.
   The state of the binding entry will not be affected by any message.

   If the lifetime of an entry with state BOUND expires, delete the
   entry in BST and Filter Table.

   Switch port down event (or more general, anchor turns off-link) will
   change the corresponding entry, as described in section 15.

12.2. State Machine of DAD Snooping

   The main state transits are listed as follows. Note that the anchor
   migration of binding entry is not included.

   State      Message/Event       Action                      Next State

   -          Gra ARP/DAD NS      Generate entry               DETECTION

   DETECTION  ARP RES/DAD NA      Remove entry                         -

   DETECTION  Timeout             Finish binding                   BOUND

   BOUND      Timeout             Remove entry                         -

   Gra ARP REQ: Gratuitous ARP REQUEST


Bi                    Expires October 18, 2010               [Page 11]


Internet-Draft             savi-stateless                   April 2010


   ARP RES: ARP RESPONSE

   DAD NS: Duplicate Address Detection Neighbor Solicitation

   DAD NA: Neighbor Advertisement targeting at a tentative address

13. Supplemental Binding Processes

   Supplemental binding processes are designed to cover situations that
   no DAD procedure can be sensed by SAVI device. The typical situations
   include: DAD NS loss, layer-2 path change and movement on local link
   without triggering DAD procedure.

   This process is designed to avoid permanent blocking. It is not
   supposed that binding can be trigger whenever a data packet with
   unbound address is received. Generally a number of packets and more
   time are needed to trigger a binding.

   At least one of the following techniques MUST be implemented in SAVI
   device which deploys this solution:

   1. Rate-limited Data Triggered Binding Process

   2. Counter Triggered Process

   3. Extended Control Packet Snooping Process

   Other techniques may be prudently chosen as alternative if found to
   have equivalent or even better function to avoid permanently blocking
   after discussion, implementation and deployment.

13.1. Rate-limited Data Triggered Binding Process

13.1.1. SAVI-DataTrigger Attribute

   If data trigger binding process is implemented as the supplemental
   binding process, an additional anchor attribute, named SAVI-
   DataTrigger, MUST be implemented.

   This attribute is mutually exclusive with SAVI-SAVI.

   Data triggered binding process will be performed on the anchor with
   such attribute.

13.1.2. Data Triggered Binding Process




Bi                    Expires October 18, 2010               [Page 12]


Internet-Draft             savi-stateless                   April 2010


   If an anchor is set to have SAVI-DataTrigger attribute, data packet
   whose source address is not bound with the anchor, may not be
   filtered directly; instead, the SAVI device will check whether the
   address can be used by the client on the local link with limited rate:

   1. If the address has a local conflict, meaning the DAD on the
      address fails, the packet MUST be discarded. The DAD procedure is
      performed by the SAVI device, through sending two or more DAD NS
      probes. The format and delivery of the DAD NS is specified in
      section 15. If the DAD is successful, the address MUST be bound
      with the anchor, with a lifetime equal to lifetime of
      corresponding prefix.

   The data triggered process MUST be rate limited to avoid Denial of
   Services attack against the SAVI device itself. A constant
   DATA_TRIGGER_INTERVAL is used to control the frequency. Two data
   trigger processes on one anchor must have a minimum interval time
   DATA_TRIGGER_INTERVAL. This constant SHOULD be configured prudently
   to avoid Denial of Services.

   Data triggered process is not strict secure. The node with data-
   trigger anchor has the ability to use the address of an inactive node,
   which doesn't reply to the DAD probe.

13.2. Counter Triggered Process

13.2.1. SAVI-CounterTrigger Attribute

   If counter triggered binding process is implemented as the
   supplemental binding process, an additional anchor attribute, named
   SAVI-CounterTrigger, MUST be implemented.

   This attribute is mutually exclusive with SAVI-SAVI.

   Counter triggered binding process will be performed on the anchor
   with such attribute.

13.2.2. Counter Triggered Process

   In this process, a counter is used to record the number of filtered
   packets by this solution or all the enabled SAVI solutions on anchor
   with SAVI-CounterTrigger attribute. A constant TRIGGER_COUNT is set
   with the counter.

   Whenever the counter reaches TRIGGER_COUNT, this event MUST be
   handled by the SAVI device. The SAVI device performs following steps:



Bi                    Expires October 18, 2010               [Page 13]


Internet-Draft             savi-stateless                   April 2010


   1. Set the counter to 0;

   2. Perform DAD process on the source address of the packet triggering
      this event, through sending two or more DAD NS probe as specified
      in section 15. If the DAD fails, the packet MUST be discarded. If
      the DAD is successful, a binding MUST be set up on the anchor.

   3. This event MUST be announced to network administrator. For example,
      a SNMP trap may be triggered; or an alert on console interface may
      be generated.

   The constant TRIGGER_COUNT MUST be prudently configured to fit the
   specified deployment scenario. In extreme situation, it can be set to
   1.

13.3. External Control Packet Snooping Process

13.3.1. SAVI-ExtSnooping Attribute

   If extended control packet snooping is implemented as the
   supplemental binding process, an additional anchor attribute, named
   SAVI-ExSnooping, MUST be implemented.

   This attribute is mutually exclusive with SAVI-SAVI.

   Extended control packet snooping process will be performed on the
   anchor with such attribute.

13.3.2. Extended Control Packet Snooping

   In this snooping process, other than DAD messages, other types of
   control packets processed by processor of SAVI device, if the source
   address is not bound, may trigger the device to perform binding
   process.

   The control messages that MUST be processed include: (1) address
   resolution Neighbor Solicitation; (2) Neighbor Advertisement; (3)
   neighbor unreachability detection; (4) Multicast Listener Discovery;
   (5) Address Resolution Protocol. Other ICMP messages that may be
   processed by intermediate device may also trigger the binding process.

   The SAVI device MUST perform DAD to check if the address has a local
   conflict. The format and delivery of DAD probe is specified in
   section 15.

   A minimum time interval EXT_SNOOPING_INTERVAL MUST be set to limit
   the rate of such triggering process.


Bi                    Expires October 18, 2010               [Page 14]


Internet-Draft             savi-stateless                   April 2010


   Note that this process may not be able to avoid permanent block, in
   case that only data packets are sent by node. Generally, this
   mechanism is still practical, because data packet sending without
   control plane communication is rare and suspicious in reality. Normal
   traffic will contain control plane communication packets to help
   traffic setup and fault diagnosis.

14. Filtering Specification

   This section specifies how to use bindings to filter packets. Because
   the Filtering Table is an allow-table, packet with source address not
   in the table will be filtered.

   Filtering policies are different for data packet and control packet.
   ND messages that may cause state transit are classified into control
   packet. Neighbor Advertisement and ARP Response are also included in
   control packet, because the Target Address of NA and ARP Response
   should be checked to prevent spoofing. All other packets are
   considered to be data packets.

14.1. Data Packet Filtering

   Data packets with an anchor which has attribute SAVI-Validation MUST
   be checked.

   If the source of a packet associated with its anchor is in the FT,
   this packet SHOULD be forwarded; or else the packet MUST be discarded.

14.2. Control Packet Filtering

   For anchors with SAVI-Validation attribute:

   The source address of IPv6 NS and IPv4 gratuitous ARP MUST pass the
   check on FT.

   The target address and source address in all the Neighbor
   Advertisement packets and ARP replies MUST also pass the checks on FT.

   For other anchors:

   All RA packets MUST be from anchor with the SAVI-RA-Trust attribute.

15. Format and Delivery of Probe Messages

   The SAVI device MAY send detection probes on behavior of node to
   determine whether the assigned address is duplicated in case of data



Bi                    Expires October 18, 2010               [Page 15]


Internet-Draft             savi-stateless                   April 2010


   trigger is enabled. Currently no other probes are designed in this
   solution.

15.1. Duplicate detection

      Message Type: DAD NS, Gratuitous ARP Request

      Format:

                   Link layer source - link layer address of host;

                   Link layer destination - For IPv6, use multicast address
      specified in [RFC3307]; For IPv4, use broadcast address;

                   IP source - Unspecified address for IPv6; The tentative

      address for IPv4;

                   IP destination - For IPv6, multicast address specified in
      section 5.4.2 of [RFC4861]; For IPv4, the tentative address;

      Delivery:

         MUST not be delivered to the host which the SAVI device is
      performing DAD on behavior of.

16. Binding Remove

   If the lifetime of an entry with state BOUND expires, the entry MUST
   be removed.

17. Handle Anchor Off-link event

   Port DOWN event MUST be handled if switch port is used as anchor. In
   more general case, if an anchor turns off-link, this event MUST be
   handled.

   Whenever an anchor with attribute SAVI-Validation turns down, the
   bindings with the anchor MUST be kept for a short time.

   To handle movement, if receiving DAD NS/Gra ARP request targeting at
   the address during the period, remove the entry.

   If the anchor turns on-link during the period, recover bindings. It
   may result in some security problem, e.g., a malicious node
   immediately associates with the anchor got off by a previous node,
   then it can use the address assigned to the previous node. However,


Bi                    Expires October 18, 2010               [Page 16]


Internet-Draft             savi-stateless                   April 2010


   this situation is very rare in reality. Authors decide not to handle
   this situation.

18. About Collision in Detection

   The SAVI device may receive a response in detection. Some related
   details are specified here.

18.1. The Result of Detection without Host Aware

   In case the SAVI device send detection packet instead of the host,
   the host will not be aware of the detection result. If the detection
   succeeds, there is no problem. However, if the detection fails, the
   packets from the host with the assigned address will be filtered out.
   This result can be regarded as a reasonable punishment for not
   performing duplicate detection and using a collision address. The
   SAVI device MAY choose to notice the client that the assigned address
   has been used, through a NA message. This mechanism is not required
   in this solution.

19. Filtering during Detection

   In this mechanism, whenever a DAD NSOL is received, this address will
   be allowed immediately even before duplicate detection is completed.
   This design is in consideration of a host may start to send packets
   straightway without detection. Also this design is to be compatible
   with optimistic DAD [RFC4429].

   However, this feature may allow an attacker to send quantities of
   packets with source addresses already assigned to other nodes.

20. Binding Number Limitation

   It is suggested to configure some mechanism in order to prevent a
   single node from exhausting the binding table entries on the SAVI
   device. Either of the following mechanism is sufficient to prevent
   such attack.

   1. Set the upper bound of binding number for each anchor with SAVI-
      Validation.

   2. Reserve a number of binding entries for each anchor with SAVI-
      Validation attribute and all anchors share a pool of the other
      binding entries.

   3. Limit DAD NSOL rate per anchor, using the bound entry number of
      each anchor as reverse indicator.


Bi                    Expires October 18, 2010               [Page 17]


Internet-Draft             savi-stateless                   April 2010


21. MLD Consideration

   The SAVI device MUST join the tentative address multicast group
   whenever perform duplicate detection on behavior of host.

22. Link Layer Address Binding Toleration

   As packet is possible to get lost on the link, and the first packet,
   which is generally DAD for link layer address, has higher lost
   probability because of the link initialization or authentication
   mechanism, a more tolerable mechanism for link local address MUST be
   used to avoid false positive.

   Whenever a control message with link local source address is
   processed by this solution (ND, NA), if the address is not bound, the
   SAVI device MUST perform DAD to check the uniqueness of the address.
   If no collision is found, a binding entry for the link local address
   MUST be inserted into the binding table.

   Other layer 3 control messages, including MLD, MAY also be used to
   trigger this process.

23. Handle Layer 2 Path Change

   Layer 2 path change is an important challenge on this control plane
   based solution. The SAVI device MUST be sensitive to any layer 2 path
   change. Whenever a layer 2 control protocol frame, including STP,
   RSTP, TRILL, is received from some anchor, which announces a layer 2
   incoming path is changed to the anchor, data packet trigger process
   MUST be enabled on the anchor for a period. Although generally such
   events can be handled through pre-configuration of data-trigger
   attribute, the future layer 2 protocol may be flexible and hard to
   handle through manual configuration.

24. State Restoration

   If a SAVI device reboots accidentally or designedly, the states kept
   in volatile memory will get lost. This may cause hosts indirectly
   attached to the SAVI device to be broken away from the network,
   because they can't recover bindings on the SAVI device of themselves.
   Thus, binding entries SHOULD be saved into non-volatile storage
   whenever a new binding entry changes to BOUND state or a binding with
   state BOUND is removed, unless other alternatives specified here is
   implemented.

   If binding is saved into non-volatile memory, immediately after
   reboot, the SAVI device MUST restore binding states from the non-


Bi                    Expires October 18, 2010               [Page 18]


Internet-Draft             savi-stateless                   April 2010


   volatile storage. The lifetime and the system time of save process
   MUST be stored. Then the device MUST check whether the saved entries
   are obsolete when rebooting.

   The possible alternative is:

   If the network enables 802.1ag, the bindings can be recovered with
   the help of the first hop routers through snooping unicast Neighbor
   Solicitations sent by routers based on the Neighbor Table.

25. Constants

   MAX_ARP_DELAY              Default 1s but configurable

   MAX_DAD_DELAY              Default 1s but configurable

   DATA_TRIGGER_INTERVAL      Device capacity depended and configurable

   TRIGGER_COUNT              Device capacity depended and configurable

26. Security Considerations

   For prefix level granularity filtering is the basis of host level
   granularity filtering, to learn and configure correct prefix is of
   great importance to this mechanism. Thus, it's important to keep RA
   and DHCP-PD secure. [draft-ietf-v6ops-ra-guard-03] describes a
   mechanism to improve the security of RA message.

27. IANA Considerations

   There is no IANA consideration currently.

28. References

28.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

28.2. Informative References

    [RFC3307] B. Haberman, "Allocation Guidelines for IPv6 Multicast
   Addresses", RFC3307, August 2002.

    [RFC4861] T. Narten, E. Nordmark, W. Simpson, and H. Soliman,
   "Neighbor Discovery for IP version 6 (IPv6)", RFC4861, September 2007.



Bi                    Expires October 18, 2010               [Page 19]


Internet-Draft             savi-stateless                   April 2010


   [RFC4862] Thomson, S., Narten, T. and Jinmei, T., "IPv6 Stateless
   Autoconfiguration", RFC4862, September, 2007.

    [RFC5227] S. Cheshire, "IPv4 Address Conflict Detection", RFC5227,
   July 2008.

29. Acknowledgments

   Thanks to Christian Vogt, Eric Levy-Abegnoli, Mark Williams, Erik
   Nordmark, Marcelo Bagnulo Braun, Alberto Garcia, Jari Arkko, David
   Harrington, Pekka Savola, Xing Li, Lixia Zhang, Robert Raszuk, Greg
   Daley, Joel M. Halpern, Mikael Abrahamsson, John Kaippallimalil and
   Tao Lin for their valuable contributions.



































Bi                    Expires October 18, 2010               [Page 20]


Internet-Draft             savi-stateless                   April 2010


Authors' Addresses

   Jun Bi
   CERNET
   Network Research Center, Tsinghua University
   Beijing 100084
   China
   Email: junbi@cernet.edu.cn

   Guang Yao
   CERNET
   Network Research Center, Tsinghua University
   Beijing 100084
   China
   Email: yaog@netarchlab.tsinghua.edu.cn

   Jianping Wu
   CERNET
   Computer Science, Tsinghua University
   Beijing 100084
   China
   Email: jianping@cernet.edu.cn

   Fred Baker
   Cisco Systems
   Email: fred@cisco.com



















Bi                    Expires October 18, 2010               [Page 21]


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