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

[Joseph Touch <[e-mail]>]

Hi, Mike,

I’ve been waiting for others to participate, but given it’s been a week…

First, I want to thank you for the deep review - it’s sincerely appreciated.

I’ll also be the first to admit there are more than a few places where it needs another pair of eyes and may have inconsistencies. So let’s start by assuming that those are dealt with separately. At a minimum, assume that most of the obvious corrections will be included in the next update.

I will respond  to the revised LITE option in reply to your other post.

On the primary issues, below summarizes my perspective. I hope others on the list will weigh in.

Joe

-----

- regarding fragment/reassembly as being required
	This is one of the primary current intended use cases and motivations for UDP options. 
	That’s why it’s currently a MUST support and why I do not think that should change.

- regarding removing EOL
	Removing EOL raises several questions: can other options use that data? Do we care if it’s a covert channel? etc.
	It’s simpler to declare it zeroes and let EOL be the trigger to use a loop with a branch predictor hint (likely zero).
	At a minimum, everything past EOL MUST be covered by OCS (otherwise OCS would need to parse all options to find EOL).
	
- regarding increasing NOPs
	There was a concern in letting these be unlimited; we can increase to 7, 15, or even 31 (high enough for future-proof seems
	to open a DOS problem; IMO, DOS detection should just check to see if this is a persistent load, not a specific number)

- regarding UNSAFE option format
	Yes, we could pick a range rather than making them longer, but IMO they aren’t likely except as already accounted for, so 
	allocating space from the main range is a waste.
	However, if we did allocate from the range, we should NOT do so with a single bit; that gives the false impression
	that a given option value has two variants - safe and unsafe, and that’s not the case.

- regarding AE being safe
	This is not considered unsafe for two reasons:
	1. A(authentication) isn’t unsafe
	2. Encryption should only be used when sending packets to a party that is keyed; that can/should be known or checked before use anyway.
	i.e., there’s never a case where you send encrypted text to a party you don’t know should be ready.

----