Re: A problem with RFC 6465's Uniform Format for Extension Headers

Thomas Narten <narten@us.ibm.com> Thu, 06 February 2014 12:22 UTC

Return-Path: <narten@us.ibm.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA6E1A03B7 for <ipv6@ietfa.amsl.com>; Thu, 6 Feb 2014 04:22:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.436
X-Spam-Level:
X-Spam-Status: No, score=-7.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
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 TErpSTU9wZRE for <ipv6@ietfa.amsl.com>; Thu, 6 Feb 2014 04:22:01 -0800 (PST)
Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by ietfa.amsl.com (Postfix) with ESMTP id 410B21A03C9 for <6man@ietf.org>; Thu, 6 Feb 2014 04:22:01 -0800 (PST)
Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <6man@ietf.org> from <narten@us.ibm.com>; Thu, 6 Feb 2014 05:22:00 -0700
Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e39.co.us.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 6 Feb 2014 05:21:58 -0700
Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id A1EA519D8042 for <6man@ietf.org>; Thu, 6 Feb 2014 05:21:57 -0700 (MST)
Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by b03cxnp08026.gho.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s16CLcI71114474 for <6man@ietf.org>; Thu, 6 Feb 2014 13:21:38 +0100
Received: from d03av05.boulder.ibm.com (localhost [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s16CLuVr031369 for <6man@ietf.org>; Thu, 6 Feb 2014 05:21:57 -0700
Received: from cichlid.raleigh.ibm.com (dyn9050017179.mts.ibm.com [9.50.17.179] (may be forged)) by d03av05.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s16CLt48031318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Feb 2014 05:21:56 -0700
Received: from cichlid.raleigh.ibm.com.us.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id s16CLn2u020722; Thu, 6 Feb 2014 07:21:50 -0500
Date: Thu, 06 Feb 2014 07:21:49 -0500
Message-ID: <m3k3d82zz6.wl%narten@us.ibm.com>
From: Thomas Narten <narten@us.ibm.com>
To: Fernando Gont <fgont@si6networks.com>
Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers
In-Reply-To: <52F1BD1F.2080007@si6networks.com>
References: <20140130230740.25350.9524.idtracker@ietfa.amsl.com> <52EAF63A.7050108@si6networks.com> <52F1B8CE.4070803@ericsson.com> <52F1BD1F.2080007@si6networks.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (Gojō) APEL/10.8 EasyPG/1.0.0 Emacs/23.1 (x86_64-redhat-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
X-TM-AS-MML: disable
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 14020612-9332-0000-0000-000003042A7D
Cc: "C. M. Heard" <heard@pobox.com>, Tim Chown <tjc@ecs.soton.ac.uk>, "6man@ietf.org" <6man@ietf.org>, Suresh Krishnan <suresh.krishnan@ericsson.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 06 Feb 2014 12:22:03 -0000

At Wed, 05 Feb 2014 01:25:03 -0300, Fernando Gont wrote:
> 1) If this problem remains un-addressed, then it's impossible to
> differentiate between new upper-layer headers (e.g. a new transport
> protocol) and new extension headers. Since such new extension headers
> might be leveraged for malicious purposes, the end-result is that
> middle-boxes are going to block *everything* (see RFC7045), which means:
> 
>   + no new extension headers
>   + no new transport protocols
> 
> ... so I think we really don't want to go there.

But we are already there. Folk won't deploy anything other than
TCP/UDP because NAT won't deal with it. That has already been reality
and is the reason that other or new transport protocols appear to be
virtually undeployable today.

Reality is that existing middleboxes tend to process what they
understand and have been explicitely coded to deal with. They just
punt on anything else because that is the easiest/safest thing to do.

I see little that we can do to change that.

Thomas