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

Warren Kumari <warren@kumari.net> Fri, 19 June 2015 20:19 UTC

Return-Path: <warren@kumari.net>
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 7AAF01A1A07 for <v6ops@ietfa.amsl.com>; Fri, 19 Jun 2015 13:19:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 S-EH82Y2e3Bl for <v6ops@ietfa.amsl.com>; Fri, 19 Jun 2015 13:19:46 -0700 (PDT)
Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C091A1ABF for <v6ops@ietf.org>; Fri, 19 Jun 2015 13:19:27 -0700 (PDT)
Received: by oigb199 with SMTP id b199so46125758oig.3 for <v6ops@ietf.org>; Fri, 19 Jun 2015 13:19:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=o8Stjkg0VVTrcYJf+h39vdUGyB1L3vx2XWw5adTZiW4=; b=KDwmNYE4UR5UKQeQXKfMCPAjO7uWw3l1GId7Wi99OcSUBiKqKL5iZUCflj462+Kfiw qIw9QlnrS9vFuyddG2aE2EycqwCuyvAR5A3ghyQYUpo4TEUKe7yxfGVqHmKClgxfhxoH bWgQmoKqDtpIeD7c9Ob7Cj0FIVldUS/g7+b3IxUKfAOufnMEs74KY/QMS7gcj5EH6CpS 78jfFhY3DGGwrVkcRWDgwX6E/W3SrWD27HoHC8YcYjItffpofec3yl6inWQ9x+RI2nNq b/q22/XhWEgFzXNicjp2VnPvCsf9pMpF4ZFqKkAVOubXzsKUcnQu+4mtsnxcucgTZzux DdgA==
X-Gm-Message-State: ALoCoQm6d2c5Uj4jPl7X5tNOYBAG8XvTuX132/mZ3e/29j2hNXqSrTe1CWKwAKVdv681xXWkocv6
MIME-Version: 1.0
X-Received: by 10.182.186.106 with SMTP id fj10mr14768062obc.54.1434745167151; Fri, 19 Jun 2015 13:19:27 -0700 (PDT)
Received: by 10.202.196.75 with HTTP; Fri, 19 Jun 2015 13:19:26 -0700 (PDT)
In-Reply-To: <470861705.2069879.1434705232342.JavaMail.yahoo@mail.yahoo.com>
References: <20150619083410.GC39902@ernw.de> <470861705.2069879.1434705232342.JavaMail.yahoo@mail.yahoo.com>
Date: Fri, 19 Jun 2015 16:19:26 -0400
Message-ID: <CAHw9_iJE5=os9i2YO21j7hJoSxdh98bXhNe6NOnziyAFLkuz2A@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/IDctyKHL-SjMAGKfg0shs_Fp7BE>
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
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 20:19:47 -0000

On Fri, Jun 19, 2015 at 5:13 AM, Mark ZZZ Smith
<markzzzsmith@yahoo.com.au> wrote:
>
> ________________________________
> 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.

... and at an ISP if your customer calls you up because they are being
DDoSed out of existence with traffic at some port that they don't use,
and you tell them at that you cannot filter UDP port 80 because, well,
you cannot find it, you also end up with an angry customer.

> 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.

Perhaps. I figure they are /actually/ paying you to provide them with
good service. Sometimes that includes filtering for them, because you
have bigger pipes than them...

W

> 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:   || Conference: www.troopers.de
> Twitter: @Enno_Insinuator
>
>
>
> =======================================================
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf