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

[Gyan Mishra <[e-mail]>]

Yep agreed.

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

> 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 <[e-mail]>,
> wrote:
>
> 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 <[e-mail]> wrote:
>
>> Hi Gyan,
>>
>> On Tue, Jul 14, 2020 at 02:37:12AM -0400, Gyan Mishra wrote:
>> > >From a historical perspective the slow path and fast path has some
>> vendor
>> > 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
>> > a vendor terminology.
>>
>> 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
>> > connotation and should not be used.
>>
>> 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
>> > headers.
>>
>> 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
>>
>> > Gyan
>> >
>> > On Mon, Jul 13, 2020 at 11:35 PM Pengshuping (Peng Shuping) <
>> > [e-mail]> wrote:
>> >
>> > >
>> > >
>> > > > -----Original Message-----
>> > > > From: ipv6 [mailto:[e-mail]] On Behalf Of Tom Herbert
>> > > > Sent: Tuesday, July 14, 2020 3:31 AM
>> > > > To: Toerless Eckert <[e-mail]>
>> > > > Cc: Ron Bonica <rbonica=[e-mail]>;
>> [e-mail]
>> > > > Subject: Re: Death by extension header (was:RE: New Version
>> Notification
>> > > > for draft-li-6man-hbh-fwd-hdr-00.txt)
>> > > >
>> > > > On Mon, Jul 13, 2020 at 12:18 PM Toerless Eckert <[e-mail]>
>> wrote:
>> > > > >
>> > > > > 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.
>> > > > >
>> > > >
>> > > > 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
>> > >
>> > > >
>> > > > Tom
>> > > >
>> > > > > 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:
>> > > > > > 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
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > Juniper Business Use Only
>> > > > > >
>> > > > > > -----Original Message-----
>> > > > > > From: Tom Herbert <[e-mail]>
>> > > > > > Sent: Friday, July 10, 2020 2:29 PM
>> > > > > > To: Ron Bonica <[e-mail]>
>> > > > > > Cc: Pengshuping (Peng Shuping) <[e-mail]>;
>> > > > > > [e-mail]
>> > > > > > Subject: Re: Death by extension header (was: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 11:18 AM Ron Bonica <
>> [e-mail]>
>> > > > wrote:
>> > > > > > >
>> > > > > > > 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://urldefense.com/v3/__https://tools.ietf.org/html/draft-herbert-6ma
>> > > > n-icmp-limits-03__;!!NEt6yMaO-gk!XnKPvkz9vBtVNlSCx0SqcojVpo2uBgeSDJ
>> > > > zZEJa2fLd1NTKb53H0w3Ue2Xxv7iGB$ .
>> > > > > > >
>> > > > > > > - 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,
>> > > > > >
>> > > > > > 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
>> > > > > >
>> > > > > > >
>> > > > > > > Ron
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > Juniper Business Use Only
>> > > > > > >
>> > > > > > > -----Original Message-----
>> > > > > > > From: Tom Herbert <[e-mail]>
>> > > > > > > Sent: Friday, July 10, 2020 1:13 PM
>> > > > > > > To: Ron Bonica <[e-mail]>
>> > > > > > > Cc: Pengshuping (Peng Shuping) <[e-mail]>;
>> > > > > > > [e-mail]
>> > > > > > > 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=[e-mail]> 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 <[e-mail]> On Behalf Of Pengshuping
>> > > > > > > > (Peng
>> > > > > > > > Shuping)
>> > > > > > > > Sent: Thursday, July 2, 2020 12:07 PM
>> > > > > > > > To: [e-mail]
>> > > > > > > > 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: [e-mail] [mailto:
>> [e-mail]]
>> > > > > > > > Sent: Thursday, July 2, 2020 11:31 PM
>> > > > > > > > To: Lizhenbin <[e-mail]>; Pengshuping (Peng
>> Shuping)
>> > > > > > > > <[e-mail] <pengshuping@huawei..com>>
>> > > > > > > > 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-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:
>> > > > > > > >    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 [e-mail]
>> > > > > > > > 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 [e-mail]
>> > > > > > > > Administrative
>> > > > > > > > Requests:
>> > > > > > > >
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinf
>> > > > > > > > o/ip
>> > > > > > > > v6
>> > > > > > > >
>> > > > __;!!NEt6yMaO-gk!Qu9y9Ou2SvlYIZjMQa3hBXcu08HG3W4BBIcFoOHCfp41H
>> > > > tk
>> > > > > > > > dIYu
>> > > > > > > > Ds
>> > > > > > > > XM8uyxPWt9N$
>> > > > > > > >
>> ----------------------------------------------------------------
>> > > > > > > > ----
>> > > > > >
>> --------------------------------------------------------------------
>> > > > > > IETF IPv6 working group mailing list [e-mail]
>> Administrative
>> > > > > > Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> > > > > >
>> --------------------------------------------------------------------
>> > > > >
>> > > > > --
>> > > > > ---
>> > > > > [e-mail]
>> > > >
>> > > > --------------------------------------------------------------------
>> > > > IETF IPv6 working group mailing list
>>
> > > > ipv6@ietf..org <[e-mail]>
>
>
>> > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> > > > --------------------------------------------------------------------
>> > >
>> > > --------------------------------------------------------------------
>> > > IETF IPv6 working group mailing list
>> > > [e-mail]
>> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> > > --------------------------------------------------------------------
>> > >
>> > --
>> >
>> > <http://www.verizon.com/>
>> >
>> > *Gyan Mishra*
>> >
>> > *Network Solutions A**rchitect *
>> >
>> >
>> >
>> > *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>>
>> --
>> ---
>> [e-mail]
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *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>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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