Re: Conflicting requirements for sending ICMPv6 and EH scan?

Ole Troan <otroan@employees.org> Sun, 26 May 2019 11:12 UTC

Return-Path: <otroan@employees.org>
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 AA4AF12015F for <ipv6@ietfa.amsl.com>; Sun, 26 May 2019 04:12:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 Rno232PpSBaD for <ipv6@ietfa.amsl.com>; Sun, 26 May 2019 04:12:30 -0700 (PDT)
Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B93CB120048 for <ipv6@ietf.org>; Sun, 26 May 2019 04:12:30 -0700 (PDT)
Received: from [10.229.208.172] (77.16.64.172.tmi.telenormobil.no [77.16.64.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 889CCFECC2BD; Sun, 26 May 2019 11:12:28 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
Subject: Re: Conflicting requirements for sending ICMPv6 and EH scan?
From: Ole Troan <otroan@employees.org>
X-Mailer: iPhone Mail (16E227)
In-Reply-To: <CALx6S37wNpe=XweKh=Y6ARZ1nfjvySmK=km6+_UTDVFPujp7bA@mail.gmail.com>
Date: Sun, 26 May 2019 13:12:24 +0200
Cc: 6man <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C5EF34CD-8408-490F-A460-6D392495D218@employees.org>
References: <CALx6S37wNpe=XweKh=Y6ARZ1nfjvySmK=km6+_UTDVFPujp7bA@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/PLr8zK51VycAmxTaJ3qU63XgUAc>
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: Sun, 26 May 2019 11:12:32 -0000

Hi Tom,

The rfc4443 text you are quoting is from section 2.4. That deals with processing rules for ICMP messages. That is, you already know you have received an ICMP at that point. 

If you are looking at the corner case where someone sends you an ICMP message with an unparsable extension header chain, then you have to treat that as any other packet with unknown headers. 

Cheers 
Ole

> On 24 May 2019, at 22:58, Tom Herbert <tom@herbertland.com> wrote:
> 
> Hello,
> 
> I am updating the references in Linux stack from RFC2460 to RFC8200. I
> came across the ipv6_skip_exthdr function which contains a long, and
> somewhat apologetic, comment that this function is purposely walking
> over all the IPv6 extension headers for the purpose of locating the
> transport layer protocol and hence violates RFC2460 (RFC8200):
> 
> "Therefore, extension headers must be processed strictly in the order
> they appear in the packet; a receiver must not, for example, scan
> through a packet looking for a particular kind of extension header and
> process that header prior to processing all preceding ones."
> 
> The need for this function arises from the requirement of RFC4443:
> 
> "(e) An ICMPv6 error message MUST NOT be originated as a result of
>       receiving the following:
> 
>       (e.1) An ICMPv6 error message."
> 
> So, for instance, if we are sending an ICMP error because of a problem
> with an extension header, we need to walk (process) the  other
> extension headers to determine if the transport is ICMPv6 and if it is
> then not send the error.
> 
> The comment is over fourteen years old! I would like to resolve
> somehow as not being a violation of standard. Any ideas how to do
> that?
> 
> Thanks,
> Tom
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------