[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Are we solving the wrong problem?
Hi William,
If you're feeling ambitious, change "two" to "many" and modify TCP so
that during the SYN+SYN/ACK, both sides can exchange cryptographically
signed connection IDs. The presence of these two IDs with a correct
signature identifies subsequent packets associated with the
connection, regardless of the source and destination addresses.
Interesting. This sounds pretty much like HIP base exchange...
Any such "TCP" packets can also contain an "address update" option
which offers the other side a fresh list of addresses at which it can
be reached as well as hints about priority and load balancing.
... and this like HIP mobility & multi-homing.
Among other nifty things, this would allow you to completely dispense
with the source port. If you wanted to, you could also change the
destination port to a destination service name, since it need only
appear in the original SYN packet.
And this somewhat (but not quite) like id delegation in HIP.
I suppose if you want to retain backwards compatibility, you would at
least include the source and destination port numbers in the SYN
packet and drop them later if the options returned in the SYN/ACK
agreed to use your new TCP.
And this like the hack (so far unspecified) to carry HIP I1 as TCP
options.
If you're feeling *really* ambitious, exchange the hostname during the
connection setup as well so that if all the connection's IP addresses
change while the connection is idle, the next transmitter can find
the other side by refreshing the address list with a DNS lookup.
Require the DNS server to allow it's clients to update their
hostname's list of IP addresses.
If you replace DNS with a rendezvous server, your hit again at HIP :-)
<snip>
If you do all of these and then succeed in deprecating old-style
source port/dest port connections, this has some interesting
implications for route aggregation. You'll find it becomes possible to
create a fully automatic system to resize and reassign IP addresses at
need which in turn allows the Internet as a whole to automatically
achieve something near the optimum achievable aggregation through the
kind of "emergent behavior" you talk about.
That was realised in the HIP community some 6-7 years ago, and I
guess in the Nimrod and some other communities even earlier.
Say, that's pretty neat. I had considered most of these ideas before,
but it didn't occur to me to use a TCP protocol addition as the
starting point so that deployment could be incremental and fully
backwards compatible. If you don't write something up, maybe I will.
The biggest differences between your thinking and HIP seems to be
that HIP is implemented below TCP, so that it works also for UDP. I
think it matches better with the IP semantics, as a single IP address
is (today) typically associated with a number of co-located TCP and
UDP end-points.
Then there is also work specific to TCP, e.g Christian Huitema's eTCP
(or whatever it was called).
I'm glad to see that more people come to the roughly same
conclusions, independently. :-)
--Pekka Nikander
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg