PEM file format for ECH
draft-farrell-tls-pemesni-06

Uploaded new revisionInternet-Draft        DOTS Data Channel Protocol            April 2018

      }
      description
        "Choice of specifying a source or destination ports.";
    }

    grouping access-lists {
      description
        "Specifies the ordered set of Access Control Lists.";
      list acl {
        key "name";
        ordered-by user;
        description
          "An Access Control List (ACL) is an ordered list of
          Access Control Entries (ACE). Each Access Control Entry
          has a list of match criteria and a list of actions.";
        leaf name {
          type string {
            length "1..64";
          }
          description
            "The name of the access list.";
          reference
            "RFC ZZZZ: Network Access Control List (ACL)
                        YANG Data Model";
        }
        leaf type {
          type ietf-acl:acl-type;
          description
            "Type of access control list. Indicates the primary intended
            type of match criteria (e.g., IPv4, IPv6) used in the list
            instance.";
          reference
            "RFC ZZZZ: Network Access Control List (ACL)
                        YANG Data Model";
        }
        leaf activation-type {
          type enumeration {
            enum "activate-when-mitigating" {
              value 1;
              description
                "The ACL is installed only when a mitigation is active.
                The ACL is specific to this DOTS client.";
            }
            enum "immediate" {
              value 2;
              description
                "The ACL is immediately activated.";
            }

Reddy, et al.          Expires October 20, 2018              [Page 24]
Internet-Draft        DOTS Data Channel Protocol            April 2018

          }
          description
            "Indicates whether an ACL is to be installed immediately
            or when a mitigation is active.";
        }
        leaf pending-lifetime {
          type int32;
          units "minutes";
          config false;
          description
            "Indicates the pending validity lifetime of the alias
            entry.";
        }
        container aces {
          description
            "The Access Control Entries container contains
            a list of ACEs.";
          list ace {
            key "name";
            ordered-by user;
            description
              "List of access list entries.";
            leaf name {
              type string {
                length "1..64";
              }
              description
                "A unique name identifying this Access List
                Entry (ACE).";
              reference
                "RFC ZZZZ: Network Access Control List (ACL)
                          YANG Data Model";
            }
            container matches {
              description
                "The rules in this set determine what fields will be
                matched upon before any action is taken on them.

                If no matches are defined in a particular container,
                then any packet will match that container.

                If no matches are specified at all in an ACE, then any
                packet will match the ACE.";
              reference
                "RFC ZZZZ: Network Access Control List (ACL)
                            YANG Data Model";

              choice l3 {

Reddy, et al.          Expires October 20, 2018              [Page 25]
Internet-Draft        DOTS Data Channel Protocol            April 2018

                container ipv4 {
                  when "derived-from(../../../../type," +
                      "'ietf-acl:ipv4-acl-type"ietf-dots-data-channel:dots-client": [
        {
          "cuid": "dz6pHjaADkaFTbjr0JGBpw",
          "cdid": "7eeaf349529eb55ed50113"
        }
      ]
    }

                Figure 13: POST to Register (DOTS gateway)

  DOTS servers MUST limit the number of 'dots-client' resources to be
  created by the same DOTS client to 1 per request.  Requests with
  multiple 'dots-client' resources MUST be rejected by DOTS servers.
  To that aim, the DOTS server MUST rely on the same procedure to
  unambiguously identify a DOTS client as discussed in Section 4.4.1 of
  [I-D.ietf-dots-signal-channel].

  The DOTS server indicates the result of processing the POST request
  using status-line codes.  Status codes in the range "2xx" codes are
  success, "4xx" codes are some sort of invalid requests and "5xx"
  codes are returned if the DOTS server has erred or is incapable of
  accepting the creation of the 'dots-client' resource.  In particular,

  o  "201 Created" status-line is returned in the response, if the DOTS
      server has accepted the request.

  o  "400 Bad Request" status-line is returned by the DOTS server, if
      the request does not include a 'cuid' parameter.  The error-tag
      "missing-attribute" is used in this case.

  o  "409 Conflict" status-line is returned to the requesting DOTS
      client, if the data resource already exists.  The error-tag
      "resource-denied" is used in this case.

  Once a DOTS client registers itself to a DOTS server, it can
  create/delete/retrieve aliases (Section 6) and filtering rules
  (Section 7).

  A DOTS client MAY use the PUT request (Section 4.5 in [RFC8040]) to
  register a DOTS client within the DOTS server.  An example is shown
  in Figure 14.

Reddy, et al.          Expires October 20, 2018              [Page 36]
Internet-Draft        DOTS Data Channel Protocol            April 2018

            PUT /restconf/data/ietf-dots-data-channel:dots-data\
                /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1
            Host: {host}:{port}
            Content-Type: application/yang-data+json
            {
              "ietf-dots-data-channel:dots-client": [
                {
                  "cuid": "dz6pHjaADkaFTbjr0JGBpw"
                }
              ]
            }

                        Figure 14: PUT to Register

  The DOTS gateway that inserted a 'cdid' in a PUT request, MUST strip
  the 'cdid' parameter in the corresponding response before forwarding
  the response to the DOTS client.

5.2.  Uregistering DOTS Clients

  A DOTS client de-registers from its DOTS server by deleting the
  'cuid' resource.  Resources bound to this DOTS client will be deleted
  by the DOTS server.  An example of de-register request is shown in
  Figure 15.

    DELETE /restconf/data/ietf-dots-data-channel:dots-data\
          /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1
    Host: {host}:{port}

                  Figure 15: De-register a DOTS Client

6.  Managing DOTS Aliases

  The following sub-sections define means for a DOTS client to create
  aliases (Section 6.1), retrieve one or a list of aliases
  (Section 6.2), and delete an alias (Section 6.3).

6.1.  Create Aliases

  A POST or PUT request is used by a DOTS client to create aliases, for
  resources for which a mitigation may be requested.  Such aliases may
  be used in subsequent DOTS signal channel exchanges to refer more
  efficiently to the resources under attack.

  DOTS clients within the same domain can create different aliases for
  the same resource.

Reddy, et al.          Expires October 20, 2018              [Page 37]
Internet-Draft        DOTS Data Channel Protocol            April 2018

  The structure of POST requests used to create aliases is shown in
  Figure 16.

    POST /restconf/data/ietf-dots-data-channel:dots-data\
        /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1
    Host: {host}:{port}
    Content-Type: application/yang-data+json
    {
    "ietf-dots-data-channel:aliases": {
      "alias": [
        {
          "name": "string",
          "target-prefix": [
            "string"
          ],
          "target-port-range": [
            {
              "lower-port": integer,
              "upper-port": integer
            }
          ],
          "target-protocol": [
            integer
          ],
          "target-fqdn": [
            "string"
          ],
          "target-uri": [
            "string"
          ]
        }
      ]
    }
  }

                    Figure 16: POST to Create Aliases

  The parameters are described below:

  name:  Name of the alias.

      This is a mandatory attribute.

  target-prefix:  Prefixes are separated by commas.  Prefixes are
      represented using Classless Inter-domain Routing (CIDR) notation
      [RFC4632].  As a reminder, the prefix length must be less than or
      equal to 32 (resp. 128) for IPv4 (resp.  IPv6).

Reddy, et al.          Expires October 20, 2018              [Page 38]
Internet-Draft        DOTS Data Channel Protocol            April 2018

      The prefix list MUST NOT include broadcast, loopback, or multicast
      addresses.  These addresses are considered as invalid values.  In
      addition, the DOTS server MUST validate that these prefixes are
      within the scope of the DOTS client's domain.  Other validation
      checks may be supported by DOTS servers.

      This is an optional attribute.

  target-port-range:  A range of port numbers.

      The port range is defined by two bounds, a lower port number
      (lower-port) and an upper port number (upper-port).

      When only 'lower-port' is present, it represents a single port
      number.

      For TCP, UDP, Stream Control Transmission Protocol (SCTP)
      [RFC4960], or Datagram Congestion Control Protocol (DCCP)
      [RFC4340], the range of port numbers can be, for example,
      1024-65535.

      This is an optional attribute.

  target-protocol:  A list of protocols.  Values are taken from the
      IANA protocol registry [proto_numbers].

      The value '0' has a special meaning for 'all protocols'.

      This is an optional attribute.

  target-fqdn:  A list of Fully Qualified Domain Names (FQDNs).  An
      FQDN is the full name of a resource, rather than just its
      hostname.  For example, "venera" is a hostname, and
      "venera.isi.edu" is an FQDN [RFC1983].

      How a name is passed to an underlying name resolution library is
      implementation- and deployment-specific.  Nevertheless, once the
      name is resolved into one or multiple IP addresses, DOTS servers
      MUST apply the same validation checks as those for 'target-
      prefix'.

      This is an optional attribute.

  target-uri:  A list of Uniform Resource Identifiers (URIs)
      [RFC3986].

      The same validation checks used for 'target-fqdn' MUST be followed
      by DOTS servers to validate a target URI.

Reddy, et al.          Expires October 20, 2018              [Page 39]
Internet-Draft        DOTS Data Channel Protocol            April 2018

      This is an optional attribute.

  In POST requests, at least one of the 'target-prefix', 'target-fqdn',
  or 'target-uri' attributes MUST be present.  DOTS agents can safely
  ignore Vendor-Specific parameters they don't understand.

  Figure 17 shows a POST request to create an alias called "https1" for
  HTTPS servers with IP addresses 2001:db8:6401::1 and 2001:db8:6401::2
  listening on port number 443.

  POST /restconf/data/ietf-dots-data-channel:dots-data\
        /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1
  Host: www.example.com
  Content-Type: application/yang-data+json
  {
    "ietf-dots-data-channel:aliases": {
      "alias": [
        {
          "name": "https1",
          "target-protocol": [
            6
          ],
          "target-prefix": [
            "2001:db8:6401::1/128",
            "2001:db8:6401::2/128"
          ],
          "target-port-range": [
            {
              "lower-port": 443
            }
          ]
        }
      ]
    }
  }

              Figure 17: Example of a POST to Create an Alias

  "201 Created" status-line MUST be returned in the response if the
  DOTS server has accepted the alias.

  "409 Conflict" status-line MUST be returned to the requesting DOTS
  client, if the request is conflicting with an existing alias name.
  The error-tag "resource-denied" is used in this case.

  If the request is missing a mandatory attribute or its contains an
  invalid or unknown parameter, "400 Bad Request" status-line MUST be
  returned by the DOTS server.  The error-tag is set to "missing-

Reddy, et al.          Expires October 20, 2018              [Page 40]
#x27;)";
                  uses packet-fields:acl-ip-header-fields;
                  uses packet-fields:acl-ipv4-header-fields;
                  description
                    "Rule set that matches IPv4 header.";
                }
                container ipv6 {
                  when "derived-from(../../../../type," +
                      "'ietf-acl:ipv6-acl-type')";
                  uses packet-fields:acl-ip-header-fields;
                  uses packet-fields:acl-ipv6-header-fields;
                  leaf fragment {
                    type empty;
                    description
                      "Handle IPv6 fragments. When this keyword
                      is present, the match is about assessing
                      whether a packet is a fragment (that is,
                      a Fragment header is present).";
                  }
                  description
                    "Rule set that matches IPv6 header.";
                }
                description
                  "Either IPv4 or IPv6.";
              }
              choice l4 {
                container tcp {
                  uses packet-fields:acl-tcp-header-fields;
                  uses ports;
                  description
                    "Rule set that matches TCP header.";
                }
                container udp {
                  uses packet-fields:acl-udp-header-fields;
                  uses ports;
                  description
                    "Rule set that matches UDP header.