[e2e] TCP spoofing in overlay networks

[Joe Touch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Jonathan Shapiro wrote:
|
|
| Joe Touch wrote:
|
|>
|> TCP 'spoofing' of this sort is basically what TCP Splicing does; there
|> are numerous problems with this - notably that it breaks the E2E utility
|> of TCP (getting an ACK doesn't mean the other end got the data!), as
|> well as challenges when the window sizes of the two TCPs differ.
|
| I hope I am not rehashing an old debate on this list, but did the
| breaking of E2E semantics and mismatched window sizes prevent the
| deployment of spoofing/splicing for satellite links? (I'm genuinely
| curious, having only been recently exposed to this work.) If these were
| not considered insurmountable problems in that context, why should they
| be insurmountable for overlay networks?

They were considered either insurmountable or commercially deployable,
depending on your perspective.

I.e., thye were tried and continue to break E2E semantics, and break
where window sizes mismatch, but that doesn't stop people from using them.

But there are other issues with using TCP links for overlays: sending
packets over a byte-oriented network has problems, notably delays added
because:
	- TCP tries to ACK pairs of segments
	- uninitiated designers forget to disable Nagle
	- there is no way to force IP segments to align to TCP
	  segments unless you implement the TCP at both ends of the
	  system; existing TCP stacks will end up fragmenting
	- retransmission for reliability adds delays

|> As to whether this is an overlay or not, I don't see how 'overlay'
|> related. You're just spoofing a TCP connection; overlays (IMO) are
|> defined by tunnels. There's no tunnel here (unless you're saying you're
|> tunneling over TCP, which is a bad idea for numerous other reasons).
|
| I guess I have a more inclusive definition of 'overlay' in mind. I would
| define an overlay network is a graph whose vertices are a set of
| end-hosts and whose edges are a subset (not nec. a proper subset) of the
| edges in the complete graph connecting those end-hosts, and represent
| paths in the underlying network.

Edges connect the end hosts how? Tunnels ;-)

| Whether communication along those paths
| is multiplexed over tunnels or separated into transport-layer
| connections would be a choice for the designer---with non-trivial
| consequences.

IP over TCP is a tunnel. IP over IP is a tunnel The former is very
inefficient; the latter less so. Or are you talking about arbitrary
application messages, at which point is it even a network?

| Maybe this is abuse of terminology, but the above
| definition seems to be shared by some. My question was, as you point
| out, about forming overlays without tunnels. The reason to consider this
| an overlay network is that if one has multiple choices of relays, then
| one is faced with a routing problem in addition to a session-splicing
| problem.

People who do application-layer networking necessarily reinvent
transport and network protocols at the application layer. So they will
end up needing something to do E2E transport over the IP over the TCP.

The most common misconception (IMO) about such systems is the difference
between provisioning and forwarding. Selecting among multiple existing
tunnels is a forwarding operation; picking which relay to open a
connection to is a provision operation. Provisioning is what you do to
deploy a network (i.e., IMO, it's external to the network). Forwarding
is part of how the network thus deployed works.

joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCJ06hE5f5cImnZrsRAj43AJ9+43NJGTZoIE9UbUtd4nsOtf7E/wCg77Ki
AIPob5UDc+3NKf5BdCsIXMo=
=agoo
-----END PGP SIGNATURE-----