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

["Black, David" <[e-mail]>]

Still commenting as an individual …

The following text exhibits a peculiar use of “optional to implement” wording, but I think the overall simplification is useful:

> What I advocate to be "optional to implement" are the ability for a receiver
> to turn off verification of OCS when UDP CS<>0 and the ability for a
> receiver turn on verification of OCS when UDP CS=0.  This allows a receiver
> to determine whether and how to do an OCS verification by looking only at
> the IP Payload Length and the fields in the UDP header.

In other words the receiver does one of two things:
- If UDP CS != 0, expect to find that OCS !=0.  If OCS == 0, something is wrong. (MUST check OCS).
- If UDP CS == 0, don’t bother doing anything with OCS, even if OCS is non-zero. (I think “don’t bother” winds up being: SHOULD ignore OCS).

> If the above receive capabilities are optional to implement, the
> transmit capabilities to generate OCS when UCP CS<>0 and to omit OCS when
> UDP CS=0 can also be optional to implement. The primary benefit in this
> case is simplification of the API.

The use of “optional” in this second chunk of text is definitely misleading.   The easy requirement is:
- if UDP CS !=0 , OCS MUST be computed and sent.
I think there’s broad agreement on that requirement.

The UDP CS == 0 case is subtle, even if the receiver SHOULD ignore OCS as indicated above.  The reason is that OCS increases the likelihood of packet delivery, leading to Tom advocating that OCS MUST be used in this case.  As noted earlier, I’m ok with a “SHOULD use OCS” requirement here based on increased likelihood of packet delivery, but not a “MUST” even with a “receiver SHOULD ignore OCS” requirement.

>> > so the ONLY protection against corruption of the computed trailer length
>> > is the OCS.
>>
>> Again, this is certainly a risk, but why isn't it just a choice? When UDP
>> picks CS=0, they're saying they are willing to take that risk.
>
> And to make it clear, I'm OK with saying that OCS can be omitted if
> UDP CS=0 is selected. Under the appropriate circumstances (and in
> conformance with RFC 6936) that selection is indeed a valid user choice.

This is ok wrt corruption concerns, but “MAY” seems too weak (IMHO) given OCS’s visible increase in likelihood of packet delivery – the RFC 2119 admonition that “the full implications must be understood and carefully weighed before choosing a different course” seems to be a very good fit to this likelihood of packet delivery concern.

Thanks, --David

From: tsvwg <[e-mail]> On Behalf Of C. M. Heard
Sent: Tuesday, July 16, 2019 4:42 PM
To: Joe Touch
Cc: tsvwg
Subject: Re: [tsvwg] draft-ietf-udp-options issues from IETF 104


[EXTERNAL EMAIL]
In-line followups where where they seem to be warranted.

On Tue, Jul 16, 2019 at 9:08 AM Joe Touch wrote:
> On 2019-07-16 07:37, C. M. Heard wrote:
> > >  - the OCS field is now manditory (not signalled with a KIND field
> > > or optional as a field)
>
> > As mentioned in
> > https://mailarchive.ietf.org/arch/msg/tsvwg/XZxL29UA-95ReA72mxv5-kEytK0,
> > for use in the trailer I'd prefer leaving it as an option so that NOPs
> > can be prepended for alignment, at the discretion of the sender
>
> Yes, that's the trade-off. If it's mandatory, we need to decide its
> alignment (none, 16-bit, 32-bit) ahead of time for all time. AND it has
> to be there even if it's not used.
>
> If we use the 1-byte flag, the alignment can be at the user's discretion
> and we save space when not in use.

Good. We agree on the trade-offs, I've said where I stand, so for now I move on.

> > > - OCS *SHOULD be computed, but MAY be set to zero (e.g., when UDP
> > > CS=0, at user discretion and peril)
> >
> > Partly agree. I do not want to see any receiver obligated to accept
> > packets with UDP trailers that don't have a computed OCS if UDP CS<>0
> > (it's fine to allow a mode that does otherwise as long as it's an
> > optional-to-implement capability).
>
> Optional to implement seems odd; it seems fine to say the receiver can
> treat ignore the surplus area in that case (i.e., act like a legacy
> receiver).

