Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops

Tom Herbert <tom@herbertland.com> Mon, 28 March 2016 22:41 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1EEB12D1BA for <v6ops@ietfa.amsl.com>; Mon, 28 Mar 2016 15:41:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
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 UO35RGEm9lPm for <v6ops@ietfa.amsl.com>; Mon, 28 Mar 2016 15:41:24 -0700 (PDT)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 C802D12D16A for <v6ops@ietf.org>; Mon, 28 Mar 2016 15:41:24 -0700 (PDT)
Received: by mail-io0-x235.google.com with SMTP id e3so1476254ioa.1 for <v6ops@ietf.org>; Mon, 28 Mar 2016 15:41:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=OPXlJSp6fDnY2yqkPr0OGgNQvBafn6PCO55QnHXfAAI=; b=w7XZu+cR8eBmTMAOlDSqroPIsT3IVBbSiR0gvML5YN53Aihe34Cs2lPwd31AU3BwN3 rAkVTSwKzfUeiMeCw73xN9+WEyc5GsvsK6QaVVCImW0+OVQTCM7nAUwWrnq+92OFOh27 UAHPYeM9nvupUv6LIpEZg0hXtZpfSr3idOXOD4fYas8e+oeKjeE7cZ844z/zDXgT9/8B hF9OjLuaO/mMvooMiHD90LqLol4nh0/HSH80nu60o4hB+GqEUthQINFyCQn2LoopHFsz zg9qSCxIj8kZRBjhYwof1eXOqfvPJ+wdj2kQNiQkuyHKrtu2JrYCygsvYojFvkIpWzL4 YCGg==
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; bh=OPXlJSp6fDnY2yqkPr0OGgNQvBafn6PCO55QnHXfAAI=; b=H2TW4LgPehMQ4W5i3reRz1KdyiQU+Kwj+gyE4y96YisR099nK34hEuo32SO5BzrpA8 dU1ierNK4lYRRuUeXmDblFsw3N5+099zdf0YNCY21QA8sCre88cQMbq1vuUF8s980dy9 1KS1W5cl+DjG7mgnJPPf4VbmqbTT+iq/ij4wVUFB7XuczwM7bbGtsfjZRFjvOkSq2Y7c vAMaQZHP5g/3jTu7PFaOX01aW3LwyFC7DB+uIe5VKXERGqNZR4VHU4MONGwsZ98q8sP/ zzOfTc/wdxW5qmU0mc22LxjQQsI1qWV0H2gPMznMICiFzovcq4PUeW7wjS/ZraZh451i CXCA==
X-Gm-Message-State: AD7BkJKNTM5tpl4lUBes8TOE1vd/hbwGYDRDrCV44Ee2b7YIGuyHLhQolSa5UMs5SWAixMLWWCSHklk4T/zPRg==
MIME-Version: 1.0
X-Received: by 10.107.7.72 with SMTP id 69mr31867305ioh.107.1459204884141; Mon, 28 Mar 2016 15:41:24 -0700 (PDT)
Received: by 10.107.130.198 with HTTP; Mon, 28 Mar 2016 15:41:23 -0700 (PDT)
In-Reply-To: <56F9AE53.8060903@gmail.com>
References: <CAHw9_iLbqEvsw0x4dDcA3Zy3SXKUROcQuy5nSynsL9Xi+xrZLg@mail.gmail.com> <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <CALx6S37zP4UvCtBJsvnPN6OmDB0OQDMfRrJNy1XF0t4COStUjQ@mail.gmail.com> <56E98086.5040209@foobar.org> <EE17974D-EDA4-4732-B29E-B2B3BC36DB86@employees.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com>
Date: Mon, 28 Mar 2016 15:41:23 -0700
Message-ID: <CALx6S354tK+cC4TFXAGsS7mX2ph++0XC=HHUgAinNJh4FB9pgw@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/3ypUzVdbR65IWZuVbsTMYk8COnc>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 28 Mar 2016 22:41:26 -0000

On Mon, Mar 28, 2016 at 3:21 PM, Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:
> On 29/03/2016 10:36, Fred Baker (fred) wrote:
>>
>> On Mar 28, 2016, at 2:29 PM, touch@isi.edu wrote:
>>> Note, however, that the idea of an offset to "jump" to the transport
>>> header makes no sense. There's no rule that HBH header lengths never
>>> change in transit, which means you just end up with another field that
>>> might be inconsistent with the actual header.
>>
>> Don't tell the 6man chairs. They think that changing the length of a HBH header (or any header) in transit would be a problem, and I can confirm that in the event that there is an AH header in the packet. We had that discussion in 6man at IETF 94.
>
> In any case, that issue is foreseen in
> https://tools.ietf.org/html/draft-zhang-6man-offset-option-01#section-6
>
> By the way, would an incorrect offset option be any more harmful
> than an incorrect IHL (with a correponding checksum) in IPv4?
>
I would speculate that someone might use the offset option to spoof
the transport header. The idea would be that an attacker would use the
options to spoof the transport header inside some other EH. So a FW
might inspect the fake header and and end host would process the real
one. A solution for this would be that end hosts need to validate the
option is correct.

Tom

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