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

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

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.

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/


> > 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 is listed as optional-to-implement in the current draft. If what you are
saying is that an option-aware receiver that does not implement AE should
go ahead and deliver encrypted data to the application, then I would have
to disagree. It is true that such a packet should not be transmitted to a
receiver without assurance -- e.g., though manual configuration -- that the
receiver supports it, but as we all know, configuration errors do occur in
real life.

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, 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). 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 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, 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.

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.

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.