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

From: Ron Bonica <[email-masked]>
Date: Fri, 10 Jul 2020 18:18:08 +0000

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://tools.ietf.org/html/draft-herbert-6man-icmp-limits-03.

- 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

Juniper Business Use Only

-----Original Message-----
From: Tom Herbert <[email-masked]> 
Sent: Friday, July 10, 2020 1:13 PM
To: Ron Bonica <[email-masked]>
Cc: Pengshuping (Peng Shuping) <[email-masked]>; [email-masked]
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=[email-masked]> 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 <[email-masked]> On Behalf Of Pengshuping (Peng 
> Shuping)
> Sent: Thursday, July 2, 2020 12:07 PM
> To: [email-masked]
> 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: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, July 2, 2020 11:31 PM
> To: Lizhenbin <[email-masked]>; Pengshuping (Peng Shuping) 
> <[email-masked]>
> 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
> [email-masked]
> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00dbzuCmO7S4CG2fZYHGYeOXYwVmtNT
> FnzgEBbFhyl$
> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!!NEt6yMaO-gk!Qu9y9Ou2SvlYIZjMQa3hBXcu08HG3W4BBIcFoOHCfp41HtkdIYuDs
> XM8uyxPWt9N$
> --------------------------------------------------------------------

---

From: Tom Herbert <[email-masked]>
Date: Fri, 10 Jul 2020 11:29:10 -0700

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

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 10 Jul 2020 20:32:28 +0200

IMHO: See my email earlier in the thread about punting stuff to slow-path, especially when/before
you figure out that you should have just ignored something at linerarte.

Aka: not sufficiently prescriptive RFCs + bad implementations == extension header based features killed in deployments.

Cheers
    Toerless

On Fri, Jul 10, 2020 at 11:29:10AM -0700, Tom Herbert wrote:
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

-- 
---
[email-masked]

---

From: Ron Bonica <[email-masked]>
Date: Fri, 10 Jul 2020 18:43:59 +0000

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

-----Original Message-----
From: Tom Herbert <[email-masked]> 
Sent: Friday, July 10, 2020 2:29 PM
To: Ron Bonica <[email-masked]>
Cc: Pengshuping (Peng Shuping) <[email-masked]>; [email-masked]
Subject: Re: Death by extension header (was:RE: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt)

On Fri, Jul 10, 2020 at 11:18 AM Ron Bonica <[email-masked]> wrote:
> 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$ .
>

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

> > IETF IPv6 working group mailing list [email-masked] Administrative 
> > Requests:
> > IETF IPv6 working group mailing list [email-masked] Administrative 
> > Requests:

---

From: Tom Herbert <[email-masked]>
Date: Fri, 10 Jul 2020 12:35:25 -0700

> 1) unrecognized (ACT 00, 01, 10, and 11)

Anything other than ACT 00 behavior is probably unnecessary at a
router. In the same way that RFC8200 allows ignoring the HBH EH, it
makes sense they can ignore individual options and never send an ICMP
error for unrecognized options regardless of the ACT bits. The end
host can take care of sending the ICMP error if the option is
unrecognized by everyone.

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

Then that goes back to the question of what options _require_ slow
path processing. It's unclear which ones do and which ones don't and I
suspect there's no uniformity across implementations here. What if
routers just ignore those options that they think need to be processed
in the slow path? What would that break given that they can already
ignore all the HBH options anyway per RFC8200?

Tom

---

From: Warren Kumari <[email-masked]>
Date: Fri, 10 Jul 2020 16:13:10 -0400

On Fri, Jul 10, 2020 at 2:32 PM Toerless Eckert <[email-masked]> wrote:

> Aka: not sufficiently prescriptive RFCs + bad implementations == extension
> header based features killed in deployments.
>

Ah, that is my cue:
https://www.ietf.org/archive/id/draft-taylor-v6ops-fragdrop-02.txt (expired
in 2013) and
https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-03 (expired
in 2016).

I'm sure that this is once again going to devolve into the standard "But
you shouldn't!!!! It kills puppies" vs "I have a network to run; I'm not
just going to let anything in" vs "Here is some real world data" thread.
Even with the spec changes, there is still ample evidence that deployed
hardware barfs on these, and so...

W

> > > 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://tools.ietf.org/html/draft-herbert-6man-icmp-limits-03.
> > >
> > > - 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,
> >
> > > > 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:
> > > >
> > > > 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,
> > >
> > > 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.
> > > We certainly welcome the feedback from router vendors whether these
> mitigations are sufficient to make HBH options deployable.
> > >
> > > Tom
> > >
> > > > 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
> > > >
> > > > 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.
> > > >
> > > > 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:
> > > > 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
> > > >
> > > >

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Ron Bonica <[email-masked]>
Date: Fri, 10 Jul 2020 20:37:34 +0000

Tom,

There is no uniformity regarding which options can be processed on the fast path. It is very likely that one implementation will be able to process Option X on the fast path while and another implementation will not.

Given that, when people specify new options, they should probably observe the following guidelines:

1) Make the option as simple as possible, increasing the likelihood that nodes along the delivery path can support it on  their fast path
2) Set the ACT bits to 00, unless ignoring this particular option would somehow be harmful

                                                                                                                           Ron

-----Original Message-----
From: Tom Herbert <[email-masked]> 
Sent: Friday, July 10, 2020 3:35 PM
To: Ron Bonica <[email-masked]>
Cc: Pengshuping (Peng Shuping) <[email-masked]>; [email-masked]
Subject: Re: Death by extension header (was:RE: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt)

> 1) unrecognized (ACT 00, 01, 10, and 11)

Anything other than ACT 00 behavior is probably unnecessary at a router. In the same way that RFC8200 allows ignoring the HBH EH, it makes sense they can ignore individual options and never send an ICMP error for unrecognized options regardless of the ACT bits. The end host can take care of sending the ICMP error if the option is unrecognized by everyone.

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

Then that goes back to the question of what options _require_ slow path processing. It's unclear which ones do and which ones don't and I suspect there's no uniformity across implementations here. What if routers just ignore those options that they think need to be processed in the slow path? What would that break given that they can already ignore all the HBH options anyway per RFC8200?

Tom

> Subject: Re: Death by extension header (was:RE: New Version 
> Notification for draft-li-6man-hbh-fwd-hdr-00.txt)
>
> > > - Because HBH was a DoS vector, network operators deployed ACLs 
> > > that discard packets containing HBH
> > > ------------------------------------------------------------------
> > > -- IETF IPv6 working group mailing list [email-masked] 
> > > 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 [email-masked] 
> > > Administrative
> > > Requests:
> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/
> > > ip
> > > v6
> > > __;!!NEt6yMaO-gk!Qu9y9Ou2SvlYIZjMQa3hBXcu08HG3W4BBIcFoOHCfp41HtkdI
> > > Yu
> > > Ds
> > > XM8uyxPWt9N$

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 10 Jul 2020 23:02:04 +0200

