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

[Tom Herbert <[e-mail]>]

Hi Eduard, thanks for the comments. Replies inline.

On Wed, Jun 23, 2021 at 10:01 AM Vasilenko Eduard
<[e-mail]> 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:[e-mail]] On Behalf Of Tom Herbert
> Sent: Wednesday, June 23, 2021 6:01 PM
> To: 6man <[e-mail]>
> 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: <[e-mail]>
> Date: Tue, Jun 22, 2021 at 6:01 PM
> Subject: New Version Notification for draft-herbert-6man-eh-limits-00.txt
> To: Tom Herbert <[e-mail]>
>
>
>
> 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
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------