tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7513

Proposed STD
Pages: 54
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: SAVI

Source Address Validation Improvement (SAVI) Solution for DHCP

Part 1 of 3, p. 1 to 17
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                             J. Bi
Request for Comments: 7513                                         J. Wu
Category: Standards Track                                         G. Yao
ISSN: 2070-1721                                           Tsinghua Univ.
                                                                F. Baker
                                                                   Cisco
                                                                May 2015


     Source Address Validation Improvement (SAVI) Solution for DHCP

Abstract

   This document specifies the procedure for creating a binding between
   a DHCPv4/DHCPv6-assigned IP address and a binding anchor on a Source
   Address Validation Improvement (SAVI) device.  The bindings set up by
   this procedure are used to filter packets with forged source IP
   addresses.  This mechanism complements BCP 38 (RFC 2827) ingress
   filtering, providing finer-grained source IP address validation.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7513.

Copyright Notice

   Copyright (c) 2015 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.

Top       Page 2 
Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   5
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Deployment Scenario and Configuration . . . . . . . . . . . .   8
     4.1.  Elements and Scenario . . . . . . . . . . . . . . . . . .   8
     4.2.  SAVI Binding Type Attributes  . . . . . . . . . . . . . .  10
       4.2.1.  Trust Attribute . . . . . . . . . . . . . . . . . . .  10
       4.2.2.  DHCP-Trust Attribute  . . . . . . . . . . . . . . . .  11
       4.2.3.  DHCP-Snooping Attribute . . . . . . . . . . . . . . .  11
       4.2.4.  Data-Snooping Attribute . . . . . . . . . . . . . . .  11
       4.2.5.  Validating Attribute  . . . . . . . . . . . . . . . .  12
       4.2.6.  Table of Mutual Exclusions  . . . . . . . . . . . . .  13
     4.3.  Perimeter . . . . . . . . . . . . . . . . . . . . . . . .  13
       4.3.1.  SAVI-DHCP Perimeter Overview  . . . . . . . . . . . .  13
       4.3.2.  SAVI-DHCP Perimeter Configuration Guideline . . . . .  14
       4.3.3.  On the Placement of the DHCP Server and Relay . . . .  15
       4.3.4.  An Alternative Deployment . . . . . . . . . . . . . .  15
       4.3.5.  Considerations regarding Binding Anchors  . . . . . .  16
     4.4.  Other Device Configuration  . . . . . . . . . . . . . . .  17
   5.  Binding State Table (BST) . . . . . . . . . . . . . . . . . .  17
   6.  DHCP Snooping Process . . . . . . . . . . . . . . . . . . . .  18
     6.1.  Rationale . . . . . . . . . . . . . . . . . . . . . . . .  18
     6.2.  Binding States Description  . . . . . . . . . . . . . . .  19
     6.3.  Events  . . . . . . . . . . . . . . . . . . . . . . . . .  19
       6.3.1.  Timer Expiration Event  . . . . . . . . . . . . . . .  19
       6.3.2.  Control Message Arriving Events . . . . . . . . . . .  19
     6.4.  The State Machine of DHCP Snooping Process  . . . . . . .  21
       6.4.1.  Initial State: NO_BIND  . . . . . . . . . . . . . . .  21
       6.4.2.  Initial State: INIT_BIND  . . . . . . . . . . . . . .  24
       6.4.3.  Initial State: BOUND  . . . . . . . . . . . . . . . .  27
       6.4.4.  Table of State Machine  . . . . . . . . . . . . . . .  30
   7.  Data Snooping Process . . . . . . . . . . . . . . . . . . . .  31
     7.1.  Scenario  . . . . . . . . . . . . . . . . . . . . . . . .  31
     7.2.  Rationale . . . . . . . . . . . . . . . . . . . . . . . .  32
     7.3.  Additional Binding States Description . . . . . . . . . .  33
     7.4.  Events  . . . . . . . . . . . . . . . . . . . . . . . . .  33
     7.5.  Message Sender Functions  . . . . . . . . . . . . . . . .  35
       7.5.1.  Duplicate Detection Message Sender  . . . . . . . . .  35
       7.5.2.  Leasequery Message Sender . . . . . . . . . . . . . .  36
       7.5.3.  Address Verification Message Sender . . . . . . . . .  36
     7.6.  Initial State: NO_BIND  . . . . . . . . . . . . . . . . .  37
       7.6.1.  Event: EVE_DATA_UNMATCH: A data packet without a
               matched binding is received . . . . . . . . . . . . .  37
       7.6.2.  Events Not Observed in NO_BIND for Data Snooping  . .  38

