Re: I-D Action: draft-gont-6man-ipv6-universal-extension-header-01.txt

Fernando Gont <fgont@si6networks.com> Wed, 07 May 2014 10:57 UTC

Return-Path: <fgont@si6networks.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 0F6701A06C9 for <ipv6@ietfa.amsl.com>; Wed, 7 May 2014 03:57:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, 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 oK0u3VHwBehc for <ipv6@ietfa.amsl.com>; Wed, 7 May 2014 03:57:20 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8E41A064E for <ipv6@ietf.org>; Wed, 7 May 2014 03:57:19 -0700 (PDT)
Received: from [187.185.71.234] (helo=[172.17.68.218]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <fgont@si6networks.com>) id 1WhzXG-0005ZD-Rw; Wed, 07 May 2014 12:57:15 +0200
Message-ID: <536A0D7B.1070606@si6networks.com>
Date: Wed, 07 May 2014 05:39:55 -0500
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, 6man <ipv6@ietf.org>
Subject: Re: I-D Action: draft-gont-6man-ipv6-universal-extension-header-01.txt
References: <20140408103907.23507.46057.idtracker@ietfa.amsl.com> <536317AE.1090500@gmail.com>
In-Reply-To: <536317AE.1090500@gmail.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/RqLQZAyOzyzU88jeYzHgF63hJlE
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: Wed, 07 May 2014 10:57:22 -0000

Hi, Brian,

On 05/01/2014 10:57 PM, Brian E Carpenter wrote:
> 
> I've finally understood what's been bothering me about this draft.
> Actually, two things:
> 
> 1. If a node (regardless of whether it's the destination host,
> or an intermediate node such as a firewall) has a policy
> of discarding packets with an unknown extension header
> or an unknown transport protocol, it *doesn't matter* that
> it can't distinguish them. The packet is discarded anyway.
> 
> Comment on that: In either case, this discard by a host is
> consistent with RFC2460 (even as updated by RFC7045). 

While I agree that it is consistent with RFC2460, that also implicitly
means that new EHs are not incrementally deployable. Not only because of
firewalls, but also because of the hosts themselves. (i.e., if I send
you my packets with my sihny new EH then, if you don't understand it,
you'd drop the packet).

(another way to see it would be to assume that the reason for which
RFC2460 says so is because it didn't define a uniform format for EHs in
the first place?)


> In either
> case, it's what we would expect a firewall to do if it has the
> usual sort of paranoid policy, and that again is consistent
> with RFC7045.

I'm not sure I'd agree. in v4, some firewalls do not just filter packets
for the options they contain, but they do filter based on the {src ip,
dst ip, protocol, src port, dst port}



> 2. Given that argument, I think this draft should consider a
> 4th possible solution: Do Nothing. I think it's a valid option.

At the very least 6564 should probably be updated, or at least a
clarification issued. -- quite a few of us had assumed that as a result
of RFC6564, one could parse past unknown EH -- which is certainly not
possible.



> Nits: I don't see why this draft is tagged as Standards Track
> and Updates 2460. It's an informational discussion.

It's std track. And the "update" tag is because the UEH would be part of
the v6 specification (not to mention that otherwise it would be
virtually impossible for an IPv6 implementer to spot this document in
the first place).



> Please change the title of the draft. At the moment it has
> the same title as draft-gont-6man-rfc6564bis.

Will do.

Thanks!
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492