Re: [tsvwg] Rregarding soft-state and UDP options

[Joe Touch <[e-mail]>]

> On Jan 5, 2020, at 3:50 PM, C. M. Heard <[e-mail]> wrote:
> 
> On Sun, Jan 5, 2020 at 12:58 PM Joe Touch wrote:
> As I just posted, at best it would mean “if the following option is not recognized, drop all options”. It should never mean anything else.
> 
> If payload data accompanying options that are not safe to ignore is firewalled behind FRAG+LITE, then dropping all options will accomplish the goal of not delivering data that has not been processed as intended.

Yes - that’s what I’ve been saying.

> 
> Any application that cannot tolerate zero-length messages should never use those options. Any app that handles zero-length options should then work on hosts that support or do not support options that way.
> 
> s/Any app that handles zero-length options/Any app that handles zero-length messages/

Yes…(sorry - that was a typo on my part)

>  
> > I'm open to discussion as to whether a socket read should signal a zero-length datagram and whether delivery of other options in the packet should be suppressed
> 
> Now you’re getting into issues we cannot; it’s all or nothing:
> 
> - all options in the regular space MUST individually be ignored if not supported
> - options in the 253-codepoint space would then cause the options - as a whole - to be dropped
>         if you just wanted the option to be dropped, then the regular code point space would have been sufficient
> 
> I think I see a problem in the above statement of what happens to options in the regular space when it is applied to AE.

AE has two behaviors: E needs to be used with FRAG+LITE. A doesn’t.
...

> In the case where AE is used only for authentication, the above implies that an option-aware receiver that does not support AE would ignore a received AE option and deliver the payload data whether or not it was firewalled by FRAG+LITE. That behavior is different from TCP-AO, at least in the absence of TCP-FO: any data in a SYN segment sent to a receiver that does not understand TCP-AO will not be delivered,

That depends on the final ACK of the three-way handshake. Actually, if the SYN-AO, SYN-ACK-no-AO, ACK completes, then the connection simply downgrades to not using AO. Whether this is allowed by the receiver depends on the AO configuration of the receiver. A non-AO receiver would accept the data just fine.

> since the 3-way handshake will never complete (as you correctly noted, the initiator will drop the SYN-ACK returned by the receiver because it is not signed).

That’s a policy decision by the sender; the sender can send RST or can send ACK - it’s up to the configuration.

> Is this difference intentional? It seems wrong.
>  
> Again, we cannot cause the PACKET to be dropped. If the packet contains regular data, it MUST be delivered to the application.
> 
> Modulo the issue with AE noted above, that works for me as long as the payload data accompanying any option that is not safe to ignore gets firewalled behind FRAG+LITE.

It would.

>  It is up to the receiving application to decide what to do. A receiving app that wants to enforce authentication would drop the packet THEN. UDP cannot.
> 
> If that means that the application will be provided with a configuration parameter (e.g., socket option) that specifies whether datagrams with the AE option that do not match any MKT are accepted or discarded,

Yes, that’s the assumption - we stated the requirement that “senders decide which options to include, receivers decide which options to require” a LOOONG time ago.  The rules I’m explaining here are consistent with that - i.e., it’s up to an option-aware receiver to decide whether options are “all or none” or cause packets to be dropped. That can happen at the app layer or be a configuration of the UDP implementation. 

> I'm OK with that, provided that it applies to all implementations of UDP options. In this case a receiver that implements UDP options but does not support AE is just considered to have an empty set of MKTs.

It does according to the “receiver decides” - that could happen with any option.

> If I have correctly understood what I read, this is the behavior mandated for TCP-AO: RFC5925 Section 7.3 mandates that there be a configuration parameter that can be set to discard segments with the AO option not matching an MKT.

Yes, but that’s not the same as the sender forcing it. We’ve always asserted that receivers can decide what to require - and yes, that can be buried in the OS or UDP implementation. 

> Mike Heard
> 
> P.S. The current draft is unclear whether AE encrypts options or just the payload, as specified in draft-touch-tcp-ao-encrypt. I presume the latter since encrypted options cannot be parsed; but there would then need to be a special provision for payloads that are firewalled behind FRAG+LITE. Hopefully this will be clarified in the next version of the draft.

Just payload. That can be clarified, as you suggest.

Joe