RE: How should NAT terminate ?

[Johnny Shelley <syntax () nations net>]

On Mon, 10 Jan 2000, Ben Nagy wrote:

A few minor bones to pick here.

> a) a sequence number guessing genius (assuming you run a sane OS)and 

Ok, this would probably actually take some sniffing assuming a decent
sequencing implementation. 

> b) lucky enough to get your IP address when they dial up, and 

This isn't terribly hard, even without any access, someone attack your
machine with something like ath0 during peak hours and call in before
someone else grabs the session. 

> c) fast enough so that the packets you're worried about don't get bounced in
> the meantime by the ISP who has just removed the routes to that IP address
> (since you disconnected).

This assumes your ISP will remove routes and is often not the case,
especially in small mom and pop shops where the network is not much more
complicated than a few servers, a switch, dial-ins and a router.  In a
case like that, the server is just going to keep trying to send assuming
the packet got lost along the way
 
> If you're worried about the new owner of your IP address being EVIL and
> running sniffers and stuff, then you need to make sure that anything that
> you're doing which is sensitive is encrypted. But you do that anyway, right?
> I thought so.

Sadly, this can't always be the case, but it damn well should be.
 
> Your NAT sessions will all die horribly and will need to be re-established.
> You cannot pick up an old TCP session with a new IP address.

Well..
 
> One final note: Once you get the new IP address there's nothing you can do
> to close down those old sessions - the stack at the remote end won't accept
> RSTs from you since you've now got a new IP address and aren't part of the
> old session. The only way your pre-emptive strike could work is if it were
> performed before the link dropped - this is likely to be impossible.

This is the cute part.. the far end may very well still have the
connection in an open state.  I bumped into this playing around with ircd
(I know its an ugly habit).  It was actually fairly simple to send a
sequence of commands to the server for up to the ping timeout limit the
server/client had set.  

By tearing down the connection without killing the session, I could dial
in from a totally different ip address and have a (one sided) session.  My
machine seemed happy to 'spoof' packets from the old ip as it had never
torn down the connection. Of course it never recieved any responses, but
you know what you want to do, right? 

johnny
---
"They called me mad, and I called them mad, and damn them, they outvoted me."
                        -- Nathaniel Lee, on being consigned to a mental
                           institution, circa 17th century.