Re: IPv6 payload length check?

Mark Smith <markzzzsmith@gmail.com> Tue, 04 February 2020 23:14 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE83120144 for <ipv6@ietfa.amsl.com>; Tue, 4 Feb 2020 15:14:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.397
X-Spam-Level:
X-Spam-Status: No, score=-0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 zDUXUKJ8PPRI for <ipv6@ietfa.amsl.com>; Tue, 4 Feb 2020 15:14:25 -0800 (PST)
Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (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 C3CA71200B7 for <ipv6@ietf.org>; Tue, 4 Feb 2020 15:14:25 -0800 (PST)
Received: by mail-oi1-x233.google.com with SMTP id b18so62138oie.2 for <ipv6@ietf.org>; Tue, 04 Feb 2020 15:14:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bjawSQxfF5Ij0OlDq3b6zjMPuZnf0ssW09Mr2Vck61U=; b=Bi3/tTOdHuBanqewA/DhYQC5M+S05EuJ7RkjcKAwG2WBkyEjC+jqb0K+pfu0KA/CTs 1/OBaUaVOf4Iq8gAvqMaUlUghPXHOP4A5r3FfW4GeC8OMnCln9k5QgXGBXTAFPpLPcE4 9bv4PkkVtqSyouOdId+Bkn3VesrRxWXwAoWGWnpw/eqiKYLpIWf1LF5hWX4dnbH+XlUO AN8AURQY9qLXuO6DyMdvsJKBK/G0l+Do3vIhNw5/bsV/x6WJMzXZki6pfNCS8ohUFN4B aLs7kxuvL2ZJy/paBl/nFmqcfBhcoTDC6x2w0qhoYBho7lXqwUXtgS0VzfZuyYnhQrLY xTzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bjawSQxfF5Ij0OlDq3b6zjMPuZnf0ssW09Mr2Vck61U=; b=sCThadFyoE54XHpeO1ry5MZw+RjcYxThqoWuqfV7+1QC/BFh4vT1AcXQAJuXtOBIOB Da302Lsaa4tUrxeU85zge5JM4r0qdpA8GaVGW/TExHOl8wK55rTezLrkAxMfEo5Iikhe Qitq1PnZnGi1Zyc0s2OoWPDPxlEu31Nfh2+ROjf8Ecwjk06m5BT1DRjXg8PAMabCoXue RXM7CfgVL8sF+AG/a+L87vEItamEcT+CDeAAlJ4ywoLNy9ObTjtffiKamOUBanAbeD6N DHk5bJe6k+Ki15kPPSuwDJ1SHQHMcbAC/lpt18ZAmUVise6EFUsYIU8bkw4dCbVz6+1l lNjw==
X-Gm-Message-State: APjAAAUrzG4hVkeNYt2A40zzGNEqBSy7U5yc4npSfj7IzmHk+O0SmXib B1UqeaM+tjwVNKNIivDeBf1V9Ob7dXK3DFMJ5nk=
X-Google-Smtp-Source: APXvYqz1xTp1xQmX/Oia/67F1LvTdfTpstzyrJAIuQS6hAHd8seMLGdwFp9GVI4HYy6smztir3+Qe4H+e7E8QEpAXm8=
X-Received: by 2002:aca:5746:: with SMTP id l67mr1013001oib.60.1580858065080; Tue, 04 Feb 2020 15:14:25 -0800 (PST)
MIME-Version: 1.0
References: <90342768-7f25-b9dd-eeae-29db6045b40a@intl.att.com> <77f55628-6f9d-d06a-4e38-f84d76e716bb@intl.att.com> <CAMGpriWVN0EGLz5PyeyL5LTo_+A1i+xHCD6kw0E0pCRCcGcY2g@mail.gmail.com> <21c14789-73b8-1347-98bf-9c70c3d31e76@intl.att.com> <CAO42Z2yDrdQBGyk97f3Op7KtRRfXjnYyAV3=qGY4E03+P2L3cw@mail.gmail.com>
In-Reply-To: <CAO42Z2yDrdQBGyk97f3Op7KtRRfXjnYyAV3=qGY4E03+P2L3cw@mail.gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Wed, 05 Feb 2020 10:14:12 +1100
Message-ID: <CAO42Z2w8LrGfhKTQoQTLh6pq1RyXoQ7in-QTh2Se8VH3sCRTFw@mail.gmail.com>
Subject: Re: IPv6 payload length check?
To: "Aitken, Paul" <paul.aitken@intl.att.com>
Cc: Erik Kline <ek.ietf@gmail.com>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000068d73e059dc83300"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/3A523uwGNaLD-DoasEmM9n07yds>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Feb 2020 23:14:27 -0000

On Tue, 4 Feb 2020, 19:40 Mark Smith, <markzzzsmith@gmail.com> wrote:

>
>
> On Tue, 4 Feb 2020, 18:43 Aitken, Paul, <paul.aitken@intl.att.com> wrote:
>
>> Thanks Eric.
>>
>> In this case the packet is *not* larger than the MTU of the outgoing
>> link. Rather a packet has been received (or possibly generated locally)
>> with an IPv6 payload length greater than the link layer frame size.
>>
>> Probably this packet should not be forwarded.
>>
>
> It's better to forward it without checking.
>
> These packets with this fault are going to be rare. Checking each and
> every packet for this rare problem at each forwarding hop would impact
> forwarding performance.
>


Thinking a bit more, they'll be rare at forwarding nodes.

However as Brian said it would be a bug at the API layer or below on the
sending node. Either the outgoing MTU vs. the packet size check failed to
occur correctly, or that check passed and then something broke within the
link layer encapsulation.

That would probably mean most if not all packets emitted by this node on
this interface would be effected by the bug, making it obvious where the
fault is occurring. Signs would be high or entire packet loss from this
node, and application connection failures visible to the end-user.


> The fault with the packet will be detected at the final destination and
> dealt with there.
>
>
> However, I couldn't find anything to say that it's invalid.
>>
>
> When could it ever be valid?
>
> With protocol specs, everything unspecified is implicitly invalid, because
> it is out of specification or unspecified behaviour.
>
>
>
>> Thanks,
>> P.
>>
>>
>> On 03/02/2020 22:05, Erik Kline wrote:
>>
>> Interestingly, 8200 contains this text in the Routing Header section
>> (4.4):
>>
>> """
>>    If, after processing a Routing header of a received packet, an
>>    intermediate node determines that the packet is to be forwarded onto
>>    a link whose link MTU is less than the size of the packet, the node
>>    must discard the packet and send an ICMP Packet Too Big message to
>>    the packet's Source Address.
>> """
>>
>> Really that text would seem to apply even if a routing header is absent.
>> 4443 on PTBs (3.2) has the text you might be looking for:
>>
>> """
>>    A Packet Too Big MUST be sent by a router in response to a packet
>>    that it cannot forward because the packet is larger than the MTU of
>>    the outgoing link.
>> """
>>
>> On Mon, Feb 3, 2020 at 7:31 AM Aitken, Paul <paul.aitken@intl.att.com>
>> wrote:
>>
>>> Can anyone point me to a standards reference for the check to validate
>>> that the IPv6 payload length is less than or equal to the link layer
>>> frame size upon forwarding a packet?
>>>
>>> Thanks,
>>> Paul
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=ZfTZz_O9E1tN4KFtMYO2ZkKk5U5-6SlI-21vZEhzDuU&m=qBignlV2D2HjQ1OG98CXIFMbZryHbieyfesxKE4ZOfg&s=Hcp5fCXJd8pXcMtmqOUaw179roZQXSQntvE-zFdQYbY&e=>
>>> --------------------------------------------------------------------
>>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>