Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-29.txt

Hi Tiru, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar
> Reddy
> Envoyé : vendredi 22 février 2019 17:20
> À : dots@ietf.org; i-d-announce@ietf.org
> Objet : Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-29.txt
> 
> Hi Med,
> 
> Couple of Nits:
> 
> 1)
> OLD:
> Likewise, 'sid' value is
> monotonically increased by the DOTS client for each configuration
> session, attackers replaying configuration requests with lower
> numeric 'sid' values will be rejected by the DOTS server if it
> maintains a higher numeric 'sid' value for this DOTS client.
> 
> NEW:
> Likewise, 'sid' value is
> monotonically increased by the DOTS client for each configuration
> request, attackers replaying configuration requests with lower
> numeric 'sid' values will be rejected by the DOTS server if it
> maintains a higher numeric 'sid' value for this DOTS client.
> 

[Med] OK for s/session/request. 

> 2)
> Define 'idle' time (i.e. when no attack traffic is present).

[Med] This one is not needed, IMHO. We do already have the following in the draft: 

   The same or distinct configuration sets may be used during times when
                                                              ^^^^^^^^^^
   a mitigation is active ('mitigating-config') and when no mitigation
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   is active ('idle-config').  This is particularly useful for DOTS
   ^^^^^^^^^^^^^^^^^
   servers that might want to reduce heartbeat frequency or cease
   heartbeat exchanges when an active DOTS client has not requested
   mitigation.  If distinct configurations are used, DOTS agents MUST
   follow the appropriate configuration set as a function of the
   mitigation activity (e.g., if no mitigation request is active, 'idle-
   config'-related values must be followed).  Additionally, DOTS agents
   MUST automatically switch to the other configuration upon a change in
   the mitigation activity (e.g., if an attack mitigation is launched
   after an 'idle' time, the DOTS agent switches from 'idle-config' to
   'mitigating-config'-related values).

> 
> -Tiru
> 
> > -----Original Message-----
> > From: Dots <dots-bounces@ietf.org> On Behalf Of internet-drafts@ietf.org
> > Sent: Friday, February 22, 2019 9:00 PM
> > To: i-d-announce@ietf.org
> > Cc: dots@ietf.org
> > Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-29.txt
> >
> > This email originated from outside of the organization. Do not click links
> or
> > open attachments unless you recognize the sender and know the content is
> safe.
> >
> >
> > 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 Specification
> >         Authors         : Tirumaleswar Reddy
> >                           Mohamed Boucadair
> >                           Prashanth Patil
> >                           Andrew Mortensen
> >                           Nik Teague
> > 	Filename        : draft-ietf-dots-signal-channel-29.txt
> > 	Pages           : 99
> > 	Date            : 2019-02-22
> >
> > 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 within the document 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 Specification";
> >
> >    o  "| [RFCXXXX] |"
> >
> >    o  reference: RFC XXXX
> >
> >    Please update this statement with the RFC number to be assigned to
> >    the following documents:
> >
> >    o  "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling
> >       (DOTS) Data Channel Specification (used to be I-D.ietf-dots-data-
> >       channel)
> >
> >    Please update TBD/TBD1/TBD2 statements with the assignments made by
> >    IANA to DOTS Signal Channel Protocol.
> >
> >    Also, please update the "revision" date of the YANG modules.
> >
> >
> > 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-29
> > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-29
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel-29
> >
> >
> > 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/
> >
> > _______________________________________________
> > Dots mailing list
> > Dots@ietf.org
> > https://www.ietf.org/mailman/listinfo/dots
> 
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots