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

<mohamed.boucadair@orange.com> Fri, 30 November 2018 07:07 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 E1C6F12875B for <dots@ietfa.amsl.com>; Thu, 29 Nov 2018 23:07:35 -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 PZEDpCaCK_Z2 for <dots@ietfa.amsl.com>; Thu, 29 Nov 2018 23:07:33 -0800 (PST)
Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565FE126CB6 for <dots@ietf.org>; Thu, 29 Nov 2018 23:07:33 -0800 (PST)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 435lnv1X9gz5wjY; Fri, 30 Nov 2018 08:07:31 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 435lnv0dQQzDq7C; Fri, 30 Nov 2018 08:07:31 +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; Fri, 30 Nov 2018 08:07:30 +0100
From: mohamed.boucadair@orange.com
To: "Xialiang (Frank, Network Integration Technology Research Dept)" <frank.xialiang@huawei.com>, "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: AdSGnlgla3cLRB5MRLWQWFaJSQftBABEEW3wAAZceYAAB9nNYAAEkILwABK1JTAADUQ40A==
Date: Fri, 30 Nov 2018 07:07:29 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302E04FF9C@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <359EC4B99E040048A7131E0F4E113AFC0184C49169@marathon> <787AE7BB302AE849A7480A190F8B93302E04F649@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <BN6PR16MB1425AD85A67FFE5A0EA5A769EAD20@BN6PR16MB1425.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302E04F981@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <BN6PR16MB1425D2A6BED037A18098CF54EAD20@BN6PR16MB1425.namprd16.prod.outlook.com> <C02846B1344F344EB4FAA6FA7AF481F12C922FA7@DGGEMM531-MBS.china.huawei.com>
In-Reply-To: <C02846B1344F344EB4FAA6FA7AF481F12C922FA7@DGGEMM531-MBS.china.huawei.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/QGghnHhw-eub_3Li3QwDHkqf8sQ>
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: Fri, 30 Nov 2018 07:07:36 -0000

Hi Frank, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Xialiang (Frank, Network Integration Technology Research Dept)
> [mailto:frank.xialiang@huawei.com]
> Envoyé : vendredi 30 novembre 2018 01:44
> À : Konda, Tirumaleswar Reddy; BOUCADAIR Mohamed TGI/OLN; Roman Danyliw;
> dots@ietf.org
> Objet : 答复: WGLC on draft-ietf-dots-architecture-08
> 
> Hi Tiru and Med,
> Please see inline:
> 
> -----邮件原件-----
> 发件人: Dots [mailto:dots-bounces@ietf.org] 代表 Konda, Tirumaleswar Reddy
> 发送时间: 2018年11月30日 0:03
> 收件人: mohamed.boucadair@orange.com; Roman Danyliw <rdd@cert.org>;
> dots@ietf.org
> 主题: Re: [Dots] WGLC on draft-ietf-dots-architecture-08
> 
> > -----Original Message-----
> > From: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
> > Sent: Thursday, November 29, 2018 7:35 PM
> > To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;
> > Roman Danyliw <rdd@cert.org>; dots@ietf.org
> > Subject: RE: WGLC on draft-ietf-dots-architecture-08
> >
> > 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.
> >
> > 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.
> [Frank]: is there some specific examples to clarify this point I feel we
> don't explain the use cases and the benefits well enough in current drafts,
> or maybe I missed something.
> 

[Med] Adding the clarification I proposed into the architecture I-D would fix this, IMHO.

FWIW, we do have text for this in the protocol I-Ds, e.g., 

==
   In both DOTS signal and data channel sessions, the DOTS client MUST
   authenticate itself to the DOTS server (Section 8).  The DOTS server
   MAY use the algorithm presented in Section 7 of [RFC7589] to derive
   the DOTS client identity or username from the client certificate.
   The DOTS client identity allows the DOTS server to accept mitigation
   requests with scopes that the DOTS client is authorized to manage.

   The DOTS server couples the DOTS signal and data channel sessions
   using the DOTS client identity and optionally the 'cdid' parameter
   value, so the DOTS server can validate whether the aliases conveyed
   in the mitigation request were indeed created by the same DOTS client
   using the DOTS data channel session.  If the aliases were not created
   by the DOTS client, the DOTS server MUST return 4.00 (Bad Request) in
   the response.

   The DOTS server couples the DOTS signal channel sessions using the
   DOTS client identity and optionally the 'cdid' parameter value, and
   the DOTS server uses 'mid' and 'cuid' Uri-Path parameter values to
   detect duplicate mitigation requests.  If the mitigation request
   contains the 'alias-name' and other parameters identifying the target
   resources (such as 'target-prefix', 'target-port-range', 'target-
   fqdn', or 'target-uri'), the DOTS server appends the parameter values
   in 'alias-name' with the corresponding parameter values in 'target-
   prefix', 'target-port-range', 'target-fqdn', or 'target-uri'.
==


> > > >
> > > > (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
> [Frank]: do we still use the terminology of "DOTS signal channel" and "DOTS
> data channel" somewhere? They are the draft title. And if they still exist,
> what is the relation between the channels and the sessions?
> 

[Med] The notion of "channel" is already defined in the Requirements I-D. I do think that one is clear. 

The architecture I-D defines the notion of "DOTS session", but some changes are still needed. The changes discussed in this thread will help clarifying what is the relationship between a channel and the session or set of sessions bound to it. 

[snip]
> 
> >
> > >
> > > 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.
> 
> I don't see the need for the above line, if we add the following line:
>  A DOTS signal channel 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).
> 
> > 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."
> 
> Removing the above line should avoid the confusion.
> 
> -Tiru
> 
> >
> >
> > > 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".
> [Frank]: why can we use the term " DOTS data channel session" to make it
> consistent with "DOTS signal channel session"?
> 

[Med] Perhaps I missed your point, but the signal channel is already using "DOTS data channel session".