< draft-ietf-dots-signal-channel-00.txt   draft-ietf-dots-signal-channel-01.txt >
DOTS T. Reddy DOTS T. Reddy
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track M. Boucadair Intended status: Standards Track M. Boucadair
Expires: October 1, 2017 Orange Expires: October 20, 2017 Orange
P. Patil P. Patil
Cisco Cisco
A. Mortensen A. Mortensen
Arbor Networks, Inc. Arbor Networks, Inc.
N. Teague N. Teague
Verisign, Inc. Verisign, Inc.
March 30, 2017 April 18, 2017
Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
Channel Channel
draft-ietf-dots-signal-channel-00 draft-ietf-dots-signal-channel-01
Abstract Abstract
This document specifies the DOTS signal channel, a protocol for This document specifies the DOTS signal channel, a protocol for
signaling the need for protection against Distributed Denial-of- signaling the need for protection against Distributed Denial-of-
Service (DDoS) attacks to a server capable of enabling network Service (DDoS) attacks to a server capable of enabling network
traffic mitigation on behalf of the requesting client. A companion traffic mitigation on behalf of the requesting client. A companion
document defines the DOTS data channel, a separate reliable document defines the DOTS data channel, a separate reliable
communication layer for DOTS management and configuration. communication layer for DOTS management and configuration.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 1, 2017. This Internet-Draft will expire on October 20, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 32 skipping to change at page 2, line 32
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. DOTS Signal YANG Model . . . . . . . . . . . . . . . . . 8 5.2. DOTS Signal YANG Model . . . . . . . . . . . . . . . . . 8
5.2.1. Mitigation Request Model structure . . . . . . . . . 8 5.2.1. Mitigation Request Model structure . . . . . . . . . 8
5.2.2. Mitigation Request Model . . . . . . . . . . . . . . 8 5.2.2. Mitigation Request Model . . . . . . . . . . . . . . 8
5.2.3. Session Configuration Model structure . . . . . . . . 10 5.2.3. Session Configuration Model structure . . . . . . . . 10
5.2.4. Session Configuration Model . . . . . . . . . . . . . 10 5.2.4. Session Configuration Model . . . . . . . . . . . . . 10
5.3. Mitigation Request . . . . . . . . . . . . . . . . . . . 12 5.3. Mitigation Request . . . . . . . . . . . . . . . . . . . 12
5.3.1. Requesting mitigation . . . . . . . . . . . . . . . . 12 5.3.1. Requesting mitigation . . . . . . . . . . . . . . . . 12
5.3.2. Withdraw a DOTS Signal . . . . . . . . . . . . . . . 17 5.3.2. Withdraw a DOTS Signal . . . . . . . . . . . . . . . 17
5.3.3. Retrieving a DOTS Signal . . . . . . . . . . . . . . 18 5.3.3. Retrieving a DOTS Signal . . . . . . . . . . . . . . 18
5.3.4. Efficacy Update from DOTS Client . . . . . . . . . . 22 5.3.4. Efficacy Update from DOTS Client . . . . . . . . . . 23
5.4. DOTS Signal Channel Session Configuration . . . . . . . . 24 5.4. DOTS Signal Channel Session Configuration . . . . . . . . 25
5.4.1. Discover Acceptable Configuration Parameters . . . . 25 5.4.1. Discover Acceptable Configuration Parameters . . . . 26
5.4.2. Convey DOTS Signal Channel Session Configuration . . 26 5.4.2. Convey DOTS Signal Channel Session Configuration . . 27
5.4.3. Delete DOTS Signal Channel Session Configuration . . 28 5.4.3. Delete DOTS Signal Channel Session Configuration . . 29
5.4.4. Retrieving DOTS Signal Channel Session Configuration 28 5.4.4. Retrieving DOTS Signal Channel Session Configuration 29
5.5. Redirected Signaling . . . . . . . . . . . . . . . . . . 29 5.5. Redirected Signaling . . . . . . . . . . . . . . . . . . 30
5.6. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 30 5.6. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 31
6. Mapping parameters to CBOR . . . . . . . . . . . . . . . . . 31 6. Mapping parameters to CBOR . . . . . . . . . . . . . . . . . 32
7. (D)TLS Protocol Profile and Performance considerations . . . 31 7. (D)TLS Protocol Profile and Performance considerations . . . 32
7.1. MTU and Fragmentation Issues . . . . . . . . . . . . . . 32 7.1. MTU and Fragmentation Issues . . . . . . . . . . . . . . 33
8. (D)TLS 1.3 considerations . . . . . . . . . . . . . . . . . . 33 8. (D)TLS 1.3 considerations . . . . . . . . . . . . . . . . . . 34
9. Mutual Authentication of DOTS Agents & Authorization of DOTS 9. Mutual Authentication of DOTS Agents & Authorization of DOTS
Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
10.1. DOTS signal channel CBOR Mappings Registry . . . . . . . 36 10.1. DOTS signal channel CBOR Mappings Registry . . . . . . . 37
10.1.1. Registration Template . . . . . . . . . . . . . . . 36 10.1.1. Registration Template . . . . . . . . . . . . . . . 37
10.1.2. Initial Registry Contents . . . . . . . . . . . . . 36 10.1.2. Initial Registry Contents . . . . . . . . . . . . . 37
11. Implementation Status . . . . . . . . . . . . . . . . . . . . 39 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 41
11.1. nttdots . . . . . . . . . . . . . . . . . . . . . . . . 40 11.1. nttdots . . . . . . . . . . . . . . . . . . . . . . . . 41
12. Security Considerations . . . . . . . . . . . . . . . . . . . 40 12. Security Considerations . . . . . . . . . . . . . . . . . . . 42
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 41 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
15.1. Normative References . . . . . . . . . . . . . . . . . . 42 15.1. Normative References . . . . . . . . . . . . . . . . . . 43
15.2. Informative References . . . . . . . . . . . . . . . . . 43 15.2. Informative References . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
1. Introduction 1. Introduction
A distributed denial-of-service (DDoS) attack is an attempt to make A distributed denial-of-service (DDoS) attack is an attempt to make
machines or network resources unavailable to their intended users. machines or network resources unavailable to their intended users.
In most cases, sufficient scale can be achieved by compromising In most cases, sufficient scale can be achieved by compromising
enough end-hosts and using those infected hosts to perpetrate and enough end-hosts and using those infected hosts to perpetrate and
amplify the attack. The victim in this attack can be an application amplify the attack. The victim in this attack can be an application
server, a host, a router, a firewall, or an entire network. server, a host, a router, a firewall, or an entire network.
skipping to change at page 8, line 17 skipping to change at page 8, line 17
This document defines a YANG [RFC6020] data model for mitigation This document defines a YANG [RFC6020] data model for mitigation
scope and DOTS signal channel session configuration data. scope and DOTS signal channel session configuration data.
5.2.1. Mitigation Request Model structure 5.2.1. Mitigation Request Model structure
This document defines the YANG module "ietf-dots-signal", which has This document defines the YANG module "ietf-dots-signal", which has
the following structure: the following structure:
module: ietf-dots-signal module: ietf-dots-signal
+--rw mitigation-scope +--rw mitigation-scope
+--rw scope* [policy-id] +--rw scope* [mitigation-id]
+--rw policy-id int32 +--rw mitigation-id int32
+--rw target-ip* inet:ip-address +--rw target-ip* inet:ip-address
+--rw target-prefix* inet:ip-prefix +--rw target-prefix* inet:ip-prefix
+--rw target-port-range* [lower-port upper-port] +--rw target-port-range* [lower-port upper-port]
| +--rw lower-port inet:port-number | +--rw lower-port inet:port-number
| +--rw upper-port inet:port-number | +--rw upper-port inet:port-number
+--rw target-protocol* uint8 +--rw target-protocol* uint8
+--rw FQDN* inet:domain-name +--rw FQDN* inet:domain-name
+--rw URI* inet:uri +--rw URI* inet:uri
+--rw alias* string +--rw alias* string
+--rw lifetime? int32 +--rw lifetime? int32
skipping to change at page 9, line 6 skipping to change at page 9, line 6
signal sent by the DOTS client to the DOTS server"; signal sent by the DOTS client to the DOTS server";
revision 2016-11-28 { revision 2016-11-28 {
reference reference
"https://tools.ietf.org/html/draft-reddy-dots-signal-channel"; "https://tools.ietf.org/html/draft-reddy-dots-signal-channel";
} }
container mitigation-scope { container mitigation-scope {
description "top level container for mitigation request"; description "top level container for mitigation request";
list scope { list scope {
key policy-id; key mitigation-id;
description "Identifier for the mitigation request"; description "Identifier for the mitigation request";
leaf policy-id { leaf mitigation-id {
type int32; type int32;
description "policy identifier"; description "mitigation request identifier";
} }
leaf-list target-ip { leaf-list target-ip {
type inet:ip-address; type inet:ip-address;
description "IP address"; description "IP address";
} }
leaf-list target-prefix { leaf-list target-prefix {
type inet:ip-prefix; type inet:ip-prefix;
description "prefix"; description "prefix";
} }
list target-port-range { list target-port-range {
skipping to change at page 10, line 23 skipping to change at page 10, line 23
} }
<CODE ENDS> <CODE ENDS>
5.2.3. Session Configuration Model structure 5.2.3. Session Configuration Model structure
This document defines the YANG module "ietf-dots-signal-config", This document defines the YANG module "ietf-dots-signal-config",
which has the following structure: which has the following structure:
module: ietf-dots-signal-config module: ietf-dots-signal-config
+--rw signal-config +--rw signal-config
+--rw policy-id? int32 +--rw session-id? int32
+--rw heartbeat-timeout? int16 +--rw heartbeat-timeout? int16
+--rw max-retransmit? int16 +--rw max-retransmit? int16
+--rw ack-timeout? int16 +--rw ack-timeout? int16
+--rw ack-random-factor? decimal64 +--rw ack-random-factor? decimal64
5.2.4. Session Configuration Model 5.2.4. Session Configuration Model
<CODE BEGINS> file "ietf-dots-signal-config@2016-11-28.yang" <CODE BEGINS> file "ietf-dots-signal-config@2016-11-28.yang"
module ietf-dots-signal-config { module ietf-dots-signal-config {
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-config"; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-config";
skipping to change at page 11, line 24 skipping to change at page 11, line 24
signal channel session configuration"; signal channel session configuration";
revision 2016-11-28 { revision 2016-11-28 {
reference reference
"https://tools.ietf.org/html/draft-reddy-dots-signal-channel"; "https://tools.ietf.org/html/draft-reddy-dots-signal-channel";
} }
container signal-config { container signal-config {
description "top level container for DOTS signal channel session description "top level container for DOTS signal channel session
configuration"; configuration";
leaf policy-id { leaf session-id {
type int32; type int32;
description "Identifier for the DOTS signal channel description "Identifier for the DOTS signal channel
session configuration data"; session configuration data";
} }
leaf heartbeat-timeout { leaf heartbeat-timeout {
type int16; type int16;
description "heartbeat timeout"; description "heartbeat timeout";
} }
leaf max-retransmit { leaf max-retransmit {
type int16; type int16;
skipping to change at page 13, line 15 skipping to change at page 13, line 15
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Host: "host" Uri-Host: "host"
Uri-Path: "version" Uri-Path: "version"
Uri-Path: "dots-signal" Uri-Path: "dots-signal"
Uri-Path: "signal" Uri-Path: "signal"
Content-Type: "application/cbor" Content-Type: "application/cbor"
{ {
"mitigation-scope": { "mitigation-scope": {
"scope": [ "scope": [
{ {
"policy-id": integer, "mitigation-id": integer,
"target-ip": [ "target-ip": [
"string" "string"
], ],
"target-prefix": [ "target-prefix": [
"string" "string"
], ],
"target-port-range": [ "target-port-range": [
{ {
"lower-port": integer, "lower-port": integer,
"upper-port": integer "upper-port": integer
skipping to change at page 13, line 50 skipping to change at page 13, line 50
"lifetime": integer "lifetime": integer
} }
] ]
} }
} }
Figure 5: PUT to convey DOTS signals Figure 5: PUT to convey DOTS signals
The parameters are described below. The parameters are described below.
policy-id: Identifier for the mitigation request represented using mitigation-id: Identifier for the mitigation request represented
an integer. This identifier MUST be unique for each mitigation using an integer. This identifier MUST be unique for each
request bound to the DOTS client, i.e., the policy-id parameter mitigation request bound to the DOTS client, i.e., the mitigation-
value in the mitigation request needs to be unique relative to the id parameter value in the mitigation request needs to be unique
policy-id parameter values of active mitigation requests conveyed relative to the mitigation-id parameter values of active
from the DOTS client to the DOTS server. This identifier MUST be mitigation requests conveyed from the DOTS client to the DOTS
generated by the DOTS client. This document does not make any server. This identifier MUST be generated by the DOTS client.
assumption about how this identifier is generated. This is a This document does not make any assumption about how this
mandatory attribute. identifier is generated. This is a mandatory attribute.
target-ip: A list of IP addresses under attack. This is an optional target-ip: A list of IP addresses under attack. This is an optional
attribute. attribute.
target-prefix: A list of prefixes under attack. Prefixes are target-prefix: A list of prefixes under attack. Prefixes are
represented using CIDR notation [RFC4632]. This is an optional represented using CIDR notation [RFC4632]. This is an optional
attribute. attribute.
target-port-range: A list of ports under attack. The port range, target-port-range: A list of ports under attack. The port range,
lower-port for lower port number and upper-port for upper port lower-port for lower port number and upper-port for upper port
number. When only lower-port is present, it represents a single number. When only lower-port is present, it represents a single
port. For TCP, UDP, SCTP, or DCCP: the range of ports (e.g., port. For TCP, UDP, SCTP, or DCCP: the range of ports (e.g.,
1024-65535). This is an optional attribute. 1024-65535). This is an optional attribute.
target-protocol: A list of protocols under attack. Internet target-protocol: A list of protocols under attack. Internet
Protocol numbers. This is an optional attribute. Protocol numbers. This is an optional attribute.
FQDN: A list of Fully Qualified Domain Names. Fully Qualified FQDN: A list of Fully Qualified Domain Names. Fully Qualified
Domain Name (FQDN) is the full name of a system, rather than just Domain Name (FQDN) is the full name of a system, rather than just
its hostname. For example, "venera" is a hostname, and its hostname. For example, "venera" is a hostname, and
"venera.isi.edu" is an FQDN. This is an optional attribute. "venera.isi.edu" is an FQDN. This is an optional attribute.
URI: A list of Uniform Resource Identifiers (URI). This is an URI: A list of Uniform Resource Identifiers (URI). This is an
optional attribute. optional attribute.
alias: A list of aliases (see Section 3.1.1 in alias: A list of aliases. Aliases can be created using the DOTS
[I-D.reddy-dots-data-channel]). This is an optional attribute. data channel (Section 3.1.1 in [I-D.reddy-dots-data-channel]) or
direct connection and then used in subsequent signal channel
exchanges to refer more efficiently to the resources under attack.
This is an optional attribute.
lifetime: Lifetime of the mitigation request in seconds. Upon the lifetime: Lifetime of the mitigation request in seconds. Upon the
expiry of this lifetime, and if the request is not refreshed, the expiry of this lifetime, and if the request is not refreshed, the
mitigation request is removed. The request can be refreshed by mitigation request is removed. The request can be refreshed by
sending the same request again. The default lifetime of the sending the same request again. The default lifetime of the
mitigation request is 3600 seconds (60 minutes) -- this value was mitigation request is 3600 seconds (60 minutes) -- this value was
chosen to be long enough so that refreshing is not typically a chosen to be long enough so that refreshing is not typically a
burden on the DOTS client, while expiring the request where the burden on the DOTS client, while expiring the request where the
client has unexpectedly quit in a timely manner. A lifetime of client has unexpectedly quit in a timely manner. A lifetime of
zero indicates indefinite lifetime for the mitigation request. zero indicates indefinite lifetime for the mitigation request.
The server MUST always indicate the actual lifetime in the The server MUST always indicate the actual lifetime in the
response and the remaining lifetime in status messages sent to the response and the remaining lifetime in status messages sent to the
client. This is an optional attribute in the request. client. This is an optional attribute in the request.
The CBOR key values for the parameters are defined in Section 6. The The CBOR key values for the parameters are defined in Section 6. The
IANA Considerations section defines how the CBOR key values can be IANA Considerations section defines how the CBOR key values can be
allocated to standards bodies and vendors. In the PUT request at allocated to standards bodies and vendors. In the PUT request at
least one of the attributes target-ip or target-prefix or FQDN or URI least one of the attributes target-ip or target-prefix or FQDN or URI
or alias MUST be present. DOTS agents can safely ignore Vendor- or alias MUST be present. DOTS agents can safely ignore Vendor-
Specific parameters they don't understand. The relative order of two Specific parameters they don't understand. The relative order of two
mitigation requests from a DOTS client is determined by comparing mitigation requests from a DOTS client is determined by comparing
their respective policy-id values. If two mitigation requests have their respective mitigation-id values. If two mitigation requests
overlapping mitigation scopes the mitigation request with higher have overlapping mitigation scopes the mitigation request with higher
numeric policy-id value will override the mitigation request with a numeric mitigation-id value will override the mitigation request with
lower numeric policy-id value. The Uri-Path option carries a major a lower numeric mitigation-id value. The Uri-Path option carries a
and minor version nomenclature to manage versioning and DOTS signal major and minor version nomenclature to manage versioning and DOTS
channel in this specification uses v1 major version. signal channel in this specification uses v1 major version.
In both DOTS signal and data channel sessions, the DOTS client MUST In both DOTS signal and data channel sessions, the DOTS client MUST
authenticate itself to the DOTS server (Section 9). The DOTS server authenticate itself to the DOTS server (Section 9). The DOTS server
couples the DOTS signal and data channel sessions using the DOTS couples the DOTS signal and data channel sessions using the DOTS
client identity, so the DOTS server can validate whether the aliases client identity, so the DOTS server can validate whether the aliases
conveyed in the mitigation request were indeed created by the same conveyed in the mitigation request were indeed created by the same
DOTS client using the DOTS data channel session. If the aliases were DOTS client using the DOTS data channel session. If the aliases were
not created by the DOTS client then the DOTS server returns 4.00 (Bad not created by the DOTS client then the DOTS server returns 4.00 (Bad
Request) in the response. The DOTS server couples the DOTS signal Request) in the response. The DOTS server couples the DOTS signal
channel sessions using the DOTS client identity, the DOTS server uses channel sessions using the DOTS client identity, and the DOTS server
policy-id parameter value to detect duplicate mitigation requests. uses mitigation-id parameter value to detect duplicate mitigation
requests.
Figure 6 shows a PUT request example to signal that ports 80, 8080, Figure 6 shows a PUT request example to signal that ports 80, 8080,
and 443 on the servers 2002:db8:6401::1 and 2002:db8:6401::2 are and 443 on the servers 2002:db8:6401::1 and 2002:db8:6401::2 are
being attacked (illustrated in JSON diagnostic notation). being attacked (illustrated in JSON diagnostic notation).
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Host: "www.example.com" Uri-Host: "www.example.com"
Uri-Path: "v1" Uri-Path: "v1"
Uri-Path: "dots-signal" Uri-Path: "dots-signal"
Uri-Path: "signal" Uri-Path: "signal"
Content-Format: "application/cbor" Content-Format: "application/cbor"
{ {
"mitigation-scope": { "mitigation-scope": {
"scope": [ "scope": [
{ {
"policy-id": 12332, "mitigation-id": 12332,
"target-ip": [ "target-ip": [
"2002:db8:6401::1", "2002:db8:6401::1",
"2002:db8:6401::2" "2002:db8:6401::2"
], ],
"target-port-range": [ "target-port-range": [
{ {
"lower-port": 80 "lower-port": 80
}, },
{ {
"lower-port": 443 "lower-port": 443
skipping to change at page 16, line 49 skipping to change at page 17, line 6
81 # array(1) 81 # array(1)
06 # unsigned(6) 06 # unsigned(6)
Figure 6: POST for DOTS signal Figure 6: POST for DOTS signal
The DOTS server indicates the result of processing the PUT request The DOTS server indicates the result of processing the PUT request
using CoAP response codes. CoAP 2.xx codes are success. CoAP 4.xx using CoAP response codes. CoAP 2.xx codes are success. CoAP 4.xx
codes are some sort of invalid requests. COAP 5.xx codes are codes are some sort of invalid requests. COAP 5.xx codes are
returned if the DOTS server has erred or is currently unavailable to returned if the DOTS server has erred or is currently unavailable to
provide mitigation in response to the mitigation request from the provide mitigation in response to the mitigation request from the
DOTS client. If the DOTS server does not find the policy-id DOTS client. If the DOTS server does not find the mitigation-id
parameter value conveyed in the PUT request in its configuration data parameter value conveyed in the PUT request in its configuration data
then the server MAY accept the mitigation request, and a 2.01 then the server MAY accept the mitigation request, and a 2.01
(Created) response is returned to the DOTS client, and the DOTS (Created) response is returned to the DOTS client, and the DOTS
server will try to mitigate the attack. If the DOTS server finds the server will try to mitigate the attack. If the DOTS server finds the
policy-id parameter value conveyed in the PUT request in its mitigation-id parameter value conveyed in the PUT request in its
configuration data then the server MAY update the mitigation request, configuration data then the server MAY update the mitigation request,
and a 2.04 (Changed) response is returned to indicate a successful and a 2.04 (Changed) response is returned to indicate a successful
updation of the mitigation request. If the request is missing one or updation of the mitigation request. If the request is missing one or
more mandatory attributes, then 4.00 (Bad Request) will be returned more mandatory attributes, then 4.00 (Bad Request) will be returned
in the response or if the request contains invalid or unknown in the response or if the request contains invalid or unknown
parameters then 4.02 (Invalid query) will be returned in the parameters then 4.02 (Invalid query) will be returned in the
response. For responses indicating a client or server error, the response. For responses indicating a client or server error, the
payload explains the error situation of the result of the requested payload explains the error situation of the result of the requested
action (Section 5.5 in [RFC7252]). action (Section 5.5 in [RFC7252]).
skipping to change at page 17, line 33 skipping to change at page 17, line 37
Header: DELETE (Code=0.04) Header: DELETE (Code=0.04)
Uri-Host: "host" Uri-Host: "host"
Uri-Path: "version" Uri-Path: "version"
Uri-Path: "dots-signal" Uri-Path: "dots-signal"
Uri-Path: "signal" Uri-Path: "signal"
Content-Format: "application/cbor" Content-Format: "application/cbor"
{ {
"mitigation-scope": { "mitigation-scope": {
"scope": [ "scope": [
{ {
"policy-id": integer "mitigation-id": integer
} }
] ]
} }
} }
Figure 7: Withdraw DOTS signal Figure 7: Withdraw DOTS signal
If the DOTS server does not find the policy-id parameter value If the DOTS server does not find the mitigation-id parameter value
conveyed in the DELETE request in its configuration data, then it conveyed in the DELETE request in its configuration data, then it
responds with a 4.04 (Not Found) error response code. The DOTS responds with a 4.04 (Not Found) error response code. The DOTS
server successfully acknowledges a DOTS client's request to withdraw server successfully acknowledges a DOTS client's request to withdraw
the DOTS signal using 2.02 (Deleted) response code, and ceases the DOTS signal using 2.02 (Deleted) response code, and ceases
mitigation activity as quickly as possible. mitigation activity as quickly as possible.
To protect against route or DNS flapping caused by a client rapidly To protect against route or DNS flapping caused by a client rapidly
toggling mitigation, and to dampen the effect of oscillating attacks, toggling mitigation, and to dampen the effect of oscillating attacks,
DOTS servers MAY continue mitigation for a period of up to fifteen DOTS servers MAY continue mitigation for a period of up to fifteen
minutes after acknowledging a DOTS client's withdrawal of a minutes after acknowledging a DOTS client's withdrawal of a
mitigation request. During this period, DOTS server mitigation mitigation request. During this period, DOTS server mitigation
status messages SHOULD indicate that mitigation is active but status messages SHOULD indicate that mitigation is active but
terminating. After the fifteen-minute period elapses, the DOTS terminating. After the fifteen-minute period elapses, the DOTS
server MUST treat the mitigation as terminated, as the DOTS client is server MUST treat the mitigation as terminated, as the DOTS client is
no longer responsible for the mitigation. no longer responsible for the mitigation.
5.3.3. Retrieving a DOTS Signal 5.3.3. Retrieving a DOTS Signal
A GET request is used to retrieve information and status of a DOTS A GET request is used to retrieve information and status of a DOTS
signal from a DOTS server (Figure 8). If the DOTS server does not signal from a DOTS server (Figure 8). If the DOTS server does not
find the policy-id parameter value conveyed in the GET request in its find the mitigation-id parameter value conveyed in the GET request in
configuration data, then it responds with a 4.04 (Not Found) error its configuration data, then it responds with a 4.04 (Not Found)
response code. The 'c' (content) parameter and its permitted values error response code. The 'c' (content) parameter and its permitted
defined in [I-D.ietf-core-comi] can be used to retrieve non- values defined in [I-D.ietf-core-comi] can be used to retrieve non-
configuration data or configuration data or both. configuration data or configuration data or both.
1) To retrieve all DOTS signals signaled by the DOTS client. 1) To retrieve all DOTS signals signaled by the DOTS client.
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Host: "host" Uri-Host: "host"
Uri-Path: "version" Uri-Path: "version"
Uri-Path: "dots-signal" Uri-Path: "dots-signal"
Uri-Path: "signal" Uri-Path: "signal"
Observe : 0 Observe : 0
skipping to change at page 18, line 44 skipping to change at page 19, line 29
Uri-Host: "host" Uri-Host: "host"
Uri-Path: "version" Uri-Path: "version"
Uri-Path: "dots-signal" Uri-Path: "dots-signal"
Uri-Path: "signal" Uri-Path: "signal"
Observe : 0 Observe : 0
Content-Format: "application/cbor" Content-Format: "application/cbor"
{ {
"mitigation-scope": { "mitigation-scope": {
"scope": [ "scope": [
{ {
"policy-id": integer "mitigation-id": integer
} }
] ]
} }
} }
Figure 8: GET to retrieve the rules Figure 8: GET to retrieve the rules
Figure 9 shows a response example of all the active mitigation Figure 9 shows a response example of all the active mitigation
requests associated with the DOTS client on the DOTS server and the requests associated with the DOTS client on the DOTS server and the
mitigation status of each mitigation request. mitigation status of each mitigation request.
{ {
"mitigation-scope":[ "mitigation-scope":[
{ {
"scope": [ "scope": [
{ {
"policy-id": 12332, "mitigation-id": 12332,
"target-protocol": [ "target-protocol": [
17 17
], ],
"lifetime":1800, "lifetime":1800,
"status":2, "status":2,
"bytes_dropped": 134334555, "bytes-dropped": 134334555,
"bps_dropped": 43344, "bps-dropped": 43344,
"pkts_dropped": 333334444, "pkts-dropped": 333334444,
"pps_dropped": 432432 "pps-dropped": 432432
} }
] ]
}, },
{ {
"scope": [ "scope": [
{ {
"policy-id": 12333, "mitigation-id": 12333,
"target-protocol": [ "target-protocol": [
6 6
], ],
"lifetime":1800, "lifetime":1800,
"status":3 "status":3
"bytes_dropped": 0, "bytes-dropped": 0,
"bps_dropped": 0, "bps-dropped": 0,
"pkts_dropped": 0, "pkts-dropped": 0,
"pps_dropped": 0 "pps-dropped": 0
} }
] ]
} }
] ]
} }
Figure 9: Response body Figure 9: Response body
The mitigation status parameters are described below. The mitigation status parameters are described below.
bytes_dropped: The total dropped byte count for the mitigation bytes-dropped: The total dropped byte count for the mitigation
request. This is a optional attribute. request. This is a optional attribute.
bps-dropped: The average dropped bytes per second for the mitigation
bps_dropped: The average dropped bytes per second for the mitigation
request. This is a optional attribute. request. This is a optional attribute.
pkts_dropped: The total dropped packet count for the mitigation pkts-dropped: The total dropped packet count for the mitigation
request. This is a optional attribute. request. This is a optional attribute.
pps_dropped: The average dropped packets per second for the
pps-dropped: The average dropped packets per second for the
mitigation request. This is a optional attribute. mitigation request. This is a optional attribute.
status: Status of attack mitigation. The 'status' parameter is a status: Status of attack mitigation. The 'status' parameter is a
mandatory attribute. mandatory attribute.
The various possible values of 'status' parameter are explained The various possible values of 'status' parameter are explained
below: below:
/--------------------+---------------------------------------------------\ /--------------------+---------------------------------------------------\
| Parameter value | Description | | Parameter value | Description |
|--------------------+---------------------------------------------------| |--------------------+---------------------------------------------------|
skipping to change at page 21, line 8 skipping to change at page 22, line 6
server. Unidirectional notifications within the bidirectional signal server. Unidirectional notifications within the bidirectional signal
channel allows unsolicited message delivery, enabling asynchronous channel allows unsolicited message delivery, enabling asynchronous
notifications between the agents. A DOTS client that is no longer notifications between the agents. A DOTS client that is no longer
interested in receiving notifications from the DOTS server can simply interested in receiving notifications from the DOTS server can simply
"forget" the observation. When the DOTS server then sends the next "forget" the observation. When the DOTS server then sends the next
notification, the DOTS client will not recognize the token in the notification, the DOTS client will not recognize the token in the
message and thus will return a Reset message. This causes the DOTS message and thus will return a Reset message. This causes the DOTS
server to remove the associated entry. server to remove the associated entry.
DOTS Client DOTS Server DOTS Client DOTS Server
| | | |
| GET /<policy-id number> | | GET /<mitigation-id number> |
| Token: 0x4a | Registration | Token: 0x4a | Registration
| Observe: 0 | | Observe: 0 |
+-------------------------->| +------------------------------>|
| | | |
| 2.05 Content | | 2.05 Content |
| Token: 0x4a | Notification of | Token: 0x4a | Notification of
| Observe: 12 | the current state | Observe: 12 | the current state
| status: "mitigation | | status: "mitigation |
| in progress" | | in progress" |
|<--------------------------+ |<------------------------------+
| 2.05 Content | | 2.05 Content |
| Token: 0x4a | Notification upon | Token: 0x4a | Notification upon
| Observe: 44 | a state change | Observe: 44 | a state change
| status: "mitigation | | status: "mitigation |
| complete" | | complete" |
|<--------------------------+ |<------------------------------+
| 2.05 Content | | 2.05 Content |
| Token: 0x4a | Notification upon | Token: 0x4a | Notification upon
| Observe: 60 | a state change | Observe: 60 | a state change
| status: "attack stopped" | | status: "attack stopped" |
|<--------------------------+ |<------------------------------+
| | | |
Figure 10: Notifications of attack mitigation status Figure 10: Notifications of attack mitigation status
5.3.3.1. Mitigation Status 5.3.3.1. Mitigation Status
A DOTS client retrieves the information about a DOTS signal at A DOTS client retrieves the information about a DOTS signal at
frequent intervals to determine the status of an attack. If the DOTS frequent intervals to determine the status of an attack. If the DOTS
server has been able to mitigate the attack and the attack has server has been able to mitigate the attack and the attack has
stopped, the DOTS server indicates as such in the status, and the stopped, the DOTS server indicates as such in the status, and the
DOTS client recalls the mitigation request. DOTS client recalls the mitigation request.
skipping to change at page 23, line 15 skipping to change at page 24, line 15
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Host: "host" Uri-Host: "host"
Uri-Path: "version" Uri-Path: "version"
Uri-Path: "dots-signal" Uri-Path: "dots-signal"
Uri-Path: "signal" Uri-Path: "signal"
Content-Format: "application/cbor" Content-Format: "application/cbor"
{ {
"mitigation-scope": { "mitigation-scope": {
"scope": [ "scope": [
{ {
"policy-id": integer, "mitigation-id": integer,
"target-ip": [ "target-ip": [
"string" "string"
], ],
"target-port-range": [ "target-port-range": [
{ {
"lower-port": integer, "lower-port": integer,
"upper-port": integer "upper-port": integer
} }
], ],
"target-protocol": [ "target-protocol": [
skipping to change at page 24, line 19 skipping to change at page 25, line 19
+---------------------------------------------------------------------------+ +---------------------------------------------------------------------------+
| 2 | DOTS client determines that the attack is | | 2 | DOTS client determines that the attack is |
| | successfully mitigated | | | successfully mitigated |
| | (e.g., attack traffic is not seen). | | | (e.g., attack traffic is not seen). |
\--------------------+------------------------------------------------------/ \--------------------+------------------------------------------------------/
The DOTS server indicates the result of processing the PUT request The DOTS server indicates the result of processing the PUT request
using CoAP response codes. The response code 2.04 (Changed) will be using CoAP response codes. The response code 2.04 (Changed) will be
returned in the response if the DOTS server has accepted the returned in the response if the DOTS server has accepted the
mitigation efficacy update. If the DOTS server does not find the mitigation efficacy update. If the DOTS server does not find the
policy-id parameter value conveyed in the PUT request in its mitigation-id parameter value conveyed in the PUT request in its
configuration data then the server MAY accept the mitigation request configuration data then the server MAY accept the mitigation request
and will try to mitigate the attack, resulting in a 2.01 (Created) and will try to mitigate the attack, resulting in a 2.01 (Created)
Response Code. The 5.xx response codes are returned if the DOTS Response Code. The 5.xx response codes are returned if the DOTS
server has erred or is incapable of performing the mitigation. server has erred or is incapable of performing the mitigation.
5.4. DOTS Signal Channel Session Configuration 5.4. DOTS Signal Channel Session Configuration
The DOTS client can negotiate, configure and retrieve the DOTS signal The DOTS client can negotiate, configure and retrieve the DOTS signal
channel session behavior. The DOTS signal channel can be used, for channel session behavior. The DOTS signal channel can be used, for
example, to configure the following: example, to configure the following:
skipping to change at page 26, line 27 skipping to change at page 27, line 27
agents. agents.
Header: POST (Code=0.02) Header: POST (Code=0.02)
Uri-Host: "host" Uri-Host: "host"
Uri-Path: "version" Uri-Path: "version"
Uri-Path: "dots-signal" Uri-Path: "dots-signal"
Uri-Path: "config" Uri-Path: "config"
Content-Format: "application/cbor" Content-Format: "application/cbor"
{ {
"signal-config": { "signal-config": {
"policy-id": integer, "session-id": integer,
"heartbeat-timeout": integer, "heartbeat-timeout": integer,
"max-retransmit": integer, "max-retransmit": integer,
"ack-timeout": integer, "ack-timeout": integer,
"ack-random-factor": number "ack-random-factor": number
} }
} }
Figure 14: POST to convey the DOTS signal channel session Figure 14: POST to convey the DOTS signal channel session
configuration data. configuration data.
The parameters are described below: The parameters are described below:
policy-id: Identifier for the DOTS signal channel session session-id: Identifier for the DOTS signal channel session
configuration data represented as an integer. This identifier configuration data represented as an integer. This identifier
MUST be generated by the DOTS client. This document does not make MUST be generated by the DOTS client. This document does not make
any assumption about how this identifier is generated. This is a any assumption about how this identifier is generated. This is a
mandatory attribute. mandatory attribute.
heartbeat-timeout: Heartbeat timeout is the time to wait for a heartbeat-timeout: Heartbeat timeout is the time to wait for a
response in milliseconds to check the DOTS peer health. This is response in milliseconds to check the DOTS peer health. This is
an optional attribute. an optional attribute.
max-retransmit: Maximum number of retransmissions for a message max-retransmit: Maximum number of retransmissions for a message
(referred to as MAX_RETRANSMIT parameter in CoAP). This is an (referred to as MAX_RETRANSMIT parameter in CoAP). This is an
optional attribute. optional attribute.
ack-timeout: Timeout value in seconds used to calculate the intial ack-timeout: Timeout value in seconds used to calculate the intial
retransmission timeout value (referred to as ACK_TIMEOUT parameter retransmission timeout value (referred to as ACK_TIMEOUT parameter
in CoAP). This is an optional attribute. in CoAP). This is an optional attribute.
ack-random-factor: Random factor used to influence the timing of ack-random-factor: Random factor used to influence the timing of
retransmissions (referred to as ACK_RANDOM_FACTOR parameter in retransmissions (referred to as ACK_RANDOM_FACTOR parameter in
CoAP). This is an optional attribute. CoAP). This is an optional attribute.
In the POST request at least one of the attributes heartbeat-timeout In the POST request at least one of the attributes heartbeat-timeout
or max-retransmit or ack-timeout or ack-random-factor MUST be or max-retransmit or ack-timeout or ack-random-factor MUST be
present. The POST request with higher numeric policy-id value over- present. The POST request with higher numeric session-id value over-
rides the DOTS signal channel session configuration data installed by rides the DOTS signal channel session configuration data installed by
a POST request with a lower numeric policy-id value. a POST request with a lower numeric session-id value.
Figure 15 shows a POST request example to convey the configuration Figure 15 shows a POST request example to convey the configuration
parameters for the DOTS signal channel. parameters for the DOTS signal channel.
Header: POST (Code=0.02) Header: POST (Code=0.02)
Uri-Host: "www.example.com" Uri-Host: "www.example.com"
Uri-Path: "v1" Uri-Path: "v1"
Uri-Path: "dots-signal" Uri-Path: "dots-signal"
Uri-Path: "config" Uri-Path: "config"
Content-Format: "application/cbor" Content-Format: "application/cbor"
{ {
"signal-config": { "signal-config": {
"policy-id": 1234534333242, "session-id": 1234534333242,
"heartbeat-timeout": 30, "heartbeat-timeout": 30,
"max-retransmit": 7, "max-retransmit": 7,
"ack-timeout": 5, "ack-timeout": 5,
"ack-random-factor": 1.5 "ack-random-factor": 1.5
} }
} }
Figure 15: POST to convey the configuration parameters Figure 15: POST to convey the configuration parameters
The DOTS server indicates the result of processing the POST request The DOTS server indicates the result of processing the POST request
skipping to change at page 28, line 31 skipping to change at page 29, line 31
session configuration data (Figure 17). session configuration data (Figure 17).
Header: DELETE (Code=0.04) Header: DELETE (Code=0.04)
Uri-Host: "host" Uri-Host: "host"
Uri-Path: "version" Uri-Path: "version"
Uri-Path: "dots-signal" Uri-Path: "dots-signal"
Uri-Path: "config" Uri-Path: "config"
Content-Format: "application/cbor" Content-Format: "application/cbor"
{ {
"signal-config": { "signal-config": {
"policy-id": integer "session-id": integer
} }
} }
Figure 17: DELETE configuration Figure 17: DELETE configuration
If the DOTS server does not find the policy-id parameter value If the DOTS server does not find the session-id parameter value
conveyed in the DELETE request in its configuration data, then it conveyed in the DELETE request in its configuration data, then it
responds with a 4.04 (Not Found) error response code. The DOTS responds with a 4.04 (Not Found) error response code. The DOTS
server successfully acknowledges a DOTS client's request to remove server successfully acknowledges a DOTS client's request to remove
the DOTS signal channel session configuration using 2.02 (Deleted) the DOTS signal channel session configuration using 2.02 (Deleted)
response code. response code.
5.4.4. Retrieving DOTS Signal Channel Session Configuration 5.4.4. Retrieving DOTS Signal Channel Session Configuration
A GET request is used to retrieve the installed DOTS signal channel A GET request is used to retrieve the installed DOTS signal channel
session configuration data from a DOTS server. Figure 18 shows how session configuration data from a DOTS server. Figure 18 shows how
to retrieve the DOTS signal channel session configuration data. to retrieve the DOTS signal channel session configuration data.
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Host: "host" Uri-Host: "host"
Uri-Path: "version" Uri-Path: "version"
Uri-Path: "dots-signal" Uri-Path: "dots-signal"
Uri-Path: "config" Uri-Path: "config"
Content-Format: "application/cbor" Content-Format: "application/cbor"
{ {
"signal-config": { "signal-config": {
"policy-id": integer "session-id": integer
} }
} }
Figure 18: GET to retrieve configuration Figure 18: GET to retrieve configuration
5.5. Redirected Signaling 5.5. Redirected Signaling
Redirected Signaling is discussed in detail in Section 3.2.2 of Redirected Signaling is discussed in detail in Section 3.2.2 of
[I-D.ietf-dots-architecture]. If the DOTS server wants to redirect [I-D.ietf-dots-architecture]. If the DOTS server wants to redirect
the DOTS client to an alternative DOTS server for a signaling session the DOTS client to an alternative DOTS server for a signaling session
skipping to change at page 31, line 15 skipping to change at page 32, line 15
6. Mapping parameters to CBOR 6. Mapping parameters to CBOR
All parameters in DOTS signal channel are mapped to CBOR types as All parameters in DOTS signal channel are mapped to CBOR types as
follows and are given an integer key value to save space. follows and are given an integer key value to save space.
/--------------------+------------------------+--------------------------\ /--------------------+------------------------+--------------------------\
| Parameter name | CBOR key | CBOR major type of value | | Parameter name | CBOR key | CBOR major type of value |
|--------------------+------------------------+--------------------------| |--------------------+------------------------+--------------------------|
| mitigation-scope | 1 | 5 (map) | | mitigation-scope | 1 | 5 (map) |
| scope | 2 | 5 (map) | | scope | 2 | 5 (map) |
| policy-id | 3 | 0 (unsigned) | | mitigation-id | 3 | 0 (unsigned) |
| target-ip | 4 | 4 (array) | | target-ip | 4 | 4 (array) |
| target-port-range | 5 | 4 | | target-port-range | 5 | 4 |
| lower-port | 6 | 0 | | lower-port | 6 | 0 |
| upper-port | 7 | 0 | | upper-port | 7 | 0 |
| target-protocol | 8 | 4 | | target-protocol | 8 | 4 |
| FQDN | 9 | 4 | | FQDN | 9 | 4 |
| URI | 10 | 4 | | URI | 10 | 4 |
| alias | 11 | 4 | | alias | 11 | 4 |
| lifetime | 12 | 0 | | lifetime | 12 | 0 |
| attack-status | 13 | 0 | | attack-status | 13 | 0 |
| signal-config | 14 | 5 | | signal-config | 14 | 5 |
| heartbeat-timeout | 15 | 0 | | heartbeat-timeout | 15 | 0 |
| max-retransmit | 16 | 0 | | max-retransmit | 16 | 0 |
| ack-timeout | 17 | 0 | | ack-timeout | 17 | 0 |
| ack-random-factor | 18 | 7 | | ack-random-factor | 18 | 7 |
| MinValue | 19 | 0 | | MinValue | 19 | 0 |
| MaxValue | 20 | 0 | | MaxValue | 20 | 0 |
| status | 21 | 0 | | status | 21 | 0 |
| bytes_dropped | 22 | 0 | | bytes-dropped | 22 | 0 |
| bps_dropped | 23 | 0 | | bps-dropped | 23 | 0 |
| pkts_dropped | 24 | 0 | | pkts-dropped | 24 | 0 |
| pps_dropped | 25 | 0 | | pps-dropped | 25 | 0 |
| session-id | 26 | 0 |
\--------------------+------------------------+--------------------------/ \--------------------+------------------------+--------------------------/
Figure 21: CBOR mappings used in DOTS signal channel message Figure 21: CBOR mappings used in DOTS signal channel message
7. (D)TLS Protocol Profile and Performance considerations 7. (D)TLS Protocol Profile and Performance considerations
This section defines the (D)TLS protocol profile of DOTS signal This section defines the (D)TLS protocol profile of DOTS signal
channel over (D)TLS and DOTS data channel over TLS. channel over (D)TLS and DOTS data channel over TLS.
There are known attacks on (D)TLS, such as machine-in-the-middle and There are known attacks on (D)TLS, such as machine-in-the-middle and
skipping to change at page 36, line 50 skipping to change at page 37, line 50
o CBOR Major Type: 5 o CBOR Major Type: 5
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name: "scope" o Parameter Name: "scope"
o CBOR Key Value: 2 o CBOR Key Value: 2
o CBOR Major Type: 5 o CBOR Major Type: 5
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name: "policy-id" o Parameter Name: "mitigation-id"
o CBOR Key Value: 3 o CBOR Key Value: 3
o CBOR Major Type: 0 o CBOR Major Type: 0
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name:target-ip o Parameter Name:target-ip
o CBOR Key Value: 4 o CBOR Key Value: 4
o CBOR Major Type: 4 o CBOR Major Type: 4
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
skipping to change at page 39, line 19 skipping to change at page 40, line 19
o CBOR Major Type: 0 o CBOR Major Type: 0
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name: status o Parameter Name: status
o CBOR Key Value: 21 o CBOR Key Value: 21
o CBOR Major Type: 0 o CBOR Major Type: 0
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name: bytes_dropped o Parameter Name: bytes-dropped
o CBOR Key Value: 22 o CBOR Key Value: 22
o CBOR Major Type: 0 o CBOR Major Type: 0
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name: bps_dropped o Parameter Name: bps-dropped
o CBOR Key Value: 23 o CBOR Key Value: 23
o CBOR Major Type: 0 o CBOR Major Type: 0
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name: pkts_dropped o Parameter Name: pkts-dropped
o CBOR Key Value: 24 o CBOR Key Value: 24
o CBOR Major Type: 0 o CBOR Major Type: 0
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name: pps_dropped o Parameter Name: pps-dropped
o CBOR Key Value: 25 o CBOR Key Value: 25
o CBOR Major Type: 0 o CBOR Major Type: 0
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name: session-id
o CBOR Key Value: 26
o CBOR Major Type: 0
o Change Controller: IESG
o Specification Document(s): this document
11. Implementation Status 11. Implementation Status
[Note to RFC Editor: Please remove this section and reference to [Note to RFC Editor: Please remove this section and reference to
[RFC6982] prior to publication.] [RFC6982] prior to publication.]
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC6982]. Internet-Draft, and is based on a proposal described in [RFC6982].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
 End of changes. 51 change blocks. 
126 lines changed or deleted 137 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/