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

Tom Herbert <> Wed, 26 February 2020 04:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 823383A0C61 for <>; Tue, 25 Feb 2020 20:27:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AH30vYMmIrj3 for <>; Tue, 25 Feb 2020 20:27:16 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5A5BE3A0C5C for <>; Tue, 25 Feb 2020 20:27:16 -0800 (PST)
Received: by with SMTP id j17so2115104edp.3 for <>; Tue, 25 Feb 2020 20:27:16 -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=G1tiTc7O6i/4F233cK5j5MzowS4fSaXevWTfrgA68Cc=; b=sCGCnzu5k6IXC3R0wUQpe/+/dyt5PvjTUrOHpgIOnrLwECDEOiideQFW+Qq6xIqp+e NKX0UNJDylcITSuFCYYP5apvwf9JJF9WdkZs7+IRxcIlUtEl6LFCQzaZE+SDBAcORDHB wyfwF/Hovw1ZmVK2vQDSBzH/ulmn8AEIYVlxWyktxJ3z/wSs//T8z5/wJLjwvwFiXGVd uQc6EHwmW60W0UeQvnN3urLyhYaub838zCNjTUzQVR7jbbslrwyVvHGgb7T5XFTMMwTN VsqWV5gwuS8ra/cBuyLx/fNpBssEHJL+5jBB+yRmKnkTkro1kFRAkVYdKuMeK6xTErlg X79Q==
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=G1tiTc7O6i/4F233cK5j5MzowS4fSaXevWTfrgA68Cc=; b=bZ8Y8SEAMy0IR300/8DXf2E9mIdbM1CoYdL7LPOVxRz24UYECNOeYS0F8NPvVuHRK7 wQmOVwCAAS9WdbJ+12Bbf7h8SvknL4IET0eLiBC2vVFsy3+ZHoVzVHdFIQrIHZ18DcsK cYgqJuy2CWK6hpCvNNs0ZzMackMZyxlbM1+GzfGXqwS7IbZfRRbxn8L0rZnhMNfhfljI yUdPYavZdr36gH/8L+RqwT4DoAUSbYpx6T2kWCiReMJcLoIxUgzDmFtQUiXVe7L7xxuQ 19kiBcZuCBiNgSC0e9nfjDD5IejWEWBunPqMwmOT1bGG17ilsRXA8B3uNgU7Xbso5xBG nFaQ==
X-Gm-Message-State: APjAAAXg5gXxXvIkV3F0Ytt3bBpnSx3sVZAbRZL/uDM48M0FXeGr13pY FZe899gq7N1wxLiZYPfOLskKsmo+Ag4ZkeiBTHVpkQ==
X-Google-Smtp-Source: APXvYqzs4r6NBCyLS5+gqrC1ummZHxBcORBz52BSzkcsHHXzoB6ejHAvZaTr86UJ2CEmYbazXf99LyxqxbSj4ayAidk=
X-Received: by 2002:a17:906:1a0c:: with SMTP id i12mr2309301ejf.295.1582691234491; Tue, 25 Feb 2020 20:27:14 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Tue, 25 Feb 2020 20:27:03 -0800
Message-ID: <>
To: Suresh Krishnan <>
Cc: Bernard Aboba <>, Benjamin Kaduk <>,, 6man <>,,
Content-Type: multipart/alternative; boundary="000000000000d25137059f73040f"
Archived-At: <>
Subject: Re: [Tsv-art] [Last-Call] 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: Wed, 26 Feb 2020 04:27:19 -0000

Pointer is probably an unfortunate term. Would have been better if this was
originally described as an offset. In any case, the text is clear, the
offset of the byte in error (pointer) can be beyond the extent of the
packet, and the implementation needs to correctly deal with that.


On Tue, Feb 25, 2020, 8:02 PM Suresh Krishnan <>

> Hi Bernard/Ben,
>   Thanks for your review. Just responding to one point below.
> On Feb 25, 2020, at 2:34 PM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:
> On Tue, Feb 18, 2020 at 01:02:21PM -0800, 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.
> 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?
> Very reminiscent of heartbleed, even with the note that "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."
> Hmm. This is exactly how base ICMPv6 (RFC4443 and prior to that RFC2463
> and RFC1885) defines and uses the Pointer field. And the intent is
> specifically to be able to point past the end of the packet since the
> “offending” packet may not be able to fit into the reporting packet. Is
> there something specific that you think is being enabled by this draft and
> needs to be addressed?
> Regards
> Suresh
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------