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

Jim Schaad <ietf@augustcellars.com> Wed, 12 September 2018 14:52 UTC

Return-Path: <ietf@augustcellars.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 E90C6130DD8; Wed, 12 Sep 2018 07:52:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 mV7dJ6Fwj4dJ; Wed, 12 Sep 2018 07:52:49 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55002130DC6; Wed, 12 Sep 2018 07:52:49 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 12 Sep 2018 07:48:25 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: <mohamed.boucadair@orange.com>, <draft-boucadair-core-hop-limit@ietf.org>
CC: 'core' <core@ietf.org>, <dots@ietf.org>
References: <008c01d43a98$7beb5f90$73c21eb0$@augustcellars.com> <787AE7BB302AE849A7480A190F8B93302DFDEB7E@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DFDEB7E@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Date: Wed, 12 Sep 2018 07:52:20 -0700
Message-ID: <018a01d44aa8$36bfaf00$a43f0d00$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJuqcW/fDeCE10vqelGbqrPN3jeeAFnZ+Hto6zA/hA=
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/dD1r09yvaHSGOEQZphaOjQRVEC0>
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 14:52:54 -0000


> -----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?

> >
> > 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.

Jim