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

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Thu, 25 April 2019 13:47 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 77A8C120161 for <dots@ietfa.amsl.com>; Thu, 25 Apr 2019 06:47:45 -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 ksXqwlnlwJaH for <dots@ietfa.amsl.com>; Thu, 25 Apr 2019 06:47:42 -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 ADC6C120071 for <dots@ietf.org>; Thu, 25 Apr 2019 06:47:41 -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=1556199694; 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-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=H rDkX+Og1G/Zjx8U3uaqTWng4pGgk1jvHGFm0z2Vtx M=; b=ElWC8y+rs2Pgl/6uGJ2UOQYSWbKeLEbHJkaU/spG101h yBqcfxuUd195i9WDiyMKMic3CWMbb4aey83kgpDWNy9326zFgU IJdBETRwC9hrHvUSN+aAyiMsXzxZqU6iqXOkvjvTpNMoo3zs1e nq/5qFFIxapYnxz0xE1ZDwds7wQ=
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 46f5_5131_5532e275_c631_470e_b201_fcf7c94fda09; Thu, 25 Apr 2019 07:41:33 -0600
Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 25 Apr 2019 07:47:25 -0600
Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 25 Apr 2019 07:47:24 -0600
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 25 Apr 2019 07:47:22 -0600
Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2759.namprd16.prod.outlook.com (20.178.233.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.12; Thu, 25 Apr 2019 13:47:22 +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 13:47:22 +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: AdTuHVZNyfDh6IMnTiyfhZP8vM2pOAMPXcMAAAHlewAAACVi8AABQijQAAj4x4AAAJCXsAADitfgAAByLdAAAFuUIAAjllPAAAjlb4AAAEheYAABbuuAAAUM4MA=
Date: Thu, 25 Apr 2019 13:47:21 +0000
Message-ID: <BYAPR16MB2790E9F292C8AF74ED3AD4DEEA3D0@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> <BYAPR16MB27907A8A494FDA074713490FEA3D0@BYAPR16MB2790.namprd16.prod.outlook.com> <013c01d4fb58$576f1ae0$064d50a0$@jpshallow.com>
In-Reply-To: <013c01d4fb58$576f1ae0$064d50a0$@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: [49.37.205.191]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5c17b0ab-53ec-4f52-b37e-08d6c9848ae1
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BYAPR16MB2759;
x-ms-traffictypediagnostic: BYAPR16MB2759:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <BYAPR16MB2759ED2EA7BB6420E5E287F5EA3D0@BYAPR16MB2759.namprd16.prod.outlook.com>
x-forefront-prvs: 0018A2705B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(396003)(39850400004)(366004)(136003)(32952001)(51854002)(13464003)(189003)(199004)(73956011)(80792005)(476003)(53946003)(5024004)(3846002)(71190400001)(2906002)(71200400001)(6116002)(14444005)(97736004)(11346002)(256004)(53936002)(99286004)(9686003)(6246003)(305945005)(2501003)(7696005)(8936002)(68736007)(74316002)(53546011)(6306002)(102836004)(8676002)(6506007)(486006)(81156014)(25786009)(446003)(93886005)(7736002)(76176011)(26005)(316002)(5660300002)(110136005)(229853002)(55016002)(6436002)(81166006)(66066001)(66476007)(478600001)(86362001)(30864003)(2201001)(66446008)(64756008)(33656002)(66556008)(966005)(186003)(76116006)(66946007)(72206003)(14454004)(52536014)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2759; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: 7xpCHUoPAVCwiXr/PVuLLZC9F0pNtNaGx0hLHQnsxQzbu1Nx01d7qr9v2JwOAgEqZ+cHGtWr0Z6cUZufFx6kooum3BTQFE4hxJkJcScAzYV4X1zPya6GAKSrgrwRuP1gYVwS/JvGUvf4rZzndMCHGSxafOEUqjuLil4/emXMi9El3/kADac5hzc2nBbUpEhzYOpYrjE8AdsdB2A6zUoCUGQVAvciS8lJ+zogD/l6N7fWJ0QVXWvG+W9kry+VgvTkoDToc270vFRihP+Ey4cSypmRtZ3h9BNuy1qPdvVtr1GPmGpmL/d2a50s1k3DLssg/A4GQ5912ZhN9W+jgmXkzdwl6JRfsAeQARLTNbMv5t8hPggy0H08hFKgA/mrsQe1SDlQOdbtOlWcXNfvu//OJ4X1By4ccqVr0fxmsQUAHJE=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 5c17b0ab-53ec-4f52-b37e-08d6c9848ae1
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2019 13:47:22.0285 (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: BYAPR16MB2759
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0
X-NAI-Spam-Version: 2.3.0.9418 : core <6533> : inlines <7059> : streams <1819689> : uri <2836916>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/giUE8nrhQCekuGpPJtmA2WKcX58>
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 13:47:46 -0000

> -----Original Message-----
> From: Jon Shallow <supjps-ietf@jpshallow.com>
> Sent: Thursday, April 25, 2019 4:47 PM
> To: Konda, Tirumaleswar Reddy
> <TirumaleswarReddy_Konda@McAfee.com>;
> mohamed.boucadair@orange.com; dots@ietf.org
> 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.
> 
> Hi Tiru,
> 
> Good point about the DOTS server initial UDP Packet needs to include the
> Client Hello.  However, if it was an empty packet (no data, or some other
> specifically defined data),  the DOTS client could ignore any data (as it is
> listening on the Call Home port) then use the 5 tuple of the received packet
> to send the initial Client Hello to the DOTS server.
> 
> However, that does raise the question of an attack where someone is
> sending spoofed IP packets to the DOTS client.  But that would also be true
> for a Client Hello packet with a spoofed source IP causing the recipient to
> send out the Server Hello to the spoofed originator.

DTLS uses stateless cookie mechanism to defend against DOS attacks, see https://tools.ietf.org/html/rfc7525. 

> 
> I will continue to look at how to do the current draft thinking in libcoap ....

We should discuss this problem in the CORE WG, RFC7252 says CoAP implementation can act in both client and server roles.

-Tiru

> 
> Regards
> 
> Jon
> 
> > -----Original Message-----
> > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda,
> > Tirumaleswar Reddy
> > Sent: 25 April 2019 11:41
> > To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org
> > Subject: Re: [Dots] Adoption call for draft-reddy-dots-home-network-04
> >
> > 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
> >
> > _______________________________________________
> > Dots mailing list
> > Dots@ietf.org
> > https://www.ietf.org/mailman/listinfo/dots