Subject: Re: [tsvwg] Comments on ietf-106-tsvwg-udp-options

From: "C. M. Heard" <[email-masked]>
Date: Wed, 1 Jan 2020 11:58:42 -0800

On Tue, Dec 31, 2019 at 7:09 AM Joe Touch wrote:

> Thanks for the feedback, Mike.
>

Thank you for the reply.

> Regarding the MUST SUPPORT flag part:
>
> On Dec 29, 2019, at 4:28 PM, C. M. Heard <[email-masked]> wrote:
> ...
> I'll comment when the updated text appears.
>
>
>> - regarding MUST SUPPORT flag
>>
>> The only need for this flag has been data that must not be received by
>> legacy endpoints, e.g., compressed. That's already achievable more
>> flexibly using the FRAG+LITE with pre and post reassembly options. Can
>> anyone show a case this doesn't cover?
>>
>
> I disagree with this characterization, both of the proposed change and
> the purpose that it serves.
>
>
> I made two claims:
> 1. the need is for data that shares fate with the option on legacy
> endpoints (is ignored)
> 2. the need is already addressed by pre and (notably) post-reassembly
> options in FRAG+LITE
> I was assuming FRAG that supports the degenerate case of a single fragment.
>
> During the e-mail discussion in the weeks prior to IETF 105, I proposed
> an additional design requirement to supplement those set forth in
> https://mailarchive.ietf.org/arch/msg/tsvwg/27I9XF-mEdXagcEPah22482v65c
> (and also in the IETF 105 presentation slides).* It was:
>
> - Any option that affects the handling of the user data must share fate
> with that user data,…
>
>
> As noted above, already supported by FRAG+LITE.
>
> in the following sense: either the option and the
> user data are processed together, with the data and option indication
> being delivered to the user if the processing succeeds, or else both are
> discarded, and nothing is delivered to the user. This requirement
> applies to all receivers, legacy or otherwise.
>
>
> That’s accomplished by post-reassembly options.
>
> I do not believe that the spec, either in previous incarnations or in
> its current (-08) form, provides a way to satisfy this requirement. In
> order to fill that (perceived) gap, I proposed that (a) there shall be
> a means to transport user data in the options area with OCS coverage;
>
>
> As noted in the update, OCS covers the entire option area now (which thus
> includes FRAG+LITE).
>
> (b) user data shall be transported using that mechanism whenever it is
> accompanied by an option that affects how it is processed;
>
>
> The user makes this decision by selecting to use an option “post
> reassembly”.
>

OK, I'll wait for the promised update to FRG+LITE appears before I make
further comments.

> and (c)
> the Option Kind space shall be subdivided into two ranges, one for
> options that do not affect the handling of user data and another for
> options that do affect the handling of user data.
>
>
> That’s a mechanism - one that is not needed to achieve the other goals.
>
> Note that (a) and (b) are needed to ensure that user data accompanied by
> an option that affects its processing is not delivered to a legacy
> receiver (which ignores all options) or to an option-aware receiver
> when OCS fails (for in that case, the option-aware receiver also
> ignores the options).
>
>
> a) and b) are already supported.
>
> One way to accomplish (a) would be the version of FRAG proposed in
> https://mailarchive.ietf.org/arch/msg/tsvwg/Wv--BLVMPAX6g5umok9BQsXAEGg
> (other alternatives have also been discussed). I'll defer further
> discussion of the details until after I see the new LITE+FRAG option.
>
> Note that (c) is needed to ensure that user data accompanied by
> an option that affect its processing is not delivered to an option-aware
> receiver that does not recognize the option.
>
>
> We have already described how this should be achieved using soft-state
> negotiation between the endpoints.
>

I have reservations about the adequacy of using soft-state negotiation for
this
purpose. There are two issues I see: (1) the negotiation mechanism in the
current
draft is, in my opinion, underspecified; (2) it won't work for a
unidirectional
communication path. I'll give myself a homework assignment to be done while
I
await the new FRAG+LITE text: prepare text to fix (1) and come up with a
convincing use case for (2).

Thanks & regards,

Mike Heard

---

From: Tom Herbert <[email-masked]>
Date: Wed, 1 Jan 2020 12:24:21 -0800

On Wed, Jan 1, 2020 at 11:59 AM C. M. Heard <[email-masked]> wrote:
>> 1. the need is for data that shares fate with the option on legacy endpoints (is ignored)
>> 2. the need is already addressed by pre and (notably) post-reassembly options in FRAG+LITE
>> As noted in the update, OCS covers the entire option area now (which thus includes FRAG+LITE).
>>
>> The user makes this decision by selecting to use an option “post reassembly”.
>
>
> OK, I'll wait for the promised update to FRG+LITE appears before I make further comments.
>>
>> and (c)
>> We have already described how this should be achieved using soft-state negotiation between the endpoints.
>
>
> I have reservations about the adequacy of using soft-state negotiation for this
> purpose. There are two issues I see: (1) the negotiation mechanism in the current
> draft is, in my opinion, underspecified; (2) it won't work for a unidirectional
> communication path.
+1

More generally, soft-state negotiation has not been specified to show
it's necessary and sufficient or even robust. Until and unless it's
well defined, I don't see how it can claim to achieve any goal or be
referenced in the context of a normative requirement (e.g. from the
draft: ">> UDP options that rely on soft-state exchange MUST allow for
message reordering and loss"-- where presumably "soft-state exchange"
is the same concept as "soft state negotiation" which itself is not
even clear). This issue has been brought up several times on the list
and also at the WG meeting at IETF104. From
https://datatracker.ietf.org/doc/minutes-104-tsvwg/:

Tom: The idea of option negotiation is unclear in the draft, and
needed for options that are not stateless. How do you deal with
unknown options - startling TCP-style negotiated options and stateless
mechanisms as in IPv6.
Gorry (as chair): I agree that clarity is important, please discuss
on the list with Joe - the text needs to be clearer.

The answer to #2, and potential other cases where trying to force
negotiation on an inherently stateless protocol, should follow from a
normative specification of what soft-state negotiation is and how it
works.

Tom

> I'll give myself a homework assignment to be done while I

---

From: Joe Touch <[email-masked]>
Date: Wed, 1 Jan 2020 13:08:05 -0800

(changing the subject to track the thread)

As we’ve said before, soft state negotiation is an application layer issue.

There’s normative text to indicate that this is expected for some uses of these options but it cannot be specified here because it is not internal to UDP.

However - note that soft-state coordination isn’t needed to ensure fate sharing of options and option-modified data. That’s already reliably achieved without soft-state using the existing LITE+FRAG post-reassembly options. The revision integrates LITE+FRAG (as they would not be used independently) but otherwise is basically the same.

Joe

> On Jan 1, 2020, at 12:24 PM, Tom Herbert <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Thu, 2 Jan 2020 08:19:42 -0800

> As we’ve said before, soft state negotiation is an application layer issue.
Pushing the problem to the application layer really doesn't help to
clarify or resolve the issues that have been raised. For instance,
Mike's question on how soft-state negotiation would work for a
unidirectional flow is still valid.

> There’s normative text to indicate that this is expected for some uses of these options but it cannot be specified here because it is not internal to UDP.

