doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc7067.txt b/doc/rfc/rfc7067.txt
new file mode 100644
index 0000000..75a34d5
--- /dev/null
+++ b/doc/rfc/rfc7067.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         L. Dunbar
+Request for Comments: 7067                                   D. Eastlake
+Category: Informational                                           Huawei
+ISSN: 2070-1721                                               R. Perlman
+                                                                   Intel
+                                                            I. Gashinsky
+                                                                   Yahoo
+                                                           November 2013
+
+
+      Directory Assistance 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 Address
+   Distribution Information) protocol.  When an ingress TRILL switch
+   receives a data frame 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 (Address
+   Resolution Protocol / Neighbor Discovery), thus improving TRILL
+   network scalability and security.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   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).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see 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/rfc7067.
+
+
+
+
+
+
+
+Dunbar, et al.                Informational                     [Page 1]
+
+RFC 7067            TRILL: Directory Assist Framework      November 2013
+
+
+Copyright Notice
+
+   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.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Terminology .....................................................4
+   3. Impact of Massive Number of End Stations ........................5
+      3.1. Issues of Flooding-Based Learning in Data Centers ..........5
+      3.2. Two Examples ...............................................6
+   4. Benefits of Directory-Assisted TRILL Edge .......................7
+   5. Generic Operation of Directory Assistance .......................8
+      5.1. Information in Directory for Edge RBridges .................8
+      5.2. Push Model and Requirements ................................9
+      5.3. Pull Model and Requirements ...............................11
+   6. Recommendation .................................................12
+   7. Security Considerations ........................................12
+   8. Acknowledgements ...............................................13
+   9. Informative References .........................................14
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dunbar, et al.                Informational                     [Page 2]
+
+RFC 7067            TRILL: Directory Assist Framework      November 2013
+
+
+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
+   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 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, 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,
+   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, a Server/VM (virtual machine) Management System
+      orchestrates the assignment of guest operating systems to servers,
+      racks, and rows; it is not done at random.  So, the information
+      necessary for a directory is normally available from that
+      Management System.
+
+   2. Rapid workload shifting in data centers can accelerate the
+      frequency of the physical servers being reloaded with different
+      applications.  Sometimes, 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 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
+
+
+
+
+Dunbar, et al.                Informational                     [Page 3]
+
+RFC 7067            TRILL: Directory Assist Framework      November 2013
+
+
+      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
+   applications belonging to different subnets.
+
+2.  Terminology
+
+   The terms "VLAN" and "Data Label" are used interchangeably with
+   "Subnet" in this document, because it is common to map one subnet to
+   one VLAN or FGL.
+
+   Bridge:  Device compliant with IEEE Std 802.1Q-2011 [802.1Q].
+
+   Data Label:  VLAN or FGL
+
+   EoR:     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, at least one MAC address, and is connected to a
+            network.
+
+   FGL:     Fine-Grained Label [FGL]
+
+   IS-IS:   Intermediate System to Intermediate System routing protocol.
+            TRILL uses IS-IS [IS-IS] [RFC6326].
+
+   RBridge: "Routing Bridge", an alternate name for a TRILL switch.
+
+   ToR:     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:  A device implementing the TRILL protocol [RFC6325].
+
+   VM:      Virtual Machine
+
+
+
+
+
+
+
+
+
+
+
+Dunbar, et al.                Informational                     [Page 4]
+
+RFC 7067            TRILL: Directory Assist Framework      November 2013
+
+
+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.  Issues of 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
+                     +---+---+/        +------+/
+                      /     \            /      \
+                     /       \          /        \
+                  +---+    +---+      +---+     +---+
+                  |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 are placed under multiple edge RBridges:
+
+      -  Unnecessary filling of slots in the MAC address learning table
+         of edge RBridges, e.g., RBridge T11, due to T11 receiving
+         broadcast/multicast traffic (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.
+
+
+
+Dunbar, et al.                Informational                     [Page 5]
+
+RFC 7067            TRILL: Directory Assist Framework      November 2013
+
+
+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.  Let's
+   consider the following two scenarios for the TRILL campus 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.
+
+         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 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, 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 advertisements among
+         hundreds of parallel ports.
+
+         However, the number of MAC&Label <-> Egress RBridge 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
+
+
+
+
+
+Dunbar, et al.                Informational                     [Page 6]
+
+RFC 7067            TRILL: Directory Assist Framework      November 2013
+
+
+         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.
+
+4.  Benefits of 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 through some form of directory
+   service, then there is much less chance of RBridge edge nodes
+   receiving unknown MAC destination addresses, therefore less chance of
+   flooding.
+
+   Avoiding unknown unicast address flooding to the TRILL campus is
+   especially valuable in the data center environment, because there is
+   a higher chance of an edge RBridge receiving packets with an unknown
+   unicast destination address and 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 is
+   unknown to their attached edge RBridges.  In addition, gratuitous ARP
+   (IPv4 [RFC826]) or Unsolicited Neighbor Advertisement (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:
+
+      -  Avoids flooding an unknown unicast destination address across
+         the TRILL campus.  The 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 to end stations
+         (servers/VMs), possibly via bridged LANs, a 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 locate the destination.  When the directory
+         doesn't have the needed information, the frames can be dropped
+         or flooded depending on the policy configured.
+
+
+
+
+
+
+Dunbar, et al.                Informational                     [Page 7]
+
+RFC 7067            TRILL: Directory Assist Framework      November 2013
+
+
+      -  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
+         LAN.  If the destination MAC is unknown, the RBridge floods the
+         decapsulated Ethernet frame out all ports in the 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.
+
+      -  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.
+
+      -  Eliminates ARP/ND being broadcast or multicast through the
+         TRILL core.
+
+      -  Provides some protection against spoofing of source addresses
+         (see Section 7).
+
+5.  Generic Operation of Directory Assistance
+
+   There are two different models for directory assistance to edge
+   RBridges: Push Model and Pull Model.  The directory information is
+   described in Section 5.1 below, while Section 5.2 discusses Push
+   Model requirements, and Section 5.3 Pull Model requirements.
+
+5.1.  Information in Directory for Edge RBridges
+
+   To achieve the benefits of directory assistance for TRILL, the
+   corresponding 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.  The {list of interested RBridges} are the remote RBridges
+   that might have attached hosts that communicate with the host in this
+   entry.
+
+
+
+
+Dunbar, et al.                Informational                     [Page 8]
+
+RFC 7067            TRILL: Directory Assist Framework      November 2013
+
+
+   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.  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.  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 the Pull Directory
+      Server(s).
+
+   It may not be necessary for every edge RBridge 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 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) to push the mapping entries.  This
+   method should at least include the Data Labels enabled on the
+   RBridge, so that the Directory Server doesn't need to push down the
+
+
+
+Dunbar, et al.                Informational                     [Page 9]
+
+RFC 7067            TRILL: Directory Assist Framework      November 2013
+
+
+   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 needs to push a large number of entries to
+   edge RBridges, efficient data organization should be 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.
+
+         +------------+---------+--------------------------------+
+         | 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 from Directory
+
+   Whenever there is any change in MAC&Label <-> Egress RBridge mapping
+   that can be triggered by end stations being added, moved, or
+   decommissioned, an incremental update can be sent to the edge
+   RBridges that are impacted by the change.  Therefore, something like
+   a sequence number has to be maintained by Directory Servers and
+   RBridges.  Detailed mechanisms will be specified in a separate
+   document.
+
+
+
+
+
+
+Dunbar, et al.                Informational                    [Page 10]
+
+RFC 7067            TRILL: Directory Assist Framework      November 2013
+
+
+5.3.  Pull Model and Requirements
+
+   Under this model, an RBridge pulls the MAC&Label <-> Egress RBridge
+   mapping entry from the 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
+   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 or sent along with the Pulled reply by the
+   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.
+   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 Layer-3/Layer-2 boundary router waiting for an ARP or ND
+
+
+
+Dunbar, et al.                Informational                    [Page 11]
+
+RFC 7067            TRILL: Directory Assist Framework      November 2013
+
+
+   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 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 resend
+   an ARP/ND request a few more times before dropping the packets.  So,
+   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 mapping from a Directory Server.
+
+   RBridges with mapping entries being pushed from a Directory Server
+   can be configured to use the Pull Model for targets 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).
+
+6.  Recommendation
+
+   TRILL should provide a 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 mechanisms for delivering such information will be
+   discussed in the document or documents specifying those mechanisms.
+
+   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.
+
+
+
+
+
+
+Dunbar, et al.                Informational                    [Page 12]
+
+RFC 7067            TRILL: Directory Assist Framework      November 2013
+
+
+   With that default TRILL 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 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, and S could confuse RB1 by sending
+   frames with the forged source MAC address of other end stations on
+   RB1.  Although it would also still be restricted to frames in a VLAN
+   that would both be admitted by S's port of attachment and for which
+   that port is an Appointed Forwarder.
+
+   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 [RFC3971] or use of secure
+   ESADI (as described in [ESADI]) may also be helpful to security.
+
+8.  Acknowledgements
+
+   Thanks for comments and review from the following:
+
+   Sam Aldrin, David Black, Charlie Kaufman, Yizhou Li, and Erik
+   Nordmark
+
+
+
+
+
+
+
+
+
+Dunbar, et al.                Informational                    [Page 13]
+
+RFC 7067            TRILL: Directory Assist Framework      November 2013
+
+
+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 to Intermediate System
+              intra-domain routeing information exchange protocol for
+              use in conjunction with the protocol for providing the
+              connectionless-mode network service (ISO 8473)", ISO/IEC
+              10589:2002.
+
+   [RFC826]   Plummer, D., "Ethernet Address Resolution 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]    Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O.
+              Stokes, "TRILL (Transparent Interconnection of Lots of
+              Links): ESADI (End Station Address Distribution
+              Information) Protocol", Work in Progress, July 2013.
+
+   [FGL]      Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and
+              D. Dutt, "TRILL (Transparent Interconnection of Lots of
+              Links): Fine-Grained Labeling", Work in Progress, May
+              2013.
+
+
+
+
+
+
+Dunbar, et al.                Informational                    [Page 14]
+
+RFC 7067            TRILL: Directory Assist Framework      November 2013
+
+
+Authors' Addresses
+
+   Linda Dunbar
+   Huawei Technologies
+   5430 Legacy Drive, Suite #175
+   Plano, TX 75024, USA
+
+   Phone: +1-469-277-5840
+   EMail: ldunbar@huawei.com
+
+
+   Donald Eastlake
+   Huawei Technologies
+   155 Beaver Street
+   Milford, MA 01757 USA
+
+   Phone: +1-508-333-2270
+   EMail: d3e3e3@gmail.com
+
+
+   Radia Perlman
+   Intel Labs
+   2200 Mission College Blvd.
+   Santa Clara, CA 95054-1549 USA
+
+   Phone: +1-408-765-8080
+   EMail: Radia@alum.mit.edu
+
+
+   Igor Gashinsky
+   Yahoo
+   45 West 18th Street 6th floor
+   New York, NY 10011 USA
+
+   EMail: igor@yahoo-inc.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dunbar, et al.                Informational                    [Page 15]
+