Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-15.txt

From: [email-masked]
Date: Wed, 10 Jan 2018 05:06:41 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DDoS Open Threat Signaling WG of the IETF.

        Title           : Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel
        Authors         : Tirumaleswar Reddy
                          Mohamed Boucadair
                          Prashanth Patil
                          Andrew Mortensen
                          Nik Teague
	Filename        : draft-ietf-dots-signal-channel-15.txt
	Pages           : 89
	Date            : 2018-01-10

Abstract:
   This document specifies the DOTS signal channel, a protocol for
   signaling the need for protection against Distributed Denial-of-
   Service (DDoS) attacks to a server capable of enabling network
   traffic mitigation on behalf of the requesting client.

   A companion document defines the DOTS data channel, a separate
   reliable communication layer for DOTS management and configuration
   purposes.

Editorial Note (To be removed by RFC Editor)

   Please update these statements with the RFC number to be assigned to
   this document:

   o  "This version of this YANG module is part of RFC XXXX;"

   o  "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling
      (DOTS) Signal Channel";

   o  "| 3.00 | Alternate server | [RFCXXXX] |"

   o  reference: RFC XXXX

   o  This RFC

   Please update TBD statements with the port number to be assigned to
   DOTS Signal Channel Protocol.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dots-signal-channel-15
https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel-15

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: <[email-masked]>
Date: Wed, 10 Jan 2018 13:23:24 +0000

Hi all, 

This new version integrates almost all received comments. In particular, the changes in this version are as follows: 

* Introduce CUID (Client Unique Identifier) which meant to disambiguate clients that belong to the same domain. 
* Rename client-identifier to client-domain-hash: This parameter is inserted by a server-domain gateway to supply the identity of the origin client domain to the server. This information will be used by the server to enforce policies. Only single-valued client-domain-hash are allowed.
* Fix the target resource to be included in the options, not the message body.
* Rename "attack-time-config and peace-time-config" to "mitigating-config and idle-config"   
* Update the YANG module with some missing attributes (e.g., redirected signaling)
* Discuss SNI support
* Add some text about authentication

There is still one pending comment from Jon: hop-limit. We have prepared some text for it, but it is not included in -15 because we do need more feedback from the WG to further assess if this feature is really useful. FWIW, I'm inserting the description below:  

==
hop-limit:  This attribute is used to detect and prevent infinite
      loops.  This attribute is typically inserted by a DOTS gateway.

      Each intermediate DOTS agent involved in the handling of a DOTS
      message MUST decrement the hop-limit value by 1 prior to
      forwarding upstream if this parameter exists.  DOTS messages MUST
      NOT be forwarded if the value of hop-limit is set to '0' after
      decrement.  Messages that cannot be forwarded because of exhausted
      hop-limit SHOULD be logged with a 5.06 (Hop Limit Reached) error
      message sent back to the DOTS peer.  It is RECOMMENDED that DOTS
      clients and gateways support means to alert administrators about
      loop errors so that appropriate actions are undertaken.

      The initial hop-limit value SHOULD be configurable.  If no initial
      value is explicitly provided, the default initial hop-limit value
      of 16 MUST be used.

      Because forwarding errors may occur if inadequate hop-limit values
      are used, DOTS agents at the boundaries of an administrative
      domain MAY be instructed to rewrite the value of hop-limit carried
      in received messages (that is, ignore the value of hop-limit
      received in a message).

      This is an optional attribute.
==

Please review and share comments. 

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de internet-
> [email-masked]
> Envoyé : mercredi 10 janvier 2018 14:07
> À : [email-masked]
> Cc : [email-masked]
> Objet : [Dots] I-D Action: draft-ietf-dots-signal-channel-15.txt
> 
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots