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

[Bob Hinden <[e-mail]>]

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.


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

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