Re: Validation of Packet Too Big Payload using Echo Request

Prabhakar Lakhera <plakhera@apple.com> Wed, 29 July 2020 18:16 UTC

Return-Path: <plakhera@apple.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 D30363A0E2A for <ipv6@ietfa.amsl.com>; Wed, 29 Jul 2020 11:16:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 GS_bQoF8ZarE for <ipv6@ietfa.amsl.com>; Wed, 29 Jul 2020 11:16:07 -0700 (PDT)
Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E92D83A0E02 for <6man@ietf.org>; Wed, 29 Jul 2020 11:16:07 -0700 (PDT)
Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 06TIFoa8062834; Wed, 29 Jul 2020 11:16:03 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=ZU4OjF67TgqrN2bJuMP9j5KQhYL6slYhHlqYTeNK77o=; b=eXs32dsrxIb1pHsBVm67bTDTNJNKx3oyoWNkNwEr7LPqvPZWaoTrLrdvejpQxQw8e2PM xI8YUAlsvENSqajA13nEikBLBSbCar7ZYpgw8F4MOTSJtwEUSA3LyPcLecVlB246f+VI pOBqQ2k2ur/aMPW14s4OroqoWDuYH6ptoEVcr0ABk38UUXNUyoC5sbecEvs+cSEjxea3 t6MmMN4GiSjmdp+A/YHyKaHIrS/o/RhLIopW3Rzd/nmLKsp61n1jlr3y28vaSXJMQwkp sy4xRng4vIGX9++4gncSakdR1XoPH7vIXQWyA36u6ZU24h1LUllZCi9bECxfyqdiMx4H 6g==
Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by nwk-aaemail-lapp03.apple.com with ESMTP id 32h4eptg4d-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 29 Jul 2020 11:16:03 -0700
Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QE800C0QTERQOJ0@rn-mailsvcp-mta-lapp01.rno.apple.com>; Wed, 29 Jul 2020 11:16:03 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QE800T00S6AB300@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Wed, 29 Jul 2020 11:16:03 -0700 (PDT)
X-Va-A:
X-Va-T-CD: eeb530a43afdbed44757bc67818dc989
X-Va-E-CD: f5c12aef7156e4eaffb3234cbd110187
X-Va-R-CD: f19c62e0b4b466324fa430a169bcbf72
X-Va-CD: 0
X-Va-ID: 23fb1065-0968-4951-9c03-2372ba045718
X-V-A:
X-V-T-CD: eeb530a43afdbed44757bc67818dc989
X-V-E-CD: f5c12aef7156e4eaffb3234cbd110187
X-V-R-CD: f19c62e0b4b466324fa430a169bcbf72
X-V-CD: 0
X-V-ID: 00e9c60e-1663-4f16-9893-ec9e7926b429
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-29_13:2020-07-29, 2020-07-29 signatures=0
Received: from localhost (unknown [17.234.122.5]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QE800STCTEP2E00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Wed, 29 Jul 2020 11:16:01 -0700 (PDT)
From: Prabhakar Lakhera <plakhera@apple.com>
Message-id: <DE991374-96A4-4CCC-9D5B-CC97CC5B361F@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_B0249A9B-91F6-49EB-BFA1-2B1171173312"
MIME-version: 1.0 (Mac OS X Mail 13.0 \(3649\))
Subject: Re: Validation of Packet Too Big Payload using Echo Request
Date: Wed, 29 Jul 2020 11:16:00 -0700
In-reply-to: <CAKD1Yr0MWME0Te6Sek5Kyi_TZT2sPo_HPoZce5rrU1oJSxsYBw@mail.gmail.com>
Cc: Shawn Zhang <yuanshan_zhang=40apple.com@dmarc.ietf.org>, 6MAN <6man@ietf.org>, Timothy Winters <twinters@iol.unh.edu>, Lorenzo Colitti <lorenzo@google.com>
To: Timothy Winters <tim@qacafe.com>
References: <26C02BD5-96CC-44D1-9CCB-00DE059D40D9@employees.org> <20200728114355.GF39464@shawns-mbp.lan> <CAJgLMKuzreN7Er5yebbxtZWwp-A1EXuqAYaF6ZgqF6NyhaPaFA@mail.gmail.com> <CAKD1Yr0MWME0Te6Sek5Kyi_TZT2sPo_HPoZce5rrU1oJSxsYBw@mail.gmail.com>
X-Mailer: Apple Mail (2.3649)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-29_13:2020-07-29, 2020-07-29 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/8naoD_KonR8QWTytSVvXPw4ONqQ>
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 18:16:11 -0000

Specially, given the proposed test expects node to be stateful with ICMPv6 Echo Replies.
That just opens up another window of exploit.

It is also not great that one can only provide “best effort” checks. That is do one thing for ICMPv6, check for tuple for UDP, additionally check for  sequence numbers for TCP.

Given the MTU has lower bound of 1280, the requirement should *not* be part of IPv6 ready logo as a must. The spec says it is a should, and that’s how it needs to be read.

Thanks! 

> On Jul 29, 2020, at 5:02 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
> 
> 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 <mailto: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 <mailto:info@ipv6ready.org>.
> 
> ~Tim
> 
> On Tue, Jul 28, 2020 at 7:48 AM Shawn Zhang <yuanshan_zhang=40apple.com@dmarc.ietf.org <mailto: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 <mailto:ipv6@ietf.org>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org <mailto:ipv6@ietf.org>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
> --------------------------------------------------------------------