Subject: Re: SSH and NAT and re-connections.
To: None <netbsd-help@netbsd.org>
From: James K. Lowden <jklowden@schemamania.org>
List: netbsd-help
Date: 11/11/2002 00:45:10
On Sun, 10 Nov 2002 20:44:33 -0600 (CST), Richard Rauch <rauch@rice.edu>
wrote:
> > A TCP connection can't survive if the IP address changed. ssh isn't
> > designed to restart a tcp connection for the sme session.
> 
> I know that TCP can't handle it.  That's why this seems like a ``good
> thing'' for ssh to be able to recover from.  I'd hoped that it was a
> feature that was built into ssh.  

Keith already offered a cogent answer, but I read your question slightly
differently.  Let me take a different slant on it, from a data comm
perspective.  

Protocol layers generally carry the notion that upper layers rely on lower
ones.  TCP is singularly resilient in that regard AFAIK.  Other popular
protocols e.g. DECnet, SNA, X.25 (gee, everything TCP/IP made obsolete,
hmm) terminate higher level connections when a lower one fails.  Even TCP
doesn't reëstablish a connection so much as wait awhile for the lower
levels to get their act together before giving up.  

Analogous to ssh reëstablishing a connection after a TCP failure in which
the ip address changed would be TCP reëstablishing a connection after the
link layer address changed.  The only example of something like that I can
think of would be changing the MAC address of an Ethernet card on the fly.
 I don't think TCP would be amenable to that.  It seems to me it would be
impossible to do securely (as defined.  Cell phones are an example of
changing packet addresses as you drive down the road while (sometimes)
maintaining the session.)

I'm not saying it can't be done, just that things don't normally work that
way.  

I have a feeling you know most of this already, but I thought I'd chime
in, in case you hadn't looked at it that way.  

Regards, 

--jkl