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

[Tom Herbert <[e-mail]>]

On Mon, Jul 15, 2019 at 3:01 PM Joe Touch <[e-mail]> wrote:
>
>
>
>
>
> On 2019-07-15 14:43, C. M. Heard wrote:
>
> ...
> > NOTE2: *as repeatedly already noted*, again - GIVEN THIS CONTEXT -
> > there is no utility in the additional pre-option header proposed in
> > draft-herbert-udp-space-hdr-01.
>
> Actually, there is something in the draft that IMO has great utility --
> not the pre-option header per-se, but the **functionality** provided by
> the draft's protocol header packet format. Specifically, that packet
> format allows options to share fate with the payload data that they
> accompany (i.e., either both are accepted and processed or neither is).
>
>
> How is that true? We can't redefine the UDP checksum, which covers the payload.
>
> A legacy receiver doesn't care about the surplus area and can ignore it. At which point, whether the surplus is corrupted or not, a legacy receiver will accept it.
>
> A UDP-option-aware receiver would do the same thing with OCS (as currently defined) as with the one in draft-herbert. Remember, OCS was already redefined before the last IETF to have the same "zero out" property as in draft-herbert-00.
>
>
> ...
> Besides defining a UDP surplus header (USH, Section 2), the draft also
> defines two variations of is usage: a protocol trailer variant (Section
> 2.1) and a protocol header variant (Section 2.2).
>
> In the trailer variant the UDP user data (and padding bytes as needed
> for alignment) precede the USH and trailing options appear at the the
> offset indicated by the UDP Length. It applies only when UDP Length > 8.
> It provides functionality similar to the packet format defined in
> draft-ietf-tsvwg-udp-options-07.
>
> In the header variant the UDP Length is set to 8. The USH immediately
> follows the UDP header (with no padding), the options are next, and the
> payload is last. This is functionally similar to what you get if you
> start with draft-ietf-tsvwg-udp-options-07 and add a "user data" option
> that consumes all trailing bytes, like the modified FRAG proposed in
> https://mailarchive.ietf.org/arch/msg/tsvwg/Wv--BLVMPAX6g5umok9BQsXAEGg.
>
> One can reasonably ask, why on earth would we want both formats? My
> answer is that they provide different but complementary functions.
>
>
> Didn't you just prove they're equivalent to, in essence, LITE and non-LITE?
>
>
> - The trailer variant can be sent to a legacy receiver with a reasonable
> expectation that the user data will be processed normally and the
> options will be ignored.
>
>
> that's how UDP options already work...
>
>
> ...
> - The header variant can be used to safely send options that need to
> share the fate of the payload data that they accompany (the options
> and payload share the same checksum, so both will be discarded if
> the checksum fails).
>
>
> How is this not LITE?
>
> Note, however, that a packet still shows up (albeit zero length) with either approach. So this isn't exactly the same as true fate-sharing.
>
>
> Options that cause the payload to be handled
> differently when they are present fall into that category. Examples
> include FRAG (for obvious reasons), ACS (as data failing the alternate
> checksum would normally be discarded instead of being passed to the
> application), and AE (as data failing authentication or decryption would
> normally be discarded instead of being passed to the application).
>
> Note that draft-herbert-udp-space-hdr-01 stipulates that options which
> cause the payload to be handled differently when they are present may
> reside in the header variant only.
>
> Why is this important?
>
> Clearly, for legacy receivers, options in the trailer cannot be
> guaranteed to share fate with the payload because they discard all
> options. Similarly, if a new option option that affects data
> handling is defined in the future, option-aware receivers that do
> not recognize it will skip over it. These issues can in principle
> be dealt with by insisting (as draft-ietf-tsvwg-udp-options-07 does)
> that options that are not safe to ignore must not be sent without
> prior knowledge (obtained by negotiation or configuration) that the
> target receiver can properly handle them.
>
> BUT, it's not just legacy receivers that feel the impact; option-aware
> receivers treat the entire options trailer as being absent if the option
> checksum fails. If the UDP checksum passes, and there are options that
> change the handling of the preceding payload data, then that data will
> be handled incorrectly. In other words, a correctly implemented receiver
> that recognizes all options nonetheless has the potential to pass
> corrupted data to the application. In my opinion that's not acceptable.
>
>
> That's not a feature of draft-herbert vs the exising UDP options; that is a choice in Sec 8 of udp-options.
>
> We chose to have that case ignore options to emulate legacy receivers; if that's not what we want, we change that rule.
>
> If that rule is changed, then you'd get the fate sharing you seek.
>
> But you can't have it both ways - with either solution. They're the same here. Either failed options means "act like legacy" or it means "fail", but that means that incorrect options would succeed in a legacy receiver but fail in an options-aware one - EITHER WAY.
>
>
>
> AFAICT, draft-ietf-tsvwg-udp-options-07 currently has no means for
> providing the fate-sharing of options and payload.
>
> '
> It does, as shown above.
>
>
>
>
>
> The protocol header
> format in draft-herbert-udp-space-hdr-01 does. I'd like to see
> draft-ietf-tsvwg-udp-options-07 revised to provide that functionality.
>
> I have my own ideas on how best to do that, but I am going to hold them
> in abeyance for a later time because I think it's much more important
> for us to discuss whether I am correct to insist on the need for an
> option and payload fate-sharing capability for protocol correctness.
>
>
> I agree with that - let's decide what functionality we want and THEN figure out how to deliver it. Or at least separate those two discussions where possible.
>
> However, header/trailer is a misnomer. It's really about whether and how much to use LITE.
>
I disagree. We have at least thirty years experience with protocol
_headers_ on the Internet. All implementations have been tuned for
them, and it would be naive to think that introducing protocol
trailers in data path protocols won't cause issues with established
deployment (some have already been highlighted). IMO, it is a very
relevant and pertinent question as to whether IETF wants to pursue
protocol trailers in data path protocols at this time.

Tom

> Joe
>