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

Nick Hilliard <nick@foobar.org> Fri, 18 March 2016 15:59 UTC

Return-Path: <nick@foobar.org>
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 41F8312D6B0 for <v6ops@ietfa.amsl.com>; Fri, 18 Mar 2016 08:59:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 WbHjrkbQ4f_z for <v6ops@ietfa.amsl.com>; Fri, 18 Mar 2016 08:59:29 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 972B312D56F for <v6ops@ietf.org>; Fri, 18 Mar 2016 08:59:29 -0700 (PDT)
X-Envelope-To: v6ops@ietf.org
Received: from cupcake.foobar.org (089-101-070076.ntlworld.ie [89.101.70.76] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u2IFxGLt059075 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Mar 2016 15:59:16 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070076.ntlworld.ie [89.101.70.76] (may be forged) claimed to be cupcake.foobar.org
Message-ID: <56EC25D2.2090101@foobar.org>
Date: Fri, 18 Mar 2016 15:59:14 +0000
From: Nick Hilliard <nick@foobar.org>
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: "Fred Baker (fred)" <fred@cisco.com>
References: <A277BE71-BD70-4AFE-97DA-F224D7DBBCB8@cisco.com> <56E6FC18.1060304@foobar.org> <CALx6S35pcSj_LLnDWJ68KwSYiHeu6FwrXTaR4N2xE6aY7MRO1A@mail.gmail.com> <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.504 0209@foobar.org> <EE17974D-EDA4-4732-B29E-B2B3BC36DB86@employees.org> <56E9A16B.4030605@si6networks.com> <A2634C00-EBF8-48DA-9604-790F5213F536@employees.org> <56EA93C0.104090 4@si6networks.com> <34E270CB-AEB4-4034-99B8-1E6AB528CF67@employees.org> <d6967727-1fd6-1d43-0fbb- f665ed20e101@bogus.com> <3AE9BA3C-E7B6-4C0F-B6B4-5A737485123D@employees.org> <56EB2630.2020208@foobar.org> <9B901C5C-6BD1-4EFE-B448-AFFE9E07F972@cisco.com>
In-Reply-To: <9B901C5C-6BD1-4EFE-B448-AFFE9E07F972@cisco.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/x6wwSViK6Wl32-yru0csA1_2Bb8>
Cc: Fernando Gont <fgont@si6networks.com>, "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: Fri, 18 Mar 2016 15:59:32 -0000

Fred Baker (fred) wrote:
> In there first statement, you assert that we're looking at a protocol
> problem. We may be, but that's not obvious to me.

for non-trivial EH chains, most people seem to be acknowledging that
start-to-end EH chain walking is too difficult for vendors to implement
in silicon and is too expensive to handle in software.  Vendors could
implement it, but the cost-to-return ratio doesn't work.

If the ietf designs a protocol which is too difficult / expensive for
vendors to implement or where the cost-to-return doesn't work, then the
problem lies with the protocol definition, not with the vendors' lack of
inclination to implement it.

> There is an issue
> with HBH headers, or at least with their implementation, which we are
> looking at in draft-ietf-6man-hbh-header-handling.

hbh is a separate issue and we should probably park that for this
discussion.

> Nalini Elkins has
> a problem with the lack of a counterpart to the IPv4 ident field,
> which she wants to address with a Destination Option in
> draft-ietf-ippm-6man-pdm-option. Several folks have issues with
> fragmentation and reassembly (draft-bonica-6man-frag-deprecate), but
> that is more about security policy and perceived application designer
> laziness than about issues with the header; it in fact fragments and
> reassembles if used for that purpose, and AFAIK is widely
> implemented.

The ipv6-ehs-in-real-world draft notes that if you attach a
fragmentation extension header to a packet, it stands a good chance of
being dropped on the floor.  Protocols don't work when they are dropped
by the network.  This matters for frags / ipsec.

> You go on to say that IPv6 Extension Headers implement core
> functionality. I'll agree that the Security Header is core; I go to
> work using one of a couple of VPN technologies, and packet layer
> encryption is central to both. I'm hard pressed to say that the other
> headers are core;

ipsec and fragmentation are the two EHs that concern me.  Other people
may have other opinions.  Personally, I see no future for either RH or
HBH headers, but that is a personal opinion.

> some different processing algorithm". The only one we have deprecated
> is RH0, and even there, the issue isn't that RH0 can't be used to
> implement what in IPv4 we would call a Loose Source Route and Record;
> it's that even in IPv4 we decided that having that option was a
> security nightmare.

agreed.  IPv4 options stopped working in the mid 90s but no-one noticed
because they didn't do anything very important.  The result is that
there is plenty of silicon being sold today which is unable to forward
packets with ipv4 options, and no-one cares.

> If we're looking at a protocol problem, we should be able to describe
> proposed changes to the protocol to fix it. I'm not hearing such
> things described, apart from draft-wkumari-long-headers.
> 
> Is the issue addressed in draft-wkumari-long-headers what we're
> talking about? If so, can we discard the bluster in tone and say
> that? Is there another issue? Can we describe it?

The draft deliberately avoids prescription of a fix. First, there are a
lot of people in this WG claiming that there isn't a problem in the
first place and second, the authors want to try to get consensus that
there is a problem before prescribing a fix.

The authors have discussed this offline and feel that if the WG came to
a consensus that there is a problem, that it would be better to poll the
WG about potential fixes or workarounds.

Personally, I think there is a problem and that the problem could be
helped in the long term by drastically reining in the EH chain limits
prescribed in 7112 (namely, 1280 bytes).

If there are minimum acceptable limits imposed, then the obvious choices
would either to limit by the number of headers or the number of octets
used for headers.  The latter would be much simpler to implement.
Gaining consensus on a reasonable value for either would be very
difficult because the IETF has a long history of having difficulties
settling on what are ultimately arbitrary numbers.  From a practical
point of view, vendor input might be advisable, but I fear this is
bikeshed territory.

draft-wkumari-long-headers discourages EHs completely.  Personally, I
don't think this is workable because of ipsec / fragmentation requirements.

draft-zhang-6man-offset-option is also not ideal.  From a technical
point of view, it is difficult to implement due to packet lookahead
limitations in silicon.  Also the IPR statement allows retaliatory
infringement action, which some people may have issues with.

Nick