Re: New Version Notification for draft-herbert-6man-eh-limits-00.txt
Tom Herbert <tom@herbertland.com> Wed, 23 June 2021 18:53 UTC
Return-Path: <tom@herbertland.com>
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 502C53A0B8C for <ipv6@ietfa.amsl.com>; Wed, 23 Jun 2021 11:53:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 yrq5ev1Rk7Kw for <ipv6@ietfa.amsl.com>; Wed, 23 Jun 2021 11:53:03 -0700 (PDT)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 5084E3A0B8B for <ipv6@ietf.org>; Wed, 23 Jun 2021 11:53:03 -0700 (PDT)
Received: by mail-ed1-x52a.google.com with SMTP id i5so4939846eds.1 for <ipv6@ietf.org>; Wed, 23 Jun 2021 11:53:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aSqFaYUX/ldXMm4rM/CkLszmdxpGdyv9uv4CP0JCzxE=; b=0Wphxxge8GMrMAqN0vxbm6DXGByljhnpRKlPQ1q+4Ako3wNE97KvgFIewGPBjt4RB+ hTMu1v8zbtZ9zNlgOtJn1yoDsOj3f7Tg5zVpECQV6crMVIYhQHqAyLhBN8YwebUMGhFQ t5yreiZA36U1jl95C5eW8HbY11QUSTT9u5qpFmPKofp7fkO74LbEXEEKnKJvQS74e8O3 Uy71L+ULvQBQ2hX382QvGpICfEfRIL00e4Ix7F/g2LCMHuwlSv5QVH2AIwisduaDoAdz 0or/p3QRjo75dNAjyTiVGP19inORd2R8PJrLvLUXxdQ3DtfKc33aKpz4flde8GzC8Ksy Nu7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aSqFaYUX/ldXMm4rM/CkLszmdxpGdyv9uv4CP0JCzxE=; b=JfaqbwcCek71uJ4dNLzwbmhVToq7dMphZBulGglY7Ll6ONVESkYWTsZ0LMb4FmMY1S ZGvnDHNHDgDpFNNQGI6xJjqamNsEtmspiFEgkYd9IK4BA3hzAyOVmNjhkdsbDA2y5+d1 V3xvp9RT+h1fvenAe8qVNYvnc229FaOgf6o1c1hyZdf+7CHV4yTps5BkQ3GU9ZRieGUC 4Q/yHycYJriDQvoidYayj+pIiEsgd6Yz4VJGV42gTVrrursSa/ghQw/Lg40lw6/1GH0H uc50Wqq4tZdRht8WwpJ08qJwzLz0QIdHYgTLd64H/+mwV+ucV0vYs+qrMcGGXI3nudU8 cM9Q==
X-Gm-Message-State: AOAM531DHcAGo/nJBR7WBuX1xp1/6EWnSGjq944Cjrf5V8ScAuDqXUwT qlTyvjH0dWbwaF31y4pvY/RBe4j1anYOUY8pWnKkjA==
X-Google-Smtp-Source: ABdhPJz694lTLr5n+GnuhSMCDhmu9mXMiBtRvy/x4R0HNXz77h1wUXqpW/vA/ErdhuER6C0MINojjoi5XoTJXxQ5uXs=
X-Received: by 2002:aa7:c256:: with SMTP id y22mr1652720edo.177.1624474380788; Wed, 23 Jun 2021 11:53:00 -0700 (PDT)
MIME-Version: 1.0
References: <162441011037.16699.15159470178446552952@ietfa.amsl.com> <CAOuuhY_Qv6C4sie0EyWdtHq+fPGmJscVL0ZrQe_hyACBCg8o3A@mail.gmail.com> <CALx6S36Rdc1AEj8ZmwxTp9bnmwjTTUX-VHkW4cLTMycG8z_RWQ@mail.gmail.com> <d9f231b76bd84f00bb830d4c44b9d9e9@huawei.com>
In-Reply-To: <d9f231b76bd84f00bb830d4c44b9d9e9@huawei.com>
From: Tom Herbert <tom@herbertland.com>
Date: Wed, 23 Jun 2021 11:52:49 -0700
Message-ID: <CALx6S346rMV=TZGkZP45hnTk8Qkq0Kyd-+UZkLcZesZfOEe4sg@mail.gmail.com>
Subject: Re: New Version Notification for draft-herbert-6man-eh-limits-00.txt
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: 6man <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/9ZI8JzSTFDG8BcPxPQvEH_BkVEE>
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: Wed, 23 Jun 2021 18:53:09 -0000
Hi Eduard, thanks for the comments. Replies inline. On Wed, Jun 23, 2021 at 10:01 AM Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote: > > Hi Tom, > > 0. What has motivated you to improve all other options except HbH? Where is the problem? > The intermediate node should not look to anything except HbH. The limits apply to all nodes with different requirements per node type. While intermediate node aren't supposed to look beyond HBH perf RFC8200, many of them do inspect the transport layer header-- hence limits on IP header chain length. > > 1.You propose to restrict the header chain to 104 bytes. > Are you going to cancel SRH (together with SRv6) because it could be 216Bytes? > The same question is about iOAM. Primary use case for both of these is limited domain, not public Internet. In limited domain limits can be higher per the needs of the doman. > My point here: it is fine to signal restriction through the network (ICMP, ISIS, ..), but it is not good to restrict innovations. > A similar opinion I have about all other "numbered" restrictions where you restrict something in bytes or instances. > It is not a good approach to cut scalability in any direction. > I believe that only "qualitative" restrictions could help. Please consider the differences between requirements for public Internet and limited domains. In the public Internet we will want to be more restrictive in what we send (by robustness principle). > > 2. If you restrict so many things, then please restrict the number of headers in the IPv6 packet. > Because current RFC8200 permits to have many instances of any EH (for example, 5 RHs are permitted) > And there is a clear statement that Destination Node should process all of these. > RFC8200 only restricts that HbH should be 1st, but the number of HbH headers is not restricted:-) > Hence, just say that all headers should be only once, except DO maybe twice. > There are limits on the number of extension headers defined in the document. Might make sense to make it MUST that hosts don't send more than one type of EH (2 for DO) or don't send in prescribed order of RFC8200 (again with the exception if sender is in limited domain) > 3. You did miss addressing one big problem. > Recently I have participated in tests where security specialist attacks router with many HbH options (50+). High order option type bits 00, the rest 6 bits are jumping at random. > The router has to take it to software (because the option is unknown) then rate limit to 200packets/second (control plane protection against DoS). > It was effectively "almost everything dropped" because the attacker generates the big volume. > You see, one unknown HbH option would be enough to block such service on all intermediate routers (DoS protection). > It is because some options are implemented in hardware and some in software, but only software makes the final decision. > What to restrict here? That's an interesting hardware design and pretty obvious it's susceptible to DoS. I'm not sure there is a protocol solution to this since there's no normative definitions of fast and slow path options. I would recommend that if hardware wants to defer processing then it should be configured with the exact options to send to slow path. Also, I believe there was some discussion on creating a new EH and splitting HBH options to slow path and fast path ones. > Unknown options should be processes by hardware, i.e. hardware should have the table of all options that are implemented in software too (to punch to software only what is supported). Move final decision to hardware. Right. > I believe that this one is the root cause of HbH's low acceptance. You could put it into "draft-herbert-6man-eh-limits" or "draft-hinden-6man-hbh-processing" or both. > > PS: it would not help anyway because of business reasons, but I did post this reasoning here. > > Eduard > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Tom Herbert > Sent: Wednesday, June 23, 2021 6:01 PM > To: 6man <ipv6@ietf.org> > Subject: Fwd: New Version Notification for draft-herbert-6man-eh-limits-00.txt > > Hello, > > I posted a draft that sets various limits for IPv6 extension headers. > This was motivated in part by draft-hinden-6man-hbh-processing and draft-gont-v6ops-ipv6-ehs-packet-drops. > > Thanks, > Tom > > ---------- Forwarded message --------- > From: <internet-drafts@ietf.org> > Date: Tue, Jun 22, 2021 at 6:01 PM > Subject: New Version Notification for draft-herbert-6man-eh-limits-00.txt > To: Tom Herbert <tom@sipanda.io> > > > > A new version of I-D, draft-herbert-6man-eh-limits-00.txt > has been successfully submitted by Tom Herbert and posted to the IETF repository. > > Name: draft-herbert-6man-eh-limits > Revision: 00 > Title: Limits on Sending and Processing IPv6 Extension Headers > Document date: 2021-06-22 > Group: Individual Submission > Pages: 18 > URL: > https://www.ietf.org/archive/id/draft-herbert-6man-eh-limits-00.txt > Status: https://datatracker.ietf.org/doc/draft-herbert-6man-eh-limits/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-herbert-6man-eh-limits > > > Abstract: > This specification defines various limits that may be applied to > receiving, sending, and otherwise processing packets that contain > IPv6 extension headers. The need for such limits is pragmatic to > facilitate interoperability amongst hosts and routers in the presence > of extension headers and thereby increasing the feasibility of > deployment of extension headers. > > > > > The IETF Secretariat > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------
- Fwd: New Version Notification for draft-herbert-6… Tom Herbert
- RE: New Version Notification for draft-herbert-6m… Vasilenko Eduard
- Re: New Version Notification for draft-herbert-6m… Tom Herbert