[core] πŸ”” WGLC of draft-ietf-core-hop-limit-03.txt

Carsten Bormann <cabo@tzi.org> Tue, 11 June 2019 18:17 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30DE7120048 for <core@ietfa.amsl.com>; Tue, 11 Jun 2019 11:17:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 yt7rgMezjgyz for <core@ietfa.amsl.com>; Tue, 11 Jun 2019 11:17:25 -0700 (PDT)
Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6DD5120074 for <core@ietf.org>; Tue, 11 Jun 2019 11:17:24 -0700 (PDT)
Received: from [192.168.217.113] (p54A6CA4C.dip0.t-ipconnect.de [84.166.202.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45NdWk6trBzyyH; Tue, 11 Jun 2019 20:17:22 +0200 (CEST)
From: Carsten Bormann <cabo@tzi.org>
Content-Type: text/plain; charset="utf-8"
X-Mao-Original-Outgoing-Id: 581969840.89281-0c199097a590b9e618cacba386d749bc
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Tue, 11 Jun 2019 20:17:22 +0200
Message-Id: <4E26BDEB-A895-45AC-B9B9-F6064E279D85@tzi.org>
To: core <core@ietf.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/ZKGAOfeWrXQQQj_4BGWXbI2nmXw>
Subject: [core] πŸ”” WGLC of draft-ietf-core-hop-limit-03.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jun 2019 18:17:27 -0000

During the last interim, we said we want to run a Working Group last call on

https://tools.ietf.org/html/draft-ietf-core-hop-limit-03


When we discussed this at the interim, we said that, apart from the overall state of the document, we would like to address two questions in this WGLC:

(1) With a way to perform proxy loop mitigation now available, what is our recommendation for usage?  Is this something that is (a) specific to DOTS, something that (b) it would now be reasonable to expect a proxy to add, or (c) something that every CoAP implementation should do?  (At the interim, we were leaning towards (b).)

(2) The HTTP world has a concurrent document addressing the same issue, 

https://tools.ietf.org/html/rfc8586

The technical approach is different here (based on leaving breadcrumbs in the requests), so it acts as a true loop prevention mechanism, not just mitigation.  It also is more expensive, adding dozens of bytes to each request passing a proxy.  Still, we want to make sure the difference in approaches is well justified.


The WGLC will end in exactly 336 hours so we can discuss the outcome at the CoRE WG Interim meeting on 2019-06-26.  Please indicate your position in a message to the CoRE mailing list (core@ietf.org) or, exceptionally, to the chairs (core-chairs@ietf.org).


Grüße, Carsten