Re: Death by extension header (was:RE: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt)

Toerless Eckert <tte@cs.fau.de> Mon, 13 July 2020 21:11 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56803A0A49 for <ipv6@ietfa.amsl.com>; Mon, 13 Jul 2020 14:11:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 lbkji9xOZ0M3 for <ipv6@ietfa.amsl.com>; Mon, 13 Jul 2020 14:11:53 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA8933A0A2E for <6man@ietf.org>; Mon, 13 Jul 2020 14:11:52 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id EAF9B548068; Mon, 13 Jul 2020 23:11:46 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id E55FC440043; Mon, 13 Jul 2020 23:11:46 +0200 (CEST)
Date: Mon, 13 Jul 2020 23:11:46 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
Cc: "6man@ietf.org" <6man@ietf.org>
Subject: Re: Death by extension header (was:RE: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt)
Message-ID: <20200713211146.GG38490@faui48f.informatik.uni-erlangen.de>
References: <DM6PR05MB6348708352E1EE4421A61D63AE650@DM6PR05MB6348.namprd05.prod.outlook.com> <CALx6S34e21BLHRfx+p7agrzzDsx-M-XxB6cZQnWc-d0wqSesRQ@mail.gmail.com> <DM6PR05MB6348BCE5DDB6A8AF52D04FFAAE650@DM6PR05MB6348.namprd05.prod.outlook.com> <20200713191832.GC38490@faui48f.informatik.uni-erlangen.de> <DM6PR05MB6348285B5DB0FE7CDCAB2DF8AE600@DM6PR05MB6348.namprd05.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <DM6PR05MB6348285B5DB0FE7CDCAB2DF8AE600@DM6PR05MB6348.namprd05.prod.outlook.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/-3vfTYwgHIMZkMxybsoaaCtx6gY>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jul 2020 21:11:56 -0000

On Mon, Jul 13, 2020 at 08:29:52PM +0000, Ron Bonica wrote:
> Toerless,
> 
> Are we trying to fix an implementation problem with a protocol change?

Not necessarily. I think we need to clearly identify
a) what fixes we can do within the scope of 8200
b) what the minimum changes/benefits are that require us to go beyond 8200
c) what additional possible benefits there are if we did a) outside the
   scope of 8200.

Aka: no protocol change for just the benefit of just protocol change.

But think about for example trying to make protocol header processing easier,
and lets say we find this not to be well enough feasible within 8200. 
Well, maybe we could still make it canonically, e.g.: on the ingres convert
from IPv6 header into something easier to process and on egress convert back.

Aka: there are various options to overcome limitations without becoming fully
incompatible.

> Maybe the solution to this problem isn't a standards track IETF RFC, but an implementation agreement regarding how extension headers should be processed on routers that have a fast path and a slow path.

Practically speaking i hope we can go along with what Tom said, that slow
path should really be irrelevant, because i for once can't think right now
about a good reason to build something with slow-path.

But that being said, it means that there would have to be fast-path versions
of things designed so far for the slow-path. Such as evolving in-band-signaling
that is heavy on hop-by-hop bidirectional state-building, such as RSVP,
and hence infeasible for fast-path over to in-band signaling that is lightweight
enough to be done in the fast-path. iOAM is IMHO an example of the latter.

The whole binary distinction is also quite historic. The closer the FPE becomes
to general purpose CPU, the more there is going to be gradual degradation of
performance through additional features, and the more its IMHO important
to first focus on the "no added processing cost for stuff i don't care about"
vs the actual performance impact IF i (as a router) do care about processing a
feature.

Cheers
    Toerless

