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

["C. M. Heard" <[e-mail]>]

On Tue, Jul 16, 2019 at 9:18 PM Joe Touch <[e-mail]> wrote:

> Hi, Tom, et al.,
>
> The checksum behavior as described in Sec 8. These were designed based on
> WG discussion to achieve the following properties:
>
> - presence of options should NEVER cause behavior different than at a
> legacy receiver
>         this is why if UDP CS passes but OCS fails, the UDP payload should
> still be passed to the user
>         i.e., it should never be a penalty to use options
>

I have no issue with that action.


> - individual options can cause the receiver to drop the packet when the
> option fails ONLY if both sides agree in advance
>         when that is NOT the case, the success/failure of the option is
> indicated to the user but UDP doesn’t made the decision
>

There is a counter-argument to this: when an option that affects payload
processing is present, and an options-aware implementation does not
understand it, ignoring it and passing the payload data to the application
is clearly incorrect. Such options need (a) to share fate with the payload
(i.e., be covered by the same checksum) and (b) must be marked in the KIND
as requiring that packet to be dropped if they are present. As I have
explained previously, fate-sharing, while unachievable with the protocol
trailer format but can be achieved with a protocol header packet format.


> What changed that makes these incorrect or insufficient?
>

Additionally, it is highly undesirable to loop though the option TLVs prior
to validating the OCS is undesirable.
draft-ietf-tsvwg-udp-options-07#section-8 doesn't account for that.

Admittedly it's taken me a while to figure this out, sorry that I am so
slow on the uptake. But serious bugs do need to be corrected, even if they
are discovered late.

Mike