Re: [tsvwg] A review of draft-ietf-tsvwg-udp-options-12

[Joseph Touch <[e-mail]>]

So, for everyone, getting back to the list and in summary, AFAICT (please let me know if I miss anything):

> On Jun 10, 2021, at 9:07 PM, Joseph Touch <[e-mail]> wrote:
> 
> - regarding fragment/reassembly as being required

Mike and I (at least) appear to agree that FRAG is required and at least single-frag messages MUST be supported.

I hope we can at least require reassembly of at least 2, if not 4 fragments.

> - regarding removing EOL

I think we agree to keep EOL and:
	- transmitter MUST set everything post EOL as zero
	- receiver MAY check those zeros
	- those zeroes MUST be covered by OCS

> - regarding increasing NOPs

I think we still want a limit, but it MUST NOT be smaller than 7 in a row.

IMO, checks for excessive use of NOPs as DOS should be optional.

> - regarding UNSAFE option format

I think it is probably sufficient to reserve a block of option values for this purpose, BUT not a single bit that would imply options could be “unsafe or not, depending on the flag”. I’ll look at the number space to see what might work (probably at most 25%)

> - regarding AE being safe

Revise so that:
- when used as AUTH, it is safe and can be used wherever
- when used as ENCRYPT (modifying payload data), it MUST be used only as post-FRAG to be safe

Finally, regarding FRAG:
- we need to decide whether we want to support zero-copy (probably a better way of putting it than RDMA)
	if so, then we should also consider whether to allow options after non-terminal fragments
	that would operate on the fragment only (this would help reduce the amount of data that needs to be moved
	to allow zero copy)

- either way
	- non-terminal fragments MUST use FRAG last
	- terminal fragments include post-FRAG options that operate on the entire reassembled fragment

If we DO NOT support zero-copy, the format would be:

	Nonterminal format, where OPTLEN = 8
		KIND/8, OPTLEN/8, FRAGOFFSET/16
		FRAGID/32

	Terminal format, where OPTLEN = 10
		KIND/8, OPTLEN/8, FRAGOFFSET/16
		FRAGID/32
		THISFRAGLEN/16

	FRAGOFFSET = where to place the fragment in the reassembled user data 
	THISFRAGLEN = length of the terminal fragment, i.e., indicating where the post-frag options resume

	(note - this is what we have in the current draft, version -12, except it swaps FRAGOFFSET and THISFRAGLEN
	and omits it from non-terminal fragments)

If we DO support zero-copy and thus want to allow non-terminal fragments to have post-fragoption options that operate on each fragment, then we would add THISFRAGLEN to the nonterminal format and issue different KIND numbers to nonterminal/terminal fragment.

---