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

Jen Linkova <furry13@gmail.com> Wed, 17 June 2015 13:41 UTC

Return-Path: <furry13@gmail.com>
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 C67EC1AC444 for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 06:41:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 hlT7OIg_-a2M for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 06:41:23 -0700 (PDT)
Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (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 9167F1AC7E7 for <v6ops@ietf.org>; Wed, 17 Jun 2015 06:41:22 -0700 (PDT)
Received: by ykfl8 with SMTP id l8so39906205ykf.1 for <v6ops@ietf.org>; Wed, 17 Jun 2015 06:41:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aocfp6y0nJGmZ0RLnUQeazprxlkhUBz1J25r6UGp/Mk=; b=TOB++BniVM7q8cM/mkQyfIusjYTPYBVj+pmuoGUlJtBCfnsJLZqY4KAln0sIGR/SSp Hp3cjQ8aAh/idIfyX52NGcMi8mlCCOn78ipJDLSNft1z3X4SIQvAmms4Vjl1VFzhURyO /Q6/U8OvU/WoFMB2XtTrHVw9Q2AFidY4OwAGHDiyR4d3TO6ikHvwhIFicPeNaFpgGSkk NQRNPkbv676ijCuDmxQyjr1oLuDplWbhM7r0kSNNX2UblEkt+TIoDpB1lnSb2sW2i6qQ hsyYTfVH8ruGnKKIrt26y9AodcqzcBbEbfx7jb20sCWYZaW1RHSng7CCPmQDe3Jn3tk8 pRbA==
X-Received: by 10.52.227.200 with SMTP id sc8mr4817285vdc.35.1434548481962; Wed, 17 Jun 2015 06:41:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.82.130 with HTTP; Wed, 17 Jun 2015 06:41:01 -0700 (PDT)
In-Reply-To: <20150617133328.GB16716@ernw.de>
References: <CAFU7BAR0YeGe7NbYTqNSAcMukGjAz6akWaVcODWVJwpTJKQhWQ@mail.gmail.com> <20150617.140235.74748217.sthaug@nethelp.no> <CAFU7BARNa--MEuOzH5ZsBJ+hY8hCxUH4tVDcSEP95BdkmooLgw@mail.gmail.com> <20150617.152750.41635871.sthaug@nethelp.no> <20150617133328.GB16716@ernw.de>
From: Jen Linkova <furry13@gmail.com>
Date: Wed, 17 Jun 2015 15:41:01 +0200
Message-ID: <CAFU7BATv3U7TtSnM8Litneq+xGvXmmHLBHHz0HFGE=AjoYeSHg@mail.gmail.com>
To: Enno Rey <erey@ernw.de>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/wQHQRNry-zMgtf8XQ-FTN70hVNo>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, "ipv6-wg@ripe.net IPv6" <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: Wed, 17 Jun 2015 13:41:24 -0000

On Wed, Jun 17, 2015 at 3:33 PM, Enno Rey <erey@ernw.de> wrote:
>> I see *large* variable length headers, in combination with complex
>> parsing rules, as the problem.
>
> (*large* variable headers) exactly, plus fragmentation

Fragmentation is not specific to IPv6, is it? And, as the fragment
header itself is just 8 bytes (AFAIR, too lazy to check ;)) - I'd not
classify it as *large* variable header.

> and "ambiguities" wrt fragmentable vs. unfragmentable part and how headers point to the next one once there's a cut between them due to fragmentation. the, what we consider, "problem space" is much larger, unfortunately.

Has not RFC7112 addressed this particular problem?

-- 
SY, Jen Linkova aka Furry