IETF Logo Mail Archive

Re: IPv6 payload length check?

Michael Richardson <mcr@sandelman.ca> Tue, 04 February 2020 13:45 UTC

Return-Path: <mcr@sandelman.ca>
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 4E3AB1200CD for <ipv6@ietfa.amsl.com>; Tue, 4 Feb 2020 05:45:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.436
X-Spam-Level: *
X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 La0Vy4Jfig2Q for <ipv6@ietfa.amsl.com>; Tue, 4 Feb 2020 05:45:30 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 123D31200C3 for <ipv6@ietf.org>; Tue, 4 Feb 2020 05:45:29 -0800 (PST)
Received: from dooku.sandelman.ca (ip5f5bd76d.dynamic.kabel-deutschland.de [95.91.215.109]) by relay.sandelman.ca (Postfix) with ESMTPS id 7BE981F45A for <ipv6@ietf.org>; Tue, 4 Feb 2020 13:45:27 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 27BDE1142; Tue, 4 Feb 2020 08:45:09 -0500 (EST)
From: Michael Richardson <mcr@sandelman.ca>
To: 6man WG <ipv6@ietf.org>
Subject: Re: IPv6 payload length check?
In-reply-to: <CAO42Z2yDrdQBGyk97f3Op7KtRRfXjnYyAV3=qGY4E03+P2L3cw@mail.gmail.com>
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>
Comments: In-reply-to Mark Smith <markzzzsmith@gmail.com> message dated "Tue, 04 Feb 2020 19:40:45 +1100."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 25.1.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Tue, 04 Feb 2020 14:45:09 +0100
Message-ID: <2640.1580823909@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/SK9vUWQJyDMOpIF5eI1-ymQ-BJY>
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 13:45:32 -0000

Mark Smith <markzzzsmith@gmail.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.

    > The fault with the packet will be detected at the final destination and
    > dealt with there.

Yes, I agree that it will get discarded.  Maybe... Probably?

When the hardware sends the packet, will it send it with the correct L2 frame
size? (i.e. equal to the L3 packet length)
If so, what will it put at the end of the packet?
Will it clear those bytes?

If it doesn't, then it might send stuff from a previous transmission.

Note that the inverse case, where L3.length < L2.length is also interesting,
because if forwarded according to L2.length, then there is a covert channel
opportunity.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

v2.23.0 | Report a Bug | By Email