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

Radia Perlman <radiaperlman@gmail.com> Sun, 29 September 2019 06:24 UTC

Return-Path: <radiaperlman@gmail.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 C675712006A; Sat, 28 Sep 2019 23:24:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.098
X-Spam-Level:
X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 FcZhkxOY7EtN; Sat, 28 Sep 2019 23:24:13 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4B3A12000F; Sat, 28 Sep 2019 23:24:09 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id q64so6201511ljb.12; Sat, 28 Sep 2019 23:24:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=2gJJKnaWxcX/66227S7niSIHA7IwWYlj8tS/oFGXOpc=; b=e9sfAp7+8m8tBMRJCCXgDjaNLCFo/NdWMhyIqJ53NynUdXY05pueE3lJ53taHe1Yd0 YlhISn3395B1y6bMdqqh8cSLvQL2EPhdAC64WorX+5VPXwaUXS+j66RLs1hjhtOK8ATE YAMwl58lj3shlbXQHUhJJWSPwwdb+x3tcgctDOTkqpcxJp7OonWyDOsq0bxsMKuk+QeZ Ol5VGmrXUPOiaE3KOs/A86JgF0W4r9P4ZyQmwvlJrAaVmUeuzVZHxkl5qyaERvApQlc4 GJSwkCxvmP05MPEnTOVpGopiQ0/FFoCTcv852qKov2ByaHMelen0Zmm20cLwAHnoHR2n A3HA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2gJJKnaWxcX/66227S7niSIHA7IwWYlj8tS/oFGXOpc=; b=cpGiy65mdBcGsgoyZUK6hCA0AHPthS81PZGMU0zWsXyGB919yMnSgOQOTNxvFShCSI jmMWgiLhbbiF4jhaaijpYX3gB21EnkK2ZnfQnymU2lOEj28b0h5rxAbXK2BWMkdAy1q1 eVfcIkWa5m2WYPD6DQyLiyuwUXvNVSM5RmtE+RgL9PKKBTArHoH9CecpUtFn2u9NlnP4 hlDpApP6nqfBww5Z7hj2re7FXspm5BWWJeqBil33gFo5NOB6bzk7JIKiwZKqgZzWA3XU 3G8NMCzQ19WxVh0iw3cY/F6qjwAbp4+Se+DVdDJgdDAQH/GB19b8JiJAHDXxAe134kUz YPTw==
X-Gm-Message-State: APjAAAX5OLZLhZ4bU6bFB0MYtdEVrCkurg5swOSFoDcA0U/e9AiNURhx 4jEW1KbfHYUIwPPtk2MGnxdoWpQdByj3lgb8O1bvIQuf
X-Google-Smtp-Source: APXvYqz9q8uKso8bJPhNtXVqCC4+EpAkKQLOPc5f8zgxq8LDFrSdXGn6mV6cibpTzdx057x38INvgif34bECiVM50KI=
X-Received: by 2002:a2e:1504:: with SMTP id s4mr6913801ljd.80.1569738247890; Sat, 28 Sep 2019 23:24:07 -0700 (PDT)
MIME-Version: 1.0
From: Radia Perlman <radiaperlman@gmail.com>
Date: Sat, 28 Sep 2019 23:23:56 -0700
Message-ID: <CAFOuuo5bAzvGR8mvkfVXot5XVUSvnjj0khievH8WW1MA-T6JAw@mail.gmail.com>
To: draft-ietf-core-hop-limit@ietf.org, secdir@ietf.org, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a7eb280593ab2aac"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/N2cvdMOCXwWqsnqDCUgkl7pngUc>
Subject: [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: Sun, 29 Sep 2019 06:24:15 -0000

   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