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

[Tom Herbert <[e-mail]>]

On Fri, Jan 3, 2020 at 12:42 PM Joe Touch <[e-mail]> wrote:
>
>
>
> > On Jan 3, 2020, at 12:19 PM, Tom Herbert <[e-mail]> wrote:
> >
> > On Fri, Jan 3, 2020 at 11:37 AM Joe Touch <[e-mail]> wrote:
> >>
> >> 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.
> >>
> > 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.
>
> 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

> >
> > Tom
> >
> >>> On Jan 3, 2020, at 11:30 AM, Joe Touch <[e-mail]> wrote:
> >>>
> >>> How about an example of any *deployed* *transport* option with this property?
> >>>
> >>> Joe
> >>>
> >>>>> On Jan 3, 2020, at 11:22 AM, Tom Herbert <[e-mail]> wrote:
> >>>>>
> >>>>> On Fri, Jan 3, 2020 at 11:04 AM Joe Touch <[e-mail]> wrote:
> >>>>>
> >>>>> 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,
> >>>>
> >>>> 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
> >>>>
> >>>>> Joe
> >>>>>
> >>>>>> On Jan 3, 2020, at 8:07 AM, Tom Herbert <[e-mail]> wrote:
> >>>>>>
> >>>>>> On Thu, Jan 2, 2020 at 8:21 PM Joe Touch <[e-mail]> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Jan 2, 2020, at 7:00 PM, C. M. Heard <[e-mail]> wrote:
> >>>>>>>
> >>>>>>>> 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
> >>>>>>>>> solve this problem by the "drop if unrecognized" bit so no negotiation
> >>>>>>>>> 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.
> >>>>>>>
> >>>>>>>
> >>>>>>> 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.
> >>>>>>
> >>>>>> 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
> >>>>>>
> >>>>>>>
> >>>>>>> …
> >>>>>>>
> >>>>>>> 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
> >>>>>>
> >>>>>
> >>>
> >>
>