What I advocate to be "optional to implement" are the ability for a receiver
to turn off verification of OCS when UDP CS<>0 and the ability for a
receiver turn on verification of OCS when UDP CS=0. This allows a receiver
to determine whether and how to do an OCS verification by looking only at
the IP Payload Length and the fields in the UDP header -- there is no need
to inspect, or worse still, loop through the options trailer to make that
determination. And if OCS does need to be verified, it can be done by a
simple and well-understood Internet checksum computation (adjusted by the
compensation pseudo-header and conceptually prepending/appending zero bytes
when the trailer starts or ends on an odd byte boundary). As a bonus, CS
offload can be done as for a TCP segment (with appropriate adjustment for
the protocol number in the pseudo-header) since the combination of that
checksum and OCS being valid is mathematically equivalent to the combination
of the UDP checksum being valid and OCS being valid. And finally, the API
can be simpler because there are fewer combinations to support.

If the above receive capabilities are optional to implement, the
transmit capabilities to generate OCS when UCP CS<>0 and to omit OCS when
UDP CS=0 can also be optional to implement. The primary benefit in this
case is simplification of the API.

Granted, this is another tradeoff; we would reduce implementation
complexity at the cost of flexibility. My judgment call is that the
capabilities in question are not likely to be wanted and so are not
worth inducing implementation complexity.

> > Remember, in IPV6 the IP Payload Length is NOT protected by an IP header
> > checksum or by the pseudo-header in the UDP checksum,
>
> Good point - that needs to be noted.
>
> > so the ONLY protection against corruption of the computed trailer length
> > is the OCS.
>
> Again, this is certainly a risk, but why isn't it just a choice? When UDP
> picks CS=0, they're saying they are willing to take that risk.

And to make it clear, I'm OK with saying that OCS can be omitted if
UDP CS=0 is selected. Under the appropriate circumstances (and in
conformance with RFC 6936) that selection is indeed a valid user choice.

> > > - with LITE, OCS might be transmit-side computed and receive-side
> > > ignored to allow for the intended NON-ROBUST capability (at least
> > > when NOT transiting buggy middbleboxes; see below) of LITE
> > >
> > > (if LITE data doesn't change, that will transit middleboxes; if the
> > > LITE data does change, there's no way to help it transit middleboxes
> > > anyway)
> >
> > As a point of clarification: this means that OCS would include the LITE
> > data (which it does NOT do now) and the options; OCS would not be
> > checked on receive; is that correct?
>
> That is what I'm thinking, but there are certainly variants of what might
> or might not be covered.
>
> I.e., we could do things a few different ways:
> - in the current draft text OCS is "all or none" for the CS area, where
>   LITE is "not covered" because it's jumped over completely
> - if we want protection for PART of the surplus area, we would need two
>   different CS. That argues for going back to Gorry's CCO proposal.

Thanks for the clarification. I'll respond presently with an update to
the other (long) message.

> As a note, I think we're diverging from our intended goals. Those might
> be useful to include in udp-opts. My recollection was:
>
> - support a version of what LITE does, if possible
> - support frag/reassy
> - support single-packet (each way) exchanges with legacy receivers
>   (notably for the DNSSEC case, e.g., send a request with a null option to
>   allow enabled receivers to respond directly either in legacy mode or
>   option-enabled-mode)
> - support transport-level security (akin to TCP-AO)
> - support PLPMTUD (via the echo exchange)

To that last add MTU probing, which draft-ietf-tsvwg-udp-options-07
actually handles just fine, but yes, it would be good to write down
the goals in -08.

> Many of these simply won't work as automatically legacy-compatible with
> draft-herbert; the legacy data can easily exceed its limits, at a minimum.

My take (as stated in the long message) is that we probably want both the
trailer format pretty much as defined in draft-ietf-tsvwg-udp-options-07
for the backward compatible / safe to ignore  options (MSS, TIME, REQ, RES,
dummy FRAG used for negotiation) and and a variant of the header format as
defined in draft-herbert for the others. I do have to admit that that this
has an unwanted level of complexity, but I don't think it's unwarranted
given the goals. In the end "unwarranted" is a judgment call, and YMMV.

Mike