[e2e] Can we revive T/TCP ?

[Joe Touch]

Michael Welzl wrote:
...
> But it seems to me that some things just can't be solved
> on top, and so I started questioning the usefulness of
> connection setup in authenticated environments.

Security associations are different from transport connections. The
former defines an identity and an agreement to accept
authenticated/encrypted packets. The latter is for reliability,
reordering, and congestion control.

> But I'm
> also questioning the problem with long lasting connections
> in such environments... I don't see a problem, but I'm not
> a security expert, and the fact that nobody has spoken up
> saying "sure, the problem is..." gives me some confidence.

If the IPsec SA persists, then any connection inside it is (by
definition) permitted, including long-lived ones. Long-lived transport
connections give a more accurate sense of RTT, congestion info, etc.

The concern about long-lived connections of late is with on- and
off-path attacks, both of which presume a LACK of IPsec-levels of
protection.

>> If you're doing short function calls, then why do you need TCP? If you
>> want congestion control, have you considered DCCP? Or SCTP?
> 
> We want reliability, so TCP or SCTP would be our protocols of
> choice. I don't see much benefit of SCTP's features for our
> scenario (but I'd be thankful for inspirational comments in
> this direction  :)  ).

You want short transactions. Things you would care about include:
	- multi-packet transactions (even if short)
	- reliability
	- congestion control

UDP doesn't provide those; TCP with control block sharing (RFC2140) or
using a central Congestion Manager would help (parts of 2140 are in
Linux), but don't address the 3WHS delays.

Pipelining at over a single connection would, but you need a muxing and
chunking mechanism. You can use:
	per-transaction TCP connections
	BXXP directly over TCP
	SOAP over HTTP over TCP
	SCTP

You might want to compare the delays of each.

>>> - exactly my thinking. So skipping the handshake would make sense
>>> in such an environment, right?
>> So would skipping shared state on a per-exchange basis. ;-)
> 
> What do you mean? Sounds like a hint in the right direction,
> but I can't solve the puzzle behind your words...

RPC over UDP. If you don't need the transport layer to manage state, use
a stateless transport layer ;-)

If you still want congestion control, RPC over DCCP ;-))

>>> To me, there's just one open question. When all nodes authenticate
>>> themselves in a Grid, why don't they just set up and maintain TCP
>>> connections to each other forever? The UTO draft could help here.
>>>
>>> I've been told (by Grid people) that this is completely impossible
>>> because it's a big security problem. I fail to see why, and nobody
>>> ever explained it to me.
>> If they use IPsec, it'd be useful to understand the security problem
>> that persistent TCP connections present.
> 
> This was a comment from an anonymous paper review, so I can't
> ask back  :)   and the reviewer might not have thought of IPSec,
> but using it is surely an option in Grids. Maybe it was just
> a misunderstanding - me considering a Grid with, and her/him
> considering a Grid without IPSec.

That sounds, IMO, more likely. Long-lived connections are worrisome for
BGP of late, but that's in the absence of IPsec, or worries about the
particular algorithm (e.g., MD5) being broken over time (which can be
solved using 3DES, AES, etc.)

Joe