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

[Joe Touch <[e-mail]>]

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. 

Joe