Ron,

IMHO, we just need to agree on a "tagging" of options that we feel confident
can be supported by all platforms that WANT to support an option in the fast
path. And that does not increase overhead in processing for those nodes
that DO NOT WANT to support the option. The existing extension header structure
may not be that tagging. Maybe we need something else than the IPv6 packet header
structure (gee, so sorry for surprising everybody here by saying that ;-)

The MALICE draft evolved from using STUN cookie DPI to solve this problem.
Not creating any overhead for routers who do not care, and still easy enough
to extract for routers that do care. Of course this is the reactive solution
when you can not proactive build  an appropriate network header. If would
be great if IETF would finally conclde that we should open up the discussion
how to build better network headers to solve problem like this

I am happy to concede that this may be beyond something to directly go to
6man, e.g.: maybe a stage of IRTF work needed on this. But ultimately:
If we do not do this, than any on-path processing will be done long term
solely through application level gateways by proprietary siloed distributed
applications, and the network layer is completely commoditized, if not
eliminated. We alreadyy had this in industrial networks in the 80th/90th
in europe, when TP4 was run directly on top of ethernet without Ethernet
instead of TP4. And the same trend is visible in todays manufacturing/
industrial networks.

Just saying

Cheers
    Toerless

i don't know if there will be a 

-- 
---
[email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Jul 2020 14:43:25 -0300

On 10/7/20 17:13, Warren Kumari wrote:
> 
> 
> On Fri, Jul 10, 2020 at 2:32 PM Toerless Eckert <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Aka: not sufficiently prescriptive RFCs + bad implementations ==
>     extension header based features killed in deployments.
> 
> 
> Ah, that is my cue: 

Curiously enough, draft-gont-v6ops-ipv6-ehs-packet-drops was kind of 
shot down at the time since it was seen as an invitation for operators 
to drop packets that contain EHs (!) -- which honestly feels a bit like 
shooting the messenger.

> just going to let anything in" vs "Here is some real world data" thread.

Just a humble minor correction ;-) : I think there's only two real "vs": 
the real world data is essentially in the same camp as "I have a network 
to run", since measurements essentially measure what folks that run 
networks do, as opposed to what folks that publish specs say.

draft-gont-v6ops-ipv6-ehs-packet-drops essentially tried to analyze why 
the numbers in RFC7872 were what they were. Curiously enough, at the 
time when RFC7872 was adopted and published we were requested to strip 
any sort of rationale for the packet drops from RFC7872, which I guess 
helped the idea of some that folks dropping these packets are just 
irrational.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Jul 2020 15:00:44 -0300

> Aka: not sufficiently prescriptive RFCs + bad implementations == extension header based features killed in deployments.

Indeed. And add to that that the EH structure itself seems to be rather 
unfriendly with some popular hardware architectures. (unless with "not 
sufficiently prescriptive RFCs" you are meaning to set the maximum 
EH-header chain length to some sane value that folks might agree to 
comply with).

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Tom Herbert <[email-masked]>
Date: Mon, 13 Jul 2020 11:11:31 -0700

> EH-header chain length to some sane value that folks might agree to

RFC8504 implicitly does that for number of Hop-by-Hop or Destination
options in a packet:

"A host MAY impose a limit on the maximum number of non-padding
options allowed in the destination options and hop-by-hop extension
headers.  If this feature is supported, the maximum number SHOULD be
configurable, and the default value SHOULD be set to 8."

The default value of eight was derived from the number of already
defined options, extrapolation of new options that might be defined
and deployed, and discussions with some HW vendors that they can
efficiently process a small number of TLVs (as opposed to hundreds in
a packet that are possible without a limit).

Tom

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Jul 2020 15:33:47 -0300

> a packet that are possible without a limit).

Kudos to RFC8504 and authors for that- That said, given that options may 
have a rather unlimited length, is that enough? It would seem to me that 
the most important thing is that E-H header length, as opposed to the 
length of individual options, or ther number of options...

Thanks,

---

From: Tom Herbert <[email-masked]>
Date: Mon, 13 Jul 2020 11:53:08 -0700

> length of individual options, or ther number of options...

Fernando,

draft-ietf-6man-icmp-limits-08 defines the ICMP errors for limits of
number of options, length of extension headers, length of extension
header chain, etc. However, I don't believe any default limits are
suggested other than the RFC8504 limits.

Wrt byte length, the most interesting limit with regards to routers is
when the aggregate length of the header chain exceeds the size of the
parsing buffer in the device. As I understand it common lengths of
parsing buffers are 128, 256, or 512 bytes. That might suggest the
default minimum should be 128 bytes or maybe 256 bytes. That is, we
would expect that routers should be able to process IP header,
extension headers, and first four bytes of transport header (e.g. to
get ports for ECMP) fit in the parsing buffer in the first N bytes of
the packet. We can narrow this down if the standard is followed such
that routers only process the IPv6 and HBH headers, intermediate
destinations in a routing header only process headers through the
routing header, and end hosts process all options.

Tom

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 13 Jul 2020 21:18:32 +0200

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

-- 
---
[email-masked]

---

From: Tom Herbert <[email-masked]>
Date: Mon, 13 Jul 2020 12:31:18 -0700

> protocol specs in this respect.

Toerless,

I wouldn't expect any IETF to use the term "slow path" and "fast
path". RFCs tend to describe protocol behavior and generally
themselves don't care whether they are processed in a slow path or
fast path as long as the external behavior is conformant. If you want
to make these terms explicit it seems like we would need to quantify
in exact terms what a slow path is and exactly what a fast path is--
that is, they need normative definitions if we are to set normative
requirements around them.

Tom

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 13 Jul 2020 21:33:51 +0200

> routing header, and end hosts process all options.

Indeed, the parsing depth is a key criteria. There is also the
question of how high the cost of rewrites in the packet header is.
That is much less clear to me. Programming languages like P4 make
it look as if you could arbitrarily reshuffle headers, but the
compiled code might expose extremely different performance output
based on the amount of rewrites.

For example, when we do PE-P-PE designs, we typically create a new
additional encap to minimize lookup depth for P nodes. And the overhead
of this is particularily big for IPv6. Leander headers or reordering
header fields might be a better cost effective option going forward.
Hard to say. Would be great to collect researched data points.

Cheers
   Toerless

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 13 Jul 2020 21:36:42 +0200

> requirements around them.

Exactly. thats why i was suggestive text with relative performance
specs. This is difficult, and new territory for us to explore for
future specs. Once we think we can come up with text we feel confident
with we can go back to name calling.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 13 Jul 2020 22:01:41 +0200

