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

Versions: (draft-bi-savi-dhcp) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 RFC 7513

SAVI                                                      J. Bi, J. Wu
Internet Draft                                                 CERNET
Intended status: Standard Tracks                               G. Yao
Expires: November 2010                                  Tsinghua Univ.
                                                             F. Baker
                                                                Cisco
                                                          May 28, 2010



                          SAVI Solution for DHCP
                        draft-ietf-savi-dhcp-03.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

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




Bi                   Expires November 28, 2010               [Page 1]


Internet-Draft                savi-dhcp                       May 2010


   This Internet-Draft will expire on November 28, 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
   DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and a
   binding 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.

Table of Contents


   Copyright Notice ............................................... 2
   Abstract ....................................................... 2
   1. Introduction ................................................ 4
   2. Conventions used in this document............................ 4
   3. Mechanism Overview .......................................... 4
   4. Background and Related Protocols............................. 4
   5. Terminology ................................................. 5
   6. Conceptual Data Structures................................... 5
      6.1. Binding State Table (BST)............................... 5
      6.2. Filtering Table (FT).................................... 6
   7. Binding States Description................................... 6
   8. DHCP Scenario ............................................... 7
   9. Anchor Attributes ........................................... 7
      9.1. SAVI-Validation Attribute............................... 7
      9.2. SAVI-DHCP-Trust Attribute............................... 8
      9.3. SAVI-SAVI Attribute..................................... 8
      9.4. Optional Attributes..................................... 8
   10. Prefix Configuration........................................ 8
   11. Binding Set Up ............................................. 9


Bi                   Expires November 28, 2010               [Page 2]


Internet-Draft                savi-dhcp                       May 2010


      11.1. Process of Control Packet Snooping..................... 9
         11.1.1. Initialization.................................... 9
            11.1.1.1. Trigger Event................................ 9
            11.1.1.2. Event Validation............................. 9
            11.1.1.3. Following Actions............................ 9
         11.1.2. From START to LIVE............................... 11
            11.1.2.1. Trigger Event............................... 11
            11.1.2.2. Event Validation............................ 11
            11.1.2.3. Following Actions........................... 11
         11.1.3. From LIVE to DETECTION........................... 12
            11.1.3.2. Event Validation............................ 12
            11.1.3.3. Following Actions........................... 12
         11.1.4. From DETECTION to BOUND.......................... 12
            11.1.4.1. Trigger Event............................... 12
            11.1.4.2. Following Actions........................... 13
         11.1.5. Binding Deletion in DETECTION State.............. 13
            11.1.5.1. Trigger Event............................... 13
            11.1.5.2. Following Actions........................... 13
         11.1.6. After BOUND...................................... 13
      11.2. State Machine of DHCP Snooping........................ 14
   12. Supplemental Binding Process............................... 15
      12.1. Data Packet based Binding Process..................... 16
         12.1.1. SAVI-DataBased Attribute......................... 16
         12.1.2. Data Packet based Binding Process................ 16
      12.2. External Control Packet Snooping Process.............. 18
         12.2.1. SAVI-ExtSnooping Attribute....................... 18
         12.2.2. Extended Control Packet Snooping................. 18
   13. Filtering Specification.................................... 18
      13.1. Data Packet Filtering................................. 19
      13.2. Control Packet Filtering.............................. 19
   14. Format and Delivery of Probe Messages...................... 20
      14.1. Duplicate detection................................... 20
   15. Binding Remove ............................................ 20
   16. Handle Anchor Off-link event............................... 20
   17. About Collision in Detection............................... 21
      17.1. Whether to Notify the DHCP Server..................... 21
      17.2. The Result of Detection without Host Aware............ 21
   18. Filtering during Detection................................. 21
   19. Binding Number Limitation.................................. 22
   20. MLD Consideration ......................................... 22
   21. State Restoration ......................................... 22
   22. Stateless DHCP ............................................ 23
   23. Confirm Triggered Binding.................................. 23
   24. Handle Layer 2 Path Change................................. 23
   25. Duplicate Bindings on Same Address......................... 23
   26. Constants ................................................. 24
   27. Security Considerations.................................... 24


Bi                   Expires November 28, 2010               [Page 3]


Internet-Draft                savi-dhcp                       May 2010


   28. IANA Considerations........................................ 24
   29. References ................................................ 24
      29.1. Normative References.................................. 24
      29.2. Informative References................................ 24
   30. Acknowledgments ........................................... 25

