Use cases for DDoS Open Threat Signaling
draft-ietf-dots-use-cases-12

DOTS                                                          R. Dobbins
Internet-Draft                                            Arbor Networks
Intended status: Informational                                D. Migault
Expires: October 17, 2018                                       Ericsson
                                                               S. Fouant

                                                            R. Moskowitz
                                                          HTT Consulting
                                                               N. Teague
                                                                Verisign
                                                                  L. Xia
                                                                  Huawei
                                                            K. Nishizuka
                                                      NTT Communications
                                                          April 15, 2018

                Use cases for DDoS Open Threat Signaling
                      draft-ietf-dots-use-cases-12

Abstract

   The DDoS Open Threat Signaling (DOTS) effort is intended to provide
   protocols to facilitate interoperability across disparate DDoS
   mitigation solutions.  This document presents use cases which
   describe the interactions expected between the DOTS components as
   well as DOTS messaging exchanges.  These use cases are meant to
   identify the interacting DOTS components, how they collaborate and
   what are the typical information to be exchanged.

Status of This Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on October 17, 2018.

Dobbins, et al.         Expires October 17, 2018                [Page 1]
Internet-Draft               DOTS Use Cases                   April 2018

Copyright Notice

   Copyright (c) 2018 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
   (https://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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology and Acronyms  . . . . . . . . . . . . . . . . . .   3
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Upstream DDoS Mitigation by an Upstream Internet Transit
           Provider  . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  DDoS Mitigation by a Third party DDoS Mitigation Service
           Provider  . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.3.  DDoS Orchestration  . . . . . . . . . . . . . . . . . . .  10
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  12
   7.  Informative References  . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   At the time of writing, distributed denial-of-service (DDoS) attack
   mitigation solutions are largely based upon siloed, proprietary
   communications schemes with vendor lock-in as a side-effect.  This
   can result in the configuration, provisioning, operation, and
   activation of these solutions being a highly manual and often time-
   consuming process.  Additionally, coordinating multiple DDoS
   mitigation solutions simultaneously is fraught with both technical
   and process-related hurdles.  This greatly increases operational
   complexity which, in turn, can degrade the efficacy of mitigations.

   The DDoS Open Threat Signaling (DOTS) effort is intended to specify
   protocols that facilitate interoperability between diverse DDoS
   mitigation solutions and ensure greater integration in term of
   mitigation requests and attack characterization patterns.  As DDoS
   solutions are broadly heterogeneous among vendors, the primary goal

Dobbins, et al.         Expires October 17, 2018                [Page 2]
Internet-Draft               DOTS Use Cases                   April 2018

   of DOTS is to provide high-level interaction amongst differing DDoS
   solutions, such as initiating, terminating DDoS mitigation assistance
   or requesting the status of a DDoS mitigation.

   This document provides use cases to provide inputs for the design of
   the DOTS protocol(s).  The use cases are not exhaustive and future
   use cases are expected to emerge as DOTS is adopted and evolves.

2.  Terminology and Acronyms

   This document makes use of the same terminology and definitions as
   [I-D.ietf-dots-requirements].  In addition it uses the terms defined
   below:

   o  DDoS Mitigation Service Provider: designates the administrative
      entity providing the DDoS Mitigation Service.

   o  DDoS Mitigation Service: designates a DDoS service provided to a
      customer and which is scoped to mitigate DDoS attacks.  Services
      usually involve Service Level Agreement (SLA) that have to be met.
      It is the responsibility of the service provider to instantiate
      the DDoS Mitigation System to meet these SLAs.

   o  DDoS Mitigation System (DMS): A system that performs DDoS
      mitigation.  The DDoS Mitigation System may be composed by a
      cluster of hardware and/or software resources, but could also
      involve an orchestrator that may take decisions such as
      outsourcing partial or more of the mitigation to another DDoS
      Mitigation System.

   o  DDoS Mitigation: The action performed by the DDoS Mitigation
      System.

   o  Internet Transit Provider (ITP): designates the entity that
      delivers the traffic to the network.  It can be an Internet
      Service Provider (ISP), or an upstream entity delivering the
      traffic to the ISP.

3.  Use Cases

3.1.  Upstream DDoS Mitigation by an Upstream Internet Transit Provider

   This use case describes how an enterprise or a residential customer
   network may take advantage of a pre-existing relation with its
   Internet Transit Provider (ITP) in order to mitigate a DDoS attack
   targeting its network.  To improve the clarity of our purpose, the
   targeted network will be designated as enterprise network, but the
   same scenario applies to any downstream network, including

Dobbins, et al.         Expires October 17, 2018                [Page 3]
Internet-Draft               DOTS Use Cases                   April 2018

   residential network.  As the ITP provides connectivity to the
   enterprise network, it is already on the path of the inbound or
   outbound traffic of the enterprise network and well aware of the
   networking parameters associated to the enterprise network
   connectivity.  This eases both the configuration and the
   instantiation of a DDoS Mitigation Service.  This section considers
   two kind of DDoS Mitigation Service between an enterprise network and
   an ITP:

   o  The upstream ITP may instantiate a DDoS Mitigation System (DMS)
      upon receiving a request from the enterprise network.  This
      typically corresponds to the case when the enterprise network is
      under attack.

   o  On the other hand, the ITP may identify an enterprise network as
      the source of an attack and send a mitigation request to the
      enterprise DMS to mitigate this at the source.

   In the first scenario, as depicted in Figure 1, an enterprise network
   with self-hosted Internet-facing properties such as Web servers,
   authoritative DNS servers, and VoIP servers has a DMS deployed to
   protect those servers and applications from DDoS attacks.  In
   addition to on-premise DDoS defense capability, enterprises have
   contracted with their Internet transit provider for DDoS Mitigation
   Services which threaten to overwhelm their WAN link(s) bandwidth.

Dobbins, et al.         Expires October 17, 2018                [Page 4]
Internet-Draft               DOTS Use Cases                   April 2018

       +------------------+        +------------------+
       | Entreprise       |        | Upstream         |
       | Network          |        | Internet Transit |
       |                  |        | Provider         |
       |      +--------+  |        |             DDoS Attack
       |      | DDoS   |  | <=================================
       |      | Target |  | <=================================
       |      +--------+  |        |  +------------+  |
       |                  | +-------->| DDoS       |  |
       |                  | |      |S | Mitigation |  |
       |                  | |      |  | System     |  |
       |                  | |      |  +------------+  |
       |                  | |      |                  |
       |                  | |      |                  |
       |                  | |      |                  |
       |  +------------+  | |      |                  |
       |  | DDoS       |<---+      |                  |
       |  | Mitigation |C |        |                  |
       |  | System     |  |        |                  |
       |  +------------+  |        |                  |
       +------------------+        +------------------+

          * C is for DOTS client functionality
          * S is for DOTS server functionality

       Figure 1: Upstream Internet Transit Provider DDoS Mitigation

   The enterprise DMS is configured such that if the incoming Internet
   traffic volume exceeds 50% of the provisioned upstream Internet WAN
   link capacity, the DMS will request DDoS mitigation assistance from
   the upstream transit provider.

   The requests to trigger, manage, and finalize a DDoS Mitigation
   between the enterprise DMS and the ITP is performed using DOTS.  The
   enterprise DMS implements a DOTS client while the ITP implements a
   DOTS server which is integrated with their DMS.

   When the enterprise DMS detects an inbound DDoS attack targeting its
   resources ( e.g. servers, hosts or applications), it immediately
   begins a DDoS Mitigation.

   During the course of the attack, the inbound traffic volume exceeds
   the 50% threshold; the DMS DOTS client signals the DOTS server on the
   upstream ITP to initiate DDoS Mitigation.  The DOTS server signals
   the DOTS client that it can serve this request, and mitigation is
   initiated on the ITP network by the ITP DMS.

Dobbins, et al.         Expires October 17, 2018                [Page 5]
Internet-Draft               DOTS Use Cases                   April 2018

   Over the course of the attack, the DOTS server of the ITP
   periodically informs the DOTS client on the enterprise DMS mitigation
   status, statistics related to DDoS attack traffic mitigation, and
   related information.  Once the DDoS attack has ended, the DOTS server
   signals the enterprise DMS DOTS client that the attack has subsided.

   The enterprise DMS then requests the ITP to terminate the DDoS
   Mitigation.  The DOTS server on the ITP receives this request and
   once the mitigation has ended, confirms the end of upstream DDoS
   Mitigation to the enterprise DMS DOTS client.

   The following is an overview of the DOTS communication model for this
   use-case:

   o  (a) A DDoS attack is initiated against resources of a network
      organization which has deployed a DOTS-capable DMS - typically a
      DOTS client.

   o  (b) The DMS detects, classifies, and begins the DDoS Mitigation.

   o  (c) The DMS determines that its capacity and/or capability to
      mitigate the DDoS attack is insufficient, and sends via its DOTS
      client a DOTS DDoS Mitigation request to one or more DOTS servers
      residing on the upstream ITP.

   o  (d) The DOTS server which receive the DOTS Mitigation request
      determines that they have been configured to honor requests from
      the requesting DOTS client, and honored its DDoS Mitigation by
      orchestrating its DMS.

   o  (e) While the DDoS Mitigation is active, DOTS servers regularly
      transmit DOTS DDoS Mitigation status updates to the DOTS client.

   o  (f) The DOTS client transmits a DOTS DDoS Mitigation termination
      request to the DOTS server.

   o  (g) The DOTS server terminates DDoS Mitigation.

   Note that communications between the enterprise DOTS client and the
   upstream transit provider DOTS Server may take place in-band within
   the main Internet WAN link between the enterprise and the ITP; out-
   of-band via a separate, dedicated wireline network link utilized
   solely for DOTS signaling; or out-of-band via some other form of
   network connectivity such as a third-party wireless 4G network
   connectivity.

   Note also that a DOTS clients that sends a DOTS Mitigation request
   may be also triggered by a network admin that manually confirms the

Dobbins, et al.         Expires October 17, 2018                [Page 6]
Internet-Draft               DOTS Use Cases                   April 2018

   request to the upstream ITP, in which case the request may be sent
   from an application such as a web browser or a dedicated mobile
   application.

   Note also that when the enterprise is multihomed and connected to
   multiple upstream ITPs, each ITP is only able to provide a DDoS
   Mitigation Service for the traffic it transits.  As a result, the
   enterprise network may require to coordinate the various DDoS
   Mitigation Services associated to each link.  More multi-homing
   considerations are discussed in [I-D.boucadair-dots-multihoming].

   The current scenario describes the case where the DDoS Target is in
   the enterprise network while the secondary DMS is provided by the
   upstream ITP.  An alternate use case may consider the scenario where
   the ITP informs the enterprise network it is involved into an ongoing
   attack or that infected machines have been identified.  In this case
   the DOTS client and DOTS server roles are inverted.  The DOTS client
   is located in the ITP network and the DOTS server is hosted in the
   enterprise network.  The enterprise network is then responsible to
   perform the DDoS Mitigation.  In some case the DDoS Mitigation may be
   delegated back to the upstream ITP, as described in this section.

3.2.  DDoS Mitigation by a Third party DDoS Mitigation Service Provider

   This use case differs from the previous use case described in
   Section 3.1 in that the DDoS Mitigation Service is not provided by an
   upstream ITP.  In other words, as represented in Figure 2, the
   traffic is not forwarded through the DDoS Mitigation Service Provider
   by default.  In order to steer the traffic to the DDoS Mitigation
   Service Provider, some network configuration changes are required.
   As such, this use case likely to match large enterprises or large
   data centers, but not exclusively.  Another typical scenario for this
   use case is the relation between DDoS Mitigation Service Provider
   forming an overlay of DMS.  When an DDoS Mitigation Service Provider
   mitigating a DDoS attack reaches it resources capacities, it may
   chose to delegate the DDoS Mitigation to another DDoS Mitigation
   Service Provider.

Dobbins, et al.         Expires October 17, 2018                [Page 7]
Internet-Draft               DOTS Use Cases                   April 2018

      +------------------+        +------------------+
      | Entreprise       |        | Upstream         |
      | Network          |        | Internet Transit |
      |                  |        | Provider         |
      |      +--------+  |        |             DDoS Attack
      |      | DDoS   |  | <=================================
      |      | Target |  | <=================================
      |      +--------+  | +----------------------------+
      |                  | |      |                  |  |
      |                  | |      +------------------+  |
      |                  | |                            |
      |                  | |      +------------------+  |
      |                  | |      | DDoS Mitigation  |  |
      |                  | |      | Service Provider |  |
      |                  | |      |                  |  |
      |  +------------+  | |      |  +------------+  |  |
      |  | DDoS       |<---+      |  | DDoS       |<----+
      |  | Mitigation |C |        |  | Mitigation |S |
      |  | System     |  |        |  | System     |  |
      |  +------------+  |        |  +------------+  |
      +------------------+        +------------------+

          * C is for DOTS client functionality
          * S is for DOTS server functionality

      Figure 2: DDoS Mitigation between an Enterprise Network and third
                party DDoS Mitigation Service Provider

   In this scenario, an Enterprise Network has entered into a pre-
   arranged DDoS mitigation assistance agreement with one or more other
   DDoS Mitigation Service Providers in order to ensure that sufficient
   DDoS mitigation capacity and/or capabilities may be activated in the
   event that a given DDoS attack threatens to overwhelm the ability of
   a given DMS to mitigate the attack on its own.

   The pre-arrangement typically includes the agreement on the
   mechanisms used to redirect the traffic to the DDoS Mitigation
   Service Provider, as well as the mechanism to to re-inject the
   traffic back to the Enterprise Network.  Redirection to the DDoS
   Mitigation Service Provider typically involves BGP prefix
   announcement eventually combined with DNS redirection, while re-
   injection may be performed via tunneling mechanisms such as GRE for
   example.  Of course, such mechanisms needs to be regularly tested and
   evaluated.  These exact mechanisms used for traffic steering are out
   of scope.

Dobbins, et al.         Expires October 17, 2018                [Page 8]
Internet-Draft               DOTS Use Cases                   April 2018

     +------------------+        +------------------+
     | Entreprise       |        | Upstream         |
     | Network          |        | Internet Transit |
     |                  |        | Provider         |
     |      +--------+  |        |             DDoS Attack
     |      | DDoS   |  |<----------------+         | ++====
     |      | Target |  |    Mitigated    |         | || ++=
     |      +--------+  |        |        |         | || ||
     |                  |        |        |         | || ||
     |                  |        +--------|---------+ || ||
     |                  |                 |           || ||
     |                  |        +--------|---------+ || ||
     |                  |        | DDoS Mitigation  | || ||
     |                  |        | Service Provider | || ||
     |                  |        |        |         | || ||
     |  +------------+  |        |  +------------+  | || ||
     |  | DDoS       |<------------>| DDoS       |  | || ||
     |  | mitigation |C |        |S | mitigation |<===++ ||
     |  | system     |  |        |  | system     |<======++
     |  +------------+  |        |  +------------+  |
     +------------------+        +------------------+

          * C is for DOTS client functionality
          * S is for DOTS server functionality

     Figure 3: Redirection to a DDoS Mitigation Service Provider

   When the Enterprise Network is under attack or at least is reaching
   its capacity or ability to mitigate a given DDoS attack traffic, the
   DOTS client sends a DOTS request to the DDoS Mitigation Service
   Provider to initiate network traffic diversion - as represented in
   Figure 3 - and DDoS mitigation activities.  Ongoing attack and
   mitigation status messages may be passed between the Enterprise
   Network and the DDoS Mitigation Service Provider.

   Once the requesting Enterprise Network is confident that the DDoS
   attack has either ceased or has fallen to levels of traffic/
   complexity which they can handle on their own or that it has received
   a DOTS DDoS Mitigation termination request from a downstream
   Enterprise Network or DDoS Mitigation Service Provider, the
   requesting Enterprise Network DOTS client sends a DOTS DDoS
   Mitigation termination request to the DDoS Mitigation Service
   Provider.

Dobbins, et al.         Expires October 17, 2018                [Page 9]
Internet-Draft               DOTS Use Cases                   April 2018

3.3.  DDoS Orchestration

   In this use case, one or more DDoS telemetry systems or monitoring
   devices monitor a network - typically an ISP network.  Upon detection
   of a DDoS attack, these telemetry systems alert an orchestrator in
   charge of coordinating the various DMS within the domain.  The
   telemetry systems may be configured to provide required information,
   such as a preliminary analysis of the observation to the
   orchestrator.

   The orchestrator analyses the various information it receives from
   specialized equipment, and elaborates one or multiple DDoS mitigation
   strategies.  In some case, a manual confirmation may also be required
   to choose a proposed strategy or to initiate a DDoS Mitigation.  The
   DDoS Mitigation may consist of multiple steps such as configuring the
   network, or updating already instantiated DDoS mitigation functions.
   In some cases, some specific DDoS mitigation functions must be
   instantiated and properly ordered.  Eventually, the coordination of
   the mitigation may involve external DDoS resources such as a transit
   provider or a DDoS Mitigation Service Provider.

   The communications used to trigger a DDoS Mitigation between the
   telemetry and monitoring systems and the orchestrator is performed
   using DOTS.  The telemetry systems implements a DOTS client while the
   orchestrator implements a DOTS server.

   The communication between a network administrator and the
   orchestrator is also performed using DOTS.  The network administrator
   via its web interfaces implements a DOTS client, while the
   Orchestrator implements a DOTS server.

   The communication between the orchestrator and the DDoS mitigation
   systems is performed using DOTS.  The orchestrator implements a DOTS
   Client while the DDoS mitigation systems implement a DOTS Server.

   The configuration aspects of each DDoS mitigation system, as well as
   the instantiations of DDoS mitigation functions or network
   configuration is not part of DOTS.  Similarly, the discovery of
   available DDoS mitigation functions is not part of DOTS; and as such
   is out of scope.

Dobbins, et al.         Expires October 17, 2018               [Page 10]
Internet-Draft               DOTS Use Cases                   April 2018

          +----------+
          | network  |C
          | adminis  |<-+
          | trator   |  |
          +----------+  |
                        |                       (internal)
          +----------+  | S+--------------+     +-----------+
          |telemetry/|  +->|              |C   S| DDoS      |+
          |monitoring|<--->| Orchestrator |<--->| mitigation||
          |systems   |C   S|              |<-+  | systems   ||
          +----------+     +--------------+C |  +-----------+|
                                             |    +----------+
                                             |
                                             |  (external)
                                             |  +-----------+
                                             | S| DDoS      |
                                             +->| mitigation|
                                                | systems   |
                                                +-----------+
          * C is for DOTS client functionality
          * S is for DOTS server functionality

   Figure 4: DDoS Orchestration

   The telemetry systems monitor various network traffic and perform
   some measurement tasks.  These systems are configured so that when an
   event or some measurement indicators reach a predefined level to
   report a DOTS mitigation request to the orchestrator.  The DOTS
   mitigation request may be associated with some element such as
   specific reporting.

   Upon receipt of the DOTS mitigation request from the telemetry
   system, the orchestrator responds with an acknowledgment, to avoid
   retransmission of the request for mitigation.  The status of the DDoS
   mitigation indicates the orchestrator is in an analyzing phase.  The
   orchestrator begins collecting various information from various
   telemetry systems in order to correlate the measurements and provide
   an analysis of the event.  Eventually, the orchestrator may ask
   additional information to the telemetry system, however, the
   collection of these information is out of scope.

   The orchestrator may be configured to start a DDoS Mitigation upon
   approval from a network administrator.  The analysis from the
   orchestrator is reported to the network administrator via a web
   interface.  If the network administrator decides to start the
   mitigation, they order through her web interface a DOTS client to
   send a request for DDoS mitigation.  This request is expected to be

Dobbins, et al.         Expires October 17, 2018               [Page 11]
Internet-Draft               DOTS Use Cases                   April 2018

   associated with a context that identifies the DDoS mitigation
   selected.

   Upon receiving the DOTS request for DDoS mitigation from the network
   administrator, the orchestrator coordinates the DDoS mitigation
   according to a specified strategy.  Its status indicates the DDoS
   mitigation is starting while not effective.

   Orchestration of the DDoS mitigation systems works similarly as
   described in Section 3.1.  The orchestrator indicates with its status
   whether the DDoS Mitigation is effective.

   When the DDoS mitigation is finished on the DMS, the orchestrator
   indicates to the telemetry systems as well as to the network
   administrator the DDoS mitigation is finished.

4.  Security Considerations

   DOTS is at risk from three primary attacks: DOTS agent impersonation,
   traffic injection, and signaling blocking.  The DOTS protocol must be
   designed for minimal data transfer to address the blocking risk.

   Impersonation and traffic injection mitigation can be managed through
   current secure communications best practices.  One consideration
   could be to minimize the security technologies in use at any one
   time.  The more needed, the greater the risk of failures coming from
   assumptions on one technology providing protection that it does not
   in the presence of another technology.

   Additional details of DOTS security requirements can be found in
   [I-D.ietf-dots-requirements].

5.  IANA Considerations

   No IANA considerations exist for this document at this time.

6.  Acknowledgments

   The authors would like to thank among others Tirumaleswar Reddy;
   Andrew Mortensen; Mohamed Boucadaire; Artyom Gavrichenkov; Jon
   Shallow and the DOTS WG chairs, Roman D.  Danyliw and Tobias Gondrom,
   for their valuable feedback.

7.  Informative References

Dobbins, et al.         Expires October 17, 2018               [Page 12]
Internet-Draft               DOTS Use Cases                   April 2018

   [I-D.boucadair-dots-multihoming]
              Boucadair, M. and T. Reddy, "Multi-homing Deployment
              Considerations for Distributed-Denial-of-Service Open
              Threat Signaling (DOTS)", draft-boucadair-dots-
              multihoming-02 (work in progress), October 2017.

   [I-D.ietf-dots-requirements]
              Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed
              Denial of Service (DDoS) Open Threat Signaling
              Requirements", draft-ietf-dots-requirements-14 (work in
              progress), February 2018.

Authors' Addresses

   Roland Dobbins
   Arbor Networks
   Singapore

   EMail: rdobbins@arbor.net

   Daniel Migault
   Ericsson
   8275 Trans Canada Route
   Saint Laurent, QC  4S 0B6
   Canada

   EMail: daniel.migault@ericsson.com

   Stefan Fouant
   USA

   EMail: stefan.fouant@copperriverit.com

   Robert Moskowitz
   HTT Consulting
   Oak Park, MI  48237
   USA

   EMail: rgm@labs.htt-consult.com

Dobbins, et al.         Expires October 17, 2018               [Page 13]
Internet-Draft               DOTS Use Cases                   April 2018

   Nik Teague
   Verisign
   12061 Bluemont Way
   Reston, VA  20190

   EMail: nteague@verisign.com

   Liang Xia
   Huawei
   No. 101, Software Avenue, Yuhuatai District
   Nanjing
   China

   EMail: Frank.xialiang@huawei.com

   Kaname Nishizuka
   NTT Communications
   GranPark 16F 3-4-1 Shibaura, Minato-ku
   Tokyo  108-8118
   Japan

   EMail: kaname@nttv6.jp

Dobbins, et al.         Expires October 17, 2018               [Page 14]