On Mon, Jul 13, 2020 at 03:00:44PM -0300, Fernando Gont wrote:
> sufficiently prescriptive RFCs" you are meaning to set the maximum EH-header
> chain length to some sane value that folks might agree to comply with).

I think we might want to start with a draft collecting what we think to
kow about the problem and figure out if we can structure it accordingl
to make sense out of it to make progress that is not just incrementally fixing
one single bit. 

Cheers
    Toerless

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Jul 2020 16:33:37 -0300

Hello, Tom,

On 13/7/20 15:53, Tom Herbert wrote:
[....]
> suggested other than the RFC8504 limits.

Yep, that's what I meant.

> parsing buffer in the device. 

Indeed.

> As I understand it common lengths of

Please see: 
https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-03 . 
Folks need to look deeper. SO unless the entire length of the EH chain 
is limited, this problem will be faced.

Indeed, the longer the EH-chain length, the higher the chances of 
packets being dropped -- as per RFC7872 and others.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Jul 2020 17:17:54 -0300

> to make sense out of it to make progress that is not just incrementally fixing

We already did that: 
https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops

Thanks,

---

From: Tom Herbert <[email-masked]>
Date: Mon, 13 Jul 2020 13:26:28 -0700

Fernando,

Yes, the practical limit is probably to be able to parse all IP
headers and at least four bytes of transport layer headers. There is
some ambiguity when encapsulation is present since packets may have
multiple transport layer headers in the presence of encapsulation and
whether network devices should be parsing into encapsulations (which
may not even be possible in many cases).

One comment about draft-gont-v6ops-ipv6-ehs-packet-drops-03:

"However, we note that for a long time many IPv6 implementations
failed to set the Flow Label, and ECMP and Hash-based Load-Sharing
devices also did not employ the Flow Label for performing their task."

I believe the first part of this statement has been addressed, all
major OSes set the flow label AFAIK. Hopefully, devices are migrating
to use flow labels for ECMP.

---

From: Ron Bonica <[email-masked]>
Date: Mon, 13 Jul 2020 20:29:52 +0000

Toerless,

Are we trying to fix an implementation problem with a protocol change?

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.

                                                                      Ron

-----Original Message-----
From: Toerless Eckert <[email-masked]> 
Sent: Monday, July 13, 2020 3:19 PM
To: Ron Bonica <[email-masked]>
Cc: Tom Herbert <[email-masked]>; [email-masked]
Subject: Re: Death by extension header (was:RE: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt)

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:
> __;!!NEt6yMaO-gk!TyC_ZXb3C9EvO8vGJVxVflVTXAD5z8RJ-wPORIx9ZaWOT1mdd12ER
> 4MKte7T8QdN$

--
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 13 Jul 2020 23:11:46 +0200

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

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

-- 
---
[email-masked]

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Tue, 14 Jul 2020 03:35:26 +0000

> From: ipv6 [mailto:[email-masked]] On Behalf Of Tom Herbert
> Sent: Tuesday, July 14, 2020 3:31 AM
> To: Toerless Eckert <[email-masked]>
> Cc: Ron Bonica <rbonica=[email-masked]>; [email-masked]
> > 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.
> >
> 
> Toerless,
> 
> I wouldn't expect any IETF to use the term "slow path" and "fast path". RFCs
> tend to describe protocol behavior and generally themselves don't care
> whether they are processed in a slow path or fast path as long as the
> external behavior is conformant. If you want to make these terms explicit it
> seems like we would need to quantify in exact terms what a slow path is and
> exactly what a fast path is-- that is, they need normative definitions if we are
> to set normative requirements around them.

But do we still need to differentiate "control plane" and "forwarding plane"? The processing capability in bps and pps of the two planes are different, so the corresponding terms are used as "slow path" and "fast path", respectively. 

There are some HBH options such as RA* that carry the information that need to be consumed by the "control plane", so they will be sent to the "control plane" anyway. While other HBH options carry the information that will not be consumed by the "control plane" but still sent to the "control plane" / "slow path", which cause problems.

* https://www.iana.org/assignments/ipv6-routeralert-values/ipv6-routeralert-values.xhtml#ipv6-routeralert-values-1

Shuping

> > 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
> >
> > > Given that you parse the extension header chain on the fast path, HBH
> and destination options can be categorized as follows:
> > >
> > > 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
> > >
> > >
> > >
> > >
> > >
> > > > 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-6ma
> n-icmp-limits-03__;!!NEt6yMaO-gk!XnKPvkz9vBtVNlSCx0SqcojVpo2uBgeSDJ
> zZEJa2fLd1NTKb53H0w3Ue2Xxv7iGB$ .
> > > >
> > > > - 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,
> > >
> 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
> > > >
> > > >
> > > >
> > > > On Fri, Jul 10, 2020 at 7:59 AM Ron Bonica
> <rbonica=[email-masked]> wrote:
> > > > >
> > > > > Peng,
> > > > >
> functions that are executed on the slow path to fail. These critical functions
> include routing and network management.
> > > > >
> > > > > - 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,
> > > >
> issues faced by the Hop-by-Hop Options Header, which has been sparsely
> used without any form of large scale deployment.
> > > > >
> https://urldefense.com/v3/__https://www.ietf.org/internet-drafts/draft-li-6
> man-hbh-fwd-hdr-00.txt__;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00d
> bzuCmO7S4CG2fZYHGYeOXYwVmtNTFnzgB-bqLrg$
> > > > > Status:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-li-6man-
> hbh-fwd-hdr/__;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00dbzuCmO7S
> 4CG2fZYHGYeOXYwVmtNTFnzgM5iPE22$
> > > > > Htmlized:
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-li-6man-hbh-f
> wd-hdr-00__;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00dbzuCmO7S4C
> G2fZYHGYeOXYwVmtNTFnzgPvsH43l$
> > > > > Htmlized:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-li-
> 6man-hbh-fwd-hdr__;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00dbzuC
> mO7S4CG2fZYHGYeOXYwVmtNTFnzgBQxbwZb$
> > > > >
> > > > >
> > > > > Abstract:
> submission until the htmlized version and diff are available at tools.ietf.org.
> > > > >
> > > > > The IETF Secretariat
> > > > >
> > > > >
> > > > > ----------------------------------------------------------------
> > > > > ---- IETF IPv6 working group mailing list [email-masked]
> > > > > Administrative
> > > > > Requests:
> > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinf
> > > > > o/ip
> > > > > v6
> > > > >
> __;!!NEt6yMaO-gk!QoInpMGHwaC7LsKAVISa9A00dbzuCmO7S4CG2fZYHGYe
> OXY
> > > > > wVmt
> > > > > NT
> > > > > FnzgEBbFhyl$
> > > > > ----------------------------------------------------------------
> > > > > ---- IETF IPv6 working group mailing list [email-masked]
> > > > > Administrative
> > > > > Requests:
> > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinf
> > > > > o/ip
> > > > > v6
> > > > >
> __;!!NEt6yMaO-gk!Qu9y9Ou2SvlYIZjMQa3hBXcu08HG3W4BBIcFoOHCfp41H
> tk
> > > > > dIYu
> > > > > Ds
> > > > > XM8uyxPWt9N$
> > > Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 14 Jul 2020 02:37:12 -0400