1. Introduction

   This document describes the procedure for creating bindings between
   DHCP assigned addresses and an 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 inspired by the work of IP Source Guard [IP
   Source Guard]. This solution differs from IP Source Guard in the
   specification for collision detection, which is essential in
   environments with multiple address assignment methods. There are also
   other differences in details.

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 DHCP snooping to set up bindings between DHCP
   assigned IP addresses and corresponding anchors. The bindings can be
   used to validate the source address in the packets.

4. Background and Related Protocols

   This mechanism is an instance of a SAVI [savi-framework] solution,
   specialized for addresses assigned using the DHCP protocol.

   Dynamic Host Configuration Protocol version 4 [RFC2131] and Dynamic
   Host Configuration Protocol version 6 [RFC3315] specify the


Bi                   Expires November 28, 2010               [Page 4]


Internet-Draft                savi-dhcp                       May 2010


   procedures for providing a client with assigned address and other
   configuration information from a DHCP server. If a client gets an
   address through the DHCP protocol, the address should be regarded as
   a potential "authorized" or "registered" address of the client.

   In IPv6, IPv6 Stateless Autoconfiguration [RFC4862] is used as
   another address assignment mechanism. A node can use this mechanism
   to auto-configure an IPv6 address. A DHCPv6 client may use a
   stateless address to send message to DHCP server. Even in a DHCPv6-
   only environment, a node must assign its link-local address through
   this mechanism. [RFC4862] clearly requires that duplicated address
   detection must be performed on any IPv6 address, including DHCPv6
   address.

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

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

5. Terminology

   Main terms used in this document are described in [savi-framework],
   [RFC2131] and [RFC3315].

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

6.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
   entry has a lifetime field recording the remaining lifetime of the
   entry, a state field recording the state of the binding and a field
   recording other information.




Bi                   Expires November 28, 2010               [Page 5]


Internet-Draft                savi-dhcp                       May 2010


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


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

7. Binding States Description

   This section describes the binding states of this mechanism.

   START        A DHCP request (or a DHCPv6 Confirm, or a DHCPv6
   Solicitation with Rapid Commit option) has been received from host,
   and it may trigger a new binding.

   LIVE       A DHCP address has been acknowledged by a DHCP server.

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

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






Bi                   Expires November 28, 2010               [Page 6]


Internet-Draft                savi-dhcp                       May 2010


8. DHCP Scenario

   Figure 3 shows the main elements in a DHCP enabled network. At least
   one DHCP server MUST be deployed in the network, and DHCP relay MAY
   be used to relay message between client and server. Other address
   assignment mechanisms may be also used in such network.

                                +--------+
                                | DHCP   |
                                | Server |
                                +-------,+
                                    |
                                    |
                                    |
                               +----'-----+
                               |  SAVI    |
                               |  Device  |
                               +-/------/-+
                                 |      |
                            +----\-+   +\-----+
                            |DHCP  |   |Client|
                            |Relay |   |      |
                            +------+   +------+
                          Figure 3 DHCP Scenario

9. 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, server type DHCP message from this
   anchor MUST be dropped. However, other packets SHOULD NOT be dropped.

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





Bi                   Expires November 28, 2010               [Page 7]


Internet-Draft                savi-dhcp                       May 2010


9.2. SAVI-DHCP-Trust Attribute

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

   If DHCP is used to assign address in the network, there MUST be at
   least one anchor with this attribute. DHCP Reply message not coming
   from such ports MUST be dropped.

9.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 message will also be trusted.

   This attribute is mutually exclusive with SAVI-Validation.

9.4. Optional Attributes

   Section 12 describes some optional attributes. At least one of these
   attributes MUST be implemented.

10. Prefix Configuration

   In DHCP scenario, address advertised by DHCP server should be
   believed in. However, in this solution, a node shares the same anchor
   as the DHCP server can disguise as the DHCP server and offer the
   client incorrect configuration information. Without fully deployment
   of SAVI, this problem is difficult to solve. Thus, it is SUGGESTED
   that correct address prefix should be configured, and DHCP server
   message which assigns address out of the scope should be dropped.
   This mechanism can ensure the client can at least get an address with
   proper prefix.

   The SAVI device enabled this solution SHOULD set allowed prefix
   through RA snooping, DHCP-PD protocol, or manual configuration.

   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 November 28, 2010               [Page 8]


