Re: [secdir] Secdir review of draft-ietf-core-hop-limit-05

<mohamed.boucadair@orange.com> Mon, 30 September 2019 05:43 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F31A120106; Sun, 29 Sep 2019 22:43:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 wMTe5OxWoK4f; Sun, 29 Sep 2019 22:43:46 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C67DC120019; Sun, 29 Sep 2019 22:43:45 -0700 (PDT)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 46hWXw1Qzlz5vs9; Mon, 30 Sep 2019 07:43:44 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.107]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 46hWXv2YFvz1xpp; Mon, 30 Sep 2019 07:43:43 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM8F.corporate.adroot.infra.ftgroup ([fe80::74f6:8fc8:b1b8:dbba%21]) with mapi id 14.03.0468.000; Mon, 30 Sep 2019 07:43:43 +0200
From: <mohamed.boucadair@orange.com>
To: Radia Perlman <radiaperlman@gmail.com>, "draft-ietf-core-hop-limit@ietf.org" <draft-ietf-core-hop-limit@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, The IESG <iesg@ietf.org>
Thread-Topic: Secdir review of draft-ietf-core-hop-limit-05
Thread-Index: AQHVdo6FqmzEbgOJzUafFrD/OWqlv6dDthjg
Date: Mon, 30 Sep 2019 05:43:42 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933031327F05@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <CAFOuuo5bAzvGR8mvkfVXot5XVUSvnjj0khievH8WW1MA-T6JAw@mail.gmail.com>
In-Reply-To: <CAFOuuo5bAzvGR8mvkfVXot5XVUSvnjj0khievH8WW1MA-T6JAw@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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933031327F05OPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/Zd6xOlh0mjkxBvAp6o5jXa9IBW8>
Subject: Re: [secdir] Secdir review of draft-ietf-core-hop-limit-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Sep 2019 05:43:48 -0000

Hi Radia,

Noted. We will consider your suggestion.

Thank you for the review.

Cheers,
Med

De : Radia Perlman [mailto:radiaperlman@gmail.com]
Envoyé : dimanche 29 septembre 2019 08:24
À : draft-ietf-core-hop-limit@ietf.org; secdir@ietf.org; The IESG
Objet : Secdir review of draft-ietf-core-hop-limit-05


   I have reviewed this document as part of the security directorate's

    ongoing effort to review all IETF documents being processed by the

    IESG.  These comments were written primarily for the benefit of the

    security area directors.  Document editors and WG chairs should treat

    these comments just like any other last call comments.

Summary:  This document is fine.

This document defines an option for preventing infinite loops of  Constrained Application Protocol (CoAP) proxies. The document says that infinite forward loops is undesirable", which is a cute wording.

I'm very much in favor of hop count limits whenever things are forwarded (I was always somewhat terrified of forwarding Ethernet packets without a hop count).

If I have to make an editorial comment (to show I was awake when reading this), I might comment about this text:

  "If no initial value is explicitly provided, the default initial Hop-Limit value of

   16 MUST be used.  This value is chosen to be sufficiently large to

   guarantee that a CoAP request would not be dropped in networks when

   there were no loops, but not so large as to consume CoAP proxy

   resources when a loop does occur.

My quibble with that text is that if there were a value that would always be sufficiently large that a request would never be prematurely dropped, and not so large as to consume resources because of loops not being detected soon enough, then it needn't be configurable...just always use that value.

So, maybe the text should say "this value is chosen so that in the majority of cases it is sufficiently large...but is still configurable to accommodate unusual topologies.



Radia