>From a historical perspective the slow path and fast path has some vendor
connotations into it “cxxxx”.

I think any document within the IETF  should stay clear of anything that is
a vendor terminology.

The concept of “punt” meanIng send to control plane also has vendor
connotation and should not be used.

I personally like control plane and data plane processing of extension
headers.

Gyan

On Mon, Jul 13, 2020 at 11:35 PM Pengshuping (Peng Shuping) <
[email-masked]> wrote:

> But do we still need to differentiate "control plane" and "forwarding
> plane"? The processing capability in bps and pps of the two planes are
> different, so the corresponding terms are used as "slow path" and "fast
> path", respectively.
>
> There are some HBH options such as RA* that carry the information that
> need to be consumed by the "control plane", so they will be sent to the
> "control plane" anyway. While other HBH options carry the information that
> will not be consumed by the "control plane" but still sent to the "control
> plane" / "slow path", which cause problems.
>
> *
> https://www.iana.org/assignments/ipv6-routeralert-values/ipv6-routeralert-values.xhtml#ipv6-routeralert-values-1
>
> Shuping
>
> >
> > Tom
> >
> > > > > I am forking a new thread since this is not directly related to
> Shuping's
> > draft.
> > > > >
> > > > > >    sparsely used without any form of large scale deployment.
> Also,
> > most
> > > > > > ----
> > > > > > ----
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 14 Jul 2020 09:36:12 +0200

Hi Gyan,

On Tue, Jul 14, 2020 at 02:37:12AM -0400, Gyan Mishra wrote:
> connotations into it ???cxxxx???.

I think its used pretty consistently throughout the industry.
If you have an example of a router that has something other vendors
would call slowpath but calls it differently, i would be interested to
know such alternative terms.

> I think any document within the IETF  should stay clear of anything that is

Definitely agreed if something is really specific to a subset of vendors
instead of the most widely used term. I think its the most widely used term.

> The concept of ???punt??? meanIng send to control plane also has vendor

I think the same applies here as what i said above for slow/fast path.

Btw: these are just comments about my best understanding about terminology.
Not an endorsement to base any upcoming work on those terms. I already
sent emails as to the opposite.

> I personally like control plane and data plane processing of extension

Do you have a good definition for control-plane and data-plane processing ?
E.g.: inband-signaling, is that decidedly control-plane for data-plane
to you ?

Cheers
   Toerless

-- 
---
[email-masked]

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 14 Jul 2020 19:00:12 +0000

BFD is a control function by definition, but is executed on the line card.
Is it in the data plane or the control plane?
A label action that causes a second lookup may occur in one pass or
may require to recirculate the packet for a second pass.
To walk the list of extension headers to find the TCP ports to run an ACL
may be done inline or require more passes.
How slow is the slow path?

Regards,
Jakob.

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Toerless Eckert
Sent: Tuesday, July 14, 2020 12:36 AM
To: Gyan Mishra <[email-masked]>
Cc: Ron Bonica <rbonica=[email-masked]>; [email-masked]
Subject: Re: Death by extension header (was:RE: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt)

Hi Gyan,

Cheers
   Toerless

-- 
---
[email-masked]

---

From: Tom Herbert <[email-masked]>
Date: Tue, 14 Jul 2020 12:23:55 -0700

> How slow is the slow path?

There was a time when TCP SYNs were processed in the slow control
plane path, but then that gave rise to some very effective SYN attacks
and we quickly realized that they really need to be processed in the
fast path. Subsequently, we have seen this story line repeat itself
time and time again at several levels of the stack: "slow path" in the
data path == "DOS vector" in the data path. The answer is either to
change the implementation to be able to process more efficiently, or
to limit the processing it's willing to do which is okay if the
potential limits are commonly understood.

Tom

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 14 Jul 2020 15:31:10 -0400

There are routers with no "fast path".  (Or maybe they have no "slow path"?)
There are routers with more than one tier of "slower" path.

There are meaningful distinctions in protocol design about what kind of 
processing is required.   Trying to distinguish in protocol design 
between fast path and slow path tends to be counter productive and 
misleading.

Tom's examples are good ways of seeing how misleading it can be.
Yours,
Joel

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 14 Jul 2020 21:39:45 +0200

I am watching this thread and have one question ... how any draft can
mandate to any implementation how it should process a packet ?

One implementation can use 100% programmable hardware, the other can not.
Some process all packets in CPUs. Some may offload some processing to on
line card CPU vs punting it to RE/RP.

Some may punt only first packet and then install forwarding state in the
dataplane so any subsequent packets are fully hardware switched.

I am really not sure what is the value of this thread ....

Many thx,
R.

On Tue, Jul 14, 2020 at 9:24 PM Tom Herbert <[email-masked]> wrote:

> path".
> > > > RFCs
> > > > > seems like we would need to quantify in exact terms what a slow
> path is
> > > > and
> > > > > exactly what a fast path is-- that is, they need normative
> definitions
> > > > if we are
> > > > > > > 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
> > > > > > > On Fri, Jul 10, 2020 at 11:18 AM Ron Bonica <
> [email-masked]>
> > > > > wrote:
> > > > > > > >
> > > > > > > > Tom,
> > > > > > > >
> > > > > > > > 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
> > > > > > > > - The total number of options contained by all instances of
> the
> > > > HBH and
> limits
> > > > > suggested in that doc. Do you think this is sufficient in routers
> to get
> > > > past the
> > > > > DOS concern?
> > > > > > >
> > > > > > > Tom
> > > > > > >
> > > > > > > >
> > > > > > > > Ron
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > latched on to a problem that needs to be solved. HBH Options, as
> they
> > > > were
> > > > > > > > > When IPv6 was first implemented on high-speed routers
> (circa
> > > > 2000),
> > > > > Control Lists (ACLs) that discard all packets containing HBH
> Options.
> > > > This
> > > > > > > > I think there were "protocol problems" in the original
> design of
> > > > HBH.
> > > > > > > > > From: ipv6 <[email-masked]> On Behalf Of
> Pengshuping
> > > > > > > > > (Peng
> > > > > > > > > Shuping)
> > > > > > > > > We have just uploaded a new draft aiming to analyze and
> tackle
> > > > the
> > > > > > > > >    each hop in the delivery path of the packet.  However,
> RFC8200
> > > > > also
> > > > > > > > >    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
> > > > > > > > >    For these reasons, over time, the Hop-by-Hop Options
> header
> > > > > has been
> > > > > > > > >    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
> https://www.ietf.org/mailman/listinfo/ipv6
> > > > >

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 15 Jul 2020 00:34:44 +0200