Internet-Draft                savi-dhcp                       May 2010


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

11.1. Process of Control Packet Snooping

11.1.1. Initialization

   A binding entry is initialized in this step.

11.1.1.1. Trigger Event

   A DHCPv4/v6 Request or a DHCPv6 Confirm or a DHCPv6 Solicitation with
   Rapid Commit option is received.

   Or a DHCP Reply is received from anchor with SAVI-DHCP-Trust
   attribute. Note that vulnerability may be caused by DHCP Reply
   triggered initialization. The binding of assigned address and anchor
   may be threatened if the binding mechanism between anchor and link
   layer address is not secure. If one of the following conditions is
   satisfied, the security can be ensured.

   1. Option 82 is used to keep anchor in DHCP Request and Reply, or

   2. Unspoofable MAC is used as anchor(802.11i,802.1ae/af), or

   3. The mapping table from MAC to anchor is secure.

   It is SUGGESTED not to initialize a binding based on DHCP Reply,
   until the associated mechanism is also implemented.

11.1.1.2. Event Validation

   The SAVI device checks current BST as follows:

   1. Whether the limitation on binding entry number of this anchor will
      be exceeded if a new entry is triggered.

11.1.1.3. Following Actions

   If the check fails, the triggering message SHOULD be discarded. This
   event MAY be announced on console interface.

   If the check is passed:



Bi                   Expires November 28, 2010               [Page 9]


Internet-Draft                savi-dhcp                       May 2010


   If the triggering message is DHCP Request/Confirm/Solicitation with
   Rapid Commit Option:

   The SAVI device MUST forward the message.

   The SAVI device MUST generate an entry for the anchor in the Binding
   State Table (BST) and set the state field to START. The lifetime of
   this entry MUST set to be MAX_DHCP_RESPONSE_TIME. The Transaction ID
   (Refer to Section 2 in [RFC2131] and Section 4.2 in [RFC3315]) field
   of the request packet SHOULD be recorded in the entry.

   +---------+----------+-------+-----------------------+-------+
   | Anchor  | Address  | State | Lifetime              |Other  |
   +---------+----------+-------+-----------------------+-------+
   | A       |          | START |MAX_DHCP_RESPONSE_TIME | TID   |
   +---------+----------+-------+-----------------------+-------+
      Figure 4 Binding entry in BST on client triggered initialization

   The TID is kept as a mediator of assigned address and the anchor of
   requesting node, to assure that the assigned address can be bound
   with anchor secure.

   If the triggering message is DHCP Reply:

   The SAVI device MUST deliver the message to the destination.

   The SAVI device MUST generate a new entry in BST and FT. The anchor
   in entry is looked up based on the destination link layer address,
   from mapping table from link layer address to anchor (e.g., the MAC-
   Port mapping table in case that port is used as anchor). The state of
   the corresponding entry is set to be LIVE. The lifetime of the entry
   MUST be set to be MAX_ARP_PREPARE_DELAY or MAX_DAD_PREPARE_DELAY
   respectively. The lease time MUST be recorded in the entry.

   +---------+----------+-------+------------------------+-------+
   | Anchor  | Address  | State | Lifetime               |Other  |
   +---------+----------+-------+------------------------+-------+
   | A       | Addr     | LIVE  |MAX_ARP_PREPARE_DELAY or| Lease |
   |         |          |       |MAX_DAD_PREPARE_DELAY   | Time  |
   +---------+----------+-------+------------------------+-------+
      Figure 5 Binding entry in BST on Reply triggered initialization








Bi                   Expires November 28, 2010              [Page 10]


Internet-Draft                savi-dhcp                       May 2010


                          +---------+----------+
                          |Anchor   |Address   |
                          +---------+----------+
                          |A        |Addr      |
                          +---------+----------+
       Figure 6 Binding entry in FT on Reply triggered initialization



11.1.2. From START to LIVE

11.1.2.1. Trigger Event

   A DHCPv4 DHCPACK or DHCPv6 REPLY message is received from SAVI-DHCP-
   Trust anchor.

11.1.2.2. Event Validation

   The SAVI device checks the message and BST as follows:

   1. Whether there exists an entry in the BST with corresponding TID in
      the START state.