> Juniper Business Use Only
> 
> -----Original Message-----
> From: Toerless Eckert <tte@cs.fau.de> 
> Sent: Monday, July 13, 2020 3:19 PM
> To: Ron Bonica <rbonica@juniper.net>
> Cc: Tom Herbert <tom@herbertland.com>; 6man@ietf.org
> Subject: Re: Death by extension header (was:RE: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt)
> 
> [External Email. Be cautious of content]
> 
> 
> And now find me any single IETF RFC that even uses the term slow-path and fast-path to formalize requirements against them. We are just not explicit enough about this. Hence my example of redooing router-alert as the most simple example. Not that i think this would be most important, but just to make the community consider that we need to be more diligent about protocol specs in this respect.
> 
> Some maximum amount of fast-path extensions is already in specs as an example, but it too is not comprehensive enough to feel more confident about safe extensibility.
> 
> And we need to break free of the rfc8200 constraints whenever we deploy the network protocol in controlled networks. rfc8200 is such a career limiter when comparing IPv6 with MPLS for this type of use-cases. Not to speak of the unnecessary long addresses.
> 
> Oh well...
> 
> Cheers
>     Toerless
> 
> On Fri, Jul 10, 2020 at 06:43:59PM +0000, Ron Bonica wrote:
> > Tom,
> >
> > Given that you parse the extension header chain on the fast path, HBH and destination options can be categorized as follows:
> >
> > 1) unrecognized (ACT 00, 01, 10, and 11)
> > 2) recognized and processed on the fast path
> > 3) recognized and processed on the slow path
> >
> > Types 1 and 2 cannot be used in a DoS attack, because they are never sent to the slow path. Type 3 is the dangerous one.
> >
> > I think that an implementation is safe if it only recognizes options that it can process on the fast path. It may also be safe if it severely rate limits packets as it sends them to the slow path.
> >
> >                                                                                       
> > Ron
> >
> >
> >
> >
> >
> > Juniper Business Use Only
> >
> > -----Original Message-----
> > From: Tom Herbert <tom@herbertland.com>
> > Sent: Friday, July 10, 2020 2:29 PM
> > To: Ron Bonica <rbonica@juniper.net>
> > Cc: Pengshuping (Peng Shuping) <pengshuping@huawei.com>; 6man@ietf.org
> > Subject: Re: Death by extension header (was:RE: New Version 
> > Notification for draft-li-6man-hbh-fwd-hdr-00.txt)
> >
> > [External Email. Be cautious of content]
> >
> >
> > On Fri, Jul 10, 2020 at 11:18 AM Ron Bonica <rbonica@juniper.net> wrote:
> > >
> > > Tom,
> > >
> > > I am forking a new thread since this is not directly related to Shuping's draft.
> > >
> > > Any variable length extension header can be used in a DoS attack. So, if a node encounters a packet that satisfies any of the following criteria, it should discard the packet and send an ICMP message as described in https://urldefense.com/v3/__https://tools.ietf.org/html/draft-herbert-6man-icmp-limits-03__;!!NEt6yMaO-gk!XnKPvkz9vBtVNlSCx0SqcojVpo2uBgeSDJzZEJa2fLd1NTKb53H0w3Ue2Xxv7iGB$ .
> > >
> > > - The extension header chain is longer than the node can process
> > > - An individual extension header is longer than the node can process
> > > - The total number of options contained by all instances of the HBH and Destination Options header exceeds the number or options that the node can process.
> > >
> >
> > Ron,
> >
> > Right, those are the ICMP errors for the allowance to drop or ignore extension headers in section 5.3 of RFC8504, there's also default limits suggested in that doc. Do you think this is sufficient in routers to get past the DOS concern?
> >
> > Tom
> >
> > >
> > > Ron
> > >
> > >
> > >
> > > Juniper Business Use Only
> > >
> > > -----Original Message-----
> > > From: Tom Herbert <tom@herbertland.com>
> > > Sent: Friday, July 10, 2020 1:13 PM
> > > To: Ron Bonica <rbonica@juniper.net>
> > > Cc: Pengshuping (Peng Shuping) <pengshuping@huawei.com>; 
> > > 6man@ietf.org
> > > Subject: Re: New Version Notification for 
> > > draft-li-6man-hbh-fwd-hdr-00.txt
> > >
> > > [External Email. Be cautious of content]
> > >
> > >
> > > On Fri, Jul 10, 2020 at 7:59 AM Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org> wrote:
> > > >
> > > > Peng,
> > > >
> > > > While your solution may require refinement, I think that you have latched on to a problem that needs to be solved. HBH Options, as they were originally conceived in RFC 1883, are very useful.
> > > >
> > > > When IPv6 was first implemented on high-speed routers (circa 2000), HBH options were not yet well-understood and ASICs were not so capable as they are today. So, early IPv6 implementation dispatched all packet that contain HBH options to their slow path. In these implementations, a large flow of IPv6 packets could congest the slow path, causing other critical functions that are executed on the slow path to fail. These critical functions include routing and network management.
> > > >
> > > > To mitigate this DoS vulnerability, many operators deployed Access Control Lists (ACLs) that discard all packets containing HBH Options. This introduced a circular problem:
> > > >
> > > > - An implementation problem caused HBH to become a DoS vector
> > > > - Because HBH was a DoS vector, network operators deployed ACLs 
> > > > that discard packets containing HBH
> > > > - Because network operators deployed ACLs that discard packets 
> > > > containing HBH, network designers stopped defining new HBH Options
> > > > - Because network designers stopped defining new HBH Options, the 
> > > > community was not motivated to fix the implementation problem that 
> > > > cause HBH to become a DoS vector
> > > >
> > > > If we can fix the implementation problem that caused HBH to become a DoS vector, we can break this cycle and start using HBH Options.
> > > >
> > > Ron,
> > >
> > > I think there were "protocol problems" in the original design of HBH.
> > > The requirement that _all_ routers in the path process Hop-by-Hop options was in retrospect too austere, and the possibility that an attacker could stuff a packet with hundreds of bogus options, only limited by MTU, was, again in retrospect, a pretty obvious DOS vector.
> > > I believe these problems have been addressed in RFC8200 and RFC8504.
> > > We certainly welcome the feedback from router vendors whether these mitigations are sufficient to make HBH options deployable.
> > >
> > > Tom
> > >
> > > > Let's continue to work on a solution.
> > > >
> > > >                                                          Ron
> > > >
> > > >
> > > >
> > > > Juniper Business Use Only
> > > >
> > > > -----Original Message-----
> > > > From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Pengshuping (Peng
> > > > Shuping)
> > > > Sent: Thursday, July 2, 2020 12:07 PM
> > > > To: 6man@ietf.org
> > > > Subject: FW: New Version Notification for 
> > > > draft-li-6man-hbh-fwd-hdr-00.txt
> > > >
> > > > [External Email. Be cautious of content]
> > > >
> > > >
> > > > Hi Folks,
> > > >
> > > > We have just uploaded a new draft aiming to analyze and tackle the issues faced by the Hop-by-Hop Options Header, which has been sparsely used without any form of large scale deployment.
> > > >
> > > > However, as IPv6 is being rapidly and widely deployed worldwide, more and more new services that requires hop-by-hop forwarding process behavior are emerging, and also the already defined over ten HBH Options are going to be used widely in practice.
> > > >
> > > > We look forward to hearing your feedback and comments, and try to release the benefits that could be provided by HBH Options header altogether.
> > > >
> > > > Best regards,
> > > > Shuping
> > > >
> > > > -----Original Message-----
> > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > > > Sent: Thursday, July 2, 2020 11:31 PM
> > > > To: Lizhenbin <lizhenbin@huawei.com>; Pengshuping (Peng Shuping) 
> > > > <pengshuping@huawei.com>
> > > > Subject: New Version Notification for 
> > > > draft-li-6man-hbh-fwd-hdr-00.txt
> > > >
> > > >
> > > > A new version of I-D, draft-li-6man-hbh-fwd-hdr-00.txt has been successfully submitted by Shuping Peng and posted to the IETF repository.
> > > >
> > > > Name:           draft-li-6man-hbh-fwd-hdr
> > > > Revision:       00
> > > > Title:          Hop-by-Hop Forwarding Options Header
> > > > Document date:  2020-07-03
> > > > Group:          Individual Submission
> > > > Pages:          10
> > > > URL:            https://urldefense.com/v3/__https://www.ietf.org/internet-drafts/draft-li-6man-hbh-fwd-hdr-00.txt__;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00dbzuCmO7S4CG2fZYHGYeOXYwVmtNTFnzgB-bqLrg$
> > > > Status:         https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-li-6man-hbh-fwd-hdr/__;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00dbzuCmO7S4CG2fZYHGYeOXYwVmtNTFnzgM5iPE22$
> > > > Htmlized:       https://urldefense.com/v3/__https://tools.ietf.org/html/draft-li-6man-hbh-fwd-hdr-00__;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00dbzuCmO7S4CG2fZYHGYeOXYwVmtNTFnzgPvsH43l$
> > > > Htmlized:       https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-li-6man-hbh-fwd-hdr__;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00dbzuCmO7S4CG2fZYHGYeOXYwVmtNTFnzgBQxbwZb$
> > > >
> > > >
> > > > Abstract:
> > > >    RFC8200 specifies the HBH header that is assumed to be processed by
> > > >    each hop in the delivery path of the packet.  However, RFC8200 also
> > > >    expects that nodes processing the HBH header have been explicitly
> > > >    configured to do so.  Therefore, it cannot be assumed that a HBH
> > > >    header present in the packet is processed.  It all depends on the
> > > >    configuration of each node across the path.  Moreover, in most of
> > > >    networks today, the processing of the HBH header is done in the
> > > >    control plane (slow processing path) which incurs several limitations
> > > >    among which resources consumption and security risk.
> > > >
> > > >    For these reasons, over time, the Hop-by-Hop Options header has been
> > > >    sparsely used without any form of large scale deployment.  Also, most
> > > >    of already defined HBH options are forwarding options which contain
> > > >    forwarding plane information that needs not to be sent to the control
> > > >    plane.
> > > >
> > > >    This document proposes a new Hop-by-Hop Forwarding Options Header in
> > > >    order to carry Hop-by-Hop options that are solely intended to and
> > > >    processed by the forwarding plane.  This new HBH header is confined
> > > >    in and dedicated to the forwarding plane while the current HBH header
> > > >    can still be used for control plane options.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
> > > >
> > > > The IETF Secretariat
> > > >
> > > >
> > > > ------------------------------------------------------------------
> > > > -- IETF IPv6 working group mailing list ipv6@ietf.org 
> > > > Administrative
> > > > Requests:
> > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/
> > > > ip
> > > > v6
> > > > __;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00dbzuCmO7S4CG2fZYHGYeOXYwV
> > > > mt
> > > > NT
> > > > FnzgEBbFhyl$
> > > > ------------------------------------------------------------------
> > > > --
> > > >
> > > > ------------------------------------------------------------------
> > > > -- IETF IPv6 working group mailing list ipv6@ietf.org 
> > > > Administrative
> > > > Requests:
> > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/
> > > > ip
> > > > v6
> > > > __;!!NEt6yMaO-gk!Qu9y9Ou2SvlYIZjMQa3hBXcu08HG3W4BBIcFoOHCfp41HtkdI
> > > > Yu
> > > > Ds
> > > > XM8uyxPWt9N$
> > > > ------------------------------------------------------------------
> > > > --
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: 
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> > __;!!NEt6yMaO-gk!TyC_ZXb3C9EvO8vGJVxVflVTXAD5z8RJ-wPORIx9ZaWOT1mdd12ER
> > 4MKte7T8QdN$
> > --------------------------------------------------------------------
> 
> --
> ---
> tte@cs.fau.de
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
---
tte@cs.fau.de