Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Configuration Attributes for Faster Block Transmission
draft-bosh-dots-quick-blocks-01

Document Type Active Internet-Draft (individual)
Authors Mohamed Boucadair  , Jon Shallow 
Last updated 2021-01-13
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf htmlized (tools) htmlized bibtex
Yang Validation 0 errors, 1 warnings.
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
DOTS                                                        M. Boucadair
Internet-Draft                                                    Orange
Intended status: Standards Track                              J. Shallow
Expires: July 17, 2021                                  January 13, 2021

   Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
     Channel Configuration Attributes for Faster Block Transmission
                    draft-bosh-dots-quick-blocks-01

Abstract

   This document specifies new DOTS signal channel configuration
   parameters that are negotiated between DOTS peers to enable the use
   of Q-Block1 and Q-Block2 Options.  These options enable faster
   transmission rates for large amounts of data with less packet
   interchanges as well as supporting faster recovery should any of the
   blocks get lost in transmission.

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 July 17, 2021.

Copyright Notice

   Copyright (c) 2021 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

Boucadair & Shallow       Expires July 17, 2021                 [Page 1]
Internet-Draft        DOTS Fast Block Transmission          January 2021

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  DOTS Attributes for Faster Block Transmission . . . . . . . .   4
   4.  DOTS Fast Block Transmission YANG Module  . . . . . . . . . .   7
     4.1.  Tree Structure  . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  YANG/JSON Mapping Parameters to CBOR  . . . . . . . . . .   9
     4.3.  YANG Module . . . . . . . . . . . . . . . . . . . . . . .   9
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
     5.1.  DOTS Signal Channel CBOR Mappings Registry  . . . . . . .  13
     5.2.  DOTS Signal Filtering Control YANG Module . . . . . . . .  14
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   The Constrained Application Protocol (CoAP) [RFC7252], although
   inspired by HTTP, was designed to use UDP instead of TCP.  The
   message layer of CoAP over UDP includes support for reliable
   delivery, simple congestion control, and flow control.  [RFC7959]
   introduced the CoAP Block1 and Block2 Options to handle data records
   that cannot fit in a single IP packet, so not having to rely on IP
   fragmentation and was further updated by [RFC8323] for use over TCP,
   TLS, and WebSockets.

   The CoAP Block1 and Block2 Options work well in environments where
   there are no or minimal packet losses.  These options operate
   synchronously where each individual block has to be requested and can
   only ask for (or send) the next block when the request for the
   previous block has completed.  Packet, and hence block transmission
   rate, is controlled by Round Trip Times (RTTs).

   There is a requirement for these blocks of data to be transmitted at
   higher rates under network conditions where there may be asymmetrical
   transient packet loss (i.e., responses may get dropped).  An example
   is when a network is subject to a Distributed Denial of Service
   (DDoS) attack and there is a need for DDoS mitigation agents relying
   upon CoAP to communicate with each other (e.g.,
   [I-D.ietf-dots-telemetry]).  As a reminder, [RFC7959] recommends the
Show full document text