Re: HBH Obsolete? (was Review of draft-ietf-6man-hbh-header-handling-01)

[Ronald Bonica <[e-mail]>]

Folks,

Having read through this email thread, the following are a few observations. Again, we have three options:

1) Tighten up HBH handling (as currently proposed in draft-ietf-6man-hbh-header-handling)
2) Follow the path of RFC 7045. Repurpose draft-ietf-6man-hbh-header-handling to document the implications of that decision
3) Deprecate the HBH Options Extension Header

Nobody (including me) is crazy about Option 1. We have heard support for Options 2 and 3. So, let's consider those.

When the HBH Options Extension Header was conceived, the founding fathers couldn't foresee what kind of options would be defined in the future. Given twenty years of hindsight, we now can categorize HBH Option into the following categories:

- Forwarding plane options
- Control plane options

A forwarding plane option contains information required to forward the packet. That information can be discarded as soon as the packet has been forwarded. The Jumbogram HBH Option is an example of a forwarding plane option. 

A control plane option contains information that is used to create or destroy more persistent state on an intermediate node. The router alert option is an example of a forwarding plane option.

If we pursue Option 2, forwarding plane options will work, but applicability will be limited to the following scenarios:

- the information carried by the forwarding option is not critical. The packet can be forwarded even if the intermediate node ignores the option
- the information carried by the forwarding plane is critical. The packet cannot be forwarded if the intermediate node ignores the option. However, the sender is certain that every intermediate node that the packet traverses will process the option.

Control plane options may not have been a very good idea in the first place. As Fernando is fond of pointing out, they expose the control plane to untrusted parties, increasing the attack surface of the intermediate node. There are better ways to establish state in intermediate nodes

If we were to adopt Option 2, control plane options would work, but would be limited to the following scenarios:

- A protocol uses HBH to establish state on intermediate nodes, but that state isn't so critical that the protocol will not work unless that state is not established
- A protocol uses HBH to establish state on intermediate nodes. That state is critical and the protocol will not work unless that state is not established. However, the sending station is certain that every node along the path will process the option

The following is my personal opinion and possibly the end of rational discourse:

We should follow both options 2 and 3. For the time being, we should follow the path of RFC 7045 and repurpose draft-ietf-6man-hbh-header-handling to document the implications of that decision. We should also revisit protocols that rely on HBH, determining whether 7045 breaks any of them.

Regarding Option 3 draft-ietf-6man-hbh-header-handling should also say:

- that the IETF will never standardize another HBH Option
- that the IETF will never standardize another protocol that relies on HBH

In my mind, this is what it means to deprecate HBH.

Comments?

                            Ron Bonica