Re: Usable extension headers [Re: New Version Notification for draft-voyer-6man-extension-header-insertion-08.txt]

Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> Thu, 28 November 2019 14:49 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.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 55DD7120886 for <ipv6@ietfa.amsl.com>; Thu, 28 Nov 2019 06:49:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 ZWJbnNZI_xS6 for <ipv6@ietfa.amsl.com>; Thu, 28 Nov 2019 06:49:07 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (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 3827A12022E for <ipv6@ietf.org>; Thu, 28 Nov 2019 06:49:07 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1iaL6N-0000FvC; Thu, 28 Nov 2019 15:49:03 +0100
Message-Id: <m1iaL6N-0000FvC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Subject: Re: Usable extension headers [Re: New Version Notification for draft-voyer-6man-extension-header-insertion-08.txt]
From: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <CALx6S346p=M09ZPY_xM2X3gkPp_0KUVZU_u4UeLUagomRnjhPw@mail.gmail.com> <79d22e5a-0145-9ad9-e965-d3744b58c3bf@gmail.com> <d791c9eee34c4e019292fc74d629217c@boeing.com> <5d2af468-be61-d2ca-5bf0-35d5f71fdb6c@gmail.com> <6A41AB04-F56B-46E1-8B8B-3E24B928A042@jisc.ac.uk> <1B629A88-AE10-4F65-8D3D-FD2702B6D63D@employees.org> <363DE16C-20CD-485C-9846-437984E7600E@jisc.ac.uk> <7405ECF9-2736-4DB5-BA5E-F1F0149A3DC8@employees.org> <20191128133739.GB83199@ernw.de> <0DBC1A8B-BFA3-41E4-BD36-41B190F413F7@employees.org> <20191128142431.GE82618@ernw.de>
In-reply-to: Your message of "Thu, 28 Nov 2019 15:24:31 +0100 ." <20191128142431.GE82618@ernw.de>
Date: Thu, 28 Nov 2019 15:49:03 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/_GLbG5IyoUznDtU0uh2GF64RF6w>
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, 28 Nov 2019 14:49:09 -0000

In your letter dated Thu, 28 Nov 2019 15:24:31 +0100 you wrote:
>iirc the DestOptions packets sent as part of the experiments being the basis f
>or RFC 7872 were sent with PadN options. As for those RFC 8200 states:
>"These padding options must be recognized by
>   all IPv6 implementations"

There is a long standing practice in firewall design of throwing out
everything you don't need.

Obviously, that has significant negative effects on how internet protocols
can evolve. But I can also understand the need to have a secure system and
not wait for hardly used options to be used as an attack vector.

And, if a single firewall has to protect a collection of hosts, then parsing
all possible combinations of extension headers at wire speed may also be
an issue. Is it worth investing in such capabilities if all packets you
actually expect have no extension headers at all?