INTERNET-DRAFT                                              Linda
Internet Engineering Task Force (IETF)                         L. Dunbar
Intended Status: Informational                           Donald
Request for Comments: 7067                                   D. Eastlake
Category: Informational                                           Huawei
                                                           Radia
ISSN: 2070-1721                                               R. Perlman
                                                                   Intel
                                                          Igor
                                                            I. Gashinsky
                                                                   Yahoo
Expires: February 10, 2014                               August 11,
                                                           November 2013

         TRILL (Transparent Interconnection of Lots of Links):
                  Edge

      Directory Assistance Framework
             <draft-ietf-trill-directory-framework-07.txt> Problem and High-Level Design Proposal

Abstract

   Edge TRILL (Transparent Interconnection of Lots of Links) switches
   currently learn the mapping between MAC (Media Access Control)
   addresses and their egress TRILL switch by observing the data packets
   they ingress or egress or by the TRILL ESADI (End Station (End-Station Address
   Distribution Information) protocol.  When an ingress TRILL switch
   receives a data frame whose for a destination address (MAC&Label) that the
   switch does not know, the data frame is flooded within the frame's
   Data Label across the TRILL campus.

   This document describes the framework for using directory services to
   assist edge TRILL switches in reducing multi-destination frames,
   particularly unknown unicast frames flooding, and ARP/ND, ARP/ND (Address
   Resolution Protocol / Neighbor Discovery), thus improving TRILL
   network scalability and security.

Status of This Memo

   This Internet-Draft document is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Distribution of this not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is unlimited. Comments should be sent
   to the TRILL working group mailing list.

   Internet-Drafts are working documents a product of the Internet Engineering Task Force (IETF), its areas,
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and its working groups.  Note that
   other groups may also distribute working has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents as Internet-
   Drafts.

   Internet-Drafts
   approved by the IESG are draft documents valid for a maximum candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It
   http://www.rfc-editor.org/info/rfc7067.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is inappropriate subject to use Internet-Drafts 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 reference
   material or they describe your rights and restrictions with respect
   to cite them other than this document.  Code Components extracted from this document must
   include Simplified BSD License text as "work described in progress."

INTERNET-DRAFT                         TRILL: Directory Assist Framework

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html. The list Section 4.e of Internet-Draft
   Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

INTERNET-DRAFT                         TRILL: Directory Assist Framework
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction............................................4 Introduction ....................................................3
   2. Terminology.............................................6 Terminology .....................................................4
   3. Impact of Massive Number of End Stations................7
      3.1 Stations ........................5
      3.1. Issues of Flooding Based Flooding-Based Learning in Data Centers......7
      3.2 Centers ..........5
      3.2. Two Examples...........................................8 Examples ...............................................6
   4. Benefits of Directory Assisted Directory-Assisted TRILL Edge...............9 Edge .......................7
   5. Generic operation Operation of Directory Assistance..............11
      5.1 Assistance .......................8
      5.1. Information in Directory for Edge RBridges............11
      5.2 RBridges .................8
      5.2. Push Model and Requirements...........................11
      5.3 Requirements ................................9
      5.3. Pull Model and Requirements...........................13 Requirements ...............................11
   6. Recommendation.........................................15 Recommendation .................................................12
   7. Security Considerations................................15 Considerations ........................................12
   8. IANA Considerations....................................17 Acknowledgements ...............................................13
   9. Acknowledgements.......................................17

      10. References............................................18
      10.1 Normative References.................................18
      10.2 Informative References...............................18

      Authors' Addresses........................................19

INTERNET-DRAFT                         TRILL: Directory Assist Framework References .........................................14

1.  Introduction

   Edge TRILL (Transparent Interconnection of Lots of Links) switches
   (devices implementing [RFC6325], also known as RBridges) currently
   learn the mapping between destination MAC addresses and their egress
   TRILL switch by observing data packets or by the ESADI (End Station (End-Station
   Address Distribution Information) protocol.  When an ingress RBridge
   (Routing Bridge) receives a data frame for a destination address
   (MAC&Label) that RBridge does not know, the data frame is flooded
   within that Data Label across the TRILL campus. (Data Labels are
   VLANs or FGLs (Fine
   Grained (Fine-Grained Labels [FGL]).

   This document describes a framework for using directory services in
   environments where such services are available, such as typical data
   centers, to assist edge TRILL switches.  This assistance can reduce
   multi-destination frames, particularly ARP [RFC826], ND [RFC4861],
   and unknown unicast unicast, thus improving TRILL network scalability.  In
   addition, the information provided by a directory can be more secure
   than that learned from the data plane (see Section 7).

   Data centers, especially Internet and/or multi-tenant data centers centers,
   tend to have a large number of end stations with a wide variety of
   applications.  Their networks differ from enterprise campus networks
   in several ways that make them attractive for the use of directory
   assistance, in particular:

   1. Data center topology is often based on racks and rows.
      Furthermore, guest operating system assignment to Servers, Racks,
      and Rows is orchestrated by a Server/VM (virtual machine) Management system, System
      orchestrates the assignement of guest operating systems to
      servers, racks, and rows; it is not done at random. So  So, the
      information necessary for a directory is normally available from
      that
      management system. Management System.

   2. Rapid workload shifting in data centers can accelerate the
      frequency of the physical servers being re-loaded reloaded with different
      applications.  Sometimes, the applications loaded into one physical
      server at different times can belong to different subnets.  When a
      VM is moved to a new location or when a server is loaded with a
      new application with different IP/MAC addresses, it is more likely
      that the destination address of data packets sent out from those
      VMs are unknown to their attached edge RBridges.

   3. With server virtualization, there is an increasing trend to
      dynamically create or delete VMs when the demand for resource resources
      changes, to move VMs from overloaded servers to less loaded
      servers, or to aggregate VMs onto fewer servers when demand is
      light.  This results in the more frequent occurrence of multiple
      subnets on the same port at the same time and a higher change rate
      for VMs than for physical servers.

   Both items 2 and 3 above can lead to applications in one subnet being
   placed in different locations (racks or rows) or one rack having

INTERNET-DRAFT                         TRILL: Directory Assist Framework
   applications belonging to different subnets.

INTERNET-DRAFT                         TRILL: Directory Assist Framework

2.  Terminology

   The terms "VLAN" and "Data Label" are used interchangeably with
   "Subnet" in this document document, because it is common to map one subnet to
   one VLAN or FGL.

   Bridge:  Device compliant with IEEE Std 802.1Q-2011 compliant device [802.1Q]. In this
            document, Bridge is used interchangeably with Layer 2
            switch.

   Data label: Label:  VLAN or FGL. FGL

   EoR:     End of Row     End-of-Row switches in a data center.  Also known as
            aggregation switches.

   End Station:  Guest OS running on a physical server or on a virtual
            machine.  An end station in this document has at least one
            IP
            address and address, at least one MAC address address, and is connected to a
            network.

   FGL:     Fine Grained     Fine-Grained Label [FGL]. [FGL]

   IS-IS:   Intermediate System to Intermediate System routing protocol.
            TRILL uses IS-IS [IS-IS] [RFC6326].

   RBridge: "Routing Bridge", an alternative alternate name for a TRILL switch.

   ToR:     Top of Rack Switch     Top-of-Rack switches in a data center.  Also known as access
            switches in some data centers.

   TRILL:   Transparent Interconnection of Lots of Links [RFC6325]

   TRILL switch: Switch:  A device implementing the TRILL protocol [RFC6325] [RFC6325].

   VM:      Virtual Machine

INTERNET-DRAFT                         TRILL: Directory Assist Framework

3.  Impact of Massive Number of End Stations

   This section discusses the impact of a massive number of end stations
   in a TRILL campus using Data Centers as an example.

3.1

3.1.  Issues of Flooding Based Flooding-Based Learning in Data Centers

   It is common for Data Center networks to have multiple tiers of
   switches, for example, one or two Access Switches for each server
   rack (ToR), aggregation switches for some rows (or EoR switches), and
   some core switches to interconnect the aggregation switches.  Many
   aggregation switches deployed in data centers have high port density.
   It is not uncommon to see aggregation switches interconnecting
   hundreds of ToR switches.

                       +-------+         +------+
                     +/------+ |       +/-----+ |
                     | Aggr11| + ----- |AggrN1| +    EoR Switches switches
                     +---+---+/        +------+/
                      /     \            /      \
                     /       \          /        \
                  +---+    +---+      +---+     +---+
                  |T11|... |T1x|      |T21| ..  |T2y| ToR switches
                  +---+    +---+      +---+     +---+
                    |        |          |         |
                  +-|-+    +-|-+      +-|-+     +-|-+
                  |   |... |   |      |   | ..  |   |
                  +---+    +---+      +---+     +---+ Server racks
                  |   |... |   |      |   | ..  |   |
                  +---+    +---+      +---+     +---+
                  |   |... |   |      |   | ..  |   |
                  +---+    +---+      +---+     +---+

               Figure 1: Typical Data Center Network Design

   The following problems could occur when TRILL is deployed in a data
   center with a large number of end stations and when the end stations
   in one subnet/Label could be are placed under multiple edge RBridges:

      -  Unnecessary filling of slots in the MAC address learning table
         of edge RBridges, e.g. e.g., RBridge T11, due to T11 receiving
         broadcast / multicast
         broadcast/multicast traffic (e.g. (e.g., ARP/ND, cluster multicast,
         etc.) from end stations under other edge RBridges that are not
         actually communicating with any end stations attached to T11.

      -  Packets being flooded across a TRILL campus when their
         destination MAC addresses are not in the ingress RBridge's MAC
         address to the egress RBridge cache.

INTERNET-DRAFT                         TRILL: Directory Assist Framework

3.2

3.2.  Two Examples

   Consider a data center with 1,600 server racks.  Each server rack has
   at least one ToR switch.  The ToR switches are further divided into 8
   groups, with each group being connected by a set of aggregation
   switches.  There could be 4 to 8 aggregation switches in each set to
   achieve load sharing for traffic to/from server racks. If TRILL is
   deployed in this data center environment, let's  Let's
   consider the following two scenarios for the TRILL campus boundary: boundary if
   TRILL is deployed in this data center environment:

      -  Scenario #1: TRILL campus boundary starts at the ToR switches:

         If each server rack has one ToR, there are 1,600 edge RBridges.
         If each rack has two ToR switches, then there will be 3,200
         edge RBridges RBridges.

         In this scenario, the TRILL campus will have more than 1,600
         (or 3,200) + 8*4 (or 8*8) nodes, which is a large IS-IS area.
         Even though a mesh IS-IS area can scale up to thousands of
         nodes, it is challenging for aggregation switches to handle IS-
         IS link state
         IS-IS link-state advertisement among hundreds of parallel
         ports.

         If each ToR has 40 downstream ports facing servers and each
         server has 10 VMs, there could be 40*10 = 400 end stations
         attached.  If those end stations belong to 8 Labels Labels, then the
         total number of MAC&Label entries learned by each edge RBridge
         in the worst case might be 400*8 = 3,200, which is not a large
         number.

      -  Scenario #2: TRILL campus boundary starts at the aggregation
         switches:

         With the same assumptions as before, the number of nodes in the
         TRILL campus will be less than 100, and aggregation switches
         don't have to handle IS-IS link state link-state advisements among
         hundreds of parallel ports.

         However, the number of MAC&Label <-> Egress RBridge Mapping mapping
         entries to be learned and managed by the RBridge edge node can
         be very large.  In the example above, each edge RBridge has 200
         edge ports facing the ToR switches.  If each ToR has 40
         downstream ports facing servers and each server has 10 VMs,
         there could be 200*40*10 = 80,000 end stations attached.  If
         all those end stations belong to 1,600 Labels (50 per Data
         Label) and each Data Label has 200 end stations, then under the worst-
         case
         worst-case scenario, the total number of MAC&Label entries to
         be learned by each edge RBridge can be 1,600*200=320,000, which
         is very large.

INTERNET-DRAFT                         TRILL: Directory Assist Framework

4.  Benefits of Directory Assisted Directory-Assisted TRILL Edge

   In some environments, particularly data centers, the assignment of
   applications to servers, including rack and row selection, is
   orchestrated by Server (or VM) Management System(s).  That is, there
   is a database or multiple databases that have the knowledge of where
   each application is placed.  If the application location information
   can be fed to RBridge edge nodes, nodes through some form of Directory
   Service, directory
   service, then there is much less chance of RBridge edge nodes
   receiving unknown MAC destination address, addresses, therefore less chance of
   flooding.

   Avoiding unknown unicast address flooding to the TRILL campus is
   especially valuable in the data center environment environment, because there is
   a higher chance of an edge RBridge receiving packets with an unknown
   unicast destination address and broadcast / multicast broadcast/multicast messages due to
   VM migration and servers being loaded with different applications.
   When a VM is moved to a new location or a server is loaded with a new
   application with a different IP/MAC addresses, it is more likely that
   the destination address of data packets sent out from those VMs are is
   unknown to their attached edge RBridges.  In addition, gratuitous ARP
   (IPv4,
   (IPv4 [RFC826]) or Unsolicited Neighbor Advertisement (IPv6, (IPv6
   [RFC4861]) sent out from those newly migrated or activated VMs have
   to be flooded to other edge RBridges that have VMs in the same
   subnets.

   The benefits of using directory assistance include:

      - Avoid  Avoids flooding an unknown unicast destination address across
         the TRILL campus.  The Directory enforced directory-enforced MAC&Label <-> Egress
         RBridge mapping table can determine if a data packet needs to
         be forwarded across the TRILL campus.

         When multiple RBridge edge ports are connected, possibly via
         bridged LANs, connected to end stations
         (servers/VMs), possibly via bridged LANs, a directory
         assisted directory-assisted
         edge RBridge won't need to flood unknown unicast destination
         data frames to all ports of the edge RBridges in the frame's
         Data Label when it ingresses a frame.  It can depend on the
         directory to tell it where locate the destination is. destination.  When the directory
         doesn't have the needed information, the frames can be dropped
         or flooded depending on the policy configured.

      - Reduce  Reduces flooding of decapsulated Ethernet frames with an
         unknown MAC destination address to a bridged LAN connected to
         RBridge edge ports.

         When an RBridge receives a unicast TRILL data packet whose
         destination Nickname matches with its own, the normal procedure
         is for the RBridge to decapsulate it and forward the
         decapsulated Ethernet frame to the directly attached bridged

INTERNET-DRAFT                         TRILL: Directory Assist Framework
         LAN.  If the destination MAC is unknown, the RBridge floods the
         decapsulated Ethernet frame out all ports in the fame's frame's Data
         Label.  With directory assistance, the egress RBridge can
         determine if the MAC destination address in a frame matches any
         end stations attached via the bridged LAN.  Frames can be
         discarded if their destination addresses do not match.

      - Reduce  Reduces the amount of MAC&Label <-> Egress RBridge mapping
         maintained by edge RBridges.  There is no need for an edge
         RBridge to keep MAC entries of remote end stations that don't
         communicate with the end stations locally attached.

      - Eliminate  Eliminates ARP/ND being broadcast or multicast through the
         TRILL core.

      - Some  Provides some protection against spoofing of source addresses
         (see Section 7).

INTERNET-DRAFT                         TRILL: Directory Assist Framework

5.  Generic operation Operation of Directory Assistance

   There are two different models for Directory directory assistance to edge
   RBridges: Push Model and Pull Model.  The Directory Information directory information is
   described in Section 5.1 below below, while Section 5.2 discusses Push
   Model
   requirements requirements, and Section 5.3 Pull Model requirements.

5.1

5.1.  Information in Directory for Edge RBridges

   To achieve the benefits of directory assistance for TRILL, the
   corresponding directory server Directory Server entries will need, at a minimum, the
   following logical data structure:

   [IP, MAC, Data Label, {list of attached RBridge nicknames}, {list of
   interested RBridges}]

   The {list of attached RBridges} are the edge RBridges to which the
   host (or VM) is attached as specified by the [IP, MAC, Data Label] in
   the entry is
   attached. entry.  The {list of interested RBridges} are the remote RBridges
   that might have attached hosts that communicate with the host in this
   entry.

   When a host has multiple IP addresses, there will be multiple
   entries.

   The {list of interested RBridges} could get populated when an RBridge
   queries for information, or information is pushed from a directory
   server. Directory
   Server.  The list is used to notify those RBridges when the host
   (specified by the [IP, MAC, Data Label]) in the entry changes its
   RBridge attachment.  An explicit list in the directory is not needed
   as long as the interested RBridges can be determined.

5.2

5.2.  Push Model and Requirements

   Under this model, Directory Server(s) push the MAC&Label <-> Egress
   RBridge mapping for all the end stations that might communicate with
   end stations attached to an RBridge edge node.  If the packet's
   destination address can't be found in the MAC&Label <-> Egress
   RBridge table, the Ingress RBridge could be configured to:

      simply drop a data packet,

      flood it to the TRILL campus, or

      start the pull process to get information from pull directory
          server(s)

INTERNET-DRAFT                         TRILL: the Pull Directory Assist Framework
      Server(s).

   It may not be necessary that for every edge RBridge gets to get the entire
   mapping table for all the end stations in a campus.  There are many
   ways to narrow the full set down to a smaller set of remote end
   stations that communicate with end stations attached to an edge
   RBridge.  A simple approach is to only push the mapping for the Data
   Labels that have active end stations under an edge RBridge.  This
   approach can reduce the number of mapping entries being pushed.

   However, the Push Model usually will usually push more entries of MAC&Label
   <-> Egress RBridge mapping to an edge RBridges than needed.  Under
   the normal process of edge RBridge cache aging and unknown
   destination address flooding, rarely used mapping entries would have
   been removed.  But it can be difficult for Directory Servers to
   predict the communication patterns among applications within one Data
   Label.  Therefore, it is likely that the Directory Servers will push
   down all the MAC&Label entries if there are end stations in the Data
   Label attached to the edge RBridge.  This is a disadvantage of the
   Push Model compared with the Pull Model described below.

   In the Push Model, it is necessary to have a way for an RBridge node
   to request directory server(s) Directory Server(s) to push the mapping entries.  This
   method should at least include the Data Labels enabled on the
   RBridge, so that directory server the Directory Server doesn't need to push down the
   entire set of mapping entries for all the end stations in the campus.
   An RBridge must be able to get mapping entries when it is initialized
   or restarted.

   The Push Model's detailed method and any handshake mechanism between
   an RBridge and Directory Server(s) is beyond the scope of this
   framework document.

   When a directory server Directory Server needs to push a large number of entries to
   edge RBridges, efficient data organization should be considered. For considered, for
   example, with one edge RBridge nickname being associated with all the
   attached end stations' MAC addresses and Data Labels.  As shown in
   Table 1 below, to make the data more compact, a representation can be
   used where a nickname need only occur once for a set of Labels, each
   of which occurs only once and each of which is associated with a set
   of multiple IP and MAC address pairs.  It would be much more bulky to
   have each IP and MAC address pair separately accompanied by its Label
   and by the nickname of the RBridge by which it is reachable.

INTERNET-DRAFT                         TRILL: Directory Assist Framework

         +------------+---------+--------------------------------+
         | Nickname1  |Label-1  | IP/MAC1, IP/MAC2, ,, IP/MACn   |
         |            |-------- +--------------------------------+
         |            |Label-2  | IP/MAC1, IP/MAC2, ,, IP/MACn   |
         |            |-------- +--------------------------------+
         |            |  ...... | IP/MAC1, IP/MAC2, ,, IP/MACn   |
         +------------+-------- +--------------------------------+
         | Nickname2  |Label-1  | IP/MAC1, IP/MAC2, ,, IP/MACn   |
         |            |-------- +--------------------------------+
         |            |Label-2  | IP/MAC1, IP/MAC2, ,,IP/MACn    |
         |            |-------- +--------------------------------+
         |            |         | IP/MAC1, IP/MAC2, ,, IP/MACn   |
         +------------+-------- +--------------------------------+
         | -------    |-------- +--------------------------------+
         |            |         | IP/MAC1, IP/MAC2, ,, IP/MACn   |
         +------------+-------- +--------------------------------+

           Table 1: Summarized table pushed down Table Pushed Down from directory Directory

   Whenever there is any change in MAC&Label <-> Egress RBridge mapping, mapping
   that can be triggered by end stations being added, moved, or de-
   commissioned,
   decommissioned, an incremental update can be sent to the edge
   RBridges
   which that are impacted by the change.  Therefore, something like
   a sequence number has to be maintained by directory servers Directory Servers and
   RBridges.  Detailed mechanisms will be specified in a separate
   document.

5.3

5.3.  Pull Model and Requirements

   Under this model, an RBridge pulls the MAC&Label <-> Egress RBridge
   mapping entry from the directory server Directory Server when its cache doesn't have
   the entry.  There are a couple of possibilities for triggering the
   pulling process:

      -  The RBridge edge node can send a pull request whenever it
         receives an unknown MAC destination, or

      -  The RBridge edge node can intercept all ARP/ND requests and
         forward them or appropriate requests to the Directory Server(s)
         that has the information on where the target end stations are
         located.

   The Pull Directory response could indicate that the address being
   queried is unknown or that the requestor is administratively
   prohibited from getting an informative response.

   By using a Pull Directory, a frame with an unknown MAC destination
   address doesn't have to be flooded across the TRILL campus and the

INTERNET-DRAFT                         TRILL: Directory Assist Framework
   ARP/ND requests don't have to be broadcast or multicast across the
   TRILL campus.

   The ingress RBridge can cache the response pulled from the directory.
   The timer for such a cache should be short in an environment where
   VMs move frequently.  The cache timer could be configured by the
   management system
   Management System or could be sent along with the Pulled reply by the
   directory server(s).
   Directory Server(s).  It is important that the cached information be
   kept consistent with the actual placement of addresses in the campus;
   therefore, there needs to be some mechanism by which RBridges that
   have pulled information that has not expired can be informed when
   that information changes or becomes invalid for other reasons.

   One advantage of the Pull Model is that edge RBridges can age out
   MAC&Label entries if they haven't been used for a certain configured
   period of time or a period of time provided by the Directory. directory.
   Therefore, each edge RBridge will only keep the entries that are
   frequently used, so its mapping table size will be smaller.  Edge
   RBridges would query the Directory Server(s) for unknown MAC
   destination addresses in data frames or ARP/ND and cache the
   response.  When end stations attached to remote edge RBridges rarely
   communicate with the locally attached end stations, the corresponding
   MAC&VLAN entries would be aged out from the RBridge's cache.

   An RBridge waiting for a response from Directory Servers upon
   receiving a data frame with an unknown destination address is similar
   to an L3/L2 Layer-3/Layer-2 boundary router waiting for an ARP or ND
   response upon receiving an IP data packet whose destination IP is not
   in the router's IP/MAC cache table.  Most deployed routers today do
   hold the packet and send ARP/ND requests to the target upon receiving
   a packet with a destination IP not in its IP to MAC IP-to-MAC cache.  When
   ARP/ND replies are received, the router will send the data packet to
   the target.  This practice minimizes flooding when targets don't
   exist in the subnet.

   When the target doesn't exist in the subnet, routers generally re-
   send resend
   an ARP/ND request a few more times before dropping the packets.  So, the holding time by routers to wait for an ARP/ND response,
   if the target doesn't exist in the subnet, the router's holding time
   to wait for an ARP/ND response can be longer than the time taken by
   the Pull Model to get IP to MAC IP-to-MAC mapping from a directory
   server.

   For Directory Server.

   RBridges with mapping entries being pushed from a directory
   server, they Directory Server
   can be configured to use the Pull Model for targets
   which that don't exist
   in the mapping data being pushed.

   A separate document will specify the detailed messages and mechanism
   for RBridges to pull information from directory server(s).

INTERNET-DRAFT                         TRILL: Directory Assist Framework Server(s).

6.  Recommendation

   TRILL should provide a directory assisted directory-assisted approach.  This document
   describes a basic framework for directory assistance to RBridge edge
   nodes.  More detailed mechanisms will be described in a separate
   document or documents.

7.  Security Considerations

   For general TRILL security considerations, see Section 6 of
   [RFC6325].

   Accurate mapping of IP addresses into MAC addresses and of MAC
   addresses to the RBridges from which they are reachable is important
   to the correct delivery of information.  The security of specific
   directory assisted
   directory-assisted mechanisms for delivering such information will be
   discussed in the document or documents specifying those mechanisms.

   Directory assisted

   A directory-assisted TRILL edge can be used to substantially improve
   the security of a TRILL campus over TRILL's default MAC address
   learning from the data plane.  Assume S is an end station attached to
   RB1 trying to spoof a target end station T and that T is attached to
   RB2.  Perhaps S wants to steal traffic intended for T or forge
   traffic as if it was from T.

   With that default TRILL data plane data-plane learning as described in
   [RFC6325], S can impersonate T or any other end station in the same
   Data Label (VLAN or FGL [FGL]) as S and possibly other Data Labels,
   depending on how tightly VLAN admission and Appointed Forwarders
   [RFC6439] are configured at the port by which S is connected to RB1.
   S can just send native frames with the forged source MAC addresses of
   T, perhaps broadcast frames for maximum effectiveness.  With this
   technique, S will frequently receive traffic intended for T. And T and S can
   easily forge traffic as being from T.

   Such spoofing can be prevented to the extent that the network
   RBridges (1) use trusted directory services as described above in
   this document, (2) discard native frames received from a local end
   station when the directory says that end stations should be remote,
   and, (3) when appropriate, intercept ARP and ND messages and respond
   locally.  Under these circumstances, S would be limited to spoofing
   targets on the same RBridge as the ingress RBridge for S (that is,
   RB1 = RB2).  RB1 would still need to learn which local end stations
   were attached to which port port, and S could confuse RB1 by sending
   frames with the forged source MAC address of other end stations on RB1
   although
   RB1.  Although it would also still be restricted to frames in a VLAN
   that
   both would both be admitted by S's port of attachment and for which
   that port is an Appointed Forwarder.

INTERNET-DRAFT                         TRILL: Directory Assist Framework

   Security against spoofing could be even further strengthened by
   adding port of attachment information to the directory and discarding
   native frames that are received on the wrong port.  This would limit
   S to spoofing targets that were on the same link as S and in a VLAN
   admitted by the port of that link's attachment to RB1 and for which
   that port is an Appointed Forwarder (or, if the link is multiply
   connected, in the same way at all of the ports by which the link is
   attached to an RBridge).

   Even without directory services, secure ND (Secure Neighbor Discovery
   [RFC3971]) [RFC3971] or use of secure
   ESADI (as described in [ESADI]) may also be helpful to security.

INTERNET-DRAFT                         TRILL: Directory Assist Framework

8. IANA Considerations

   This document requires no IANA actions. RFC Editor: please delete
   this section before publication.

9.  Acknowledgements

   Thanks for comments and review from the following:

   Sam Aldrin, David Black, Charlie Kaufman, Yizhou Li, and Erik
   Nordmark

   The document was prepared in raw nroff. All macros used were defined
   within the source file.

INTERNET-DRAFT                         TRILL: Directory Assist Framework

10. References

10.1 Normative References

   As an Informational document, this draft has no Normative References.

10.2

9.  Informative References

   [802.1Q] -   IEEE Std 802.1Q-2011, "IEEE Standard for Local and
              metropolitan area networks - Virtual Bridged Local Area
              Networks", May 2011.

   [IS-IS] -    ISO/IEC, "Intermediate system System to Intermediate system System
              intra-domain routeing information exchange protocol for
              use in conjunction with the Protocol protocol for providing the Connectionless-mode Network
         Service
              connectionless-mode network service (ISO 8473)", ISO/IEC
              10589:2002.

   [RFC826] -   Plummer, D., "An Ethernet "Ethernet Address Resolution Protocol", Protocol: Or
              Converting Network Protocol Addresses to 48.bit Ethernet
              Address for Transmission on Ethernet Hardware", STD 37,
              RFC 826, November 1982.

   [RFC3971] -  Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
              "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.

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

   [RFC6325] -  Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
              Ghanwani, "Routing Bridges (RBridges): Base Protocol
              Specification", RFC 6325, July 2011.

   [RFC6326] -  Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A.
              Ghanwani, "Transparent Interconnection of Lots of Links
              (TRILL) Use of IS-IS", RFC 6326, July 2011.

   [RFC6439] -  Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F.
              Hu, "Routing Bridges (RBridges): Appointed Forwarders",
              RFC 6439, November 2011.

   [ESADI] - H.    Zhai, F. H., Hu, R. F., Perlman, D. Eastlake, R., Eastlake 3rd, D., and O.
              Stokes, "TRILL: "TRILL (Transparent Interconnection of Lots of
              Links): ESADI Protocol", draft-ietf-trill-esadi, work (End Station Address Distribution
              Information) Protocol, Work in progress. Progress, July 2013.

   [FGL] - D. Eastlake, M.      Eastlake 3rd, D., Zhang, P. M., Agarwal, R. P., Perlman, R., and
              D. Dutt, "TRILL (Transparent Interconnection of Lots of
              Links): Fine-
         Grained Fine-Grained Labeling", draft-ietf-trill-fine-labeling, Work in RFC
         Editor's queue.

INTERNET-DRAFT                         TRILL: Directory Assist Framework Progress, May
              2013.

Authors' Addresses

   Linda Dunbar
   Huawei Technologies
   5430 Legacy Drive, Suite #175
   Plano, TX 75024, USA

   Phone: +1-469-277-5840
   Email:
   EMail: ldunbar@huawei.com

   Donald Eastlake
   Huawei Technologies
   155 Beaver Street
   Milford, MA 01757 USA

   Phone: +1-508-333-2270
   Email:
   EMail: d3e3e3@gmail.com

   Radia Perlman
   Intel Labs
   2200 Mission College Blvd.
   Santa Clara, CA 95054-1549 USA

   Phone: +1-408-765-8080
   Email:
   EMail: Radia@alum.mit.edu

   Igor Gashinsky
   Yahoo
   45 West 18th Street 6th floor
   New York, NY 10011 USA

   Email:

   EMail: igor@yahoo-inc.com

INTERNET-DRAFT                         TRILL: Directory Assist Framework

Copyright, Disclaimer, and Additional IPR Provisions

   Copyright (c) 2013 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.  The definitive version of
   an IETF Document is that published by, or under the auspices of, the
   IETF. Versions of IETF Documents that are published by third parties,
   including those that are translated into other languages, should not
   be considered to be definitive versions of IETF Documents. The
   definitive version of these Legal Provisions is that published by, or
   under the auspices of, the IETF. Versions of these Legal Provisions
   that are published by third parties, including those that are
   translated into other languages, should not be considered to be
   definitive versions of these Legal Provisions.  For the avoidance of
   doubt, each Contributor to the IETF Standards Process licenses each
   Contribution that he or she makes as part of the IETF Standards
   Process to the IETF Trust pursuant to the provisions of RFC 5378. No
   language to the contrary, or terms, conditions or rights that differ
   from or are inconsistent with the rights and licenses granted under
   RFC 5378, shall have any effect and shall be null and void, whether
   published or posted by such Contributor, or included with or in such
   Contribution.