One document matched: draft-andreasen-dots-info-data-model-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-andreasen-dots-info-data-model-00"
     ipr="trust200902">
  <front>
    <title abbrev="DOTS Information Model">Distributed Denial-of-Service Open
    Threat Signaling (DOTS) Information and Data Model</title>

    <author fullname="Flemming Andreasen" initials="F." surname="Andreasen">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street/>

          <country>USA</country>
        </postal>

        <email>fandreas@cisco.com</email>
      </address>
    </author>

    <author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>Cessna Business Park, Varthur Hobli</street>

          <street>Sarjapur Marathalli Outer Ring Road</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560103</code>

          <country>India</country>
        </postal>

        <email>tireddy@cisco.com</email>
      </address>
    </author>

    <date/>

    <workgroup>DOTS</workgroup>

    <abstract>
      <t>This document defines an information model and a data model for
      Distributed Denial-of-Service Open Threat Signaling (DOTS). The document
      specifies the Message and Information Elements that are transported
      between DOTS agents and their interconnected relationships. The primary
      purpose of the DOTS Information and Data Model is to address the DOTS
      requirements and DOTS use cases.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>A distributed denial-of-service (DDoS) attack is an attempt to make
      machines or network resources unavailable to their intended users. In
      most cases, sufficient scale can be achieved by compromising enough
      end-hosts and using those infected hosts to perpetrate and amplify the
      attack. The victim in this attack can be an application server, a
      client, a router, a firewall, or an entire network.</t>

      <t>In order to mitigate a DDoS attack while still providing service to
      legitimate entities, it is necessary to identify and separate the
      majority of attack traffic from legitimate traffic and only forward the
      latter to the entity under attack, which is also known as "scrubbing".
      Depending on the type of attack, the scrubbing process may be more or
      less complicated, and in some cases, e.g. a bandwidth saturation, it
      must be done upstream of the DDoS attack target.</t>

      <t>DDoS Open Threat Signaling (DOTS) defines an architecture to help
      solve these issues (see <xref target="I-D.ietf-dots-architecture"/>). In
      the DOTS architecture, a DDoS attack target is associated with a DOTS
      client which can signal a DOTS server for help in mitigating an attack.
      The DOTS client and DOTS server (collectively referred to as DOTS
      agents) can interact with each other over two different channels: a
      signal and a data channel, as illustrated in (<xref
      target="channels"/>).</t>

      <t/>

      <t><figure align="center" anchor="channels"
          title="DOTS signal and data channels">
          <artwork><![CDATA[     +---------------+                                 +---------------+
     |               | <------- Signal Channel ------> |               |
     |  DOTS Client  |                                 |  DOTS Server  |
     |               | <=======  Data Channel  ======> |               |
     +---------------+                                 +---------------+]]></artwork>
        </figure></t>

      <t/>

      <t>The DOTS signal channel is primarily used to convey information
      related to a possible DDoS attack so appropriate mitigation actions can
      be undertaken on the suspecT traffic. The DOTS data channel is used for
      infrequent bulk data exchange between DOTS agents in the aim to
      significantly augment attack response coordination.</t>

      <t>In this document, we define the overall information model and data
      model for the DOTS signal channel and data channel. The information and
      data models are designed to adhere to the overall DOTS architecture
      <xref target="I-D.ietf-dots-architecture"/> , the DOTS use case
      scenarios, and the DOTS requirements <xref
      target="I-D.ietf-dots-requirements"/> . </t>

      <t> </t>
    </section>

    <section anchor="notation" title="Notational Conventions and Terminology">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119"/>.</t>

      <t>The reader should be familiar with the terms defined in <xref
      target="I-D.ietf-dots-architecture"/>.</t>
    </section>

    <section title="Information Model">
      <t>[Editor's note: The following is very much -00 work in
      progress...]</t>

      <t>The Information Model is broken into 3 separate pieces:</t>

      <t><list style="symbols">
          <t>General, which describes the overall structure of the information
          model </t>

          <t>Signal Channel specific</t>

          <t>Data Channel specific </t>
        </list></t>

      <t>Following these, specific information elements to be used by the
      above are described. </t>

      <t> </t>

      <section title="General">
        <t>Security services in the form of authentication, authorization,
        message integrity and confidentiality are assumed to be handled by
        lower layers (e.g. DTLS or TLS) and hence they do not form part of the
        information model. </t>

        <t><list style="symbols">
            <t>Note: Not clear this is (operationally) sufficient to support
            the mutual authentication between DOTS client and DOTS server and
            the following authorization aspects governed by the service
            relationship that's assumed to be in place between the two. </t>
          </list></t>

        <t>General operation and structure:</t>

        <t><list style="symbols">
            <t>Base-line functionality (with protocol and data model
            version)</t>

            <t>Extended functionality (negotiated, mandatory, optional, incl.
            data model versioning)</t>

            <t>Request/response and asynchronous delivery (signal channel)</t>

            <t>DOTS server discovery [Editors' note: Assume provisioned or
            DNS-based for now - data model]</t>
          </list></t>

        <t/>
      </section>

      <section title="Signal Channel Specific">
        <t/>

        <t>Signal Channel Messages:</t>

        <t><list style="symbols">
            <t>Start session (signal channel)</t>

            <t>Stop session</t>

            <t>Open Data Channel</t>

            <t>Close Data Channel</t>

            <t>Redirect<list style="symbols">
                <t>[Editor's note: At the IETF Berlin meeting, there was
                discussion around using anycast to possibly avoid redirection
                - do we keep "redirect" ?]</t>
              </list></t>

            <t>Heartbeat</t>

            <t>Status (peer-health, incl. attack status, mitigation status and
            mitigation efficacy)<list style="symbols">
                <t>[Editor's note: Some of these may be separate messages per
                the following]</t>
              </list></t>

            <t>Client Signal specific: "request mitigation", "stop
            mitigation", "request mitigation status", ("mitigation efficacy
            update" ?)</t>

            <t>Server Signal specific: ("mitigation status" ?)</t>
          </list></t>

        <t/>
      </section>

      <section title="Data Channel Specific">
        <t>Data Channel Messages:</t>

        <t><list style="symbols">
            <t>Open Data Channel</t>

            <t>Close Data Channel</t>

            <t>Redirect</t>

            <t>Bulk data exchange (blacklists, whitelists, filters,
            aliases\names)</t>
          </list></t>

        <t/>
      </section>

      <section title="Information Elements">
        <t/>

        <t>Protocol version</t>

        <t>Attack Target </t>

        <t><list style="symbols">
            <t>[Editor's note: may be superfluous given Mitigation Scope
            below"]</t>
          </list></t>

        <t>Agent Id (identity for each DOTS client and server, contains a
        least a domain portion that can be authenticated)</t>

        <t>Blacklist (define, retrieve, manage and refer to)</t>

        <t>Whitelist (defined, retrieve, manage and refer to)</t>

        <t>Information about the attack (e.g. targeted port range, protocol or
        scope)</t>

        <t><list style="symbols">
            <t>[Editor's note: Not clear this is really different from
            "Mitigation Scope" below - taken from requirement OP-006]</t>
          </list></t>

        <t>Attack telemetry (collected behavioral characteristics defining the
        nature of a DDoS attack)</t>

        <t>Mitigator feedback (attack mitigation feedback from server to
        client, incl. mitigation status [start, stop, metrics, etc.], attack
        ended and information about mitigation failure)</t>

        <t>Mitigation efficacy (attack mitigation efficacy feedback from
        client to server)</t>

        <t>Mitigation failure (unsupported target type, mitigation capacity
        exceeded, excessive "clean traffic", out-of-service, etc.) </t>

        <t>Mitigation Scope: Classless Internet Domain Routing (CIDR)
        prefixes, BGP prefix, URI, DNS names, E.164, "resource group alias",
        port range, protocol, or service </t>

        <t><list style="symbols">
            <t>[Editor's note: comes from requirements - not clear how
            "protocol" and "service" are defined. Also, consider which URI
            schemes]</t>

            <t>[Editor's note: It would probably be useful to structure
            mitigation scope and related information (like telemetry,
            blacklist, etc.) into different "types", since different types of
            targets will have different parameters and different DOTS servers
            may support differnt types of attack targets]</t>
          </list></t>

        <t>Mitigation Scope Conflict: Nature and scope of conflicting
        mitigation requests received from two or more clients</t>

        <t>Resource Group Alias (define in data channel, refer to in
        signal/data channel; aliases for mitigation scope)</t>

        <t>Mitigation duration (desired lifetime - renewable)</t>

        <t>Peer health (? - measure of peer health)</t>

        <t>Filters</t>

        <t>Filter-actions: rate-limit, discard</t>

        <t>Acceptable signal lossiness (for unreliable delivery)</t>

        <t>Heartbeat interval</t>

        <t>Data Channel Address </t>

        <t><list style="symbols">
            <t>[Editor's note: For discussion (not entirely aligned with
            current architecture draft text); assumes establish signal channel
            first and learn data channel address through it (would be useful
            for redirection as well and makes it easier for signal and data
            channel to terminate on different entities)]</t>
          </list></t>

        <t>Extensions: standard, vendor-specific, supported</t>

        <t/>
      </section>
    </section>

    <section title="Data Model">
      <t>TODO</t>

      <t/>
    </section>

    <section title="IANA Considerations">
      <t>TODO</t>

      <t/>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>TODO</t>

      <t/>
    </section>

    <section anchor="ack" title="Acknowledgements">
      <t>TODO</t>

      <t/>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.6020"?>

      <?rfc include="reference.I-D.ietf-dots-architecture"?>

      <?rfc include="reference.RFC.6728"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.6088"?>

      <?rfc include="reference.I-D.ietf-dots-requirements"?>
    </references>
  </back>
</rfc>