> Is it in the data plane or the control plane?

Good example.

On way to look at it is that we say we have management, control and data plane at
each layer, and i don't even have an idea what explicitly belongs to which of the
three (someone else can figure it out).

But forwarding plane are considerations that may be applied to elements of
management,control and data-plane and that relate to desigining functionality so it
can execute well on constrained HW. from low-power/bitrate/cpu IOT to Tbps
functionality constrained core routers.

> How slow is the slow path?

Right. IMHO we could say "slowpath" and fastpath should just be historic terms.

maybe we think about building blocks used to build management/control/data-planes:
forwarding, compute, inference - just to give examples of the three typical
HW building blocks one could find.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 15 Jul 2020 00:54:21 +0200

Robert: i think this is the core question, and i don't think the answer
is simple or that we can have a generic one. I think we need to test possible text.

For my beloved simple example of router-alert, requirements i already mentioned
in a prior email here could be e.g.:

- A packet with router alert and a specific "value" field MUST be forwarded
  at "roughly" same performance as the same packet without the rouer alert IF
  the "value" function is not enabled/configured.  (roughly = 80% or better).

- Enabling a router-alert "value1" functionality MUST NOT impact the performance
  with which packets with a non-enabled "value2" router alert option are forwarded.

That looks like the most simple, first type of performance requirement to discuss,
if we ever would feel safe to write something like that into a new RFC for a new
router-alert like forwarding plane feature. If we are not, then IMHO we are
effectively aborting a solution like router-alert.
  
There are a lot more difficult questions to answer, but i think it would be highly
worthwhile to try. Relative performance requirements are always a good trick too...

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 14 Jul 2020 20:00:52 -0400

Sorry I was thinking “cisco fast switching”

My fault I am good with those fast and slow and agree that is industry
standard nomenclature.

Fast path = line rate processing in hardware data plane path

Slow path = requires extra NPU control plane packet processing and is
processed In software and can impact control plane

On Tue, Jul 14, 2020 at 3:36 AM Toerless Eckert <[email-masked]> wrote:

> not
> > > > seems like we would need to quantify in exact terms what a slow path
> is
> > > and
> > > > > > On Fri, Jul 10, 2020 at 11:18 AM Ron Bonica <[email-masked]
> >
> > > > wrote:
> > > > > > >
> > > > > > > Tom,
> > > > > > >
> > > > suggested in that doc. Do you think this is sufficient in routers to
> get
> > > past the
> > > > DOS concern?
> > > > > >
> > > > > > Tom
> > > > > >
> > > > > > >
> > > > > > > Ron
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I think there were "protocol problems" in the original design
> of
> > > HBH.
> > > > > > > >    configuration of each node across the path.  Moreover, in
> most
> > > > of
> > > > > > > >    networks today, the processing of the HBH header is done
> in
> > > the
> > > > > > > >    forwarding plane information that needs not to be sent to
> the
> > > > control
> > > > > > > >    plane.
> > > > > > > >
-- 

*Gyan Mishra*

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 14 Jul 2020 17:04:12 -0700

slow path usually means - punted to the central CPU (that runs control plane)

Cheers,
Jeff
On Jul 14, 2020, 5:01 PM -0700, Gyan Mishra <[email-masked]>, wrote:
> My fault I am good with those fast and slow and agree that is industry standard nomenclature.
>
> Slow path = requires extra NPU control plane packet processing and is processed In software and can impact control plane
>
>
>
> > > instead of the most widely used term. I think its the most widely used term..
> > >
> > > > > > > > > > Let's continue to work on a solution..
> > > > > > > > > >
> > > > > > > > > >
> > > > > > Ron
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > ipv6@ietf..org
> Gyan Mishra
> Network Solutions Architect
> M 301 502-1347
> 13101 Columbia Pike
> Silver Spring, MD
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Jul 2020 12:14:29 +1200

> slow path usually means - punted to the central CPU (that runs control plane)

And isn't it true to say that the punting occurs when the packet header is such that it cannot be processed by whatever ASIC or FPGA happens to be present in the particular box? In other words, it is *not* because the header contains an option that is specified to be "slow path" by nature; it's dependent on the exact design of the router model.

   Brian

