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

[Gorry Fairhurst <[e-mail]>]

On 23/03/2017, 05:43, Joe Touch wrote:
> 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?
I suggest using CRC-16-CCITT, it's common (and fairly strong) and there 
is lookup-based code published.
>> 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
>
Gorry