Neither are UDP options internal to UDP. If the intent is that is the
draft is adding UDP options to be internal to the protocol in the same
manner as TCP options are internal to TCP, then one would reasonably
expect "UDP option negotiation" to be specified in the manner that TCP
option negotiation is specified for TCP.

>
> However - note that soft-state coordination isn’t needed to ensure fate sharing of options and option-modified data.

The terminology you're using is confusing. In this email both
"soft-state coordination" and "soft state negotiation" are used, but
the draft doesn't mention those but does use the term "soft-state
exchange". I don't see any definitions of these and I'm not even sure
if they all are supposed to mean the same thing. Please clarify this
in the draft and define the terms to make this precise.

> That’s already reliably achieved without soft-state using the existing LITE+FRAG post-reassembly options. The revision integrates LITE+FRAG (as they would not be used independently) but otherwise is basically the same.
>
>From the draft:

"The above requirements prevent using any option that cannot be safely
ignored unless that capability has been negotiated with an endpoint in
advance for a socket pair."

That assumes that negotiation works and sufficient which has yet to be
shown so I see no basis for this statement. However, I will again
point out that the "drop unrecognized options bit" in the option type,
similar to that defined for IPv6 options, is sufficient to prevent a
receiver from ignoring options that cannot safely be ignored (note
this works in the unidirectional flow case for instance).

Tom

---

From: Joe Touch <[email-masked]>
Date: Thu, 02 Jan 2020 13:50:46 -0800

Hi, Tom, 

On 2020-01-02 08:19, Tom Herbert wrote:

>> As we've said before, soft state negotiation is an application layer issue.

We've addressed this too - state negotiation is impossible for
unidirectional flows. Always has been. 

>> There's normative text to indicate that this is expected for some uses of these options but it cannot be specified here because it is not internal to UDP.
> 

The options are carried within UDP and some are internal while others
are not. E.g., FRAG and OCS are strictly internal where others are
primarily useful when passed to the user as "out of band" info (MSS,
REQ/RES, TIME). 

The same is true for TCP options - and TCP options aren't universally
negotiated by TCP. That has to be specified for each option; some are
(and defined as integrated with TCP), some aren't. E.g., TCP-AO isn't
negotiated; it has to be setup in advance. 

>> However - note that soft-state coordination isn't needed to ensure fate sharing of options and option-modified data.
> 

Soft state is a widely known concept. The nuances of coordination vs.
negotiation vs. exchange aren't relevant; they all are used in the same
sense - means to set and refresh state that is considered a hint of
previous context. 

>> That's already reliably achieved without soft-state using the existing LITE+FRAG post-reassembly options. The revision integrates LITE+FRAG (as they would not be used independently) but otherwise is basically the same.
>> 
>> From the draft:
> 
> shown so I see no basis for this statement.

Fair point - that section should discuss the use of soft or hard state
at the user level. Hard user state would provide that assurance. 

> However, I will again
> similar to that defined for IPv6 options,

IP is not a model for transport protocols. There's a reason why some
features were added to IP - some of which *remain unused and
unsupported*. 

And you don't want "drop unrecognized options". You want "drop this
ENTIRE PACKET" if the option isn't recognized. 

a) LITE+FRAG with pre and post options accomplishes this *safely* for
both legacy and option-aware endpoints 

b) an option-required" bit *cannot* accomplish this safely for both
legacy and option-aware endpoints. Legacy endpoints already treat all
options as "silently ignore". 

> is sufficient to prevent a

LITE_FRAG pre and post options already accomplish this. If the
data-modifying options aren't handled properly then the OCS on the
reassembled result would fail. And legacy receivers will ignore it all. 

The option-required bit never works properly for legacy endpoints unless
you design the option to basically *BE* LITE+FRAG (to bury the user data
in the option). We already have a solution that does that more
generally; there's no need for a bit to accomplish this. 

Joe

---

From: Tom Herbert <[email-masked]>
Date: Thu, 2 Jan 2020 14:37:48 -0800

On Thu, Jan 2, 2020 at 1:50 PM Joe Touch <[email-masked]> wrote:
> We've addressed this too - state negotiation is impossible for unidirectional flows. Always has been.
>

Hi Joe,

Where has this been addressed? I see nothing in the draft that
discusses the constraints or requirements like this for soft-state
negotiation.

> The options are carried within UDP and some are internal while others are not. E.g., FRAG and OCS are strictly internal where others are primarily useful when passed to the user as "out of band" info (MSS, REQ/RES, TIME).
>
> The same is true for TCP options - and TCP options aren't universally negotiated by TCP. That has to be specified for each option; some are (and defined as integrated with TCP), some aren't. E.g., TCP-AO isn't negotiated; it has to be setup in advance.
>
>
>
>
> Soft state is a widely known concept. The nuances of coordination vs. negotiation vs. exchange aren't relevant; they all are used in the same sense - means to set and refresh state that is considered a hint of previous context.
>
>
>
> Fair point - that section should discuss the use of soft or hard state at the user level. Hard user state would provide that assurance.
>
>
>
> However, I will again
> IP is not a model for transport protocols. There's a reason why some features were added to IP - some of which *remain unused and unsupported*.
>
> And you don't want "drop unrecognized options". You want "drop this ENTIRE PACKET" if the option isn't recognized.
>
> a) LITE+FRAG with pre and post options accomplishes this *safely* for both legacy and option-aware endpoints
>
> b) an option-required" bit *cannot* accomplish this safely for both legacy and option-aware endpoints. Legacy endpoints already treat all options as "silently ignore".
>
It's simple. Just require that options that cannot be ignored (i.e.
ones with the bit set) can only be sent in LITE+FRAG mode. If the end
point doesn't understand UDP options all it will drop the packet. If
the endpoint does understand UDP options but doesn't understand one
that can't be ignored then the packet will also be dropped. This
procedure works in *all* cases, including unidirectional flows.

> LITE_FRAG pre and post options already accomplish this. If the data-modifying options aren't handled properly then the OCS on the reassembled result would fail. And legacy receivers will ignore it all.
>
> The option-required bit never works properly for legacy endpoints unless you design the option to basically *BE* LITE+FRAG (to bury the user data in the option). We already have a solution that does that more generally; there's no need for a bit to accomplish this.

If you're referring to negotiation, I don't see how that could be
considered more general. We've already pointed out one constraint that
doesn't exist for the drop if not recognized bit (the unidirectional
problem). There are likely other cases where negotiation won't work.

Tom

---

From: Joe Touch <[email-masked]>
Date: Thu, 2 Jan 2020 17:11:12 -0800

> On Jan 2, 2020, at 2:37 PM, Tom Herbert <[email-masked]> wrote:
> 

Sec 13 makes it clear that there is no way to establish state for the first message.

That section also notes that options must be silently droppable until confirmed. it should be clear that a unidirectional flow can’t be confirmed.

> ones with the bit set) can only be sent in LITE+FRAG mode.

OK, we can include that reminder. 

> If the end

Negotiation doesn’t *have to work*. But if you don’t negotiate some sort of state, you can’t use options that can’t be silently dropped - regardless of whether they modify contents or not. That’s already stated in Sec 13.

I’ll certainly look at that section and revise to be more clear.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Thu, 2 Jan 2020 18:03:28 -0800

> Negotiation doesn’t *have to work*. But if you don’t negotiate some sort of state, you can’t use options that can’t be silently dropped - regardless of whether they modify contents or not. That’s a…

Joe,

I don't know what you mean by "Negotiation doesn't *have to work*".
What I do know is that there is insufficient description in the draft
for how a negotiation of options in a stateless protocol like UDP can
generally work correctly or robustly. For instance, by the definition
of "soft-state", it is possible that after negotiation, one side of a
communication reboots and changes its configuration such that the
state held by the peer is out of date. An option previously negotiated
may now be unrecognized by the receiver and thus it would accept an
option that is otherwise supposed to be ignored. It will continue to
incorrectly ignore the option until a renegotiation happens. Ignoring
an option that can't be ignored is fundamentally not correct. TCP does
not have this problem since options that are used on a connection are
explicitly negotiated and connection semantics are used. IPv6 options
solve this problem by the "drop if unrecognized" bit so no negotiation
is ever necessary. It's also easy to contrive other scenarios where
supported options may change between packets (e.g. destination is an
anycast address, NAT state for a UDP flow changes).

What *specifically* in soft-state negotiation prevents these types of
scenarios from leading to the incorrect behavior of a receiver
accepting an option it is supposed to ignore?

Tom

---

From: Joe Touch <[email-masked]>
Date: Thu, 2 Jan 2020 18:23:21 -0800

> On Jan 2, 2020, at 6:03 PM, Tom Herbert <[email-masked]> wrote:
> 

Correct use of options does not require bidirectional negotiation. 

> generally work correctly or robustly.

It’s an application issue. UDP isn’t stateful and these options don’t change that.

> For instance, by the definition
> state held by the peer is out of date.

That’s why it’s called soft, not hard.

> An option previously negotiated
> explicitly negotiated and connection semantics are used.

TCP doesn’t have that problem because it has hard state, not soft state. However, its up to EACH option to decide whether it is negotiated during a SYN exchange or not. If not, then TCP is in exactly the same situation as UDP.

> IPv6 options
> is ever necessary.

That is ONE way to solve things, but its hardly “solved" when nearly nobody uses it.

But it’s also not relevant here because IPv6 baked that rule in from the start. We can’t - there’s NOTHING we can do to make a legacy receiver drop packets with unknown options, regardless of the flags per se. All we can do is design them so the options and data are invisible together, which LITE+FRAG already supports.

> It's also easy to contrive other scenarios where

Yes, and that’s why soft state needs to be updated if used that way.

> accepting an option it is supposed to ignore?

Soft state remains soft. If you need assurances that options fate share with data, LITE+FRAG works. A bit in the option doesn’t.

Joe

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 2 Jan 2020 19:00:24 -0800

On Thu, Jan 2, 2020 at 6:23 PM Joe Touch wrote:

> On Jan 2, 2020, at 6:03 PM, Tom Herbert wrote:
> > IPv6 options
> But it’s also not relevant here because IPv6 baked that rule in from the
> start. We can’t - there’s NOTHING we can do to make a legacy receiver drop
> packets with unknown options, regardless of the flags per se. All we can do
> is design them so the options and data are invisible together, which
> LITE+FRAG already supports.
>

Joe, I think that you are missing an important point here, namely that
the "drop
if unrecognized" flag (or Option Kind encoding rule) is proposed for the
benefit of ***option aware*** receivers, not for the benefit of legacy
receivers. As I stated in the message that started this thread (
https://mailarchive.ietf.org/arch/msg/tsvwg/qUtvvq78nnrizdxZmBuXUuVqPDI):

"Note that (c) is needed to ensure that user data accompanied by
an option that affect its processing is not delivered to an option-aware
receiver that does not recognize the option. As an example, AE
(Authentication and Encryption), as defined in the current spec, affects
the processing of the user data, but an implementation is not required
to support it. More generally, if an option that affects data
handling (such as compression) is defined in the future, option-aware
receivers that implement the current spec won't recognize it. They need
a means to determine whether it's safe to ignore the option and deliver
the user data or whether to discard both the data and the option."

I don't disagree that some sort of option negotiation and soft state is a
necessity, but I do not think that it covers all of the bases, particularly
since (as you note) the state is necessarily soft. It definitely can't
cover unidirectional transfers.

I do agree in principle that use of FRAG+LITE (in a form that includes OCS
over the entire surplus area) plus post-reassembly options addresses (a)
and (b) of my message (though I still reserve the right to comment when I
see the details).

Thanks,

Mike Heard

---

From: Joe Touch <[email-masked]>
Date: Thu, 2 Jan 2020 20:21:44 -0800

> On Jan 2, 2020, at 7:00 PM, C. M. Heard <[email-masked]> wrote:
> 
> Joe, I think that you are missing an important point here, namely that the "drop if unrecognized" flag (or Option Kind encoding rule) is proposed for the benefit of ***option aware*** receivers, not for the benefit of legacy receivers.

FRAG+LITE already provides the behavior you want. The flag option fails to provide correct behavior for unidirectional or failed soft-state receivers - both of which are non-starters. A key requirement is that legacy receivers can silently ignore all options.

…
> I do agree in principle that use of FRAG+LITE (in a form that includes OCS over the entire surplus area) plus post-reassembly options addresses (a) and (b) of my message (though I still reserve the right to comment when I see the details).

AOK. And point taken that the soft state section needs clarification.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Fri, 3 Jan 2020 08:07:24 -0800

> FRAG+LITE already provides the behavior you want. The flag option fails to provide correct behavior for unidirectional or failed soft-state receivers - both of which are non-starters. A key require…

Here is the necessary requirements and text:

"
Options that cannot be ignored by a receiver due to side effects or
other requirements MAY be sent. An option that cannot be ignored is
indicated by the high order of the option type being set to 1 (if the
high order bit of the option type is 0 then the option can be safely
ignored).

If an option that cannot be ignored is received by a node that does
not recognize the option then the packet MUST be dropped. The
following requirements ensure this:

  - Options that cannot be ignored MUST NOT be sent in packets that do
not use FRAG+LITE format. This prevents a legacy receiver from
incorrectly ignoring an unknown option.
  - If an option is received with the high order bit of the bit of the
option type set to 1 and the receiver does not recognize the option,
then the packet MUST be dropped. This covers the case where a receiver
that processes UDP options however doesn't support a particular
received option that cannot be ignored.
"

This requirements yield a correct protocol for ALL CASES including
unidirectional, failed soft-state receivers, multicast, NAT
transitions, anycast, and simple unicast.

Tom

---

From: Joe Touch <[email-masked]>
Date: Fri, 3 Jan 2020 11:04:38 -0800

Tom,

How about providing text of an example of any deployed transport option that modifies content (other than encryption, which is already handled). That was asked several IETFs ago and remains unanswered.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Fri, 3 Jan 2020 11:21:55 -0800

Joe,

Payload compression for example. But, I think you're equating options
that can't be ignored with options that modify the data. They are not
the same thing, the latter is a proper subset of the first. An option
cannot be ignored if it is required to be processed by the receiver
for the packet to be correctly received. For instance, if someone were
to put a virtual network identifier in an option then the option MUST
processed or the packet MUST be dropped. If the receiver ignores the
virtual network identifier and accepts the packet anyway it is
breaking the isolation requirement of virtual networking.

Tom

---

From: Joe Touch <[email-masked]>
Date: Fri, 3 Jan 2020 11:30:10 -0800

How about an example of any *deployed* *transport* option with this property?

Joe

> On Jan 3, 2020, at 11:22 AM, Tom Herbert <[email-masked]> wrote:
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 3 Jan 2020 11:37:34 -0800

Ps - and explain how to differentiate both required and mandatory for legacy receivers. Without frag+lite, because once you have that you’re done and don’t need the bit.

---

From: Tom Herbert <[email-masked]>
Date: Fri, 3 Jan 2020 12:12:17 -0800

Joe,

Options that cannot be ignored (required or mandatory) can ONLY be
sent in a frag+lite mode. The only options that can be sent without
frag+lite are ones that can safely be ignored by a receiver.

When a legacy receiver receives a packet with an option that cannot be
ignored in the frag+lite mode, the receiver drops the packet by virtue
of the receiver not understanding the frag+lite mode (technically, the
receiver will accept the UDP packet with zero payload which presumably
leads to packet being effectively dropped without side effects). This
is the correct behavior with regards to an unrecognized option that
cannot be ignored and is covered by the first requirement.

If a sender sends an option that cannot be ignored without using
frag+lite mode, then that is a protocol error caused by the sender
(i.e. an implementation bug). In this case the behavior at the
receiver is indeterminate.

Tom

---

From: Joe Touch <[email-masked]>
Date: Fri, 3 Jan 2020 12:42:18 -0800

> On Jan 3, 2020, at 12:19 PM, Tom Herbert <[email-masked]> wrote:
> 

Right - that’s why the flag bit isn’t needed.

---

From: Tom Herbert <[email-masked]>
Date: Fri, 3 Jan 2020 13:13:53 -0800

> Right - that’s why the flag bit isn’t needed.
As Mike said: "the "drop if unrecognized" flag (or Option Kind
encoding rule) is proposed for the benefit of ***option aware***
receivers". If a receiver that supports UDP options sees an option
that cannot be ignored (indicated by the high order bit in the option
type) and doesn't recognize the option, then it MUST drop the packet.
This is the second requirement.

