Re: [Dots] Adoption call for draft-reddy-dots-home-network-04

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Thu, 25 April 2019 10:42 UTC

Return-Path: <TirumaleswarReddy_Konda@mcafee.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 945A6120169 for <dots@ietfa.amsl.com>; Thu, 25 Apr 2019 03:42:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com
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 FncgmIf_BGfi for <dots@ietfa.amsl.com>; Thu, 25 Apr 2019 03:42:17 -0700 (PDT)
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59961120180 for <dots@ietf.org>; Thu, 25 Apr 2019 03:42:17 -0700 (PDT)
X-NAI-Header: Modified by McAfee Email Gateway (5500)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1556188572; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-forefront-prvs:x-forefront-antispam-report: received-spf:x-ms-exchange-senderadcheck:x-microsoft-antispam-message-info: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=SyplQxChev7q6rXbKjs8are4gqAee7SPYWINuF 7h4D4=; b=S3MO5DESLjd6HrRRCKwbBoAYQNnt45653GIqEIYU lBw+fHEgxNzPP/A93mIp/sNkcvg1hU/dw917Sz8fsd10jD/h2b KJCCuzwIGtLd+D9Pp8+ZQcITt7Cw/RWsnLIggx4HAruvBj3zJO CaDrvojhekMnVKTqfs0CUmaYQ827c4k=
Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 4700_7aa3_598afc6f_17b9_4b1c_9b6d_a01e60b8adb7; Thu, 25 Apr 2019 04:36:11 -0600
Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 25 Apr 2019 04:40:45 -0600
Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 25 Apr 2019 04:40:45 -0600
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 25 Apr 2019 04:40:42 -0600
Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2567.namprd16.prod.outlook.com (20.177.226.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.12; Thu, 25 Apr 2019 10:40:42 +0000
Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::4873:7200:9e57:9e62]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::4873:7200:9e57:9e62%5]) with mapi id 15.20.1813.017; Thu, 25 Apr 2019 10:40:42 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Jon Shallow <supjps-ietf@jpshallow.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [Dots] Adoption call for draft-reddy-dots-home-network-04
Thread-Index: AdTuHVZNyfDh6IMnTiyfhZP8vM2pOAMPXcMAAAHlewAAACVi8AABQijQAAj4x4AAAJCXsAADitfgAAByLdAAAFuUIAAjllPAAAjlb4AAAEheYA==
Date: Thu, 25 Apr 2019 10:40:41 +0000
Message-ID: <BYAPR16MB27907A8A494FDA074713490FEA3D0@BYAPR16MB2790.namprd16.prod.outlook.com>
References: <023d01d4ee1f$c2bcb190$483614b0$@smyslov.net> <019001d4fa5a$cf08fb60$6d1af220$@smyslov.net> <787AE7BB302AE849A7480A190F8B93302EA648E7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB27907ABC5E91DD572EBE7807EA3C0@BYAPR16MB2790.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EA649DB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB2790ED963937C8C15B319F63EA3C0@BYAPR16MB2790.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EA64C46@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB27902B9175E96A2062D06E83EA3C0@BYAPR16MB2790.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EA64E53@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB27908314C1236FE8846984E5EA3C0@BYAPR16MB2790.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EA656B7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <012e01d4fb51$7a4d0e20$6ee72a60$@jpshallow.com>
In-Reply-To: <012e01d4fb51$7a4d0e20$6ee72a60$@jpshallow.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.2.0.6
dlp-reaction: no-action
authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com;
x-originating-ip: [103.245.47.20]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: aae76c8b-7602-4dae-8aca-08d6c96a771f
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR16MB2567;
x-ms-traffictypediagnostic: BYAPR16MB2567:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <BYAPR16MB25674246C07DC0B61447CFA4EA3D0@BYAPR16MB2567.namprd16.prod.outlook.com>
x-forefront-prvs: 0018A2705B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(39850400004)(396003)(346002)(136003)(51854002)(32952001)(199004)(189003)(13464003)(966005)(71200400001)(71190400001)(2201001)(25786009)(6246003)(73956011)(72206003)(102836004)(53546011)(8936002)(478600001)(6116002)(2906002)(30864003)(93886005)(66556008)(66946007)(66446008)(33656002)(68736007)(3846002)(2501003)(66476007)(64756008)(6506007)(76116006)(186003)(26005)(74316002)(55016002)(86362001)(14444005)(5024004)(256004)(53936002)(316002)(14454004)(52536014)(80792005)(7696005)(66066001)(97736004)(9686003)(99286004)(76176011)(8676002)(305945005)(6436002)(6306002)(476003)(81156014)(7736002)(81166006)(486006)(53946003)(229853002)(446003)(5660300002)(11346002)(110136005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2567; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: wZZSAz253+GLYkybM/hNhUNLd+RnnZsV9qDlojGY5Dd3EHmOxnjd9bFAveoiQstlPAcUbFEllXwo/IOlRn7ysON7r45S45AWQqNbs4ScXM5Y1QrnCKrT88+yj50PzG6Q+9hwVLjYF7MH59n1/C3EZtURI2ZKbWbdWtAlfS0iOXM6oRo3YnHtgaTPlZoWJDFe8BOIeZbrVBaWhA+cb3CeKyltUzigUVP+f1N0v6dd0XZsg7nY47SLUHE2U0BFjnfkZQv8r4/1F4N4EYZgXRy5+aeQ3sCdbBK78R0KUt7L7rKmPeVz/ELA46O6IxEyE1yJfjSQHFx0ql++ktV/ADdGqmSWMA8YUZQSgh4XgOiz1ANtPknsP35O6oU8hZY0hy3O38mqPagaeKihHnlgJywddi2ncxZVEm0qlsftdoc5yIk=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: aae76c8b-7602-4dae-8aca-08d6c96a771f
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2019 10:40:41.9934 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR16MB2567
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Level:
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0.1
X-NAI-Spam-Version: 2.3.0.9418 : core <6532> : inlines <7059> : streams <1819677> : uri <2836861>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/NAw62OfOuh0zAyUmq3d4nqAUMTY>
Subject: Re: [Dots] Adoption call for draft-reddy-dots-home-network-04
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, 25 Apr 2019 10:42:22 -0000

Hi Jon,

For UDP,  the first packet is the DTLS ClientHello message and it has to be sent by the DOTS server. The DOTS client cannot send the ClientHello Message as the first packet 
because of the reasons listed in https://tools.ietf.org/html/rfc8071#section-1.1. We followed the same logic for TLS/TCP.
 
Cheers,
-Tiru

> -----Original Message-----
> From: Jon Shallow <supjps-ietf@jpshallow.com>
> Sent: Thursday, April 25, 2019 3:57 PM
> To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy
> <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
> Subject: RE: [Dots] Adoption call for draft-reddy-dots-home-network-04
> 
> 
> 
> Hi Med / Tiru,
> 
> I am having a hard time working out how to implement this Call Home using
> libcoap.
> 
> The easiest way in my current thinking is that the role reversal should only be
> at the UDP or TCP layer and then (D)TLS is set up / initiated by the DOTS client
> to the DOTS server (and is how RFC8071 defines the setup of the security
> layer over TCP).
> 
> Otherwise, libcoap needs to be taught that (D)TLS set up is in the reverse
> direction to the CoAP transfers which would involve a significant re-write and
> a lot of clarity in the code (e.g. am I a server or a client at this point of working
> in the network stack?).
> 
> Just establishing a session 5 tuple in the reverse direction and then
> remembering this only for the UDP/TCP layer is a simple libcoap change.
> 
> So, I would like to see it as (as per RFC8071 Figure 1:)
> 
>                   DOTS                                   DOTS
>                   Server                                 Client
>                     |                                                 |
>                     |         1.  TCP or UDP              |
>                     |----------------------------------->|
>                     |         2.  (D)TLS  set up          |
>                     |<-----------------------------------|
>                     |         3. Mitigation request   |
>                     |<-----------------------------------|
>                     |                                                 |
> 
> Regards
> 
> Jon
> > -----Original Message-----
> > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of
> > mohamed.boucadair@orange.com
> > Sent: 25 April 2019 07:14
> > To: Konda, Tirumaleswar Reddy
> > Cc: dots@ietf.org
> > Subject: Re: [Dots] Adoption call for draft-reddy-dots-home-network-04
> >
> > Hi Tiru,
> >
> > Works for me.
> >
> > An updated version with a slightly updated wording is available at:
> > https://github.com/boucadair/dots-call-home/blob/master/draft-ietf-dot
> > s-
> > signal-call-home-00.txt
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Konda, Tirumaleswar Reddy
> > [mailto:TirumaleswarReddy_Konda@McAfee.com]
> > > Envoyé : mercredi 24 avril 2019 15:26 À : BOUCADAIR Mohamed TGI/OLN;
> > > Valery Smyslov; dots@ietf.org Cc : dots-chairs@ietf.org;
> > > kaduk@mit.edu Objet : RE: [Dots] Adoption call for
> > > draft-reddy-dots-home-network-04
> > >
> > > > -----Original Message-----
> > > > From: mohamed.boucadair@orange.com
> <mohamed.boucadair@orange.com>
> > > > Sent: Wednesday, April 24, 2019 6:42 PM
> > > > To: Konda, Tirumaleswar Reddy
> > > > <TirumaleswarReddy_Konda@McAfee.com>; Valery Smyslov
> > > > <valery@smyslov.net>; dots@ietf.org
> > > > Cc: dots-chairs@ietf.org; kaduk@mit.edu
> > > > Subject: RE: [Dots] Adoption call for
> > > > draft-reddy-dots-home-network-04
> > > >
> > > > 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.
> > > >
> > > > Re-,
> > > >
> > > > Please see inline.
> > > >
> > > > Cheers,
> > > > Med
> > > > > -----Message d'origine-----
> > > > > De : Konda, Tirumaleswar Reddy
> > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com]
> > > > > Envoyé : mercredi 24 avril 2019 14:56 À : BOUCADAIR Mohamed
> > > > > TGI/OLN; Valery Smyslov; dots@ietf.org Cc :
> > > > > dots-chairs@ietf.org; kaduk@mit.edu Objet : RE: [Dots] Adoption
> > > > > call for draft-reddy-dots-home-network-04
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: mohamed.boucadair@orange.com
> > > > > > <mohamed.boucadair@orange.com>
> > > > > > Sent: Wednesday, April 24, 2019 4:48 PM
> > > > > > To: Konda, Tirumaleswar Reddy
> > > > > > <TirumaleswarReddy_Konda@McAfee.com>; Valery Smyslov
> > > > > > <valery@smyslov.net>; dots@ietf.org
> > > > > > Cc: dots-chairs@ietf.org; kaduk@mit.edu
> > > > > > Subject: RE: [Dots] Adoption call for
> > > > > > draft-reddy-dots-home-network-04
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > > Re-,
> > > > > >
> > > > > > Please see inline.
> > > > > >
> > > > > > Cheers,
> > > > > > Med
> > > > > >
> > > > > > > -----Message d'origine-----
> > > > > > > De : Konda, Tirumaleswar Reddy
> > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com]
> > > > > > > Envoyé : mercredi 24 avril 2019 13:01 À : BOUCADAIR Mohamed
> > > > > > > TGI/OLN; Valery Smyslov; dots@ietf.org Cc :
> > > > > > > dots-chairs@ietf.org; kaduk@mit.edu Objet : RE: [Dots]
> > > > > > > Adoption call for draft-reddy-dots-home-network-04
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: mohamed.boucadair@orange.com
> > > > > > > > <mohamed.boucadair@orange.com>
> > > > > > > > Sent: Wednesday, April 24, 2019 12:18 PM
> > > > > > > > To: Konda, Tirumaleswar Reddy
> > > > > > > > <TirumaleswarReddy_Konda@McAfee.com>; Valery Smyslov
> > > > > > > > <valery@smyslov.net>; dots@ietf.org
> > > > > > > > Cc: dots-chairs@ietf.org; kaduk@mit.edu
> > > > > > > > Subject: RE: [Dots] Adoption call for
> > > > > > > > draft-reddy-dots-home-network-04
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Re-,
> > > > > > > >
> > > > > > > > Please see inline.
> > > > > > > >
> > > > > > > > Cheers,
> > > > > > > > Med
> > > > > > > >
> > > > > > > > > -----Message d'origine----- De : Konda, Tirumaleswar
> > > > > > > > > Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com]
> > > > > > > > > Envoyé : mercredi 24 avril 2019 08:13 À : BOUCADAIR
> > > > > > > > > Mohamed TGI/OLN; Valery Smyslov; dots@ietf.org Cc :
> > > > > > > > > dots-chairs@ietf.org; kaduk@mit.edu Objet : RE: [Dots]
> > > > > > > > > Adoption call for draft-reddy-dots-home-network-04
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Dots <dots-bounces@ietf.org> On Behalf Of
> > > > > > > > > > mohamed.boucadair@orange.com
> > > > > > > > > > Sent: Wednesday, April 24, 2019 11:26 AM
> > > > > > > > > > To: Valery Smyslov <valery@smyslov.net>; dots@ietf.org
> > > > > > > > > > Cc: dots-chairs@ietf.org; kaduk@mit.edu
> > > > > > > > > > Subject: Re: [Dots] Adoption call for
> > > > > > > > > > draft-reddy-dots-home-network-04
> > > > > > > > > >
> > > > > > > > > > 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.
> > > > > > > > > >
> > > > > > > > > > Re-,
> > > > > > > > > >
> > > > > > > > > > Please see inline.
> > > > > > > > > >
> > > > > > > > > > Cheers,
> > > > > > > > > > Med
> > > > > > > > > >
> > > > > > > > > > > -----Message d'origine----- De : Dots
> > > > > > > > > > > [mailto:dots-bounces@ietf.org] De la part de Valery
> > > > > > > > > > > Smyslov Envoyé : mercredi 24 avril 2019 07:02 À :
> > > > > > > > > > > dots@ietf.org
> > > > > Cc :
> > > > > > > > > > > dots-chairs@ietf.org; kaduk@mit.edu Objet : Re:
> > > > > > > > > > > [Dots] Adoption call for
> > > > > > > > > > > draft-reddy-dots-home-network-04
> > > > > > > > > > >
> > > > > > > > > > > Hi,
> > > > > > > > > > >
> > > > > > > > > > > we received a lot of replies supporting adoption of
> > > > > > > > > > > the
> > > > document.
> > > > > > > > > > > So, the document is adopted. Authors, please
> > > > > > > > > > > re-submit it as WG
> > > > > > > draft.
> > > > > > > > > > >
> > > > > > > > > > > A couple of comments.
> > > > > > > > > > > 1. The draft uses few times a keyword "MAY NOT".
> > > > > > > > > > > This combination is
> > > > > > > > not
> > > > > > > > > > >      among the list of RFC requirement keywords (it
> > > > > > > > > > > is not listed
> > > > > > > neither
> > > > > > > > > > >      in RFC2119, nor in RFC8174). If the intent was
> > > > > > > > > > > to use RFC
> > > > > > > > > requirement
> > > > > > > > > > >      language, then I'd suggest replacing it with
> > > > > > > > > > > one of MUST NOT, SHALL NOT,
> > > > > > > > > > >      SHOULD NOT. Otherwise please make it lowcase.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > [Med] Good catch. Fixed.
> > > > > > > > > >
> > > > > > > > > > > 2. When describing transport, the draft allows both
> > > > > > > > > > > TLS and
> > > DTLS.
> > > > > > > What
> > > > > > > > > > >      makes me confusing is that the draft describes
> > > > > > > > > > > it several times as "TCP/TLS or DTLS".
> > > > > > > > > > >      Why TCP is ever mentioned here? We all know
> > > > > > > > > > > that TLS usually runs
> > > > > > > > > over
> > > > > > > > > > >      TCP (however we now have QUICK) and DTLS runs
> > > > > > > > > > > over
> > UDP.
> > > > > > > > > > >      The way it is presented in the draft makes me
> > > > > > > > > > > think that
> > > > > > > probably
> > > > > > > > > > >      plain TCP is also allowed as a transport, but
> > > > > > > > > > > is seems to
> > > > > > > contradict
> > > > > > > > > > >      everything I read about DOTS. Am I missing
> > > > > > > > > > > something
> > > here?
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > [Med] Plain TCP is not allowed. The intent was to be
> > > > > > > > > > explicit that there is
> > > > > > > > > a
> > > > > > > > > > reversal in both TCP and TLS layers, but as you
> > > > > > > > > > rightfully raised this may
> > > > > > > > > be
> > > > > > > > > > confusing since, for the DOTS case, it is trivial that
> > > > > > > > > > the reversal of TLS
> > > > > > > > > roles
> > > > > > > > > > implies the reversal of TCP ones.
> > > > > > > > >
> > > > > > > > > RESTCONF call home only reverses the TCP role but not
> > > > > > > > > the TLS role. In DOTS case, the server has to initiate
> > > > > > > > > DTLS handshake for UDP. To keep the roles same for TCP,
> > > > > > > > > TLS handshake is also initiated
> > > > > by
> > > > > > the server.
> > > > > > > >
> > > > > > > > [Med] You missed "for the DOTS case" in my previous reply
> > > > > > > > :-)
> > > > > > > >
> > > > > > > > We do have the following in the draft:
> > > > > > > >
> > > > > > > >                    DOTS                                DOTS
> > > > > > > >                   Server                              Client
> > > > > > > >                     |                                    |
> > > > > > > >                     |         1. (D)TLS connection       |
> > > > > > > >                     |----------------------------------->|
> > > > > > > >                     |         2. Mitigation request      |
> > > > > > > >                     |<-----------------------------------|
> > > > > > > >                     |                                    |
> > > > > > > >
> > > > > > > > That can be trivially expanded as follows for the TLS case:
> > > > > > > >
> > > > > > > >                    DOTS                                DOTS
> > > > > > > >                   Server                              Client
> > > > > > > >                     |                                    |
> > > > > > > >                     |         1.1. TCP                   |
> > > > > > > >                     |----------------------------------->|
> > > > > > > >                     |         1.2. TLS                   |
> > > > > > > >                     |----------------------------------->|
> > > > > > > >                     |         2. Mitigation request      |
> > > > > > > >                     |<-----------------------------------|
> > > > > > > >                     |                                    |
> > > > > > >
> > > > > > > Okay.
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > As mentioned earlier, the use of TCP/TLS is OK but it may
> > > > > > > > be confusing as initially raised by Valery.
> > > > > > >
> > > > > > > The updated text is not accurate if TCP is not covered, role
> > > > > > > reversal at TLS does not mean role reversal at TCP.
> > > > > >
> > > > > > [Med] The updated text is still fine (ref to Figure 1). We
> > > > > > don't have any ambiguity in the procedure part with regards to
> > > > > > TCP. We explicitly say the
> > > > > > following:
> > > > > >
> > > > > >        If TCP is used, the DOTS server begins by initiating a TCP
> > > > > >        connection to the DOTS client.  The DOTS client MUST support
> > > > > >        accepting TCP connections on the IANA-assigned port number
> > > > > >        defined in Section 4.1, but MAY be configured to listen to a
> > > > > >        different port number.  Using this TCP connection, the DOTS
> > > > > >        server initiates a TLS connection to the DOTS client.
> > > > > >
> > > > > > > Similar to (D)TLS, I prefer explicit text to say role
> > > > > > > reversal at
> > > TCP.
> > > > > >
> > > > > > [Med] We already have such text (see the above excerpt).
> > > > >
> > > > > [TR] Yes, but the updated sentences are incomplete/incorrect at
> > > > > various places. I have listed one of the inconsistencies below
> > > > >
> > > > >    The one and only role reversal that
> > > > >    occurs are at the TLS or DTLS layers; that is, the DOTS server acts
> > > > >    as a DTLS client and the DOTS client acts as a DTLS server or the
> > > > >    DOTS server acts as a TLS client and the DOTS client acts as a TLS
> > > > >    server.  The DOTS server initiates TLS handshake or DTLS
> > > > > handshake
> > to
> > > > >    the DOTS client.
> > > > >
> > > > > The above update means no role reversal at the TCP layer !
> > > >
> > > > [Med] This text assumes that the TCP is implicitly covered by "TLS layer"
> > > > (refer again to Figure 1). There is no ambiguity that the reversal
> > > > at the
> > > TLS
> > > > layer for the DOTS case implies a reversal of the TCP roles,
> > > > because otherwise the connection cannot be established at the
> > > > first place (due to
> > > the
> > > > presence of NATs/FWs) !
> > >
> > > If NAT is not present, connection can be established. FW can be
> > > configured
> > to
> > > permit TCP connections from external peer (e.g. port forwarding).
> > >
> > > >
> > > > We can removed "one and only" if this really hurts, though.
> > >
> > > I propose the following additional change:
> > >
> > >     The role reversal that
> > >     occurs are at the TLS or DTLS layers; that is, the DOTS server acts
> > >     as a DTLS client and the DOTS client acts as a DTLS server or the
> > >    DOTS server acts as a TLS client initiating the underlying TCP
> > > connection and the DOTS client acts as a TLS
> > >    server.  The DOTS server initiates TLS handshake or DTLS handshake to
> > >    the DOTS client.
> > >
> > > -Tiru
> > _______________________________________________
> > Dots mailing list
> > Dots@ietf.org
> > https://www.ietf.org/mailman/listinfo/dots