Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-22.txt

[Tom Herbert <[e-mail]>]

On Sat, Jun 10, 2023 at 11:29 AM [e-mail]
<[e-mail]> wrote:
>
> ….
> > On Jun 10, 2023, at 10:41 AM, Tom Herbert <tom=[e-mail]> wrote:
> >
> > On Sat, Jun 10, 2023 at 10:10 AM [e-mail]
> > <[e-mail]> wrote:
> >>
> >>
> >> On Jun 10, 2023, at 8:40 AM, Tom Herbert <[e-mail]> wrote:
> >>
> >> On Fri, Jun 9, 2023 at 8:30 PM [e-mail]
> >> <[e-mail]> wrote:
> >> ...
> >> By expecting implementations that do more to allow more, the current wording both avoids that lock-in and allows more modest implementations - e.g., that don’t have resources to enable 100 options - to not need to support packets with 100 options.
> >
> > If different implementations are allowed to choose different protocol
> > parameters then that reduces interoperability;
>
> This isn’t a protocol parameter. Many protocols have different expectations for how widely each option is supported - see TCP, e.g.
>
> >> ...
> >> Adapted to the implementation. It does not talk about adaptive algorithms.
> >>
> >> As above, this just indicates that lesser implementations can allow less, but full-featured ones need to accommodate more.
> >>
> >> for a new protocol that hasn't yet seen any
> >> deployment. So much simpler to just set a limit. So we can assume the
> >> default limit will be locked in globally, and once systems are
> >> deployed changing those limits takes years as legacy systems are
> >> replaced.
> >>
> >>
> >> How’s that working out for IPv6? (It doesn’t - once you set the bar low, that’s it).
> >
> > You're asking the wrong question.The right question is "how did
> > defining unlimited options work out for out for IPv6?”.
>
> The right question is “how is treating every unexpected behavior as an attack working out”?
>
> And it isn’t.

Yes, but that's the network providers that do that. If you ignore
that, then the protocol faces a long road to be ever deployed. As I
already mentioned, if someone sees a problem with UDP Options and
calls up their provider, the network provider's response is most
likely to start dropping packets with UDP surplus. Creating a filter
on their edge devices to do that is trivial, debugging and trying to
fix the problem isn't. This is the biggest risk UDP Options faces for
real work deployment, so there really needs to be good answers to
potential problems in the protocol specification.

>
> Further, IPv6 options involve intermediate nodes that need to invest resources. UDP options do not.
> (Which is why limited HBH options is appropriate, but limiting destination options is not).

Because host processing is free? I assure you it's not. TLV processing
is a very expensive operation rather done in hardware or software,
both in complexity as well as power consumption. Sending options or
receiving options that are mostly ignored is a blatant waste of energy
even if it's not a DOS attack. If you don't believe me, take your UDP
Options implementation, send the receiving host packet with long lists
of options and measure CPU utilization to see what happens...

This discussion makes me wonder if it's time for IETF to require an
"Energy Considerations" section in RFCs! Power consumption for
processing a protocol is a first class issue now, even if it's not a
DOS attack.

>
> > Conversely,
> > one could ask "how did limited options work out for TCP?"
>
> Well, then not so well:
>
Good luck getting consensus on that!

> See draft-ietf-tcpm-tcp-edo and the numerous attempts to extend an option space that isn’t sufficient now, but at the time “40 bytes” was a specific limitation.
>

Yes, I've looked at draft-ietf-tcpm-tcp-edo. It's basically
undeployable since it breaks common TCP hardware offloads.

> See also MP-TCP and numerous methods to try to treat other portions of TCP segments as option space as well.
>
> Joe
>