Re: [Tsv-art] Tsvart last call review of draft-ietf-dots-server-discovery-11

mohamed.boucadair@orange.com Wed, 21 October 2020 15:00 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012FC3A12B2; Wed, 21 Oct 2020 08:00:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 aQE9xEBKcj0C; Wed, 21 Oct 2020 08:00:12 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.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 2C2BF3A1287; Wed, 21 Oct 2020 08:00:12 -0700 (PDT)
Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 4CGYZL3ZWRzBshB; Wed, 21 Oct 2020 17:00:10 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1603292410; bh=2PJAUyE9qUZW0RK9Tu8JPUG0G4VPNpR6uauu2s4YHt0=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=J+Aq13P5DZdkUEhe0347kgb/ZdPFH7NX0TNeguA1rfa8/VmfFvTgV7oqm24dKncs+ 8iYP4XpcWSVDOlXy2N1aj6vRo76JwaxOtmJy5oR9sfbpPLbsABfOz2LeAlbae/WWGQ 1sji655R2aOWABVPcrphIlgtdXQJ2u570wkgDTFVARsY9h+dg2r2UTJF9ou69vn3cd VePUNdKoQSHEPTB+j22X6vievFiaONG9brx9Ls8Soh+9ekQ8G60yLsyLzcCCByj0vv ARAwjuSl6fsELCC1RR59nheUrnH7mev9LsUcq8jv/PqHA/A+bXDRus3sTWjAVuePBz ri/lwuzQ3v8Ug==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 4CGYZL20YjzCqlQ; Wed, 21 Oct 2020 17:00:10 +0200 (CEST)
From: mohamed.boucadair@orange.com
To: Kyle Rose <krose@krose.org>
CC: "tsv-art@ietf.org" <tsv-art@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "dots@ietf.org" <dots@ietf.org>, "draft-ietf-dots-server-discovery.all@ietf.org" <draft-ietf-dots-server-discovery.all@ietf.org>
Thread-Topic: Tsvart last call review of draft-ietf-dots-server-discovery-11
Thread-Index: AQHWp7XJRgdZ4S16aEekcYyNLJrIR6miH2Iw
Date: Wed, 21 Oct 2020 15:00:09 +0000
Message-ID: <25324_1603292410_5F904CFA_25324_477_9_787AE7BB302AE849A7480A190F8B93303156475C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <160246137613.594.10649805135544482452@ietfa.amsl.com> <22178_1602577731_5F856543_22178_325_7_787AE7BB302AE849A7480A190F8B93303155F274@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAJU8_nV9N49LK=3kBCaoE_B-ikBcDuGxPE+z4WojnS54iueCkA@mail.gmail.com>
In-Reply-To: <CAJU8_nV9N49LK=3kBCaoE_B-ikBcDuGxPE+z4WojnS54iueCkA@mail.gmail.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.245]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/Zc8lI5Ow6cUbW4w8o_aywZ4k9Pc>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-dots-server-discovery-11
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Oct 2020 15:00:15 -0000

Hi Kyle, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Kyle Rose [mailto:krose@krose.org]
> Envoyé : mercredi 21 octobre 2020 16:24
> À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>
> Cc : tsv-art@ietf.org; last-call@ietf.org; dots@ietf.org; draft-
> ietf-dots-server-discovery.all@ietf.org
> Objet : Re: Tsvart last call review of draft-ietf-dots-server-
> discovery-11
> 
> On Tue, Oct 13, 2020 at 4:28 AM <mohamed.boucadair@orange.com>
> wrote:
> > > * Section 4 says:
> > >
> > >    The discovery method is reiterated by a DOTS agent upon the
> > > following
> > >    events:
> > >
> > >    o  Expiry of a a validity timer (e.g., DHCP lease, DNS TTL)
> > >       associated with a discovered DOTS agent.
> > >
> > > >From my reading, rendezvous information for the DOTS server is
> > > "pushed"
> > > >to the
> > > client via DHCP, so it's not clear the above is actionable. Is
> it
> > > simply the case that a client should use the DOTS server
> assigned in
> > > the most recent lease?
> > >
> >
> > [Med] The intent is to avoid using "stale" servers. So yes, this
> is about using the server that was most recently discovered but also
> about not using a server beyond a validity time associated with the
> discovered server.
> 
> I think the wording for this requirement should be normative rather
> than buried in the description of the discovery mechanism. Adding a
> statement somewhere that "a DOTS agent MUST NOT initiate or continue

[Med] The normative language is not used because managing sessions is beyond discovery. Such behavior will depend on the DOTS channel and whether a DOTS agent is in idle or attack time. For example, immediately closing a communication with a peer DOTS agent while an attack mitigation is in progress may not be convenient. We have such exceptions in RFC8782, e.g.,

   "This fallback mechanism is triggered immediately upon
   expiry of the TTL, except when a DDoS attack is active."

> communicating with a server whose associated discovery metadata has
> expired: for instance, once a DNS TTL or DHCP lease has expired, an
> appropriate DOTS server must be rediscovered using one of the
> mechanisms in {}."

FWIW, your review was taken into account in https://tools.ietf.org/rfcdiff?url2=draft-ietf-dots-server-discovery-12.txt. See the security section, in particular. 

Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.