Non-Last Small IPv6 Fragments

Timothy Winters <twinters@iol.unh.edu> Thu, 10 January 2019 15:33 UTC

Return-Path: <twinters@iol.unh.edu>
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 D950412958B for <ipv6@ietfa.amsl.com>; Thu, 10 Jan 2019 07:33:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu
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 91hX4iub0fVb for <ipv6@ietfa.amsl.com>; Thu, 10 Jan 2019 07:33:35 -0800 (PST)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 D6A2A1200B3 for <ipv6@ietf.org>; Thu, 10 Jan 2019 07:33:34 -0800 (PST)
Received: by mail-wm1-x32b.google.com with SMTP id m22so12549725wml.3 for <ipv6@ietf.org>; Thu, 10 Jan 2019 07:33:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:from:date:message-id:subject:to; bh=Wk2csCx32Zkp3fd055mdqasqj3ck/coG23xqaAUnm0c=; b=eumJ7E/6zcKJhZ4JC1dLVF7LYDjSyfRy6UZNU46t6gAxs77P4aPb3VxgbTZdoAUMT0 WIrkJMzuW22/AE+2VWzJicTo83J0iaQM0RaJPKt/X/Y0yFIDEXYxqhocVxXhCqGbky6x ju1FnAOgjTdcTIpQ5p4RRvQIZlAk+zPeJcZ8c=
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=Wk2csCx32Zkp3fd055mdqasqj3ck/coG23xqaAUnm0c=; b=drEkIy0PrLQn/HLqYUG0yp6cCvIBPfFUGLqCEKI8aelYlq7xAdSvNYZ73JtytJiXwJ VgW8FIFu4pwB+Wq4LuoAllMF5oibLeBgazcuKRi7iP2/5UNvtCD29yJ96LSzBMIDDrNh lmbXRxqxe4w4MLNMf3ONd+eyC1WJcBQkS+Qtj1EdC60bSZBMoU8eadwdIrGBb9SkJZ6s eSKbBIbMXkz2m+kxQg1Skctd3vOIl9K5iayaNa54J4xmVVkyE3WhhykLIwV/BGpWx4yf +BEt2j86gq8VVUygH/WrJyf1oxHKw00GMXpisEshQNU+urXwRvUp5QUgoPpGyi0ipE3R FnQA==
X-Gm-Message-State: AJcUukeXLLVy++eyqRlXZmred3UujopaLBX9pd3hpVQ1vLOU0v8TUS1N cn8xO46L6i8v331Dk8tWEjqtggOOiKsi9GrRLkrerLk8Y2fO6Q==
X-Google-Smtp-Source: ALg8bN79r6lm02ziYHZ1icFxHITW7IofkfnqgzhAksDi3jDNMFvXvHP236diHTBk0ASEDvh3Ks2Hl0s45Y9wMlNnjj0=
X-Received: by 2002:a1c:f71a:: with SMTP id v26mr9583760wmh.131.1547134412639; Thu, 10 Jan 2019 07:33:32 -0800 (PST)
MIME-Version: 1.0
From: Timothy Winters <twinters@iol.unh.edu>
Date: Thu, 10 Jan 2019 10:33:20 -0500
Message-ID: <CAOSSMjV0Vazum5OKztWhAhJrjLjXc5w5YGxdzHgbzi7YVSk7rg@mail.gmail.com>
Subject: Non-Last Small IPv6 Fragments
To: 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000015f080057f1c4dee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/BHFLB25KXIfbiwljn-CGHPMabwo>
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: Thu, 10 Jan 2019 15:33:38 -0000

We have encountered a potential Interoperability issue at the UNH-IOL while
running some testing.  The issue is around fragments.

The Linux Kernel updated based on the following CVE:

https://nvd.nist.gov/vuln/detail/CVE-2018-5391.

The fix was to reject IPv6 fragments less than 1280 that aren't last
fragment.  Section 4.5 of RFC 8200 allows for sending any fragment for
fragments as long they add up to the original packet.  This means that an
implementation that generates a non-last fragments with a size then 1280,
will be dropped by the updated kernel.

I'm willing to write a draft about the expected behavior, but before I do
that I wanted to get the working group feedback on if we think an
implementation should drop non-last fragments less then 1280.

~Tim