11.1.2.3. Following Actions

   If the check fails, the message may be used to trigger binding
   initialization, specified in section 11.1.1.

   If the check is passed:

   The SAVI device MUST deliver the message to the destination.

   The state of the corresponding entry is changed to be LIVE. The
   lifetime of the entry MUST be set to be MAX_ARP_PREPARE_DELAY or
   MAX_DAD_PREPARE_DELAY respectively. The lease time MUST be recorded
   in the entry.

   +---------+----------+-------+------------------------+-------+
   | Anchor  | Address  | State | Lifetime               |Other  |
   +---------+----------+-------+------------------------+-------+
   | A       | Addr     | LIVE  |MAX_ARP_PREPARE_DELAY or| Lease |
   |         |          |       |MAX_DAD_PREPARE_DELAY   | Time  |
   +---------+----------+-------+------------------------+-------+
                        Figure 7 From START to LIVE

   A corresponding entry MUST also be generated in FT.



Bi                   Expires November 28, 2010              [Page 11]


Internet-Draft                savi-dhcp                       May 2010


11.1.3. From LIVE to DETECTION

11.1.3.1. Trigger Event

   A gratuitous ARP Request or Duplicate Address Detection Neighbor
   Solicitation is received from anchor. Or a timeout event of an entry
   with state LIVE happens.

11.1.3.2. Event Validation

   The SAVI device checks the message and BST as follows:

   1. Whether the Target IP Address field of the ARP Request or Neighbor
      Solicitation has been bound with the corresponding anchor in BST
      or FT, and the state in BST must be LIVE.

11.1.3.3. Following Actions

   If the check fails because of the Target Address is not in BST, the
   packet MUST be discarded. If the entry state is not LIVE, the message
   MUST be forwarded.

   If the check is passed:

   If the event is triggered by client, SAVI device MUST set the state
   of the corresponding entry to be DETECTION.

        +---------+----------+-----------+-----------------+-------+
        | Anchor  | Address  | State     | Lifetime        |Other  |
        +---------+----------+-----------+-----------------+-------+
        | A       | Addr     | DETECTION |MAX_ARP_DELAY or | Lease |
        |         |          |           |MAX_DAD_DELAY    | Time  |
        +---------+----------+-----------+-----------------+-------+
                      Figure 8 From LIVE to DETECTION

   If the triggering event is timeout event, the SAVI device MUST send
   one or more ARP Request or DAD NSOL, with Target Address set to the
   recorded address in the entry. The format of detection packet is
   specified in section 14. The state MUST be changed to DETECTION. The
   lifetime of the entry MUST be set to be MAX_ARP_DELAY or
   MAX_DAD_DELAY respectively.

11.1.4. From DETECTION to BOUND

11.1.4.1. Trigger Event

   A timeout event of an entry with state DETECTION occurs.


Bi                   Expires November 28, 2010              [Page 12]


Internet-Draft                savi-dhcp                       May 2010


11.1.4.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 Lease time acknowledged by DHCP server.

   +---------+----------+-----------+----------------+-------+
   | Anchor  | Address  | State     | Lifetime       |Other  |
   +---------+----------+-----------+----------------+-------+
   | A       | Addr     | BOUND     | Lease time     |       |
   +---------+----------+-----------+----------------+-------+
               Figure 9 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.

11.1.5. Binding Deletion in DETECTION State

11.1.5.1. Trigger Event

   An ARP Response or NA/DAD NS targeting at an address in BST with
   state DETECTION is received from a different anchor.

11.1.5.2. Following Actions

   If ARP Response or NA is received from anchor with SAVI-Validation
   attribute, but the address is not bound with the anchor, the packet
   MUST be dropped. If DAD NS is received from anchor with SAVI-
   Validation, the message MUST be delivered to the former detecting
   node. The binding SHOULD be removed.

   If the message is received from anchor with SAVI-Validation attribute,
   and the address is bound with anchor, the message MUST be delivered
   to the detecting node, and the binding MUST be removed.

   If the message is received from anchor without SAVI-Validation
   attribute, the message MUST be delivered to the detecting node. The
   binding SHOULD be removed.

11.1.6. 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. On
   the other hand, DHCP messages with the anchor will affect the binding.
   The binding is also affected by DHCP server message toward the anchor.



Bi                   Expires November 28, 2010              [Page 13]


