Re: [tsvwg] New Version Notification for draft-touch-tsvwg-udp-options-05.txt

[Joe Touch <[e-mail]>]

Hi, Mike,


On 3/22/2017 6:52 PM, C. M. Heard wrote:
> On Fri, Mar 17, 2017 at 6:03 PM, Joe Touch <[e-mail]> wrote:
>> The queue has closed, but I have a new version of UDP options 06 that
>> will post as soon as it opens (why do we still do this?)
>>
>> Here's a pointer in the meantime:
>>
>> http://www.isi.edu/touch/pubs/draft-touch-tsvwg-udp-options-06.txt
>>
>> It includes Mike's nice observation about combining FRAG and LITE,
>> clarifies some nits about what happens in each order, etc.
>>
>> I tried to keep things simple, so LITE comes first when it's used, FRAG
>> stops processing until reassembly, and things pick up after reassembly
>> with options included after the last fragment. I think that's clean...
> Agreed, I like the way you have done this, with the final fragment being
> indicated by including a checksum. That said, the following text:
>
>>> A host SHOULD indicate FRAG support by transmitting an
>    unfragmented datagram using the Fragmentation option (e.g., with
>    Offset and M both zero), except when encoded as LITE.
>
> needs to be adjusted owing to elimination of the M bit in favor of a
> whole-datagram checksum.
Thanks for the catch. I'll fix that in -06.

> Regarding the whole-datagram checksum: it would IMHO be appropriate to
> be very specific as to what it is. I would propose the standard Internet
> checksum without a pseudo-header, with the value 0x0000 indicating the
> absence of a checksum.

It does say "IP checksum over the reassembled payload", which could be
"optional Internet checksum over the reassembled UDP payload (i.e.,
excluding the IP pseudoheader, UDP header, and UDP options), where a
value of 0x0000 indicates no checksum."

And a warning that "This reassembly checksum SHOULD be used unless a
stronger application layer integrity protection is used." (or something
close to that).
>
> Other comments:
>
> In section 5.4, was a decision made as to what the CRC16 is? Details
> will be needed in order to ensure interoperability.

That's on my to-do list (I was a bit distracted by these other issues).
There are three obvious possibilities:

CRC-16-CCITT            used by Bluetooth, X.25, HDLC (4 terms - 0x1021)
CRC-16-IBM               used by USB (4 terms -- 0x8005)
CRC-16-CDMA2000    used by CDMA  mobile nets (8 terms - 0xC867)

There are other analyses that point to other polynomials:
https://users.ece.cmu.edu/~koopman/crc/

Any suggestions?
> In Section 9, third paragraph, you may want to make the following change:
>
> OLD:
>    This feature is also inconsistent with the UDP application interface
>    [RFC768] [RFC1122].
> NEW:
>    This feature is also inconsistent with the UDP application interface
>    [RFC1122].
>
> in view of the following text in RFC 768:
>
> IP Interface
> -------------
>
> The UDP module  must be able to determine  the  source  and  destination
> internet addresses and the protocol field from the internet header.  One
> possible  UDP/IP  interface  would return  the whole  internet  datagram
> including all of the internet header in response to a receive operation.
> Such an interface  would  also allow  the UDP to pass  a  full  internet
> datagram  complete  with header  to the IP to send.  The IP would verify
> certain fields for consistency and compute the internet header checksum.

I read that section as defining the interface below UDP, not above UDP.
I.e., it's the IP API that UDP expects, not the interface UDP expects
users to utilize.

Can you double-check?

Thanks again,

Joe