Re: [v6ops] Call for adoption: draft-peng-v6ops-hbh

[Gyan Mishra <[e-mail]>]

Hi Bob

Responses in-line

Many Thanks

Gyan

On Sun, Sep 12, 2021 at 12:14 PM Bob Hinden <[e-mail]> wrote:

> Gyan,
>
> Thanks, a few points below.
>
> Bob
>
>
> > On Sep 10, 2021, at 7:30 PM, Gyan Mishra <[e-mail]> wrote:
> >
> >
> > Hi Bob
> >
> > Many thanks for your comments and feedback on this draft.
> >
> > Responses in-line
> >
>
> ……..
>
> >
> > 4) Section 7 Requirements
> >
> > This section needs a lot of work, or should be removed.   For example,
> looking at the the first requirement:
> >
> >    *  The HBH options header MUST NOT become a possible DDoS Vector.
> >
> > This has several serious issues.   The first is that any protocol
> mechanism can be used a a DDOS attack vector under the right
> circumstances.   With a MUST NOT this requirement is impossible to meet.
>  The use of upper case RFC8174 key words turns this into a protocol
> specification, I don’t think that would be in scope for V6OPS.
> >
> > Gyan> Good point.  We will reword and remove mention of DDOS vector.
>
> We clearly want to reduce the possibility of the HBH option header to be
> used as a DDOS vector, but the way this was written it would be impossible
> to meet.    It’s still good to mention DDOS, but it needs better scoping.
>

    Gyan> Thanks for the clarification.  Rewrite - HBH options usage should
not result in an DDOS attack vector as a result of control plane processing
of packets that should be processed in the forwarding plane.

>
>
> > The next requirement:
> >
> >    *  HBH options SHOULD be designed so that they don't reduce the
> >       probability of packet delivery.  For example, an intermediate node
> >       may discard a packet because it contains more HBH options than the
> >       node can process.
> >
> > How can you design an HBH option that knows how many options an
> intermediate node (we usually call these routers) can process?   Again,
> it’s a requirement that can’t be met.
> >
> >     Gyan> Good point as well.
> >
> >
> > I have similar comments on the other requirements, but won’t list them
> here.  As I said, this section either needs a lot of work, or should be
> removed.
> >
> >     Gyan>  We will work on revamping this section.  Do you have any
> requirements that you would like to add to an HBH solution?
>
> Perhaps take a look at  draft-hinden-6man-hbh-processing-01 and
> draft-herbert-6man-eh-limits.  These are written with solutions in mind,
> but they do infer requirements.


Gyan> Will do.  Thank you

>
>
> > 5) Section 8.  Migration Strategies
> >
> > This section also has serious issues.   These include:
> >
> > It talks about characterizing options into either control options or
> forward options.   We only have HBH Options, not two types.
> >
> > It says nodes are updated to the proposed behavior introduced in the
> pervious section, but the previous section says requirements.
> >
> > It says edge nodes (we usually call these hosts in IPv6) should check
> whether the packet contains an HBH header with control or forwarding
> options.   This isn’t a good description of how hosts actually work, nor
> are there control or forward options.
> >
> > This section may be a remanent of an earlier version of this draft that
> was proposing different types of HBH options, but can’t really tell.
>  Might be best to remove this section.
> >
> >     Gyan> We have discussed cleaning up this section or removing and now
> based on feedback we are leaning towards removing.
>
> I would support that.


   Gyan> Thank you

>
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*