Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available

[Joe Touch <touch at ISI.EDU>]

Andrew Knutsen wrote:
> Joe Touch wrote:
>> Simply stating that simultaneous open isn't supported is insufficient.
>> The document needs to explain what happens when a SYN is received with
>> the option when in the SYN-SENT state - i.e., what happens in response
>> to the SYN received, and what happens if the other end responds to the
>> option in the SYN that has been sent.
>>
>>
>>   
> 
>    Thats why the following text is there:
> 
> 5.2. Initiating Discovery Request
> 
>   Requests are only valid in SYN packets. They MUST NOT appear in other
>   segments and MUST be ignored when found outside of a SYN.

Does that mean that the option is ignored, or the segment?

> 5.3. Responding to Discovery Request
> 
>   Requests received in any state except SYN-SENT MUST be ignored.
> 
>   Responses are only valid in valid SYN-ACK packets. They MUST NOT
>   appear in other segments and MUST be ignored when found outside of a
>   SYN-ACK.

AOK - so only the initiator of a connection can initiate this mechanism.

>> FWIW, the text in the security considerations needs to take space into
>> account as well
> 
>    Since the context of the connection impacts the space constraints,
> and that context depends on the device capability and changes over time,
> we feel these issues should be addressed in the specific capability
> specs.  Several vendors are using various forms of this option (with
> invalid kind codes) without problems. If space problems arise, we will
> all have to change our formats, as mentioned in the spec.  Perhaps if we
> adopt this draft, we can move away from the invalid codes at the same time.

Space is less of an issue for connections not authenticated with TCP MD5
or TCP-AO. I agree that the details would be in the service capability
specs. However, it's useful in the security considerations to explain
the security impacts of the approach, i.e., basically:

	- use without TCP MD5 or TCP-AO
	which means it would require IPsec to be protected
or

	- use when the extra information is basically null
	if this isn't expected to be the common case, then
	that's worth noting

I.e., the security considerations should talk about what's expected, and
what the limitations are in those cases.

Joe

Attachment: signature.asc
Description: OpenPGP digital signature