Re: [tcpm] New version of TCP Option for Transparent Middlebox Discovery available
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Joe Touch wrote:
Andrew Knutsen wrote:
  
  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?
  

        I think the concept of ignoring options is pretty well understood, but perhaps we can add a reference. This situation is slightly unusual, since TCP options, in the "classic" Internet model, are always ignored by intermediate nodes (no "deep inspection"). This is no longer the case though, so the semantics of "ignoring" IP options apply to TCP options (pass them along intact at intermediates), as well as the usual interpretation of ignoring a TCP option (skip over them at the endpoint). This is well established "art", so we didn't see the necessity of explanation...

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.

  

    First, I'll note again that protection would not require MD5, AO or IPSec, if a hash is included in the target data.

    Regarding uses, whats expected is that the option will be used primarily for its current use (although if it has other uses thats great).  In this case, which is a compression tunnel, the only time we'd have to deal with both options is if the client sent the MD5/AO, and policy said we should pass it to the server. This is the case described in the "Interoperability" section, since it applies to other large client-originated options as well.

    In the "slow path", if the connection is in fact intercepted, there is a bit more handshake during tunnel setup to use for auth -- so MD5/AO is not necessary between the tunnel endpoints. Again, these details would depend on the specific device capability.

Andrew


Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.