RE: How should NAT terminate ?

[jrg () gbnet net (James R Grinter)]

On Mon 10 Jan, 2000, Ben Nagy <bnagy () cpms com au> wrote:
> aren't part of an existing connection, and dump them. For TCP, it is
> supposed to TCP-RST them, from memory.

(teaching grandma to suck eggs...)

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

You don't have to guess. Let's take a look at an inbound packet:

23:14:15.830838 server.8080 > client.2366: . 4031436728:4031437240(512) ack 1770624546 win 8192

their sequence number - check, they sent us it.
'our' sequence number - check, they acknowledged it
their ip address, their port - check
our ip address, our port - check

I think we have everything there. Certainly very easy to do as Darren
posits and watch the remains of someone's (plaintext) web session, acking
as it comes.

> b) lucky enough to get your IP address when they dial up, and 
> 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).

Lack of routes won't make much difference unless they divert them
somewhere which will send back RST. They'll probably just die at the
access server with 'No route to host' for a while, until the IP address
is reassigned and a route reinstalled. It's been a long time since TCP
stacks dropped connections the instant they received one of those. As
for maintaining the old session once you've got a new (different)
address - you'll never receive the packets as the route will not point
to you (and in many situations will be going to a different access
server).

Yes, some cryptographic protection is good. But I bet many people still
aren't doing so (POP3/IMAIL to their ISP - what if you get knocked off
in the middle of a large mail download.) 

Darren asks a valid question about what 'best practice' might be. I
don't have the answer, except to say that ISPs should be much better
and cleverer about dynamic IP address (re)-assignment than they
currently are.

We're diverging off the topic of firewalls, alas.

James.