Top      ToC       Page 3 
     7.7.  Initial State: DETECTION  . . . . . . . . . . . . . . . .  39
       7.7.1.  Event: EVE_ENTRY_EXPIRE . . . . . . . . . . . . . . .  39
       7.7.2.  Event: EVE_DATA_CONFLICT: ARP Reply / NA Message
               Received from Unexpected System . . . . . . . . . . .  39
       7.7.3.  Events Not Observed in DETECTION  . . . . . . . . . .  39
     7.8.  Initial State: RECOVERY . . . . . . . . . . . . . . . . .  40
       7.8.1.  Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE
               or successful LEASEQUERY-REPLY is received  . . . . .  40
       7.8.2.  Event: EVE_ENTRY_EXPIRE . . . . . . . . . . . . . . .  41
       7.8.3.  Events Not Observed in RECOVERY . . . . . . . . . . .  41
     7.9.  Initial State: VERIFY . . . . . . . . . . . . . . . . . .  41
       7.9.1.  Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE
               or successful LEASEQUERY-REPLY is received  . . . . .  41
       7.9.2.  Event: EVE_DATA_VERIFY: A valid ARP Reply or NA is
               received from the device attached via the binding
               anchor  . . . . . . . . . . . . . . . . . . . . . . .  42
       7.9.3.  Event: EVE_ENTRY_EXPIRE . . . . . . . . . . . . . . .  42
       7.9.4.  Event: EVE_DATA_EXPIRE  . . . . . . . . . . . . . . .  43
       7.9.5.  Events Not Observed in VERIFY . . . . . . . . . . . .  43
     7.10. Initial State: BOUND  . . . . . . . . . . . . . . . . . .  43
     7.11. Table of State Machine  . . . . . . . . . . . . . . . . .  44
   8.  Filtering Specification . . . . . . . . . . . . . . . . . . .  45
     8.1.  Data Packet Filtering . . . . . . . . . . . . . . . . . .  46
     8.2.  Control Packet Filtering  . . . . . . . . . . . . . . . .  46
   9.  State Restoration . . . . . . . . . . . . . . . . . . . . . .  47
     9.1.  Attribute Configuration Restoration . . . . . . . . . . .  47
     9.2.  Binding State Restoration . . . . . . . . . . . . . . . .  47
   10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . .  48
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  48
     11.1.  Security Problems with the Data Snooping Process . . . .  48
     11.2.  Securing Leasequery Operations . . . . . . . . . . . . .  49
     11.3.  Client Departure Issues  . . . . . . . . . . . . . . . .  49
     11.4.  Compatibility with Detecting Network Attachment (DNA)  .  50
     11.5.  Binding Number Limitation  . . . . . . . . . . . . . . .  51
     11.6.  Privacy Considerations . . . . . . . . . . . . . . . . .  51
     11.7.  Fragmented DHCP Messages . . . . . . . . . . . . . . . .  51
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  52
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  52
     12.2.  Informative References . . . . . . . . . . . . . . . . .  53
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  54
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  54

Top      ToC       Page 4 
1.  Introduction

   This document describes a fine-grained source address validation
   mechanism for IPv4 and IPv6 packets.  This mechanism creates bindings
   between IP addresses assigned to network interfaces by DHCP and
   suitable binding anchors (Section 4.3.5).  As discussed in Section 3
   and [RFC7039], a "binding anchor" is an attribute that is immutable
   or difficult to change that may be used to identify the system an IP
   address has been assigned to; common examples include a Media Access
   Control (MAC) address found on an Ethernet switch port or Wi-Fi
   security association.  The bindings are used to identify and filter
   packets originated by these interfaces using forged source IP
   addresses.  In this way, this mechanism can prevent hosts from using
   IP addresses assigned to any other attachment point in or not
   associated with the network.  This behavior is referred to as
   "spoofing" and is key to amplification attacks, in which a set of
   systems send messages to another set of systems claiming to be from a
   third set of systems, and sending the replies to systems that don't
   expect them.  Whereas BCP 38 [RFC2827] protects a network from a
   neighboring network by providing prefix granularity source IP address
   validity, this mechanism protects a network, including a Local Area
   Network, from itself by providing address granularity source IP
   validity when DHCP/DHCPv6 is used to assign IPv4/IPv6 addresses.
   Both provide a certain level of traceability, in that packet drops
   indicate the presence of a system that is producing packets with
   spoofed IP addresses.

   SAVI-DHCP snoops DHCP address assignments to set up bindings between
   IP addresses assigned by DHCP and corresponding binding anchors.  It
   includes the DHCPv4 and DHCPv6 Snooping Process (Section 6) and the
   Data Snooping Process (Section 7), as well as a number of other
   technical details.  The Data Snooping Process is a data-triggered
   procedure that snoops the IP header of data packets to set up
   bindings.  It is designed to avoid a permanent blockage of valid
   addresses in the case that DHCP snooping is insufficient to set up
   all the valid bindings.

   This mechanism is designed for the stateful DHCP scenario [RFC2131]
   [RFC3315].  Stateless DHCP [RFC3736] is out of scope for this
   document, as it has nothing to do with IP address allocation.  An
   alternative SAVI method would have be used in those cases.  For hosts
   using Stateless Address Autoconfiguration (SLAAC) to allocate
   addresses, First-Come, First-Served Source Address Validation
   Improvement (FCFS SAVI) [RFC6620] should be enabled.  SAVI-DHCP is
   primarily designed for pure DHCP scenarios in which only addresses
   assigned through DHCP are allowed.  However, it does not block link-

Top      ToC       Page 5 
   local addresses, as they are not assigned using DHCP.  It is
   RECOMMENDED that the administration deploy a SAVI solution for link-
   local addresses, e.g., FCFS SAVI [RFC6620].

   This mechanism works for networks that use DHCPv4 only, DHCPv6 only,
   or both DHCPv4 and DHCPv6.  However, the DHCP address assignment
   mechanism in IPv4/IPv6 transition scenarios, e.g., [RFC7341], are
   beyond the scope of this document.

2.  Requirements Language

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

   Binding anchor: A "binding anchor" is defined to be a physical and/or
   link-layer property of an attached device, as in [RFC7039].  A list
   of sample binding anchors can be found in Section 3.2 of that
   document.  To the degree possible, a binding anchor associates an IP
   address with something unspoofable that identifies a single-client
   system or one of its interfaces.  See Section 4.3.5 for more detail.

   Attribute: A configurable property of each binding anchor (port, MAC
   address, or other information) that indicates the actions to be
   performed on packets received from the attached network device.

   DHCP address: An IP address assigned via DHCP.

   SAVI-DHCP: The name of this SAVI function for DHCP-assigned
   addresses.

   SAVI device: A network device on which SAVI-DHCP is enabled.

   Non-SAVI device: A network device on which SAVI-DHCP is not enabled.

   DHCP Client-to-Server message: A message that is sent from a DHCP
   client to a DHCP server or DHCP servers and is one of the following
   types:

   o  DHCPv4 Discover: DHCPDISCOVER [RFC2131].

   o  DHCPv4 Request: DHCPREQUEST generated during SELECTING state
      [RFC2131].

   o  DHCPv4 Renew: DHCPREQUEST generated during RENEWING state
      [RFC2131].

Top      ToC       Page 6 
   o  DHCPv4 Rebind: DHCPREQUEST generated during REBINDING state
      [RFC2131].

   o  DHCPv4 Reboot: DHCPREQUEST generated during INIT-REBOOT state
      [RFC2131].

   o  Note: DHCPv4 Request/Renew/Rebind/Reboot messages can be
      identified based on Table 4 of [RFC2131].

   o  DHCPv4 Decline: DHCPDECLINE [RFC2131].

   o  DHCPv4 Release: DHCPRELEASE [RFC2131].

   o  DHCPv4 Inform: DHCPINFORM [RFC2131].

   o  DHCPv4 DHCPLEASEQUERY: A message sent to inquire about the lease
      that might exist for an IPv4 address [RFC4388].

   o  DHCPv6 Request: REQUEST [RFC3315].

   o  DHCPv6 Solicit: SOLICIT [RFC3315].

   o  DHCPv6 Confirm: CONFIRM [RFC3315].

   o  DHCPv6 Decline: DECLINE [RFC3315].

   o  DHCPv6 Release: RELEASE [RFC3315].

   o  DHCPv6 Rebind: REBIND [RFC3315].

   o  DHCPv6 Renew: RENEW [RFC3315].

   o  DHCPv6 Information-Request: INFORMATION-REQUEST [RFC3315].

   o  DHCPv6 LEASEQUERY: A message sent to inquire about the lease that
      might exist for an IPv6 address [RFC5007].

   DHCP Server-to-Client message: A message that is sent from a DHCP
   server to a DHCP client and is one of the following types:

   o  DHCPv4 ACK: DHCPACK [RFC2131].

   o  DHCPv4 NAK: DHCPNAK [RFC2131].

   o  DHCPv4 Offer: DHCPOFFER [RFC2131].

   o  DHCPv4 DHCPLEASEACTIVE: A response to a DHCPLEASEQUERY request
      containing lease information [RFC4388].

Top      ToC       Page 7 
   o  DHCPv4 DHCPLEASEUNKNOWN: A response to a DHCPLEASEQUERY request
      indicating that the server does not manage the address [RFC4388].

   o  DHCPv4 DHCPLEASEUNASSIGNED: A response to a DHCPLEASEQUERY request
      indicating that the server manages the address and there is no
      current lease [RFC4388].

   o  DHCPv6 Reply: REPLY [RFC3315].

   o  DHCPv6 Advertise: ADVERTISE [RFC3315].

   o  DHCPv6 Reconfigure: RECONFIGURE [RFC3315].

   o  DHCPv6 LEASEQUERY-REPLY: A response to a LEASEQUERY request
      [RFC5007].

   Lease time: The lease time in IPv4 [RFC2131] or the valid lifetime in
   IPv6 [RFC3315].

   Binding entry: A rule that associates an IP address with a binding
   anchor.

   Binding State Table (BST): The data structure that contains the
   binding entries.

   Binding entry limit: The maximum number of binding entries that may
   be associated with a binding anchor.  Limiting the number of binding
   entries per binding anchor prevents a malicious or malfunctioning
   node from overloading the binding table on a SAVI device.

   Direct attachment: Ideally, a SAVI device is an access device that
   hosts are attached to directly.  In such a case, the hosts are direct
   attachments (i.e., they attach directly) to the SAVI device.

   Indirect attachment: A SAVI device MAY be an aggregation device that
   other access devices are attached to and that hosts in turn attach
   to.  In such a case, the hosts are indirect attachments (i.e., they
   attach indirectly) to the SAVI device.

   Unprotected link: Unprotected links are links that connect to hosts
   or networks of hosts that receive their DHCP traffic by another path
   and are therefore outside the SAVI perimeter.

   Unprotected device: An unprotected device is a device associated with
   an unprotected link.  One example might be the gateway router of a
   network.

Top      ToC       Page 8 
   Protected link: If DHCP messages for a given attached device always
   use a given link, the link is considered to be "protected" by the
   SAVI device and is therefore within the SAVI perimeter.

   Protected device: A protected device is a device associated with a
   protected link.  One example might be a desktop switch in the
   network, or a host.

   Cut vertex: A cut vertex is any vertex whose removal increases the
   number of connected components in a (network) graph.  This is a
   concept in graph theory.  This term is used in Section 6.1 to
   accurately specify the required deployment location of SAVI devices
   when they only perform the DHCP Snooping Process.

   Identity Association (IA): "A collection of addresses assigned to a
   client" [RFC3315].

   Detection message: A Neighbor Solicitation or ARP message intended by
   the Data Snooping Process to detect a duplicate address.

   DHCP_DEFAULT_LEASE: Default lifetime for a DHCPv6 address when the
   binding is triggered by a DHCPv6 Confirm message but a DHCPv6
   Leasequery exchange [RFC5007] cannot be performed by the SAVI device
   to fetch the lease.

4.  Deployment Scenario and Configuration

4.1.  Elements and Scenario

   The essential elements in a SAVI-DHCP deployment scenario include at
   least one DHCP server (which may or may not be assigned an address
   using DHCP and therefore may or may not be protected), zero or more
   protected DHCP clients, and one or more SAVI devices.  It may also
   include DHCP relays, when the DHCP server is not co-located with a
   set of clients, and zero or more protected non-SAVI devices.  Outside
   the perimeter, via unprotected links, there may be many unprotected
   devices.

Top      ToC       Page 9 
                                 +-------------+
                                 | Unprotected |
                                 |   Device    |
                                 +------+------+
                                        |
                   +--------+     +-----+------+    +----------+
                   |DHCP    +-----+  Non-SAVI  +----+Bogus DHCP|
                   |Server A|     |  Device 1  |    |Server    |
                   +--------+     +-----+------+    +----------+
                                        |trusted, unprotected link
       . . . . . . . . . . . . . . . . .|. . . . . . . . . . . . . .
      .                                 |                           .
      .             Protection      +---+------+ trusted link       .
      .             Perimeter       | SAVI     +--------------+     .
      .                             | Device C |              |     .
      .                             +---+------+              |     .
      .                                 |                     |     .
      .  untrusted, +----------+    +---+------+       +------+---+ .
      .  protected  | SAVI     |    | Non-SAVI |       | SAVI     | .
      .  link+------+ Device A +----+ Device 3 +-------+ Device B | .
      .      |      +----+--+--+    +----------+       +-+---+----+ .
      .      |           |  +----------+    . . . .  .   |   |      .
      .      |       . . . . . .       |   .          .  |   |      .
      .      |      .    |      .      |   .    +--------+   |      .
      . +----+-----+. +--+---+  . +----+-+ . +--+---+ .  +---+----+ .
      . | Non-SAVI |. |Client|  . |DHCP  | . |Client| .  |DHCP    | .
      . | Device 2 |. |A     |  . |Relay | . |B     | .  |Server B| .
      . +----------+. +------+  . +------+ . +------+ .  +--------+ .
       . . . . . . .             . . . . .             . . . . . . .

                       Figure 1: SAVI-DHCP Scenario

   Figure 1 shows a deployment scenario that contains these elements.
   Note that a physical device can instantiate multiple elements, e.g.,
   a switch can be both a SAVI device and a DHCP relay, or in a cloud-
   computing environment, a physical host may contain a virtual switch
   plus some number of virtual hosts.  In such cases, the links are
   logical links rather than physical links.

   Networks are not usually isolated.  As a result, traffic from other
   networks, including transit traffic as specified in [RFC6620] (e.g.,
   traffic from another SAVI switch or a router) may enter a SAVI-DHCP
   network through the unprotected links.  Since SAVI solutions are
   limited to validating traffic generated from a local link, SAVI-DHCP
   does not set up bindings for addresses assigned in other networks and
   cannot validate them.  Traffic from unprotected links should be
   checked by an unprotected device or mechanisms described in

Top      ToC       Page 10 
   [RFC2827].  The generation and deployment of such a mechanism is
   beyond the scope of this document.

   Traffic from protected links is, however, locally generated and
   should have its source addresses validated by SAVI-DHCP if possible.
   In the event that there is an intervening protected non-SAVI device
   between the host and the SAVI device, however, use of the physical
   attachment point alone as a binding anchor is insufficiently secure,
   as several devices on a port or other point of attachment can spoof
   each other.  Hence, additional information such as a MAC address
   SHOULD be used to disambiguate them.

4.2.  SAVI Binding Type Attributes

   As illustrated in Figure 1, a system attached to a SAVI device can be
   a DHCP client, a DHCP relay/server, a SAVI device, or a non-SAVI
   device.  Different actions are performed on traffic originated from
   different elements.  To distinguish among their requirements, several
   properties are associated with their point of attachment on the SAVI
   device.

   When a binding association is uninstantiated, e.g., when no host is
   attached to the SAVI device using a given port or other binding
   anchor, the binding port attributes take default values unless
   overridden by configuration.  By default, a SAVI switch does not
   filter DHCP messages, nor does it attempt to validate source
   addresses, which is to say that the binding attributes are ignored
   until SAVI-DHCP is itself enabled.  This is because a SAVI switch
   that depends on DHCP cannot tell, a priori, which ports have valid
   DHCP servers attached, or which have routers or other equipment that
   would validly appear to use an arbitrary set of source addresses.
   When SAVI has been enabled, the attributes take effect.

4.2.1.  Trust Attribute

   The "Trust Attribute" is a Boolean value.  If TRUE, it indicates that
   the packets from the corresponding attached device need not have
   their source addresses validated.  Examples of a trusted attachment
   would be a port to another SAVI device, or to an IP router, as shown
   in Figure 1.  In both cases, traffic using many source IP addresses
   will be seen.  By default, the Trust attribute is FALSE, indicating
   that any device found on that port will seek an address using DHCP
   and be limited to using such addresses.

   SAVI devices will not set up bindings for points of attachment with
   the Trust attribute set TRUE; no packets, including DHCP messages,
   from devices with this attribute on their attachments will be
   validated.  However, DHCP Server-to-Client messages will be snooped

Top      ToC       Page 11 
   on attachment points with the Trust attribute set TRUE in the same
   way as if they had the DHCP-Trust attribute set (see Section 4.2.2).

4.2.2.  DHCP-Trust Attribute

   The "DHCP-Trust Attribute" is similarly a Boolean attribute.  It
   indicates whether the attached device is permitted to initiate DHCP
   Server-to-Client messages.  In Figure 1, the points of attachment of
   the DHCP server and the DHCP relay would have this attribute set
   TRUE, and attachment points that have Trust set TRUE are implicitly
   treated as if DHCP-Trust is TRUE.

   If the DHCP-Trust attribute is TRUE, SAVI devices will forward DHCP
   Server-to-Client messages from the points of attachment with this
   attribute.  If the DHCP Server-to-Client messages can trigger the
   state transitions, the binding setup processes specified in Sections
   6 and 7 will handle them.  By default, the DHCP-Trust attribute is
   FALSE, indicating that the attached system is not a DHCP server.

   A DHCPv6 implementor can refer to [DHCPv6-SHIELD] for more details.

4.2.3.  DHCP-Snooping Attribute

   The "DHCP-Snooping Attribute" is similarly a Boolean attribute.  It
   indicates whether bindings will be set up based on DHCP snooping.

   If this attribute is TRUE, DHCP Client-to-Server messages to points
   of attachment with this attribute will trigger creation of bindings
   based on the DHCP Snooping Process described in Section 6.  If it is
   FALSE, either the Trust attribute must be TRUE (so that bindings
   become irrelevant) or another SAVI mechanism such as FCFS SAVI must
   be used on the point of attachment.

   The DHCP-Snooping attribute is configured on the DHCP client's point
   of attachment.  This attribute can be also used on the attachments to
   protected non-SAVI devices that are used by DHCP clients.  In
   Figure 1, the attachment from Client A to SAVI Device A, the
   attachment from Client B to SAVI Device B, and the attachment from
   Non-SAVI Device 2 to SAVI Device A can be configured with this
   attribute.

4.2.4.  Data-Snooping Attribute

   The "Data-Snooping Attribute" is a Boolean attribute.  It indicates
   whether data packets from the corresponding point of attachment may
   trigger the binding setup procedure.

Top      ToC       Page 12 
   Data packets from points of attachment with this attribute may
   trigger the setup of bindings.  SAVI devices will set up bindings on
   points of attachment with this attribute based on the data-triggered
   process described in Section 7.

   If the DHCP-Snooping attribute is configured on a point of
   attachment, the bindings on this attachment are set up based on DHCP
   message snooping.  However, in some scenarios, a DHCP client may use
   a DHCP address without the DHCP address assignment procedure being
   performed on its current attachment.  For such attached devices, the
   Data Snooping Process, which is described in Section 7, is necessary.
   This attribute is configured on such attachments.  The usage of this
   attribute is further discussed in Section 7.

   Since some networks require DHCP deployment and others avoid it,
   there is no obvious universal default value for the Data-Snooping
   attribute.  Hence, the Data-Snooping attribute should default to
   FALSE, and a mechanism should be implemented to conveniently set it
   to TRUE on all points of attachment for which the Trust attribute is
   FALSE.

4.2.5.  Validating Attribute

   The "Validating Attribute" is a Boolean attribute.  It indicates
   whether packets from the corresponding attachment will have their IP
   source addresses validated based on binding entries on the
   attachment.

   If it is TRUE, packets coming from attachments with this attribute
   will be validated based on binding entries on the attachment as
   specified in Section 8.  If it is FALSE, they will not.  Since the
   binding table is used in common with other SAVI algorithms, it merely
   signifies whether the check will be done, not whether it will be done
   for SAVI-DHCP originated bindings.

   This attribute is by default the inverse of the Trust attribute;
   source addresses on untrusted links are validated by default.  It MAY
   be set FALSE by the administration.

   The expected use case is when SAVI is used to monitor but not block
   forged transmissions.  The network manager, in that case, may set the
   DHCP-Snooping and/or Data-Snooping attribute TRUE but the Validating
   attribute FALSE.

Top      ToC       Page 13 
4.2.6.  Table of Mutual Exclusions

   Different types of attributes may indicate mutually exclusive actions
   on a packet.  Mutually exclusive attributes MUST NOT be set TRUE on
   the same attachment.  The compatibility of different attributes is
   listed in Figure 2.  Note that although Trust and DHCP-Trust are
   compatible, there is no need to configure DHCP-Trust to TRUE on an
   attachment with Trust attribute TRUE.

    +----------+----------+----------+----------+----------+----------+
    |          |          |          | DHCP-    | Data-    |          |
    |          |  Trust   |DHCP-Trust| Snooping | Snooping |Validating|
    +----------+----------+----------+----------+----------+----------+
    |          |          |          | mutually | mutually | mutually |
    |  Trust   |    -     |compatible| exclusive| exclusive| exclusive|
    +----------+----------+----------+----------+----------+----------+
    |          |          |          |          |          |          |
    |DHCP-Trust|compatible|    -     |compatible|compatible|compatible|
    +----------+----------+----------+----------+----------+----------+
    |DHCP-     |mutually  |          |          |          |          |
    |Snooping  |exclusive |compatible|     -    |compatible|compatible|
    +----------+----------+----------+----------+----------+----------+
    |Data-     |mutually  |          |          |          |          |
    |Snooping  |exclusive |compatible|compatible|    -     |compatible|
    +----------+----------+----------+----------+----------+----------+
    |          |mutually  |          |          |          |          |
    |Validating|exclusive |compatible|compatible|compatible|    -     |
    +----------+----------+----------+----------+----------+----------+

                   Figure 2: Table of Mutual Exclusions

4.3.  Perimeter

4.3.1.  SAVI-DHCP Perimeter Overview

   SAVI devices form a perimeter separating trusted and untrusted
   regions of a network, as FCFS SAVI does (Section 2.5 of [RFC6620]).
   The perimeter is primarily designed for scalability.  It has two
   implications.

   o  SAVI devices only need to establish bindings for directly attached
      clients, or clients indirectly attached through a non-SAVI
      protected device, rather than all of the clients in the network.

   o  Each SAVI device only needs to validate the source addresses in
      traffic from clients attached to it, without checking all the
      traffic passing by.

Top      ToC       Page 14 
   Consider the example in Figure 1.  The protection perimeter is formed
   by SAVI Devices A, B, and C.  In this case, SAVI Device B does not
   create a binding for Client A.  However, because SAVI Device A
   filters spoofed traffic from Client A, SAVI Device B can avoid
   receiving spoofed traffic from Client A.

   The perimeter in SAVI-DHCP is not only a perimeter for data packets
   but also a perimeter for DHCP messages.  DHCP server response
   messages incoming across the perimeter will be dropped (Section 8).
   The placement of the DHCP relay and DHCP server, which are not
   involved in [RFC6620], is related to the construction of the
   perimeter.  The requirement on the placement and configuration of the
   DHCP relay and DHCP server is discussed in Section 4.3.3.

4.3.2.  SAVI-DHCP Perimeter Configuration Guideline

   A perimeter separating trusted and untrusted regions of the network
   is formed as follows:

   (1)  Configure the Validating and DHCP-Snooping attributes TRUE on
        the direct attachments of all DHCP clients.

   (2)  Configure the Validating and DHCP-Snooping attributes TRUE on
        the indirect attachments of all DHCP clients (i.e., DHCP clients
        on protected links).

   (3)  Configure the Trust attribute TRUE on the attachments to other
        SAVI devices.

   (4)  If a non-SAVI device, or a number of connected non-SAVI devices,
        are attached only to SAVI devices, set the Trust attribute TRUE
        on their attachments.

   (5)  Configure the DHCP-Trust attribute TRUE on the direct
        attachments to trusted DHCP relays and servers.

   In this way, the points of attachments with the Validating attribute
   TRUE (and generally together with attachments of unprotected devices)
   on SAVI devices can form a perimeter separating DHCP clients and
   trusted devices.  Data packet checks are only performed on the
   perimeter.  The perimeter is also a perimeter for DHCP messages.  The
   DHCP-Trust attribute is only TRUE on links inside the perimeter.
   Only DHCP Server-to-Client messages originated within the perimeter
   are trusted.

