Re: [Dots] Review Comments on draft-boucadair-core-hop-limit

<mohamed.boucadair@orange.com> Wed, 12 September 2018 15:06 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 E38DB130DC6; Wed, 12 Sep 2018 08:06:14 -0700 (PDT)
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 0bckL3eoL2cW; Wed, 12 Sep 2018 08:06:12 -0700 (PDT)
Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0888130DD8; Wed, 12 Sep 2018 08:06:07 -0700 (PDT)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 429Q8Y3l3tz4wgN; Wed, 12 Sep 2018 17:06:05 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 429Q8Y2Zf1zDq7L; Wed, 12 Sep 2018 17:06:05 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0415.000; Wed, 12 Sep 2018 17:06:05 +0200
From: <mohamed.boucadair@orange.com>
To: Jim Schaad <ietf@augustcellars.com>, "draft-boucadair-core-hop-limit@ietf.org" <draft-boucadair-core-hop-limit@ietf.org>
CC: 'core' <core@ietf.org>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: Review Comments on draft-boucadair-core-hop-limit
Thread-Index: AdQ6lZtWzVfWrqOXTka5fHNwSfnzLwP0eWXwAAv8EQAABI3mkA==
Date: Wed, 12 Sep 2018 15:06:04 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302DFDEF0E@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <008c01d43a98$7beb5f90$73c21eb0$@augustcellars.com> <787AE7BB302AE849A7480A190F8B93302DFDEB7E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <018a01d44aa8$36bfaf00$a43f0d00$@augustcellars.com>
In-Reply-To: <018a01d44aa8$36bfaf00$a43f0d00$@augustcellars.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.2]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/AvzzgfuJEQm_6u1CTiw1RiBpD5I>
Subject: Re: [Dots] Review Comments on draft-boucadair-core-hop-limit
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: Wed, 12 Sep 2018 15:06:15 -0000

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Jim Schaad [mailto:ietf@augustcellars.com]
> Envoyé : mercredi 12 septembre 2018 16:52
> À : BOUCADAIR Mohamed IMT/OLN; draft-boucadair-core-hop-limit@ietf.org
> Cc : 'core'; dots@ietf.org
> Objet : RE: Review Comments on draft-boucadair-core-hop-limit
> 
> 
> 
> > -----Original Message-----
> > From: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
> > Sent: Wednesday, September 12, 2018 1:19 AM
> > To: Jim Schaad <ietf@augustcellars.com>om>; draft-boucadair-core-hop-
> > limit@ietf.org
> > Cc: 'core' <core@ietf.org>rg>; dots@ietf.org
> > Subject: RE: Review Comments on draft-boucadair-core-hop-limit
> >
> > Hi Jim, all,
> >
> > Thank you for sharing the comments.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Jim Schaad [mailto:ietf@augustcellars.com] Envoyé : jeudi 23 août
> > > 2018 06:19 À : draft-boucadair-core-hop-limit@ietf.org
> > > Cc : 'core'
> > > Objet : Review Comments on draft-boucadair-core-hop-limit
> > >
> >
> > > Section 3 - para 4 - Probably does not matter, but the current
> > > algorithm wastes one bit.  Check for 0 and then decrement would give
> > > one addition possible field.  It would also compress down the size of
> > > the encoded option faster.
> 
> Did you miss this?

[Med] Actually, no. I discussed with my co-authors. Tiru proposed this change: 

"CoAP messages MUST NOT be forwarded if the Hop-Limit option is set to '0' before decrement." 

But I'm not sure this is superior to what we had already in the draft which allows to detect the loop earlier in the forwarding path. 

Please let us know if we missed your point. 

> 
> > >
> > > Section 3 - I don't know that you only want to have a proxy
> > > information appearing once.  If it appears multiple times then you can
> > > easily spot the loop.  No real option one way or the other.
> > >
> >
> > [Med] We had that restrictions for two reasons:
> > - ease correlation between hop count and the information recorded in the
> > body.
> > - maintain a reasonable message size.
> 
> Looks like I was half asleep - should have been no real opinion either way.
> This is fine.  You may want to comment on that but I don't really care.
> 
> > > Section 5 - There is a potential privacy consideration that may need
> > > to be covered.  The return value is going to provide an eavesdropper a
> > > large amount of information on the configuration of the network.  Is
> > > there value to configuring so that the error but not the trace stack is
> > provided?
> > >
> > >
> >
> > [Med] Good point. There is still a value in returning the error even
> without the
> > trace as this allows a peer to know why a request failed. Proxies at
> boundaries
> > are supposed to generate alarms to administrators.
> >
> > We can consider adding the following:
> > - a proxy which is located at the boundary of an administrative domain may
> be
> > instructed to strip the diagnostic payload or part of it before forwarding
> 5.06
> > upstream.
> 
> That would be fine.

[Med] OK, thanks.

> 
> Jim
> 
>