Re: [Dots] WGLC on draft-ietf-dots-architecture-08

<mohamed.boucadair@orange.com> Thu, 29 November 2018 14:04 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 53721129BBF for <dots@ietfa.amsl.com>; Thu, 29 Nov 2018 06:04:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 FRgSjKSjpI0B for <dots@ietfa.amsl.com>; Thu, 29 Nov 2018 06:04:39 -0800 (PST)
Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0046D129533 for <dots@ietf.org>; Thu, 29 Nov 2018 06:04:38 -0800 (PST)
Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 435K5c3ZkFz2y56; Thu, 29 Nov 2018 15:04:36 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 435K5c2c31zCqkZ; Thu, 29 Nov 2018 15:04:36 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0415.000; Thu, 29 Nov 2018 15:04:36 +0100
From: mohamed.boucadair@orange.com
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>, Roman Danyliw <rdd@cert.org>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: WGLC on draft-ietf-dots-architecture-08
Thread-Index: AdSGnlgla3cLRB5MRLWQWFaJSQftBABEEW3wAAZceYAAB9nNYA==
Date: Thu, 29 Nov 2018 14:04:35 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302E04F981@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <359EC4B99E040048A7131E0F4E113AFC0184C49169@marathon> <787AE7BB302AE849A7480A190F8B93302E04F649@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <BN6PR16MB1425AD85A67FFE5A0EA5A769EAD20@BN6PR16MB1425.namprd16.prod.outlook.com>
In-Reply-To: <BN6PR16MB1425AD85A67FFE5A0EA5A769EAD20@BN6PR16MB1425.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.168.234.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/PY6SUQjibOHRo1-dyA61noTtecE>
Subject: Re: [Dots] WGLC on draft-ietf-dots-architecture-08
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, 29 Nov 2018 14:04:41 -0000

Tiru, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com]
> Envoyé : jeudi 29 novembre 2018 14:25
> À : BOUCADAIR Mohamed TGI/OLN; Roman Danyliw; dots@ietf.org
> Objet : RE: WGLC on draft-ietf-dots-architecture-08
> 
> 
> 
> > -----Original Message-----
> > From: Dots <dots-bounces@ietf.org> On Behalf Of
> > mohamed.boucadair@orange.com
> > Sent: Thursday, November 29, 2018 2:01 PM
> > To: Roman Danyliw <rdd@cert.org>; dots@ietf.org
> > Subject: Re: [Dots] WGLC on draft-ietf-dots-architecture-08
> >
> >
> >
> > Hi Roman, all,
> >
> > I support this draft to be sent to the IESG for publication.
> >
> > Some easy-to-fix comment, though:
> >
> > (1) The document cites [I-D.ietf-dots-requirements] in may occurrences. I
> > suggest these citations to be more specific, that is to point the specific
> REQ# or
> > the section. Doing so would help readers not familiar with DOTS documents
> to
> > easily link the various pieces.
> >
> > (2) I used to point people to the DOTS architecture I-D when I receive
> > comments/questions about the notion of "DOTS session" and to the
> > Requirements I-D for clarification about DOTS channels. It seems that some
> > clarifications are needed in the architecture I-D to explain for readers
> not
> > familiar with all DOTS documents, for example:
> > - the link with the underlying transport sessions/connections and security
> > associations.
> > - mitigations are not bound to a DOTS session but to a DOTS client/domain.
> >
> > (3) The signal channel I-D uses "DOTS signal channel session", "DOTS signal
> > channel sessions" and "DOTS data channel session" to refer to specific DOTS
> > sessions. I'd like to have these terms introduced also in the arch I-D.
> >
> > BTW, the signal channel uses in few occurrences "DOTS session"; those can
> be
> > changed to "DOTS signal channel session". There is no occurrence of "DOTS
> > session" in the data channel I-D.
> 
> I don't see a need to modify the "DOTS session" discussed in the signal
> channel draft, https://tools.ietf.org/html/draft-ietf-dots-architecture-
> 07#section-3.1 defines the term "DOTS session".

[Med] I used to had the same opinion till recently. The comments I'm getting from people is that the articulation between the various terms is not that clear. We collectively need to double check this and make required changes, including simplifying the terminology. We are using the following terms in the various I-Ds:

* DOTS session
* DOTS signal channel
* DOTS data channel
* DOTS signal channel session
* DOTS data channel session
* established signal channel
* established data channel

For example, having both "DOTS signal channel session" and "DOTS session" terms in the signal channel I-D to refer to the same thing can be avoided. 

 However, I agree with your
> comments to update the section 3.1 to add the following lines:
> Mitigation requests created using a DOTS session are not bound to the DOTS
> session. Mitigation requests are associated with a DOTS client and can be
> managed using different DOTS sessions. A DOTS session is associated with a
> single transport connection (e.g. TCP or UDP session) and an ephemeral
> security association (e.g. a TLS or DTLS session).

[Med] This is a good starting point. Some part of the text is more accurate with s/DOTS session/DOTS signal channel session.

> 
> The DOTS signal data channel session is a mutually authenticated DOTS session
> between DOTS agents.
> 

[Med] I guess you meant s/signal data channel/signal channel. Putting that aside, and more importantly, a reader will then have troubles to parse the following: 

"Conversely, a
   DOTS session cannot exist without an established signal channel: when
   an established signal channel is terminated for any reason, the DOTS
   session is also said to be terminated."


> DOTS data channel draft is not using the term "DOTS data channel session", we
> can fix the signal channel draft to use "DOTS data channel" instead of "DOTS
> data channel session".
> 

[Med] May be. BTW, this part of the text:

" Conversely, a
   DOTS session cannot exist without an established signal channel
"

is conflicting with this one: 

"
To allow for DOTS
   service flexibility, neither the order of contact nor the time
   interval between channel creations is specified.  A DOTS client MAY
   establish signal channel first, and then data channel, or vice versa."

> Cheers,
> -Tiru
> 
> >
> > Thank you.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Dots [mailto:dots-bounces@ietf.org] De la part de Roman Danyliw
> > > Envoyé : mardi 27 novembre 2018 23:15 À : dots@ietf.org Objet : [Dots]
> > > WGLC on draft-ietf-dots-architecture-08
> > >
> > > Hello!
> > >
> > > Consistent with our discussion at the Bangkok meeting, we are starting
> > > a working group last call (WGLC) for the DOTS architecture draft:
> > >
> > > DOTS Architecture
> > > draft-ietf-dots-architecture-08
> > > https://tools.ietf.org/html/draft-ietf-dots-architecture-08
> > >
> > > Please send comments to the DOTS mailing list -- feedback on remaining
> > > issues or needed changes; as well as endorsements that this draft is
> ready.
> > >
> > > This WGLC will end on December 12, 2018.
> > >
> > > Thanks,
> > > Roman and Frank
> > >
> > > _______________________________________________
> > > 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