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

[Tom Herbert <[e-mail]>]

On Wed, Jul 10, 2019, 10:16 PM Joe Touch <[e-mail]> wrote:

> Updating the subject line...
>
> On Jul 10, 2019, at 8:56 PM, Tom Herbert <[e-mail]> wrote:
>
>> ...
>> So it took the better part of a day and quite a few emails to conclude
>> that the only remaining issue in this proposal is one that we’ve already
>> discussed at length.
>>
>
> Hardly the only remaining issue if you're referring to UDP options.
>
>
> Please look at minutes from last IETF. Both the subject of disambiguation
> of surplus space
>
> as well as negotiation of UDP options was raised (i.e. if the receiver
> requires checksum how
>
> does sender know that). I haven't seen these addressed by UDP options
> draft at least…
>
>
> If you review the minutes from IETF 104, you will note that the next steps
> were yours and QUICs, not mine.
>
> But let me jump in:
>
> - regarding other uses of the option space:
> - as I’ve already noted in this thread, this was discussed on this list
> long before IETF 104
> - past uses (if there are any) would be protected (if necessary) by use of
> OCS (when OCS is used)
> - future uses need not be differentiated independently; they should be
> using the UDP option code points instead
>
> Regarding soft-state coordination:
> - Sec 13 already addresses the general notion of soft state in a general
> sense.
> - on 3/20/19, I noted on the list that soft state mechanisms are not
> specified because each option might vary in how this is achieved
> - if this isn’t sufficient, can you please clarify?
>

It's not sufficient. The point of a protocol specification is to describe
how the protocol works, without normative requirements and procedures there
is no interoperability and no robustness.

Consider the proposal that receivers could require optional checksums. How
would the sender know that it must use the checksum option for some
particular peer? This isn't magic, somehow the sender needs to acquire
information about the receiver. That's a protocol. It needs some sort of
negotiation, or probing, or other. And since UDP is stateless "negotiation"
may become obsolete so that fallbacks and periodic renegotiation are needed
which I assume is what you mean by soft state. Furthermore, as reported,
network devices in the path may require the checksum. So the sender needs
to consider how to deal with that, and paths can similarly change so sender
needs to be prepared for that also.

I suggest that you spell out the protocol for receivers requiring
checksums. I don't think the protocol for this is at all trivial, and doing
the exercise to specify the protocol may very well lead you to the
conclusion that it's far simpler to just put checksum in fixed header as
the designers of IP, TCP, and UDP already figured out.

Tom




> Regarding use of options with encrypted transports:
> - I don’t know what “encrypted transports” means
> - UDP options includes AE, which is encryption and compatible with UDP
> options
> - transport *payload* encryption is independent of transport encryption
> and should have no impact on UDP AE
> - nobody from QUIC has contacted me on this issue
>
> Joe
>
>
>