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

[Gyan Mishra <[e-mail]>]

>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) <
[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]>
> > > > > > 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
> > [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