Internet-Draft                savi-dhcp                       May 2010


   Before a DHCP message is found that it may change the corresponding
   binding, its validity MUST be checked as described in section 13.2.

   Whenever a DHCP Decline is received, delete the corresponding entry
   in BST and FT.

   Whenever a DHCP Release is received, if the state of the entry is
   BOUND, delete the entry in BST and FT.

   If a DHCPv4 Acknowledgement or DHCPv6 Reply with Renew/Rebind sign is
   received from the server, set lifetime of the entry in BST to be the
   new lease time.

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

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

11.2. State Machine of DHCP Snooping

   The main state transits are listed as follows. Note that precondition
   of state transit is not included. Triggering message/event must
   satisfy the preconditions before changing the state.

   State      Message/Event       Action                      Next State

   -          REQ/CFM/SOL+RC      Generate entry                   START

   *-         ACK/RPL             Generate entry with lease         LIVE

   START      ACK/RPL             Record lease time                 LIVE

   START      Timeout             Remove entry                         -

   LIVE       Gra ARP REQ/DAD NS  -                            DETECTION

   LIVE       DECLINE/RELEASE     Remove entry                         -

   LIVE       Timeout             Send probe                   DETECTION

   DETECTION  Timeout             -                                BOUND

   DETECTION  ARP RES/DAD NS/NA   Remove entry                         -

   DETECTION  DECLINE/RELEASE     Remove entry                         -


Bi                   Expires November 28, 2010              [Page 14]


Internet-Draft                savi-dhcp                       May 2010


   BOUND      RELEASE/DECLINE     Remove entry                         -

   BOUND      Timeout             Remove entry                         -

   BOUND      RPL with REN/REB    Set new lifetime                 BOUND

   *: optional but NOT SUGGESTED.

   REQ: DHCP REQUEST

   CFM: DHCP CONFIRM

   SOL: DHCP SOLICITATION

   RC:  Rapid Commit option

   ACK: DHCP ACKNOWLEDGEMENT

   RPL: DHCP REPLY

   Probe Gratuitous ARP REQUEST or Duplicate Address Detection Neighbor
   Solicitation, described in section 11.1.3 and section 14.

   Gra ARP REQ: Gratuitous ARP REQUEST

   ARP RES: ARP RESPONSE

   DAD NS: Duplicate Address Detection Neighbor Solicitation

   DAD NA: Neighbor Advertisement targeting at a tentative address

   DECLINE: DHCP DECLINE

   RELEASE: DHCP RELEASE

   REN: DHCP RENEW

   REB: DHCP REBOUND

12. Supplemental Binding Process

   Supplemental binding process is designed to cover conditions that
   packet is sent by node without previous DHCP procedure sensed by the
   SAVI device. A typical situation is that the layer-2 path changes
   after the binding has been set up, then the node will send packet to
   a different port with the bound port. Another scenario is that a node
   moves on the local link without re-configuration process. In DHCP


Bi                   Expires November 28, 2010              [Page 15]


Internet-Draft                savi-dhcp                       May 2010


   scenario, till this document is finished, layer-2 path change and
   local link movement are the only two events that must be handled
   through this supplemental binding process.

   This process is designed to avoid permanent legitimate traffic
   blocking. It is not supposed to set up a binding whenever a data
   packet with unbound source address is received. Generally, longer
   time and more packets are needed to trigger supplemental binding
   processes.

   For implementations that will face the above problem:

   1. Binding Recovery Process is a conditional MUST. If an
      implementation has sufficient capability to handle the potential
      overhead and security risk, and has ability to meet the specified
      requirements in hardware which may exceed general implementation
      practice, and the market of this implementation clearly requires
      this process, this process MUST be implemented.

   2. Extended Control Packet Snooping Process is a MUST.

   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.

12.1. Binding Recovery Process

12.1.1. SAVI-BindRecovery Attribute

   If binding recovery process is implemented as a supplemental binding
   process, an additional anchor attribute, named SAVI-BindRecovery,
   MUST be implemented.

   This attribute is mutually exclusive with SAVI-SAVI.

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

12.1.2. Bind Recovery Process

   Refer to [draft-baker-savi-one-implementation-approach] for a
   detailed implementation suggestion. The process specified here can
   only be enabled in condition that implementation can meet the
   specified hardware requirements described in [draft-baker-savi-one-
   implementation-approach].




Bi                   Expires November 28, 2010              [Page 16]


