Re: [Tsv-art] Tsvart last call review of draft-ietf-6man-icmp-limits-07

Tom Herbert <> Thu, 05 March 2020 19:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE7703A09FF for <>; Thu, 5 Mar 2020 11:12:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8islZKtZlOfN for <>; Thu, 5 Mar 2020 11:12:39 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::542]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ED3983A09F6 for <>; Thu, 5 Mar 2020 11:12:38 -0800 (PST)
Received: by with SMTP id y3so8144188edj.13 for <>; Thu, 05 Mar 2020 11:12:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VvcfBOnBpq32+vpn2soAKkFGcM9IDAEYDxHiUnm4C50=; b=JAr3AG9XNdnbGdbQbHOsfcungRidEfhYA2kA7LYmL4ioBlY9sbgCQAxC8GJgjeztrD W30MPmEJ9R3ELIg6qLQlW8plLCEG3Gu6rj6A7lxNar/AA6T5HP27AdJr1vF3b72Py2cO /REGx+rJA4/VWVqcHG2nv6iRx2lp+MwFARqar0gUpe0QQM5wG/KEllEUp2ib9g//IKXH NoyCDwWYHhTJUHJagKaf9OLMrgnwOJ9aygHdOwuL0eebvVaofmL2+Ic36gO2uaVuzsV+ 7sSz8ix3wgJJN5oMjRn+WmuAwJKARbcFAzvIZxbe58nsUd+wmd7oI1rh5vjKiGh4gxWg 2pCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VvcfBOnBpq32+vpn2soAKkFGcM9IDAEYDxHiUnm4C50=; b=dTI7/BJDhcJqKT2Yza28DKCd5Q95UHfik7RsOkcILCJ42vc/vu/+n7Br/9iTr50pZp cDIBCma+OvksVQzB+8UqUKfaK1/Y/mGD/gDghv1WbaDE9LuCemZCL2WN5iYoO96Z+KkU N+lhknB/QLo47RK3cQ7QwpwRk6MOdnv2lJyhElEd74fm+5Xw/tUQbWwKPOoIvIsX5X0R pFUZGn2rN4Zo0AStnB26z+6CfZGl07vGHNw94RVM6oPMtvLYkFdMXG1cI0Xw+/vDETtF wwqrNt7iQ4KpDlIlnmG0bux/yPZix4Hr6l+JofgLSiLriaIejftl/D2fNvi3R+kPDNsg aCkQ==
X-Gm-Message-State: ANhLgQ2AlVkj5Z/MDn/F8N4bONS8rh6eu4XO72zhy24l/DCdCRsCzDyN 0x6hyUw/36r7tC9RFB5T+qDUrFFX2TfQfP0V6Otsjw==
X-Google-Smtp-Source: =?utf-8?q?ADFU+vvlSVHTLePPJiIjXc6i/6c31llUy0n+nQUojyqB?= =?utf-8?q?vl7bftkZbmMvIlWs5k9PE3uwX8Tr1JEyd9mBBCE0t5sFOo0=3D?=
X-Received: by 2002:a05:6402:206c:: with SMTP id bd12mr269521edb.212.1583435557179; Thu, 05 Mar 2020 11:12:37 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Thu, 5 Mar 2020 11:12:25 -0800
Message-ID: <>
To: Bernard Aboba <>
Cc:,, 6man <>,
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-6man-icmp-limits-07
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Mar 2020 19:12:41 -0000

Hi Bernard,

Thanks for the review. Comments inline.

On Tue, Feb 18, 2020 at 1:03 PM Bernard Aboba via Datatracker
<> wrote:
> Reviewer: Bernard Aboba
> Review result: Ready with Issues
> TSV-ART Review of draft-ietf-6man-icmp-limits
> Bernard Aboba
> Result: Ready with Issues
> This document specifies several new ICMPv6 errors that can be sent
> when a node discards a packet due to it being unable to process the
> necessary protocol headers because of processing constraints or
> limits.  Reasons include:
>       Code (pertinent to this specification)
>          1 - Unrecognized Next Header type encountered
>          TBA - Extension header too big
>          TBA - Extension header chain too long
>          TBA - Too many options in extension header
>          TBA - Option too big
> ICMP Reliability
> Section 5.2 states:
> "  ICMP is fundamentally an unreliable protocol and in real deployment
>    it may consistently fail over some paths. As with any other use of
>    ICMP, it is assumed that the errors defined in this document are only
>    best effort to be delivered. No protocol should be implemented that
>    relies on reliable delivery of ICMP messages. If necessary,
>    alternative or additional mechanisms may used to augment the
>    processes used to to deduce the reason that packets are being
>    discarded. Such alternative mechanisms are out of scope of this
>    specification."
> [BA] The last sentence is a bit vague. My assumption is that this is
> referring to techniques such as are used in Path MTU discovery (e.g.
> tweaking of packets so as to determine potential reasons why packets
> are being discarded).  However, a reference might be helpful.
We can provide a reference to PMTU discovery as one example. Probing
with different features in packets would also be a way to determine
what is causing packet less (something akin to Happy Eyeballs).

> Security Concerns
> Pointer field
> In Section 3.1, the description of the Pointer field states:
> "      Pointer
>          Identifies the octet offset within the invoking packet where
>          the problem occurred.
>          The pointer will point beyond the end of the ICMPv6 packet if
>          the field having a problem is beyond what can fit in the
>          maximum size of an ICMPv6 error message."
> [BA] I worry about attackers using the Pointer field for
> mischief, such as buffer overflows.  The draft currently
> does not provide advice to implementers about validating
> the Pointer field (e.g. checking it against the length of
> the offending packet). Do we really need a 32-bit Pointer field?
The thirty-bit Pointer field is from RFC4443. We will add text that
the pointer field must be validated (I don't believe RFC4443 mentions

> Use by attackers
> Section 4.2 states:
> "  A host MAY modify its usage of protocol headers in subsequent packets
>    to avoid repeated occurrences of the same error."
> [BA] While this response is optional, I do worry about the potential for
> spoofed ICMP packets to modify the host's security posture. Are there any
> types of usage modifications that a host should be particularly wary
> of?

I think it's like any other use case of ICMP errors that might also be
spoofed. One mitigation against spoofing in the ICMP protocol is that
the packet that caused the error is set in the ICMP data so that a
source host should validate that it sent the packet that caused the
error. Generally, though for ICMP there is no inherent security so the
sources need to take the messages as advisory and any response needs
to be done in accordance with security policies in effect.

> Section 6 states:
> "  In some circumstances, the sending of ICMP errors might conceptually
>    be exploited for denial of service attack or as a means to covertly
>    deduce processing capabilities of nodes. As such, an implementation
>    SHOULD allow configurable policy to withhold sending of the ICMP
>    errors described in this specification in environments where security
>    of ICMP errors is a concern."
> [BA] This concern seems quite realistic to me, and as a result, it would
> not surprise me if implementations either do not send these ICMP errors,
> or withhold them by default. Do you have a position on that?

I don't think the risk is any greater than any other ICMP errors. I
suspect switches and intermediate nodes will probably not bother
sending the errors since they mostly don't send existing ICMP errors
anyway. In host implementations, such as Linux, I don't believe there
will be much concern with supporting these errors. The errors are
still subject to general policies that limit ICMP errors.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------