>> On Tue, Jul 14, 2020 at 3:36 AM Toerless Eckert <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     Hi Gyan,
>>
>>     > [email-masked] <mailto:[email-masked]>> wrote:
>>     >
>>     > >
>>     > >
>>     > > > From: ipv6 [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Tom Herbert
>>     > > > To: Toerless Eckert <[email-masked] <mailto:[email-masked]>>
>>     > > > Cc: Ron Bonica <rbonica=[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>>     > > > On Mon, Jul 13, 2020 at 12:18 PM Toerless Eckert <[email-masked] <mailto:[email-masked]>> wrote:
>>     > > > >
>>     > > > > > From: Tom Herbert <[email-masked] <mailto:[email-masked]>>
>>     > > > > > To: Ron Bonica <[email-masked] <mailto:[email-masked]>>
>>     > > > > > Cc: Pengshuping (Peng Shuping) <[email-masked] <mailto:[email-masked]>>;
>>     > > > > > [email-masked] <mailto:[email-masked]>
>>     > > > > > On Fri, Jul 10, 2020 at 11:18 AM Ron Bonica <[email-masked] <mailto:[email-masked]>>
>>     > > > wrote:
>>     > > > > > >
>>     > > > > > > Tom,
>>     > > > > > >
>>     > > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-herbert-6ma <https://urldefense.com/v3/__https://tools.ietf..org/html/draft-herbert-6ma>
>>     > > > > > > From: Tom Herbert <[email-masked] <mailto:[email-masked]>>
>>     > > > > > > To: Ron Bonica <[email-masked] <mailto:[email-masked]>>
>>     > > > > > > Cc: Pengshuping (Peng Shuping) <[email-masked] <mailto:[email-masked]>>;
>>     > > > > > > [email-masked] <mailto:[email-masked]>
>>     > > > <rbonica=[email-masked] <mailto:[email-masked]>> wrote:
>>     > > > > > > >
>>     > > > > > > > Peng,
>>     > > > > > > >
>>     > > > > > > > From: ipv6 <[email-masked] <mailto:[email-masked]>> On Behalf Of Pengshuping
>>     > > > > > > > (Peng
>>     > > > > > > > Shuping)
>>     > > > > > > > To: [email-masked] <mailto:[email-masked]>
>>     > > > > > > > From: [email-masked] <mailto:[email-masked]> [mailto:[email-masked] <mailto:[email-masked]>]
>>     > > > > > > > To: Lizhenbin <[email-masked] <mailto:[email-masked]>>; Pengshuping (Peng Shuping)
>>     > > > > > > > <[email-masked] <mailto:pengshuping@huawei..com>>
>>     > > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-li-6man-hbh-f <https://urldefense.com/v3/__https://tools.ietf..org/html/draft-li-6man-hbh-f>
>>     > > tools.ietf.org <http://tools.ietf.org>.
>>     > > > > > > >
>>     > > > > > > > The IETF Secretariat
>>     > > > > > > >
>>     > > > > > > >
>>     > > > > > > > ---- IETF IPv6 working group mailing list [email-masked] <mailto:[email-masked]>
>>     > > > > > > > Administrative
>>     > > > > > > > Requests:
>>     > > > > > > > ---- IETF IPv6 working group mailing list [email-masked] <mailto:[email-masked]>
>>     > > > > > > > Administrative
>>     > > > > > > > Requests:
>>     > > > > > IETF IPv6 working group mailing list [email-masked] <mailto:[email-masked]> Administrative
>>     > > > > [email-masked] <mailto:[email-masked]>
>>     > > >
>>     > > > ipv6@ietf..org <mailto:[email-masked]>
>>     > > [email-masked] <mailto:[email-masked]>
>>     [email-masked] <mailto:[email-masked]>
>>
>> --
>>
>> /Network Solutions A//rchitect /
>>
>> /M 301 502-1347
>> 13101 Columbia Pike 
>> /Silver Spring, MD
>>
>>

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 14 Jul 2020 20:42:01 -0400

Yep agreed.

On Tue, Jul 14, 2020 at 8:04 PM Jeff Tantsura <[email-masked]>
wrote:

>> > > > > > > > <[email-masked] <pengshuping@huawei..com>>
> > > > ipv6@ietf..org <[email-masked]>
>
>
> *M 301 502-1347 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g> *Silver
> Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g>
>

*Gyan Mishra*

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 15 Jul 2020 02:48:51 +0200

Brian,

Slowpath/fastpath predate ASIC/FPGA, otherwise you're right.

On Wed, Jul 15, 2020 at 12:14:29PM +1200, Brian E Carpenter wrote:
> >> Sorry I was thinking ???cisco fast switching??? 
> >>

-- 
---
[email-masked]

---

From: Philip Homburg <[email-masked]>
Date: Wed, 15 Jul 2020 11:33:08 +0200

>I am really not sure what is the value of this thread ....

Maybe it is not so much about implementation details but about
externally observable effects.

If adding a particular type of extension header makes throughput go down by
90% then starting to use that extension header on a large scale may become
a problem.

If the first packet with a particular destination is slow then using lots of
IPv6 addresses (for example one per process on a host) may overload a router,
etc.

So 'fast path' could be specified as within x% of the throughput/delay of a
packet without the extension header.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 15 Jul 2020 10:36:00 +0100

It can be useful to use terms like "fast path" and "slow path" but there 
is a spectrum and too often the terms are used in way which 
over-simplifies operational reality.

Packets can be processed on a pipelined system which will ~ guarantee 
processing within a specific time period.

Packets can be processed on run-to-completion silicon which will handle 
more complex packets, but where the complexity of the packet has a cost 
in terms of processing capacity.

Packets can be recirculated back to the ASIC or NPU.  This will result 
in a ~linear drop in both performance and processing capacity.

"Fast path" could refer to a different packet forwarding algorithm 
deployed on a CPU-forwarded device, in comparison to the "slow path" 
which just hooks into a bunch more processing subroutines (e.g. current 
Mikrotik processing, or the original "ip route-cache" on Cisco"

More complex packets can be punted to a control plane, or dropped 
unconditionally, or forwarded unconditionally.  The dividing line 
between what constitutes a more complex packet will vary from device to 
device and is highly dependent even on things like software / firmware 
version.

A management plane might be a CPU that runs the BGP / IGP processes, or 
it might be a line card CPU or it might be a core on one or other of these.

There are "management plane" features that can be run almost directly 
from NPUs and forwarding plane packet categories that are 
unconditionally punted.

The link from the forwarding plane to the management plane might be 
inline or OOB, and if it's effectively OOB, it might be large or small, 
or it could be that these terms are subjective.  So for example in 2020, 
a 1G management plane link might be sufficient to handle all management 
traffic on a device, but from a different perspective that could be 
considered tiny, e.g. in relation to the total throughput of the device 
or by comparison to residential last mile access which often runs at 1G 
on fibre.

There are devices currently available on the market which do all these 
things, and lots more.  It's a messy world out there.

In terms of protocol design and management, there's no such thing as a 
free lunch.  The more complex something is, in any dimension, the higher 
the cost.

Regardless of how tempting it might be to berate manufacturers who cut 
corners to make things work, this is how things work in the real world. 
There is no compelling commercial case to make a device which costs 10x 
or 100x just so that it can handle lots of corner cases and little-used 
features which not that many are interested in paying for.

 From a protocol design point of view, what's important is not pointing 
finger when this happens, but understanding that all complexity has a 
cost and that when this impinges too much on real-world applications, 
the protocol or protocol proposal needs to be examined.

Nick

Jeff Tantsura wrote on 15/07/2020 01:04:
>>     > > > From: ipv6 [mailto:[email-masked]
>>     <mailto:[email-masked]>] On Behalf Of Tom Herbert
>>     > > > Cc: Ron Bonica <rbonica=[email-masked]
>>     <mailto:[email-masked]>>; [email-masked]
>>     <mailto:[email-masked]>
>>     > > > On Mon, Jul 13, 2020 at 12:18 PM Toerless Eckert
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>     > > > >
>>     > > > I wouldn't expect any IETF to use the term "slow path" and
>>     "fast path".
>>     > > RFCs
>>     > > > seems like we would need to quantify in exact terms what a
>>     slow path is
>>     > > and
>>     > > > > > 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
>>     > > > > > On Fri, Jul 10, 2020 at 11:18 AM Ron Bonica
>>     <[email-masked] <mailto:[email-masked]>>
>>     > > > wrote:
>>     > > > > > >
>>     > > > > > > Tom,
>>     > > > > > >
>>     > > > > > > 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
>>     <https://urldefense.com/v3/__https://tools.ietf..org/html/draft-herbert-6ma>
>>     > > >
>>     > > > > > > - An individual extension header is longer than the
>>     node can
>>     > > > > > > process
>>     > > > > > > - The total number of options contained by all
>>     instances of the
>>     > > HBH and
>>     > > > suggested in that doc. Do you think this is sufficient in
>>     routers to get
>>     > > past the
>>     > > > DOS concern?
>>     > > > > >
>>     > > > > > Tom
>>     > > > > >
>>     > > > > > >
>>     > > > > > > Ron
>>     > > > > > >
>>     > > > > > >
>>     > > > > > >
>>     > > > <rbonica=[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>     > > > > > > >
>>     > > > > > > > Peng,
>>     > > > > > > >
>>     > > > latched on to a problem that needs to be solved. HBH
>>     Options, as they
>>     > > were
>>     > > > > > > > When IPv6 was first implemented on high-speed
>>     routers (circa
>>     > > 2000),
>>     > > > > > > > To mitigate this DoS vulnerability, many operators
>>     deployed
>>     > > Access
>>     > > > > > > > containing HBH, network designers stopped defining
>>     new HBH
>>     > > > > > > > Options
>>     > > > options was in retrospect too austere, and the possibility
>>     that an
>>     > > attacker
>>     > > > > > > I believe these problems have been addressed in
>>     RFC8200 and
>>     > > > RFC8504.
>>     > > > > > > > From: ipv6 <[email-masked]
>>     <mailto:[email-masked]>> On Behalf Of Pengshuping
>>     > > > > > > > (Peng
>>     > > > > > > > Shuping)
>>     > > > > > > > We have just uploaded a new draft aiming to analyze
>>     and tackle
>>     > > the
>>     > > > > > > > From: [email-masked]
>>     <mailto:[email-masked]> [mailto:[email-masked]
>>     <mailto:[email-masked]>]
>>     > > > > > > > To: Lizhenbin <[email-masked]
>>     <mailto:[email-masked]>>; Pengshuping (Peng Shuping)
>>     > > > > > > > <[email-masked]
>>     > > > > > > > A new version of I-D,
>>     draft-li-6man-hbh-fwd-hdr-00.txt has been
>>     <https://urldefense.com/v3/__https://tools.ietf..org/html/draft-li-6man-hbh-f>
>>     > > > > > > >    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
>>     > > > > > > >    For these reasons, over time, the Hop-by-Hop
>>     Options header
>>     > > > has been
>>     > > > > > > >    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
>>     > > > > > > >    processed by the forwarding plane.  This new HBH
>>     header is
>>     > > > confined
>>     > > > > > > >    in and dedicated to the forwarding plane while
>>     the current HBH
>>     > > > header

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 15 Jul 2020 15:40:27 +0200

> externally observable effects

But the point is that those effects will differ vendor to vendor ...
implementation by implementation ... product line by product line all for
the very same packet on the wire (or in the fiber).

One box for the very same extension header processing can be lightning fast
and the other terribly slow as some vendor can not handle it in their data
plane or perhaps just does not want to.

So what do you do ? Do you want to state that given extension must be
supported in fast path by all vendors before it is published as an RFC ?

Thx,
R.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 15 Jul 2020 16:34:32 +0200

Latest dedicated firewalls will likely forward by CPU-flexible forwardine
plane elements, so if the packet can be parsed, a dedicated firewall is the likely
best device to do it. Comes with the territory. But given how end-to-end
encryption is making the classical firewall filtering less and less relevant,
firewalls struggle at a different level.

But firewall functionality is in every router these days, and the faster they
are, the worse typically their ability to corectly process christmas tree packets.

Also remember that the one key aspecct you didn't metion in your writeup below
is the state based forwarding, where you e.g.: have five-tuple forwarding
plane lookup and associated policies (block, permit, do-something-with-its-packets),
and you only punt packets for unknown flow so that the "foobar-plane" can
decide if/what new flow entry to create. I am saying foobar, because i am
not sure whether i wanted to call this 'punt-path' control plane. Classically
i think wee would have said so, but you can see how fuzzy these terms become
the closer you look at actual implementations.

Cheers
    Toerless

On Wed, Jul 15, 2020 at 02:59:52AM -0400, Gyan Mishra wrote:
> The slow & fast path concept has been around for decades as has been
> mentioned.  On older software based platforms, all feature processing was
> done in software, so there was a control plane hit for most every feature
> or any packet processing that required header lookup or IP options
> processing had a control plane hit.
> 
> Earlier on,  most routers were software based single processor, but as
> the routers got bigger and  became distributed processors with NPU per LC
> FIB data plane line rate processing in hardware became the new Norm.
> 
> The concept of "punting" to control plane in basic terms originally was
> coined for any flow that was router bound would be processed by the control
> plane thus a "processor hit" such as routing protocols packets.
>  Regardless of hardware or software based platforms distributed or
> centralized processor all router bound packets routing protocol packets
> ospf,bgp,isis etc hits the control plane for processing.
> 
> On most hardware based platforms both single or multi distributed processor
> platforms for many years  processing ACL, QOS, NAT has been done in
> hardware line rate in the data plane "forwarding plane".
> 
> A lot of what use to be done in the "slow path" control plane hit has
> transitioned to the data plane "fast" path at line rate including some EH
> processing.
> 
> There has been a lot of improvement over the years across vendor hardware
> related to EH processing and header chains.
> 
> However since the header chain is not bounded to a max allowed,  I guess
> with massive header chains you can still end up in the slow path even with
> high end routers. I think that's the major worry with operators and dropped
> packets from EH headers DDOS, especially with hbh.
> 
> I think the one big issue with header chains which I believe Fernando had
> written some documents on related to firewalls processing with EH chains as
> the transport layer comes after all the header chains,  that EH processing
> could break firewall filtering policy.
> 
> Does anyone know if that issue still exists today with firewalls vendors
> and EH processing especially with large header chains?
> 
> Gyan
> 
> 
> 
> 
> On Tue, Jul 14, 2020 at 8:48 PM Toerless Eckert <[email-masked]> wrote:
> 
> > Brian,
> >
> > > And isn't it true to say that the punting occurs when the packet header
> > is such that it cannot be processed by whatever ASIC or FPGA happens to be
> > present in the particular box? In other words, it is *not* because the
> > header contains an option that is specified to be "slow path" by nature;
> > it's dependent on the exact design of the router model.
> > >
> > >    Brian
> > >
> > > >
> > > > Cheers,
> > > > Jeff
> > > >>     > > > From: ipv6 [mailto:[email-masked] <mailto:
> > [email-masked]>] On Behalf Of Tom Herbert
> > <mailto:[email-masked]>>; [email-masked] <mailto:
> > [email-masked]>
> > > >>     > > > On Mon, Jul 13, 2020 at 12:18 PM Toerless Eckert <
> > [email-masked] <mailto:[email-masked]>> wrote:
> > > >>     > > > >
> > > >>     > > > external behavior is conformant. If you want to make these
> > terms
> > > >>     > > explicit it
> > [email-masked] <mailto:[email-masked]>>
> > > >>     > > > wrote:
> > > >>     > > > > > >
> > > >>     > > > > > > Tom,
> > > >>     > > > > > >
> > <
> > https://urldefense.com/v3/__https://tools.ietf..org/html/draft-herbert-6ma
> > >
> > > >>     > > >
> > > >>     > > > > > > Cc: Pengshuping (Peng Shuping) <
> > [email-masked] <mailto:[email-masked]>>;
> > > >>     > > > Control Lists (ACLs) that discard all packets containing
> > HBH Options.
> > > >>     > > This
> > > >>     > > > > > > I think there were "protocol problems" in the
> > original design of
> > > >>     > > HBH.
> > > >>     > > > > > > > From: ipv6 <[email-masked] <mailto:
> > [email-masked]>> On Behalf Of Pengshuping
> > > >>     > > > > > > > (Peng
> > > >>     > > > > > > > Shuping)
> > > >>     > > > > > > > From: [email-masked] <mailto:
> > [email-masked]> [mailto:[email-masked] <mailto:
> > [email-masked]>]
> > > >>     > > > > > > > To: Lizhenbin <[email-masked] <mailto:
> > [email-masked]>>; Pengshuping (Peng Shuping)
> > <
> > https://urldefense.com/v3/__https://tools.ietf..org/html/draft-li-6man-hbh-f
> > >
> > > >>     > > >
> > > >>     > > > > > > >    expects that nodes processing the HBH header
> > have been
> > > >>     > > > explicitly
> > > >>     > > > > > > >    control plane (slow processing path) which
> > incurs several
> > > >>     > > > limitations
> > > >>     > > > > > > >    forwarding plane information that needs not to
> > be sent to the
> > > >>     > > > control
> > > >>     > > > > > > >    plane.
> > > >>     > > > > > > >
> > > >>     > > > > > > >    order to carry Hop-by-Hop options that are
> > solely intended to
> > > >>     > > > and

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 15 Jul 2020 19:49:18 +0200

Sure, but the simple answer has since been that

a) Expensive firewalls promise to be safe in the face of any christmas tree packet,
   no additional worries required (sales pitch. reality may be different).

b) Any other devices with a firewall type config desired typically have operator
   enabled ACLs that filter out anything that they do not care for or understand,
   including DSCP != 0, ECN != 0, extension headers, ttl < diameter of SP network,
   fragments, port numbers other than 80 and any undesirable destination addresses.

I am of course facetious about some of those filters, but in general one needs to
think about how to evolve IP to a place where this is not necessary, because
operators do not do this to pain users but for valid reasons, of which the
most important on is: Nobody gives me a guarantee this stuff can not cause harm.

And IMHO we can at least ry to write RFCs that will bear this promise when
implementations comply to them, and making it more easy to comply than how
to implement it wrong.

Cheers
    Toerless
 
On Wed, Jul 15, 2020 at 01:18:31PM -0400, Gyan Mishra wrote:
> Thanks Toreless
> 
> >From an operators standpoint the Christmas tree packets is the big worry if
> it creates a hole in the stateful firewall due to incomplete or buffer
> issues related to eh packet processing that creates a DDOS effect.  If you
> hammer enough Christmas tree packets at the firewall that you can create a
> security hole vulnerability.
> 
> Gyan
> 
> On Wed, Jul 15, 2020 at 10:34 AM Toerless Eckert <[email-masked]> wrote:
> 
> > > > > > slow path usually means - punted to the central CPU (that runs
> > control
> > > > plane)
> > > > >
> > > > > > On Jul 14, 2020, 5:01 PM -0700, Gyan Mishra <[email-masked]
> > >,
> > > > wrote:
> > > > > >>     > >From a historical perspective the slow path and fast path
> > has
> > > > some vendor
> > > > > >>     Definitely agreed if something is really specific to a subset
> > of
> > > > vendors
> > > > > >>     instead of the most widely used term. I think its the most
> > widely
> > > > used term..
> > > > > >>
> > > > > >>     I think the same applies here as what i said above for
> > slow/fast
> > > > 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
> > > > > >>     > > > tend to describe protocol behavior and generally
> > themselves
> > > > don't care
> > > > > >>     > > > whether they are processed in a slow path or fast path
> > as
> > > > long as the
> > > > > >>     > > plane"? The processing capability in bps and pps of the
> > two
> > > > planes are
> > > > > >>     > > different, so the corresponding terms are used as "slow
> > path"
> > > > and "fast
> > > > > >>     > > path", respectively.
> > > > > >>     > >
> > > > > >>     > > need to be consumed by the "control plane", so they will
> > be
> > > > sent to the
> > > > > >>     > > will not be consumed by the "control plane" but still
> > sent to
> > > > the "control
> > > > > >>     > > > > 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
> > > > > >>     > > > > > Given that you parse the extension header chain on
> > the
> > > > fast path, HBH
> > > > > >>     > > > > > Types 1 and 2 cannot be used in a DoS attack,
> > because
> > > > they are never
> > > > > >>     > > > > > > I am forking a new thread since this is not
> > directly
> > > > related to
> > > > > >>     > > Shuping's
> > > > > >>     > > > draft.
> > > > > >>     > > > > > >
> > > > > >>     > > > > > > - The extension header chain is longer than the
> > node
> > > > can process
> > > > > >>     > > > > > 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
> > > > > >>     > > > > > > > While your solution may require refinement, I
> > think
> > > > that you have
> > > > > >>     > > > HBH options were not yet well-understood and ASICs were
> > not
> > > > so capable as
> > > > > >>     > > > 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
> > > > > >>     > > > > > > > - An implementation problem caused HBH to
> > become a
> > > > DoS vector
> > > > > >>     > > > > > > > - Because HBH was a DoS vector, network
> > operators
> > > > deployed ACLs
> > > > > >>     > > > could stuff a packet with hundreds of bogus options,
> > only
> > > > limited by MTU,
> > > > > >>     > > > > > > We certainly welcome the feedback from router
> > vendors
> > > > whether these
> > <https://www.google.com/maps/search/%3E+Sent:+Thursday,+July+2,+2020+12:07+PM?entry=gmail&source=g>
> > > > > >>     > > > release the benefits that could be provided by HBH
> > Options
> > > > header
> > > > > >>     > > > altogether.
> > > > > >>     > > > > > > >
> > > > > >>     > > > > > > > Best regards,
> > > > > >>     > > > > > > > Shuping
> > > > > >>     > > > > > > >
> > > > > >>     > > > > > > > <[email-masked] <mailto:
> > pengshuping@huawei.
> > > > .com>>
> > > > > >>     > > > > > > >    among which resources consumption and
> > security
> > > > risk.
> > > > > >>     > > > > > > >

-- 
---
[email-masked]