Internet-Draft                savi-dhcp                       May 2010


   If an anchor is set to have SAVI-BindRecovery attribute, a FIFO queue
   or register MUST be used to save recently filtered packets. The SAVI
   device will fetch packet from the queue/register to check the source
   address can be used by corresponding 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. If the address is not
      being used, go to the next step.

   2.

   IPv4 address:

   Send a DHCPLEASEQUERY [RFC4388] message querying by IP address to all
   DHCPv4 servers for IPv4 address or a configured server address. The
   server addresses may be discovered through DHCPv4 Discovery. If no
   DHCPLEASEACTIVE message is received, discard the packet; otherwise
   generate a new binding entry for the address.

   IPv6 address:

   Send a LEASEQUERY [RFC5007] message querying by IP address to
   All_DHCP_Relay_Agents_and_Servers multicast address or a configured
   server address. If no successful LEASEQUERY-REPLY is received,
   discard the packet; otherwise generate a new binding entry for the
   address. The SAVI device may repeat this process if a LEASEQUERY-
   REPLY with OPTION_CLIENT_LINK is received, in order to set up binding
   entries for all the address of the client.

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

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

   In case that the SAVI device is a pure layer-2 device, DHCP Confirm
   MAY be used to replace the DHCP LEASEQUERY. The security degree may
   degrade for the address may not be assigned by DHCP server.

   This process may fail if any DHCP server doesn't support LEASEQUERY.




Bi                   Expires November 28, 2010              [Page 17]


Internet-Draft                savi-dhcp                       May 2010


12.2. External Control Packet Snooping Process

12.2.1. SAVI-ExtSnooping Attribute

   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.

12.2.2. Extended Control Packet Snooping

   In this snooping process, other than DHCP initialization 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; (6) DHCP Renew/Rebind. Other ICMP
   messages that may be processed by intermediate device may also
   trigger the binding process.

   The SAVI device MUST first perform DAD to check if the address has a
   local conflict, and then send DHCP LEASEQUERY or Confirm to recover
   binding based on DHCP server message.

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

   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.

13. 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. Considering DHCP may coexist with
   other address assignment methods, e.g., Stateless Auto-configuration,
   the specification made here is based on the assumption that other


Bi                   Expires November 28, 2010              [Page 18]


Internet-Draft                savi-dhcp                       May 2010


   SAVI solutions will also use BST and FT to keep bindings and filter
   packets. Otherwise this solution will conflict with other SAVI
   solutions.

   Filtering policies are different for data packet and control packet.
   DHCP and 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.

13.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 SHOULD be
   discarded, or alternatively the SAVI SHOULD record this violation.

13.2. Control Packet Filtering

   For anchors with SAVI-Validation attribute:

   The source address of DHCPv4 Discovery MUST be set to all zeros. The
   source address of DHCPv4 Request MUST be set to all zeros or a bound
   address in FT.

   The source address of DHCPv6 Request MUST be an address associated
   with the corresponding anchor in FT. The source address of DHCPv6
   Confirm MUST be a link local address associated with the
   corresponding anchor in FT. The source address of DHCPv6 Solicit MUST
   be a link layer address bound with corresponding anchor. The link
   layer address MAY be bound based on SAVI-SLAAC solution or other
   solutions.

   The source address of other types of DHCP messages MUST be an address
   bound with the corresponding anchor.

   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:



Bi                   Expires November 28, 2010              [Page 19]


Internet-Draft                savi-dhcp                       May 2010


   All DHCP Reply/Ack packets MUST be from anchor with the SAVI-DHCP-
   Trust attribute.

14. Format and Delivery of Probe Messages

   As described in section 11.1.3, the SAVI device MAY send detection
   probes on behavior of client to determine whether the assigned
   address is duplicated. Currently no other probes are designed in this
   solution.

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

15. Binding Remove

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

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



Bi                   Expires November 28, 2010              [Page 20]


Internet-Draft                savi-dhcp                       May 2010


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

   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,
   and then it can use the address assigned to the previous node.
   However, this situation is very rare in reality. Authors decide not
   to handle this situation.

17. About Collision in Detection

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

17.1. Whether to Notify the DHCP Server

   It is unnecessary for the SAVI device to notify the DHCP server,
   because the host will send a DECLINE message to it once it finds the
   advertised address is conflict.

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

18. Filtering during Detection

   In this mechanism, whenever the DHCP server replies an address, 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. A
   practical solution for this vulnerability is configuring the address
   pool and allocation algorithm of the DHCP server carefully.




Bi                   Expires November 28, 2010              [Page 21]


Internet-Draft                savi-dhcp                       May 2010


19. 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 DHCP Request rate per anchor, using the bound entry number
      of each anchor as reverse indicator.

20. MLD Consideration

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

21. 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 MUST be saved into non-volatile storage
   whenever a new binding entry changes to BOUND state or a binding with
   state BOUND is removed in condition that this function is supported
   by hardware, 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-
   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 alternatives are:

   If the SAVI device is also the DHCP relay, an alternative mechanism
   is fetching the bindings through bulk DHCP LEASEQUERY [RFC5460].

   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.


Bi                   Expires November 28, 2010              [Page 22]


Internet-Draft                savi-dhcp                       May 2010


22. Stateless DHCP

   In a stateless DHCP scenario [RFC3736], DHCP is used to configure
   other parameters but rather IP address. The address of the client
   SHOULD be bound based on other SAVI solutions, but rather this
   solution designed for stateful DHCP.

23. Confirm Triggered Binding

   If a binding entry is triggered by a CONFIRM message from the client,
   no lease time will be contained in the REPLY from DHCP server. The
   SAVI device MUST send LEASEQUERY message to get the lease time of the
   address to complete the binding entry. If no successful LEASEQUERY-
   REPLY is received, the binding entry SHOULD be removed. In this
   scenario, the address is not regarded as assigned by DHCP, and it may
   be bound through other SAVI solution.

   If the confirmed address has local conflict, the Client-ID field of
   Confirm and LEASEQUERY-REPLY MUST be compared. If they are not match,
   the new binding entry MUST be deleted.

24. 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
   SHOULD be enabled on the anchor for a period, or alternatively the
   device SHOULD forward the packets directly for a period, and set up
   bindings from Neighbor Table. 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.

25. Duplicate Bindings on Same Address

   Note that the same address may be bound with multiple anchors, only
   if the binding processes are finished on each anchor successfully
   respectively.

   This mechanism is designed in consideration that a node may move on
   the local ink, and a node may have multiple anchors.

   Note that the local link movement scenario is not handled perfectly.
   The former binding may not be removed, unless the node is directly



Bi                   Expires November 28, 2010              [Page 23]


Internet-Draft                savi-dhcp                       May 2010


   attached to the SAVI device. The nodes sharing the same former anchor
   of the moving node have the ability to use its address.

26. Constants

   MAX_DHCP_RESPONSE_TIME     120s

   MAX_ARP_PREPARE_DELAY      Default 1s but configurable

   MAX_ARP_DELAY              Default 1s but configurable

   MAX_DAD_PREPARE_DELAY      Default 1s but configurable

   MAX_DAD_DELAY              Default 1s but configurable

   BIND_RECOVERY_INTERVAL     Device capacity depended and configurable

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

28. IANA Considerations

   There is no IANA consideration currently.

29. References

29.1. Normative References

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

29.2. Informative References

   [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC2131,
   March 1997.

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

   [RFC3315] R. Droms, Ed. "Dynamic Host Configuration Protocol for IPv6
   (DHCPv6)", RFC3315, July 2003.



Bi                   Expires November 28, 2010              [Page 24]


Internet-Draft                savi-dhcp                       May 2010


   [RFC4388] R. Woundy and K. Kinnear, "Dynamic Host Configuration
   Protocol (DHCP) Leasequery", RFC4388, February 2006.

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

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

   [RFC5007] J. Brzozowski, K. Kinnear, B. Volz, S. Zeng, "DHCPv6
   Leasequery", RFC5007, September 2007.

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

   [IP Source Guard] Cisco, "Network Security Technologies and
   Solutions", chapter 7, Cisco Press, May 20, 2008.

   [draft-baker-savi-one-implementation-approach] F. Baker, "An
   implementation approach to Source Address Validation",
   draft-baker-savi-one-implementation-approach-00.

30. 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 November 28, 2010              [Page 25]


Internet-Draft                savi-dhcp                       May 2010


Authors' Addresses

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

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

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

   Fred Baker
   Cisco Systems
   Email: fred@cisco.com


31. Change Log

   From 02 to 03: Section 12, data trigger and counter trigger are
   combined to binding recovery process. The expression "one of MUST" is
   changed to "conditional MUST. Conditions related with the
   implementation are specified. Related constants are changed in
   section 26."










Bi                   Expires November 28, 2010              [Page 26]


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