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

Mark ZZZ Smith <markzzzsmith@yahoo.com.au> Fri, 19 June 2015 09:14 UTC

Return-Path: <markzzzsmith@yahoo.com.au>
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 3019A1A701E for <v6ops@ietfa.amsl.com>; Fri, 19 Jun 2015 02:14:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.102
X-Spam-Level: *
X-Spam-Status: No, score=1.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 f4V6LHJcLRzi for <v6ops@ietfa.amsl.com>; Fri, 19 Jun 2015 02:14:12 -0700 (PDT)
Received: from nm25-vm1.bullet.mail.bf1.yahoo.com (nm25-vm1.bullet.mail.bf1.yahoo.com [98.139.212.155]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23AAA1A87C0 for <v6ops@ietf.org>; Fri, 19 Jun 2015 02:14:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s2048; t=1434705251; bh=py+zj0O9zHALc31DQFvEKGsqYCSFdARNmBCkcVyKy8k=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=fL5P8Uk9uv+UoU7dMnd+JW4QwgCyiN4jsnGjMRcYfqDttDg0OHQV0M+aWWSas6EoUH0e7gQqDkTw7gl2AEiEKP56Aa9edZVjMB9GVrhdISrIPsv+7aSVLuwJY9I0He932hCNtbzOtwbncTRrYDQibHnecU30aaWDmBS1/p+s938TB+HJDDJBPPq9ryaDu7OBBqQUa8ag08hpHiKSFUx67/EPpR84LNK9q6OsZX+PblooNV1qntqsyxkQpxSoK+qLFOaJCMeHCUSV4v+eeGUMCIsz8Bc8dQpqfPzcgL0NHYjcLIzhVeQXzfpWnjUoZ54goP2xx1A35DamxNaGr72NKA==
Received: from [98.139.214.32] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 19 Jun 2015 09:14:11 -0000
Received: from [98.139.212.208] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 19 Jun 2015 09:14:11 -0000
Received: from [127.0.0.1] by omp1017.mail.bf1.yahoo.com with NNFMP; 19 Jun 2015 09:14:11 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 229985.69187.bm@omp1017.mail.bf1.yahoo.com
X-YMail-OSG: Xxs3ZUkVM1nbejBMVd6BGCEBZ0kH1oKdDrL0LAPcrLeTqrXEaSTe.2LUqk_feiO rpvGleKJeAYSDDgElnay_UiS7hsfuOFpGDUQerOuX_97pmiMpRY5WskOGOb0KUT7sfQXBXDXM_VJ wsGvCs2KqhYEbuR9FPvl2LSyhd1nwCKVjSOGP0_SSTFQkHf3CAx_O9Y3aqd1UMwoDgPJnieLRnO2 JrkDtICER4LImfxmQXfDlz7Q0dWEMSePIvega29sgYBb6AXmO69_OevfDiv_nvnOFzanCXNWHHtF 8H7aeJlQFJMwqkkl9ETOCT1l2hJSJatM8xMkHTXp0_7byPvrFNr5nPgLlq28vCAIZaz6oPylqbWq 7Z8o1gdDzxmEsaYnWOPCtrG3rx_9fN9vx34oJDjaZuWQhr5AHOesqWx1nG9V4G1SImqF9qmhzVq. USYSt3qMHE6Y9jFUrP7uFL3LVU2sYdpOyL8Bcw07vvXltqDpyfF.j0FlLZlV5RU1MQPgjkiamqq5 vEetUAU9LegyMb23svZQ-
Received: by 66.196.81.104; Fri, 19 Jun 2015 09:14:10 +0000
Date: Fri, 19 Jun 2015 09:13:52 +0000
From: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
To: Enno Rey <erey@ernw.de>, Ole Troan <otroan@employees.org>
Message-ID: <470861705.2069879.1434705232342.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <20150619083410.GC39902@ernw.de>
References: <20150619083410.GC39902@ernw.de>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_2069878_1986296535.1434705232338"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/ggFpWbpEoHbEEm2iRNX0Dn5fyTI>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, "ipv6-wg@ripe.net" <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
Reply-To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
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 09:14:14 -0000

      From: Enno Rey <erey@ernw.de>
 To: Ole Troan <otroan@employees.org> 
Cc: v6ops@ietf.org; ipv6-wg@ripe.net 
 Sent: Friday, 19 June 2015, 18:34
 Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices
   
Hi,

On Fri, Jun 19, 2015 at 09:56:20AM +0200, Ole Troan wrote:
> >>>> 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.

I would second the observation that this (subsequent action) actually happens.
Not least because many consider it a reasonable approach not to process and/or to drop something that induces complexity & insecurity and which at the same time is not needed by any service or application (read: all EHs except ESP and, maybe in some corner cases, AH+FH).

/ I think you're only expressing the view of many security engineers, not the many network engineers or the many more users of networks. At an ISP, if you block traffic your customer wants send, all you get is angry customers. They're paying you to deliver any and all of their packets as well as possible, with as minimum restrictions as possible, ideally none, rather than the opposite. This is why I don't think you'll ever get consensus on deprecating EHs, because I think you're only coming the position of trying to solve problem (3) I described in my last email.
/ I'd also observe that deprecating EHs, other than ESP, AH+FH, TCP and UDP, would also prevent them from being used behind the ESP EH - where you won't be able to see what is in them, so you won't be able to care what is in them. You'll also be preventing people from other transport layer protocols, such as SCTP and DCCP, that are feasible to deploy over the IPv6 Internet that couldn't be over the IPv4 network because of IPv4 NAT and other middle boxes.
thanks

Enno




> 
> cheers,
> Ole



-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator


=======================================================

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops