Re: I-D Action:draft-ietf-6man-exthdr-01.txt

Thomas Narten <narten@us.ibm.com> Tue, 04 January 2011 14:27 UTC

Return-Path: <narten@us.ibm.com>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64F263A6BA7 for <ipv6@core3.amsl.com>; Tue, 4 Jan 2011 06:27:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.599
X-Spam-Level:
X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRAMxcB-Nnei for <ipv6@core3.amsl.com>; Tue, 4 Jan 2011 06:27:06 -0800 (PST)
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by core3.amsl.com (Postfix) with ESMTP id F41DC3A6855 for <ipv6@ietf.org>; Tue, 4 Jan 2011 06:27:05 -0800 (PST)
Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e4.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p04EBOWZ021114 for <ipv6@ietf.org>; Tue, 4 Jan 2011 09:11:31 -0500
Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id ED7DC728075 for <ipv6@ietf.org>; Tue, 4 Jan 2011 09:29:11 -0500 (EST)
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p04ETBef160980 for <ipv6@ietf.org>; Tue, 4 Jan 2011 09:29:11 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p04ETA65003564 for <ipv6@ietf.org>; Tue, 4 Jan 2011 12:29:11 -0200
Received: from cichlid.raleigh.ibm.com (sig-9-49-150-65.mts.ibm.com [9.49.150.65]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p04ET9cV003489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Jan 2011 12:29:10 -0200
Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p04ET81p006364; Tue, 4 Jan 2011 09:29:08 -0500
Message-Id: <201101041429.p04ET81p006364@cichlid.raleigh.ibm.com>
To: Fernando Gont <fernando@gont.com.ar>
Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt
In-reply-to: <4D2242E9.8040804@gont.com.ar>
References: <20101217234501.11691.81147.idtracker@localhost> <AANLkTi=Lr_4zOd=-DrAxic_t_o0MvyOoWPYmiktZZod2@mail.gmail.com> <63416880-97B6-4CE4-864A-1402DA977B5F@tony.li> <AA183326-2E70-4A23-83A7-9F96131ADFF4@tony.li> <4D113364.3050105@ericsson.com> <201101032040.p03KeE86005244@cichlid.raleigh.ibm.com> <4D223EC0.7020906@gmail.com> <4D2242E9.8040804@gont.com.ar>
Comments: In-reply-to Fernando Gont <fernando@gont.com.ar> message dated "Mon, 03 Jan 2011 18:43:05 -0300."
Date: Tue, 04 Jan 2011 09:29:08 -0500
From: Thomas Narten <narten@us.ibm.com>
X-Content-Scanned: Fidelis XPS MAILER
Cc: "ipv6@ietf.org" <ipv6@ietf.org>, Brian E Carpenter <brian.e.carpenter@gmail.com>, Suresh Krishnan <suresh.krishnan@ericsson.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 04 Jan 2011 14:27:08 -0000

Fernando Gont <fernando@gont.com.ar> writes:

> On 03/01/2011 06:25 p.m., Brian E Carpenter wrote:

> > The basic motivation for the present draft is clear:
> > 
> >>    However,
> >>    some intermediate nodes such as firewalls, may need to look at the
> >>    transport layer header fields in order to make a decision to allow or
> >>    deny the packet.  
> > 
> > That is, help middleboxes to violate e2e transparency and, furthermore,
> > allow unknown headers to cross those middleboxes. 

> I don't think this I-D will make a difference.

> From the POV of a firewall, unless it really wants a packet to
> pass-through, it will block it.

I think this is the crux of the problem. firewalls, by default,
discard stuff. They don't like the idea of allowing unknown or
"uncommon" things through.  Defining new options and expecting
firewalls to give them a blank check to go through I suspect is
wishful thinking.

And look at this from the perspective of someone who wants to deploy a
new option. If 80% of the firewalls allow the new option through, will
this be good enough for deployment? Doubtful. What about 98%
cooperation from firewalls? Again, quite possibly not.

Unless this document is widely implemented in practice, it's far from
clear it is useful. We've seen time and time again that deploying
something new is a non-starter if there are key parts of the
infrastructure that don't support or allow it.

I remain skeptical that this draft solves a real problem in a
meaningful way.

Thomas