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>; draft-boucadair-core-hop- > limit@ietf.org > Cc: 'core' <core@ietf.org>; 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
- Re: [Dots] Review Comments on draft-boucadair-cor… mohamed.boucadair
- Re: [Dots] Review Comments on draft-boucadair-cor… Jim Schaad
- Re: [Dots] Review Comments on draft-boucadair-cor… mohamed.boucadair