RE: New Version Notification for draft-herbert-6man-eh-limits-00.txt

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
--------------------------------------------------------------------