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

[Tom Herbert <[e-mail]>]

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:
>
> ...
>
> IPv6 extension headers began without a limit, and then we realized we
> needed to limit them to fit into one MTU, and then we realized that
> unbounded limits are a good DOS attack vector so we added more limits
> to the receiver which are now default in Linux. Saying that we need
> unlimited options is an academic statement and doesn't reflect
> realities of deployment.
>
>
> 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.


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

In any case, if we don't mention practical limits in the protocol
specification for something that is otherwise unlimited, people will
apply their own limits. I will tell you up front, that if you try to
put this in Linux there will be significant pushback to implement
appropriate limits. We've already went down the DOS path and have
learned the lessons. We apply configurable limits with reasonable
defaults for IPv6 HBH and destination options, and they will be
applied to SR options (it's all the same code which UDP options will
use any way). Limits might be configurable, but we're not going to
allow things in the kernel that are known and obvious DOS vectors. Of
course, if people start coming up with their own limits then that
consequently reduces interoperability.

Tom






> Joe