Re: [tsvwg] draft-ietf-udp-options issues from IETF 104

[Tom Herbert <[e-mail]>]

On Tue, Jul 16, 2019 at 3:15 PM Joe Touch <[e-mail]> wrote:
>
>
>
>
>
> On 2019-07-16 15:06, Tom Herbert wrote:
>
> On Tue, Jul 16, 2019 at 2:44 PM Joe Touch <[e-mail]> wrote:
>
>
>
>
>
> On 2019-07-16 14:37, Tom Herbert wrote:
>
> On Tue, Jul 16, 2019 at 2:25 PM Joe Touch <[e-mail]> wrote:
>
> ...
> We CAN easily set a limit IF we went.
>
> We don't need to design that into the protocol structure. And we don't need to start with something that already impacts things like fragmentation/reassembly, LITE, etc. where the final user data is inside the options area.
>
> Additionally, the comparison to IP is misleading; these are endpoint options and should not have the same kinds of limits as per-hop.
>
> IPv6 has destination options for which limits are applied by Linux.
>
>
> Linux is not an example of how to follow specs; if anything, it's THE example to the contrary.
>
That statement is not at all true nor remotely constructive.

>
>
> Finally, the "realities of deployment" should not be designed or limited by what is currently available. UDP hasn't been updated in many decades; I hope we won't need to come back and re-do this in 5 years just because we're too focused on current technology.
>
>
> Tell that to the IPv6 guys ;-) It has taken years to derive a
> deployable solution and that has included real world considerations
> like DOS. IMO, it is wise to learn from that experience.
>
> Consider in the UDP options draft:
>
>  [NOTE: Tom Herbert suggested we declare "more than 3 consecutive
>    NOPs" a fatal error to reduce the potential of using NOPs as a DOS
>    attack, but IMO there are other equivalent ways (e.g., using
>    RESERVED or other UNASSIGNED values) and the "no more than 3"
>    creates its own DOS vulnerability)
>
> Okay, so there is no limit to number of NOPs in a packet.
>
>
> No, it's still under discussion.

As it has been for over year :-( In any case, I don't think I'll
comment any more on this until someone tries to push UDP Options into
Linux without any reasonable limits for DOS mitigation.

>
> The problem is the cost of the limit creates its own DOS.
>
>
> So per the
> draft we could full up an MTU or even a maximum size IP packet with
> NOPs. That's going to wreak havoc on a receiver and hence is a great
> DOS attack. If you don't believe, please run the experiment in your
> implemenation and see what happens to your CPU utilization.
>
>
> Receivers can do whatever they want to check without us setting protocol limits.
>
> A good implementation (of anything) checks resources and limits overuse. Period. We should not need to set limits to make that happen.
>
> Besides, such limits *change over time and depend on a particular system's resources* anyway.
>
> One size does not fit all for all time.
>
> Joe