RE: New Version Notification for draft-herbert-6man-eh-limits-00.txt
Vasilenko Eduard <vasilenko.eduard@huawei.com> Wed, 23 June 2021 17:01 UTC
Return-Path: <vasilenko.eduard@huawei.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 2D3DE3A3DCD for <ipv6@ietfa.amsl.com>; Wed, 23 Jun 2021 10:01:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 13-38V-w7LK0 for <ipv6@ietfa.amsl.com>; Wed, 23 Jun 2021 10:00:55 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A70A3A3DCB for <ipv6@ietf.org>; Wed, 23 Jun 2021 10:00:55 -0700 (PDT)
Received: from fraeml739-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4G98Qv5xM5z6J69R for <ipv6@ietf.org>; Thu, 24 Jun 2021 00:50:47 +0800 (CST)
Received: from msceml705-chm.china.huawei.com (10.219.141.144) by fraeml739-chm.china.huawei.com (10.206.15.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 23 Jun 2021 19:00:50 +0200
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml705-chm.china.huawei.com (10.219.141.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 23 Jun 2021 20:00:47 +0300
Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.2176.012; Wed, 23 Jun 2021 20:00:47 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Tom Herbert <tom@herbertland.com>, 6man <ipv6@ietf.org>
Subject: RE: New Version Notification for draft-herbert-6man-eh-limits-00.txt
Thread-Topic: New Version Notification for draft-herbert-6man-eh-limits-00.txt
Thread-Index: AQHXaECmiX4gHQ2+D0aiZyTSX1PNG6shxHPw
Date: Wed, 23 Jun 2021 17:00:47 +0000
Message-ID: <d9f231b76bd84f00bb830d4c44b9d9e9@huawei.com>
References: <162441011037.16699.15159470178446552952@ietfa.amsl.com> <CAOuuhY_Qv6C4sie0EyWdtHq+fPGmJscVL0ZrQe_hyACBCg8o3A@mail.gmail.com> <CALx6S36Rdc1AEj8ZmwxTp9bnmwjTTUX-VHkW4cLTMycG8z_RWQ@mail.gmail.com>
In-Reply-To: <CALx6S36Rdc1AEj8ZmwxTp9bnmwjTTUX-VHkW4cLTMycG8z_RWQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.201.106]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/SyVhw9eWcZ4Gvmawht7abJyMmN0>
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 17:01:00 -0000
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. 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. 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. 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. 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? 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. 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