Re: Validation of Packet Too Big Payload using Echo Request

Lorenzo Colitti <lorenzo@google.com> Wed, 29 July 2020 12:02 UTC

Return-Path: <lorenzo@google.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 4FAE43A09E7 for <ipv6@ietfa.amsl.com>; Wed, 29 Jul 2020 05:02:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 UvdBxLHX8hOv for <ipv6@ietfa.amsl.com>; Wed, 29 Jul 2020 05:02:50 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 C2F3D3A09DB for <6man@ietf.org>; Wed, 29 Jul 2020 05:02:50 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id e64so24172908iof.12 for <6man@ietf.org>; Wed, 29 Jul 2020 05:02:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xFFZ34I1knSOVEHapWiy4xIEidPS+e7OalI9+ecoE3k=; b=tU+NffotzSVjT1yEZ7WlGc0IcD4RG/6XW64HwjPMSid7BpNTMIC1J3CIKTwPmiDywW l4Zo7d5CSElrFPilr/6DAOiBDbmg+Ilmpbm3yRnnDssdlSfz7M4i+BFXB2EwyztjQesB 7v5Cqm3+oun6lQVlnQQ5m2C/8R4MC5t7O09OcoAx7otI5/Gbw11K9jcsfmh/LriIoYvw 0iPwbwXsfjN8TWrki8hfuFAfs3/KXdEY0l22Iv/DtSzbxbB18tvmbaR72XbMs4pQoWMt go4/19496P1hYoxaArZ4to/0iBxiYI0Zsn2sSIUbbwZ0FCP3bkGSB6zlv2eUKNCz5Sa6 hwIQ==
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=xFFZ34I1knSOVEHapWiy4xIEidPS+e7OalI9+ecoE3k=; b=WLohAv6LxuRfP/TE3EZ0tRXkFWbzH5HMb/bCQwwgzJ0b7fDLV0y7FQ+kdeNmXw9kyO L6cAcEX3SjfFRqJ2krqvdRcOnOhF2TzGiYSMPwZW4wF68cG3sP+swQZF/rBW+87lEcUA TQYm+6ZWdj/c/I+btlVNTapMXMJAfYx99VJ3c7fW072y6zvdDAYFRyFMV/YSUvSsUT1I ahBKFZYPGOSAG6E5hlEbUvFnin//22iqWAsHUML3+f99iEu5i5bRcP13Y2fZ6n3v/w93 3t3IjPzJa/9Jaf/0uJrPid0q2UOjDY0BsfAOrJ9kXIsf5dsptn3nu9ZoH39cQXiCDLj+ MQaQ==
X-Gm-Message-State: AOAM530DaiMB1o17EFdvcx3UbC0KYgJBHowi8a1aBK/Ah11n215eq3Ko YScPyjtF44b6F03VFGwhFFXS0qi97D9ckXRJafMa/+6H
X-Google-Smtp-Source: ABdhPJzpEj95gCgsu97lgwJ5B01wHKqr8qlTKGgzEvQUgItSB5g1Weo2H2tMAGWBXREDFmIjjqn8nhtXhmwyHOcsNvU=
X-Received: by 2002:a5e:980f:: with SMTP id s15mr18651785ioj.5.1596024169861; Wed, 29 Jul 2020 05:02:49 -0700 (PDT)
MIME-Version: 1.0
References: <26C02BD5-96CC-44D1-9CCB-00DE059D40D9@employees.org> <20200728114355.GF39464@shawns-mbp.lan> <CAJgLMKuzreN7Er5yebbxtZWwp-A1EXuqAYaF6ZgqF6NyhaPaFA@mail.gmail.com>
In-Reply-To: <CAJgLMKuzreN7Er5yebbxtZWwp-A1EXuqAYaF6ZgqF6NyhaPaFA@mail.gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Wed, 29 Jul 2020 21:02:38 +0900
Message-ID: <CAKD1Yr0MWME0Te6Sek5Kyi_TZT2sPo_HPoZce5rrU1oJSxsYBw@mail.gmail.com>
Subject: Re: Validation of Packet Too Big Payload using Echo Request
To: Timothy Winters <tim@qacafe.com>
Cc: Shawn Zhang <yuanshan_zhang=40apple.com@dmarc.ietf.org>, 6MAN <6man@ietf.org>, Timothy Winters <twinters@iol.unh.edu>, plakhera@apple.com
Content-Type: multipart/alternative; boundary="000000000000b3069a05ab93557a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/buN5r_FobUs5LYfO1qUgrM9hrVI>
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: Wed, 29 Jul 2020 12:02:54 -0000

I'm not sure that the desired behaviour is reasonably implementable.
Wouldn't it require the sending node to keep state on all packets it had
ever sent? For how long?

The implementation can relatively easily check if a PTB matches an
*existing* socket. But what if the following happens?

1. App opens UDP socket, sends packet.
2. App closes socket.
3. PTB arrives for packet in step #1.
4. App opens socket on same port again, sends identical packet again.

If the stack rejects the packet in #3, arguably it makes things worse. But
accepting it is difficult without keeping state on sockets after they are
closed, which is both ill-defined (how long do you need to keep the state?)
and potentially expensive / exposing a DoS vector.

On Tue, Jul 28, 2020, 21:00 Timothy Winters <tim@qacafe.com> wrote:

> Hi Shawn,
>
> If you are referring to the IPv6 Ready Logo Core Test Specification for
> this, we have a possible problem for this validation test case for devices
> that don't track ICMPv6 connections.
>
> *"Possible Problems: * If the device under test does not support tracking
> connections for ICMPv6 this test case may be omitted."
>
>
> If you have other questions about IPv6 Ready please feel free to take this
> to the info@ipv6ready.org.
>
>
> ~Tim
>
> On Tue, Jul 28, 2020 at 7:48 AM Shawn Zhang <yuanshan_zhang=
> 40apple.com@dmarc.ietf.org> wrote:
>
>> Hi Ole,
>>
>> I am reviving this thread.
>>
>> >> Frankly, I think for compliance this should be treated as a *SHOULD*
>> and not as a MUST.
>>
>> > Yes, I think that's a correct interpretation.
>> > That's what 8201 says too. "Nodes should appropriately validate..."
>>
>> Since RFC8201 says “SHOULD” instead of “MUST”, should this test be
>> removed from the compliance test as it is not a mandatory behavior?
>>
>> IMHO, since the smallest packet size is capped at 1280, it won't cause
>> too much risk  even if we don't verify it using Echo Request here.
>>
>> Bests,
>> Shawn
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>