Tom

---

From: Joe Touch <[email-masked]>
Date: Fri, 3 Jan 2020 20:35:43 -0800

Lost in this discussion has been an example to motivate the need for “drop if not supported”.

I’ve been asking for this for over a year and yet NO new existing transport examples have been cited. 

The only hypotheticals proposed are content encryption and content compression. Encryption is already supported by the AE option. TCP has a content compression option code point. It was assigned in 1999 with an experimental draft (Bellovin’s) that never made it past -00 individual.

The existing architecture already supports both these examples (i.e., that modify content) using FRAG+LITE as follows:

	- each frag (even if only one) is decrypted/decompressed as processed
	- the frags are OCS-verified after reassembly (frag completion)
	- if decompression or decryption is silently ignored (i.e., if not supported), then the reassembly OCS would fail

No example has been given of a transport protocol need for “drop if the option isn’t supported” that doesn’t modify the frag payload.

—

Right now, until there is consensus otherwise, there isn’t justification to waste half the code point space on  hypotheticals. However, there’s no reason not to assign ONE code point for such use, e.g., as follows:

	option 253 — defined as a prefix to “required options” code points, the next byte defines that code point 
	(these would be assigned as needed and have no relation to the UDP option code point values)

That way there’s support for the *remote* possibility that this feature can be useful without wasting space needlessly - and, as importantly, avoiding the impression that “flipping a bit” can change any option from “optional” to “required”.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Sat, 4 Jan 2020 09:09:37 -0800

Joe,

Section 11 of the draft describes the handling of the unrecognized
options, specifically it says:

 "The above requirements prevent using any option that cannot be
safely ignored unless that capability has been negotiated with an
endpoint in advance for a socket pair."

