IETF Logo Mail Archive

Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices

Ole Troan <otroan@employees.org> Fri, 19 June 2015 07:56 UTC

Return-Path: <otroan@employees.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACDB21A854D for <v6ops@ietfa.amsl.com>; Fri, 19 Jun 2015 00:56:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Hi92-PGMaJJI for <v6ops@ietfa.amsl.com>; Fri, 19 Jun 2015 00:56:22 -0700 (PDT)
Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AB301A86E0 for <v6ops@ietf.org>; Fri, 19 Jun 2015 00:56:22 -0700 (PDT)
Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 0A1406310; Fri, 19 Jun 2015 00:56:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=TY7ihp0bxUtspBgVzND4NtIU9WE=; b= VnBIrjVGdOOcS9tk03wcgJakhkYKlOM+dj7GXLmRZAabPAqlP1MxUODgcz3B9LyT Qxnyx1y8rXqCCUGuuarHPYAlAhTW9K8xNobfRxUeNJU2jCUIZczFDhW+I19QHghs VKHu50jY/W44A395WsBVFmv13raG2s4t+aHcFvycBBQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=A6wOODeT3jDFaYHoXa96FWI1ID nv5hxAXgJtpo1ZxYFIZ7rQOIq8hNl9NkTBkUZD9fLkqDqb218bZP0sX5G8eTdG6R TI0w3KT2END7cPC3vvOKtxwFSjE695G5uX9QwVdc9yjTk+AvfRgJBq0bzLmDFjP4 mEw6EgEZz7pA+zxrI=
Received: from gomlefisk.localdomain (unknown [173.38.220.39]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id BA1156240; Fri, 19 Jun 2015 00:56:20 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by gomlefisk.localdomain (Postfix) with ESMTP id 2D7DF4784CA4; Fri, 19 Jun 2015 09:56:21 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
Content-Type: multipart/signed; boundary="Apple-Mail=_91E84A0C-FC13-4282-AE3D-2BFE9ED97AC1"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.5
From: Ole Troan <otroan@employees.org>
In-Reply-To: <20150619.093911.74722344.sthaug@nethelp.no>
Date: Fri, 19 Jun 2015 09:56:20 +0200
Message-Id: <4B24F577-E5F1-4E44-95BA-AEFD502C6BC2@employees.org>
References: <505DC30B-8ED1-4C75-A13B-FAC9D4E5348C@cisco.com> <20150618220058.GP67883@Space.Net> <CE57FBE0-B6C0-423D-A7F6-4FFF20FD2C4A@employees.org> <20150619.093911.74722344.sthaug@nethelp.no>
To: sthaug@nethelp.no
X-Mailer: Apple Mail (2.2102)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/zYusOJNyxvTwH9xpE-q47lXB8Wk>
Cc: v6ops@ietf.org, ipv6-wg@ripe.net
Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jun 2015 07:56:23 -0000

>>>> Tell me this. Would you be happier if the fragmentation rule said that the first fragment had to contain the entire IPv6 header, plus the transport layer header (for ACL support)? I think Fernando would support such a statement (I think I have "heard" him make such a statement).
>>> 
>>> It would certainly make *me* happier�$,1s&
>> 
>> done.
>> RFC7112.
> 
> As I wrote in another mail,
> 
>> It may be relevant to ask for RFC 7112 support next time we're doing
>> an equipment RFQ (in a few years).
> ...
>> But until RFC 7112 support is available, I believe we will
>> see a significant amount of breakage for IPv6 extension headers - and
>> header chains will be limited to significantly less than 1280 bytes.
> 
> And until such support is available, we have to deal with the current
> mess. Which may imply more filtering than some people would like.

I don’t think that follows.

cheers,
Ole

v2.23.0 | Report a Bug | By Email