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

<mohamed.boucadair@orange.com> Thu, 28 February 2019 09:15 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB5D130E79 for <dots@ietfa.amsl.com>; Thu, 28 Feb 2019 01:15:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNJQhVwn9m8N for <dots@ietfa.amsl.com>; Thu, 28 Feb 2019 01:15:09 -0800 (PST)
Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1419C130E6B for <dots@ietf.org>; Thu, 28 Feb 2019 01:15:09 -0800 (PST)
Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 4496Mb0ZWVz2ygc; Thu, 28 Feb 2019 10:15:07 +0100 (CET)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.79]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 4496MZ6tJkzBrLH; Thu, 28 Feb 2019 10:15:06 +0100 (CET)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM6E.corporate.adroot.infra.ftgroup ([fe80::d89a:9017:59c2:9724%21]) with mapi id 14.03.0435.000; Thu, 28 Feb 2019 10:15:06 +0100
From: mohamed.boucadair@orange.com
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
CC: "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-29.txt
Thread-Index: AQHUysO2BSyTdnM0Qka7k+Ykw8xjSaXr/0pggAY1FWCAAQcR8IABuGog
Date: Thu, 28 Feb 2019 09:15:06 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA268D4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <155084937056.5323.18401033305053602209@ietfa.amsl.com> <DM6PR16MB27941968A6A96F37C8A64E32EA7F0@DM6PR16MB2794.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EA25825@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB2790E0DAA102D11B54ED23D4EA740@BYAPR16MB2790.namprd16.prod.outlook.com>
In-Reply-To: <BYAPR16MB2790E0DAA102D11B54ED23D4EA740@BYAPR16MB2790.namprd16.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/KxEtPFn-dHtqmr3C4xAYwJdLtwU>
Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-29.txt
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Feb 2019 09:15:12 -0000

Hi Tiru, 

'idle' time is not when no attack traffic is present, but when no attack mitigation is active. We have drawn this distinction in -15. 

The idle and mitigation times are introduced in the draft. I made this change to avoid misinterpretation:
 
   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 (also
                                                                 ^^^^^^ 
   referred to as 'idle' time), '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).

Better? 

Cheers,
Med

> -----Message d'origine-----
> De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com]
> Envoyé : mercredi 27 février 2019 07:56
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : dots@ietf.org
> Objet : RE: [Dots] I-D Action: draft-ietf-dots-signal-channel-29.txt
> 
> Hi Med,
> 
> Please see inline
> 
> > -----Original Message-----
> > From: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
> > Sent: Tuesday, February 26, 2019 8:42 PM
> > To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>
> > Cc: dots@ietf.org
> > Subject: 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
> >    ^^^^^^^^^^^^^^^^^
> 
> The above lines do not define the term 'idle'.
> We just have to append "(i.e. when no attack traffic is present)" to 'idle'
> time.
> 
> Cheers,
> -Tiru
> 
> >    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