Top      ToC       Page 15 
4.3.3.  On the Placement of the DHCP Server and Relay

   As a result of the configuration guidelines, SAVI devices only trust
   DHCP Server-to-Client messages originated inside the perimeter.
   Thus, the trusted DHCP relays and DHCP servers must be placed within
   the perimeter.  DHCP Server-to-Client messages will be filtered on
   the perimeter.  Server-to-Relay messages will not be filtered, as
   they are within the perimeter.  In this way, DHCP Server-to-Client
   messages from bogus DHCP servers are filtered on the perimeter,
   having entered through untrusted points of attachment.  The SAVI
   devices are protected from forged DHCP messages.

   DHCP Server-to-Client messages arriving at the perimeter from outside
   the perimeter are not trusted.  There is no distinction between a
   DHCP server owned and operated by the correct administration but
   outside the SAVI perimeter and a bogus DHCP server.  For example, in
   Figure 1, DHCP Server A is valid, but it is attached to Non-SAVI
   Device 1.  A bogus DHCP server is also attached to Non-SAVI Device 1.
   While one could imagine a scenario in which the valid one had a
   statistically configured port number and MAC address, and therefore a
   binding, by default SAVI-DHCP cannot distinguish whether a message
   received from the port of Non-SAVI Device 1 is from DHCP Server A or
   the bogus DHCP server.  If DHCP Server A is contained in the
   perimeter, Non-SAVI Device 1 will also be contained in the perimeter.
   Thus, DHCP Server A cannot be contained within the perimeter apart
   from manual configuration of the binding anchor.

   Another consideration on the placement is that if the DHCP server/
   relay is not inside the perimeter, the SAVI devices may not be able
   to set up bindings correctly because the SAVI devices may not be on
   the path between the clients and the server/relay, or the DHCP
   messages are encapsulated (e.g., Relay-reply and Relay-forward).

4.3.4.  An Alternative Deployment

   In common deployment practice, the traffic from the unprotected
   network is treated as trustworthy, which is to say that it is not
   filtered.  In such a case, the Trust attribute can be set TRUE on the
   unprotected link.  If non-SAVI devices, or a number of connected non-
   SAVI devices, are only attached to SAVI devices and unprotected
   devices, their attachment to SAVI devices can have the Trust
   attribute set TRUE.  Then an unclosed perimeter will be formed, as
   illustrated in Figure 3.

Top      ToC       Page 16 
           |             .             .           Protection |
           |             |             |           Perimeter  |
           |             |             |                      |
           | Unprotected |             | Unprotected          |
           | Link        |             | Link                 |
           |             |             |                      |
           |             |             |                      |
           |        +----+---+    +----+---+    +--------+    |
           |        |SAVI    +----+Non-SAVI+----+SAVI    |    |
           |        |Device  |    |Device  |    |Device  |    |
           |        +----+---+    +--------+    +----+---+    |
           |             |                           |        |
           \_____________+___________________________+________/
                         |                           |
                         |                           |
                    +--------+                  +--------+
                    |DHCP    |                  |DHCP    |
                    |Client  |                  |Client  |
                    +--------+                  +--------+

               Figure 3: Alternative Perimeter Configuration

4.3.5.  Considerations regarding Binding Anchors

   The strength of this binding-based mechanism depends on the strength
   of the binding anchor.  The sample binding anchors in [RFC7039] have
   the property in which they associate an IP address with a direct
   physical or secure virtual interface such as a switch port, a
   subscriber association, or a security association.  In addition,
   especially in the case where a protected non-SAVI device such as a
   desktop switch or a hub is between the client and SAVI devices, they
   MAY be extended to also include a MAC address or other link-layer
   attribute.  In short, a binding anchor is intended to associate an IP
   address with something unspoofable that identifies a single-client
   system or one of its interfaces; this may be a physical or virtual
   interface or that plus disambiguating link-layer information.

   If the binding anchor is spoofable, such as a plain MAC address, or
   non-exclusive, such as a switch port extended using a non-SAVI
   device, an attacker can use a forged binding anchor to evade
   validation.  Indeed, using a binding anchor that can be easily
   spoofed can lead to worse outcomes than allowing spoofed IP traffic.
   Thus, a SAVI device MUST use a non-spoofable and exclusive binding
   anchor.

Top      ToC       Page 17 
4.4.  Other Device Configuration

   In addition to a possible binding anchor configuration specified in
   Section 4.2, an implementation has the following configuration
   requirements:

   (1)  Address configuration.  For DHCPv4: the SAVI device MUST have an
        IPv4 address.  For DHCPv6: the client of a SAVI device MUST have
        a link-local address; when the DHCPv6 server is not on the same
        link as the SAVI device, the SAVI device MUST also have an IPv6
        address of at least the same scope as the DHCPv6 Server.

   (2)  DHCP server address configuration: a SAVI device MUST store the
        list of the DHCP server addresses that it could contact during a
        leasequery process.

   (3)  A SAVI device may also require security parameters, such as
        preconfigured keys to establish a secure connection for the
        leasequery process [RFC4388] [RFC5007] connection.



(page 17 continued on part 2)

Next RFC Part