The referenced requirements are different than what you are describing
here. The draft requirements don't say that an option that cannot be
ignored necessarily modifies a packet. They don't require the
reassembly checksum (the fact that you implicitly required the OCS to
be used above didn't go unnoticed!). The draft requirements do not
limit the extensibility of the protocol for new options that may
added, neither is it necessary to the normative requirements to have
examples from other protocols. The draft requirements don't even
mention that options that cannot be ignored must only be sent in
frag+lite.

As we've stated many times now, the protocol described in the draft is
NOT SUFFICIENT to ensure that a receiver doesn't ignore an option that
cannot be ignored. The fact that you needed to add additional
requirements and restrictions to make the AE option work would seem to
support that conclusion. If these additional requirements are needed
then they should be included in Section 11, and then we can discuss
those in the context of the draft.

Tom

---

From: Joe Touch <[email-masked]>
Date: Sat, 4 Jan 2020 10:11:41 -0800

> On Jan 4, 2020, at 9:09 AM, Tom Herbert <[email-masked]> wrote:
> 
> here.

Yes. That and other issues will be addressed when the draft is revised. These include:

- clarifying the use of soft state (it is NOT the sole means for ensuring unknown options are used, but it remains useful for other optimizations).
- allowing a code point to create a separate table of options that don’t modify the FRAG+LITE data to cause that data to be dropped if not supported
- updating the design goals to explain they are motivated by the unsupported claim that they may be needed in the future and that no examples are given because none have been offered
- and not necessarily using that code point for AE because it the frag reassembly check has always protected against the modified variant (encryption) and it is the receiver’s discretion whether to ever enforce the unmodified variant (authentication) anyway

I.e., yes, once the changes are made, they do assume update *throughout the document* to address related issues.

I have agreed to these changes even though you and others continue to lack any example of the need for such a feature.

What point are you now arguing?

Joe

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 4 Jan 2020 10:44:01 -0800

On Fri, Jan 3, 2020 at 8:36 PM Joe Touch <[email-masked]> wrote:

> No example has been given of a transport protocol need for “drop if the
> option isn’t supported” that doesn’t modify the frag payload.
>

What about ACS? It does not modify the payload, but it affects how the
payload is handled: if the ACS check fails, the payload is not delivered to
the user. Those semantics can be violated if the ACE option is ignored.

That issue is handled in the -08 draft by making it mandatory to recognize
and implement -- a point with which I disagree, as I think it should be
optional to implement. But even if I don't get my way on that, the point
still remains that we can't retroactively make FUTURE options such as ACS
mandatory to implement.

Mike Heard

---

From: Joe Touch <[email-masked]>
Date: Sat, 4 Jan 2020 13:24:24 -0800

> On Jan 4, 2020, at 10:44 AM, C. M. Heard <[email-masked]> wrote:
> 
> On Fri, Jan 3, 2020 at 8:36 PM Joe Touch <[email-masked] <mailto:[email-masked]>> wrote:
> What about ACS? It does not modify the payload, but it affects how the payload is handled: if the ACS check fails, the payload is not delivered to the user. Those semantics can be violated if the ACE option is ignored.

ACS is mandatory so it can’t be ignored if UDP options are implemented. If it is used with FRA+LITE, the payload would be ignored by legacy receivers and would have to be accepted by option-aware receivers.

> That issue is handled in the -08 draft by making it mandatory to recognize and implement -- a point with which I disagree, as I think it should be optional to implement. But even if I don't get my way on that, the point still remains that we can't retroactively make FUTURE options such as ACS mandatory to implement.

Such as. That seems to be the mantra.

I’ve asked for a specific example of something the draft doesn’t already cover. Still waiting.

Joe

---

From: Joe Touch <[email-masked]>
Date: Sat, 4 Jan 2020 13:31:27 -0800

> On Jan 4, 2020, at 1:24 PM, Joe Touch <[email-masked]> wrote:
> 
> 
> 
>> On Jan 4, 2020, at 10:44 AM, C. M. Heard <[email-masked] <mailto:[email-masked]>> wrote:
>> 

s/accepted/validated/

Again missing in this discussion is the premise that UDP is unreliable. That means if you don’t establish some sort of state with the endpoint, you don’t KNOW what happens anyway. If you do, all these signals are irrelevant because that state can coordinate the behavior.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Sat, 4 Jan 2020 13:42:01 -0800

On Sat, Jan 4, 2020, 1:24 PM Joe Touch <[email-masked]> wrote:

> ACS is mandatory so it can’t be ignored if UDP options are implemented. If
> it is used with FRA+LITE, the payload would be ignored by legacy receivers
> and would have to be accepted by option-aware receivers.
>

Authentication (AE option without encryption so no payload modification).
Per the draft, it is not mandatory, but similar to ACS a packet with option
can't be accepted unless validated.

Regardless of having an example, Mark's point is valid about adding
mandatory options in the future can't be done retroactively. If the intent
of the draft is that options like this can't added after the initial
publication then the draft should make that requirement clear.

Tom

---

From: Joe Touch <[email-masked]>
Date: Sat, 4 Jan 2020 14:14:19 -0800

A deliberate design decision is to let the receiver decide what to do when authentication fails. 

If they know about authentication, then they can enforce it. But they can always have ignored it so there’s no benefit to “forcing” it to be acted upon.

And it’s not “regardless of having an example”. That’s the reason why we decided not to design features into this mechanism - the lack of an example.

A design goal from the start was that receivers would decide whether they wanted to enforce an option; it isn’t in the hands of the transmitter to make that decision, largely because UDP is stateless. If you want enforcement, create state - and let that state be the way that these sorts of things are enforced.

Without that state, you can’t know what’s being ignored or implemented incorrectly anyway.

Joe

> On Jan 4, 2020, at 1:42 PM, Tom Herbert <[email-masked]> wrote:
> 
> 
> 
> On Sat, Jan 4, 2020, 1:24 PM Joe Touch <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> Authentication (AE option without encryption so no payload modification). Per the draft, it is not mandatory, but similar to ACS a packet with option can't be accepted unless validated.
> 
> Regardless of having an example, Mark's point is valid about adding mandatory options in the future can't be done retroactively. If the intent of the draft is that options like this can't added after the initial publication then the draft should make that requirement clear.
> 
> Tom
> 
> 
> Joe

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 4 Jan 2020 14:52:43 -0800

On Sat, Jan 4, 2020 at 2:14 PM Joe Touch wrote:

> If they know about authentication, then they can enforce it. But they can
> always have ignored it so there’s no benefit to “forcing” it to be acted
> upon.
>
> And it’s not “regardless of having an example”. That’s the reason why we
> decided not to design features into this mechanism - the lack of an example.
>
> A design goal from the start was that receivers would decide whether they
> wanted to enforce an option; it isn’t in the hands of the transmitter to
> make that decision, largely because UDP is stateless. If you want
> enforcement, create state - and let that state be the way that these sorts
> of things are enforced.
>

For the record, I do not agree with any of these design decisions. I have
objected before, but perhaps my objections were not sufficiently explicit.

As far as I know, there has been no consensus call on these matters, If I
end up "in the rough" after such a consensus call, so be it, but I want
such a call to take place.

My preference would be to see an updated daft prior to such a call. That
would allow those of us who have concerns to comment on just the issues
that remain.

Thanks

Mike Heard

---

From: Joe Touch <[email-masked]>
Date: Sat, 4 Jan 2020 14:59:38 -0800

> On Jan 4, 2020, at 2:52 PM, C. M. Heard <[email-masked]> wrote:
> 
> For the record, I do not agree with any of these design decisions. I have objected before, but perhaps my objections were not sufficiently explicit.
> 
> As far as I know, there has been no consensus call on these matters, If I end up "in the rough" after such a consensus call, so be it, but I want such a call to take place.

We’ve asked for feedback multiple times. There will be calls as we move forward as well.

But we’ve also asked for *examples*, not merely pleas. Absent those, it’s hard to understand why these are not driving the design towards arbitrary complexity for the sake of hypotheticals.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Sat, 4 Jan 2020 15:15:27 -0800

> objected before, but perhaps my objections were not sufficiently explicit.

Mike,

I too disagree with these design decisions, particularly the part about
introducing state into UDP and not providing any meaningful guidance on how
negotiation of that state is supposed to work.

> such a call to take place.

Agreed, maybe the chairs can start some consensus calls.

> would allow those of us who have concerns to comment on just the issues

Agreed also.

Tom

---

From: Joe Touch <[email-masked]>
Date: Sat, 4 Jan 2020 15:19:33 -0800

I don’t know how best to say this repeatedly, but we are NOT INTRODUCING STATE INTO UDP.

We have repeatedly indicated that endpoints using certiain options may need to coordinate - OUTSIDE OF UDP. That’s always been true of some options - e.g., TCP-AO and TCP-MD5. The same would be true for AE - a receiver could decide to allow or ignore checks or could require them. A transmitter that needs to know otherwise needs to confirm.

That’s what we’re talking about when we refer to the soft-state mechanism - the assumption being that because UDP can’t establish or enforce this state, it would at best be soft.

This has been discussed many times at multiple IETFs and hasn’t changed.

Joe

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 4 Jan 2020 19:10:38 -0800

On Sat, Jan 4, 2020 at 3:19 PM Joe Touch wrote:

> We have repeatedly indicated that endpoints using certiain options may
> need to coordinate - OUTSIDE OF UDP. That’s always been true of some
> options - e.g., TCP-AO and TCP-MD5. The same would be true for AE - a
> receiver could decide to allow or ignore checks or could require them. A
> transmitter that needs to know otherwise needs to confirm.
>
> That’s what we’re talking about when we refer to the soft-state mechanism
> - the assumption being that because UDP can’t establish or enforce this
> state, it would at best be soft.
>

A "drop the datagram if you don't recognize this UDP option" -- which is
what I thought we were discussing -- DOES NOT INTRODUCE STATE INTO UDP. It
is totally stateless, and it allows a receiver to drop datagrams that it
should not accept without any prior coordination. In situations where prior
coordination is required in order to make an option work as intended, it
provides protection against failures of that coordination.

Since you brought it up, let's compare and contrast the operation of TCP-AO
and TCP-MD5 with that of UDP-AE, in the case that an endpoint erroneously
(due, e.g., to a misconfiguration) attempts to initiates an exchange
containing the option with a peer that does not understand it.

For TCP-AO or TCP-MD5, the listener will receive a SYN segment with the
option. Since it does not understand the option, it will return a SYN-ACK
that does not contain the option. Seeing a SYn-ACK without the option, the
initiator will return a RST segment. That will terminate the connection,
and since the 3-way handshake never completed, the listener will not
deliver any data that may have accompanied the SYN segment.

For UDP-AE, the listener receives a datagram with an option affecting the
handling of the user data that it does not understand. In my view (and
Tom's) it should discard that datagram -- the same thing that happens with
TCP-AO or TCP-MD5. The easiest way to ensure that, without requiring
knowledge of what every option means, is to systematically embed in the
Option Kind encoding information on whether the option can be safely
ignored or not. We certainly can't do that with a three-way handshake
because, as you point out, there is no such thing in UDP (and I agree that
UDP options must not introduce it; leave that to efforts like QUIC).

Granted, UDP-AE is in the spec, so a diligent implementation that does not
understand the option will discard packets containing it. But what about
options defined in the future?

It has been indeed been discussed at length, with each of us of repeating
our arguments and failing to convince the other. But AFAICT there has been
no determination of what the WG consensus is, and that determination is not
for you or me to make.

I'm going to refrain from further discussion until I see a new version of
the draft, at which point I will do a complete review.

Thanks and regards,

Mike Heard

---

From: Joe Touch <[email-masked]>
Date: Sat, 4 Jan 2020 19:21:55 -0800

Thank you for AGAIN failing to give an example.

Joe

> On Jan 4, 2020, at 7:10 PM, C. M. Heard <[email-masked]> wrote:
> 
> A "drop the datagram if you don't recognize this UDP option" -- which is what I thought we were discussing -- DOES NOT INTRODUCE STATE INTO UDP. It is totally stateless, and it allows a receiver to drop datagrams that it should not accept without any prior coordination. In situations where prior coordination is required in order to make an option work as intended, it provides protection against failures of that coordination.
> 
> Since you brought it up, let's compare and contrast the operation of TCP-AO and TCP-MD5 with that of UDP-AE, in the case that an endpoint erroneously (due, e.g., to a misconfiguration) attempts to initiates an exchange containing the option with a peer that does not understand it.
> 
> For TCP-AO or TCP-MD5, the listener will receive a SYN segment with the option. Since it does not understand the option, it will return a SYN-ACK that does not contain the option. Seeing a SYn-ACK without the option, the initiator will return a RST segment. That will terminate the connection, and since the 3-way handshake never completed, the listener will not deliver any data that may have accompanied the SYN segment.
> 
> For UDP-AE, the listener receives a datagram with an option affecting the handling of the user data that it does not understand. In my view (and Tom's) it should discard that datagram -- the same thing that happens with TCP-AO or TCP-MD5. The easiest way to ensure that, without requiring knowledge of what every option means, is to systematically embed in the Option Kind encoding information on whether the option can be safely ignored or not. We certainly can't do that with a three-way handshake because, as you point out, there is no such thing in UDP (and I agree that UDP options must not introduce it; leave that to efforts like QUIC).
> 
> Granted, UDP-AE is in the spec, so a diligent implementation that does not understand the option will discard packets containing it. But what about options defined in the future?
> 
> It has been indeed been discussed at length, with each of us of repeating our arguments and failing to convince the other. But AFAICT there has been no determination of what the WG consensus is, and that determination is not for you or me to make.
> 
> I'm going to refrain from further discussion until I see a new version of the draft, at which point I will do a complete review.
> 
> Thanks and regards,
> 
> Mike Heard

---

From: Joe Touch <[email-masked]>
Date: Sun, 5 Jan 2020 08:25:34 -0800

Just to dive a little into the TCP example, additionally:

> For TCP-AO or TCP-MD5, the listener will receive a SYN segment with the option. Since it does not understand the option, it will return a SYN-ACK that does not contain the option.

The presence of unknown TCP options **NEVER** causes a SYN to be ignored, discarded, or to generate a RST. It is simply ignored.

It is the result of *state exchange* that enables the endpoints to know when to use - or not use - those options. It is the responsibility of the sender to know what options to use; the receiver is ALWAYS ALLOWED TO INGORE OPTIONS that it hasn’t confirmed by state exchange - even after a connection is established.

E.g., even if the side opening the connection, sending the SYN+AO were to ignore the reply (SYN-ACK without AO, never RST), let’s look at what happens to the connection afterwards. Let’s say the side opening the connection decides to include AO anyway. The receiver WOULD CONTINUE TO IGNORE OPTIONS IT DOESN’T UNDERSTAND.

See RFC1122, Sec 4.2.2.5.

Your subsequent claim is incorrect, as per the citations below:
	> Seeing a SYN-ACK without the option, the initiator will return a RST segment. 

RFC2385 for TCP-MD5, Sec 2.0:
   Unlike other TCP extensions (e.g., the Window Scale option
   [RFC1323 <https://tools.ietf.org/html/rfc1323>]), the absence of the option in the SYN,ACK segment must not
   cause the sender to disable its sending of signatures.  This
   negotiation is typically done to prevent some TCP implementations
   from misbehaving upon receiving options in non-SYN segments.  This is
   not a problem for this option, since the SYN,ACK sent during
   connection negotiation will not be signed and will thus be ignored.
   The connection will never be made, and non-SYN segments with options
   will never be sent.  More importantly, the sending of signatures must
   be under the complete control of the application, not at the mercy of
   the remote host not understanding the option.

RFC5925 for TCP-AO, Sec 11:
   TCP-AO does not include a fast decline capability, e.g., where a SYN-
   ACK is received without an expected TCP-AO and the connection is
   quickly reset or aborted. 

—

For UDP, the original design goal was to follow this behavior, i.e., that the receiver always ignores options it doesn’t understand individually. That’s largely because options overall can be ignored - there’s no way to “unring the bell”. Even if we bury options or user data inside the FRAG+LITE, the *ONLY* correct behavior is to have the receiver see a zero-length UDP packet arrival.

There is NO way to prevent that for legacy receivers - and thus there should be no way to do otherwise for option-aware receivers. The best we should ever try to do is to make option-aware receivers see what legacy receivers see in that case (unknown options) - a blank packet.

So regardless of any rules, we MUST NOT try to declare any rule where the receiver “sees NO packet”.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Sun, 5 Jan 2020 11:14:43 -0800

On Sun, Jan 5, 2020 at 8:25 AM Joe Touch <[email-masked]> wrote:
>    [RFC1323]), the absence of the option in the SYN,ACK segment must not
> For UDP, the original design goal was to follow this behavior, i.e., that the receiver always ignores options it doesn’t understand individually.

Since when was options considered in the design of UDP? I'm looking at
RFC768 and see nothing about this.

> That’s largely because options overall can be ignored - there’s no way to “unring the bell”. Even if we bury options or user data inside the FRAG+LITE, the *ONLY* correct behavior is to have the receiver see a zero-length UDP packet arrival.
>

Joe,

As discussed before, the fact that a legacy receiver can receive a
blank packet is potentially problematic. We cannot eliminate the
possibility that zero length UDP packets don't have some detrimental
side effect by some receiving application. We're accepting that the
risk of this is small, but this behavior is far from optimal and if
there were a way to ensure that legacy receivers dropped packets with
UDP options we'd do that. Forcing option-aware receivers to have this
same sub-optimal behavior just to be consistent with legacy receivers
makes no sense.
> So regardless of any rules, we MUST NOT try to declare any rule where the receiver “sees NO packet”.
Your draft doesn't meet this requirement. e.g. "Option lengths MUST
NOT exceed the IP length of the packet. If this occurs, the packet
MUST be treated as malformed and dropped".

Tom

---

From: Joe Touch <[email-masked]>
Date: Sun, 5 Jan 2020 11:21:50 -0800

Malformed packets are dropped as with TCP and the base UDP spec. 

And original UDP design goal here refers to the original requirements for this update. 

Finally, consistency with legacy receivers as a default is critical until explicitly negotiated at the app later otherwise. Because until then a sender doesn’t know what receiver it’s dealing with. 

Joe

> On Jan 5, 2020, at 11:15 AM, Tom Herbert <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Sun, 5 Jan 2020 12:13:11 -0800

> Malformed packets are dropped as with TCP and the base UDP spec.
And packet with unknown options that cannot be ignored need be dropped
(IPv6 HBH and destination options for instance). Such a packet is
equivalent to a malformed packet since these packet cannot be
correctly processed by the receiver.

In any case, send a malformed UDP options to an options aware receiver
then the packet is dropped, send the same packet to a legacy receiver
then a zero length packet is received. There is no consistency there,
and neither does that conform to the requirement in normative language
that you just proposed

Tom

---

From: Joe Touch <[email-masked]>
Date: Sun, 5 Jan 2020 12:46:20 -0800

> On Jan 5, 2020, at 12:13 PM, Tom Herbert <[email-masked]> wrote:
> 
> (IPv6 HBH and destination options for instance).

You keep citing network protocols, not transport.

Transport protocols don’t have this behavior - and it’s IMPOSSIBLE to implement for legacy UDP receivers.

> Such a packet is

I cited the section of RFC 1122 that indicates this is incorrect. It is also reiterated as incorrect in both TCP-MD5 and TCP-AO.

TCP receivers silently and individually ignore unknown options unless they indicate a parsing error.

To put it more directly, malformed != unknown. That’s true for ALL protocols of which I am aware.

> and neither does that conform to the requirement in normative language

UDP options are supposed to *ignore all options* if the options are malformed - NEVER just drop the packet. The packet and its body data (NOT the FRAG data, the conventional body data) would still be received, just without the options (and no, that’s not yet in the doc, but should have been).

This is the relevant existing text:
   >> Receivers MUST silently ignore unknown options. That includes
   options whose length does not indicate the specified value.
The text that follows regarding options that are too long is incorrect in v08; it should say that the options are all silently ignored when any are malformed.

Joe

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 5 Jan 2020 12:48:40 -0800

> Lost in this discussion has been an example to motivate the need for “drop
[ ... ]

> Right now, until there is consensus otherwise, there isn’t justification
> to waste half the code point space on  hypotheticals. However, there’s no
> reason not to assign ONE code point for such use, e.g., as follows:
>
>         option 253 — defined as a prefix to “required options” code
> points, the next byte defines that code point
> That way there’s support for the *remote* possibility that this feature
> can be useful without wasting space needlessly - and, as importantly,
> avoiding the impression that “flipping a bit” can change any option from
> “optional” to “required”.
>

In an earlier quick read I missed this proposal. My apologies for not
reading the message carefully and thereby adding unnecessary noise to this
discussion.

Under the assumption that implementations of UDP options will be required
to ***recognize*** (but not necessarily to implement) all of the options
defined in the initial version of the specification, this proposal
will accomplish
the goal that I had in mind when I proposed to subdivide the Option Kind
space into two ranges, one for options that do not affect the handling of
user data ("this option is safe to ignore") and another for options that do
affect the handling of user data. ("this option is not safe to ignore").

I would suggest that the semantics of the prefix should be "if you don't
recognize the following option, don't deliver the accompanying payload data
to the user". 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.

I'll note in passing that the prefix could appear in front of the
experimental option code point in order to indicate an experimental option
that is not safe to ignore.

Thanks,

Mike Heard

---

From: Joe Touch <[email-masked]>
Date: Sun, 5 Jan 2020 12:58:31 -0800

> On Jan 5, 2020, at 12:48 PM, C. M. Heard <[email-masked]> wrote:
...
> 
> In an earlier quick read I missed this proposal. My apologies for not reading the message carefully and thereby adding unnecessary noise to this discussion.
> 
> Under the assumption that implementations of UDP options will be required to ***recognize*** (but not necessarily to implement) all of the options defined in the initial version of the specification, this proposal will accomplish the goal that I had in mind when I proposed to subdivide the Option Kind space into two ranges, one for options that do not affect the handling of user data ("this option is safe to ignore") and another for options that do affect the handling of user data. ("this option is not safe to ignore").
> 
> I would suggest that the semantics of the prefix should be "if you don't recognize the following option, don't deliver the accompanying payload data to the user".

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.

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.

> 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

Again, we cannot cause the PACKET to be dropped. If the packet contains regular data, it MUST be delivered to the application.

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.

> I'll note in passing that the prefix could appear in front of the experimental option code point in order to indicate an experimental option that is not safe to ignore.

As noted in the proposal, this would a a *separate* code point space, but agreed, there would be an experimental value there too.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Sun, 5 Jan 2020 13:17:39 -0800

> You keep citing network protocols, not transport.
Because, just like UDP, IPv6 is a stateless, connectionless, datagram
protocol that works over unicast, multicast, anycast, and broadcast.
They have all the same pertinent properties. If you know of a
transport protocol with options having these same properties then we
can look at that (note, that protocol is not TCP!).

> Transport protocols don’t have this behavior - and it’s IMPOSSIBLE to implement for legacy UDP receivers.
It's not impossible, I've already suggested the necessary text and
requirements to prevent a receiver from incorrectly processing an
unknown options that cannot be ignored. I claim that this protocol
works for all use cases of UDP in order to satisfy the requirement the
requirement. If you dispute this claim, then please provide the exact
scenario where you think it fails. Here again are the requirements to
ensure:

"

---

From: Joe Touch <[email-masked]>
Date: Sun, 5 Jan 2020 13:57:01 -0800

> On Jan 5, 2020, at 1:17 PM, Tom Herbert <[email-masked]> wrote:
> 
>> 

IPv6 is two things UDP is or should not be:

1. a network protocol, not a transport
	network protocols rely on ways to inform the intermediate hops
	transports can and should rely on the endpoints 

2. overbuilt
	if we learned anything with IPv6, it’s that adding the kitchen sink helps delay adoption

The lesson to follow here is TCP and TCP SYNs in particular. There is no TCP option that causes a received packet to be IGNORED (there could easily have been).

> can look at that (note, that protocol is not TCP!).

It is TCP SYNs. They have to be interpreted without context.

> unknown options that cannot be ignored.

That code never affects legacy receivers.

> I claim that this protocol
> scenario where you think it fails.

First, it fails to be motivated by an example.

> Here again are the requirements to
> ensure:
> 
> "
> indicated by

The rest of this is not a requirement, it’s an implementation...

> not recognize the option then the packet MUST be dropped.

Fail. That causes the same packet to be silently dropped by option-aware receivers and received as zero-length by legacy receivers.

That’s a non-starter. There is no justification for needing that behavior.

> The

This does NOT ensure that legacy receivers and option-aware function the same way. Legacy would receive zero-length packets. Option-aware should do the same.

>  - If an option is received with [he needed signal]

(again, the rest of this sentence is implementation, not requirement)

>  and the receiver does not recognize the option,
> then the packet MUST be dropped.

Same problem. Different behavior for legacy and option-aware.

Declaring that an option CANNOT BE IGNORED affects ONLY THAT OPTION. We can decide to make it trash all other options, but we can’t make it drop a packet as a whole.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Sun, 5 Jan 2020 15:28:22 -0800

> It is TCP SYNs. They have to be interpreted without context.

TCP SYNs is the best you could come up with? One small part of a
protocol that typically doesn't carry user data, doesn't work with
multicast and is part of a stateful protocol 3WHS. Nope, IPv6 is the
better model.

> First, it fails to be motivated by an example.
Encryption option.

> Fail. That causes the same packet to be silently dropped by option-aware receivers and received as zero-length by legacy receivers.

There is no such requirement. And as I pointed out if there were the
draft would need to be changed to eliminate all cases where packets
are dropped on error since that too  "causes the same packet to be
silently dropped by option-aware receivers and received as zero-length
by legacy receivers."
> This does NOT ensure that legacy receivers and option-aware function the same way. Legacy would receive zero-length packets. Option-aware should do the same.

Again, there is no requirement.

> Same problem. Different behavior for legacy and option-aware.

Same response. Show me the requirement established by consensus of the
WG that this violates.

> Declaring that an option CANNOT BE IGNORED affects ONLY THAT OPTION. We can decide to make it trash all other options, but we can’t make it drop a packet as a whole.
The whole point of an option that cannot be ignored is that it is
incorrect to process the packet if ignored. That means that packet may
be delivered with corrupted data or other insidious side effects;
hence the packet needs to be dropped.

Tom

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 5 Jan 2020 15:50:43 -0800

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

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

---

From: Joe Touch <[email-masked]>
Date: Sun, 5 Jan 2020 16:37:38 -0800

> On Jan 5, 2020, at 3:28 PM, Tom Herbert <[email-masked]> wrote:
> 

TCP SYNs are transport and stateless. Yes, they’re the right model.

IPv6 is largely designed for intermediate devices - that’s not what we’re designing for here.

>> First, it fails to be motivated by an example.

We already have a solution for that with FRAG+LITE.

Is there any example of a packet whose contents aren’t modified but MUST NOT be accepted if the option fails?

> There is no such requirement.

I’m claiming there should be a requirement to behave the same in these cases and I explained why.

> And as I pointed out if there were the

I already said that text was being changed. 

...
> Same response. Show me the requirement established by consensus of the

We’re designing a system that has to work with legacy receivers. Having two distinctly different behaviors in those cases creates protocol complexity. 

> incorrect to process the packet if ignored.

The whole point is that it is incorrect to process the OPTIONS if ignored. Not the packet We can’t claim that it’s incorrect to process a packet if options are ignored - exactly because that’s what legacy receivers already do.

Joe

---

From: Joe Touch <[email-masked]>
Date: Sun, 5 Jan 2020 16:50:39 -0800

> On Jan 5, 2020, at 3:50 PM, C. M. Heard <[email-masked]> wrote:
> 
> 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.

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

> 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

---

From: Tom Herbert <[email-masked]>
Date: Mon, 6 Jan 2020 08:19:46 -0800

> TCP SYNs are transport and stateless. Yes, they’re the right model.
TCP SYNs are a protocol fragment, not a protocol. Also, they don't
carry any data so I'm not even sure how you could say they are
transport seeing that they don't transport anything. Has it occurred
to you that the reason all options can be ignored in a TCP SYN is that
there's no data that could be incorrectly delivered to the
application?

> IPv6 is largely designed for intermediate devices - that’s not what we’re designing for here.

The design is adding options to a stateless, connectionless, datagram
protocol that works over unicast, multicast, anycast, and broadcast.
IPv6, RFC8200 specifically which is full Internet standard, shows
exactly how to do this.

> Is there any example of a packet whose contents aren’t modified but MUST NOT be accepted if the option fails?

Any form of integrity checks that sender has set up and requested.
This includes checksums, ACS, HMACs, etc. This includes the
possibility to add new algorithms in the future per evolving needs.
For instance, the current ACS is CRC32c, that is a strong integrity
check however could very well be prohibitive to support on low powered
IoT devices. For this reason ACS should not be required to be
implemented, and the possibility of adding a CRC check more feasible
to these devices should not be precluded.

A virtual network identifier, anycast instance identifier, or any
other ancillary information that provides more specific information to
correctly deliver the packet than that in the IP header and ports.
Ignore a virtual identifier for instance, and the packet is allowed to
cross virtual networks thereby breaking required isolation.

UDP options compression option. Similar to Van Jacobson compression in
PPP, when the same options are used repeatedly they could be
compressed to save overhead.

These are the ones I can think of now. However, there is no reason to
believe that this could an exhaustive list. Once the protocol is
deployed new options may be needed that we can't even conceive
beforehand. This happens for other protocols that have options, and
will happen for UDP options if it achieves considerable deployment.
Fundamentally, it's the essence of an extensible protocol to allow the
protocol to adapt beyond the limited view of how things will evolve
when the protocol is first designed.

Tom

---

From: Joe Touch <[email-masked]>
Date: Mon, 6 Jan 2020 20:24:25 -0800

> On Jan 6, 2020, at 8:19 AM, Tom Herbert <[email-masked]> wrote:
> 
> TCP SYNs are a protocol fragment, not a protocol.

They are very similar to UDP with options - by themselves they are stateless. The only difference is that TCP knew it had options from the beginning.

> Also, they don't
> carry any data

Yes, they can.

> so I'm not even sure how you could say they are

Data in the TCP SYN is retained and presented to the application layer if a final ACK is received.

> IPv6, RFC8200 specifically which is full Internet standard, shows

It shows us how NOT to do it too, in several ways. Lots of options - few (if any) actually in use, except IPsec.

> Any form of integrity checks that sender has set up and requested.

Yes, except that we are already defining two (auth and ACS). Many protocols have tried to define many others - but interestingly NONE are used.

> to these devices should not be precluded.

So let me understand - you don’t trust the IP checksum but want something simpler than CRC32c. Any idea what that unicorn algorithm is?

And if it’s so useful, can you explain why nobody uses one for IP?

> cross virtual networks thereby breaking required isolation.

Those are network IDs. We have those - IP in IP, VPN-IDs, etc. - at the *network* layer where they belong - and are WIDELY already used.

> compressed to save overhead.

Oh - right, compression. Remember that anything that modifies the data is already covered by the regular option space because it would *modify the data* in the FRAG_LITE method.

Then again, we really need to consider that case. Consider how popular PPP is and how that sort of mechanism has already been widely deployed as an option for IP and TCP. (not).

You might consider why compression of net and transport protocols focuses on headers, not payloads. Because if an app either compresses or encrypts, there’s no further point. Compression in particular works best on long sequences and/or when the message structure is known. None of this is true at the network or transport layer.

> believe that this could an exhaustive list.

Oh, yes. I have seen the point for a while in this thread.

These options are a playground for experiments. The best part of that is how we document the way our protocols have been littered with these experiments over the years.

Silly me. I thought we were trying to learn from past experience and make this clean, simple, and likely to actually be used.

Joe