Re: How should NAT terminate ?

[Darren Reed <darrenr () reed wattle id au>]

In some email I received from Ben Nagy, sie wrote:
[...]
Don't mean to spoil your party, but...

> So, that part is all covered. Nobody can resume your old sessions unless
> they are:
> a) a sequence number guessing genius (assuming you run a sane OS)and 

Not needed.  The packet received has both sequence numbers in it (one is
an acknowledgement number and one is the sequence number) so if your TCP
stack was told to misbehave and not send out a TCP RST, you could quite
happily resume the other connection by either using a user TCP program
or hacking the kernel in such a way that you could take advantage of this
situation.  Someone replied with a reference to a phrack article about
this subejct, so assume that hacks/programs exist on the Internet to do
exactly this.

In fact, depending on the timeline of events between you loosing the
connection and an attacker trying to pick up the connection from a
broken dialup session, it is possible that any attempts by the original
NAT box to terminate sessions will be ignored due to incorrect TCP
sequence numbers.

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

This isn't necessarily a personal problem.

> 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).

In most cases, the "routes" will be a CIDR block that all terminate on
the same router, so no special "routes" will have been removed (unless
you've got your own IS and do stupid things - i.e. dialup).  The worst
that can happen is for ICMP unreachables to be returned by the router,
which some TCP stacks will suppress for a period of time, hoping that
the network will fix itself and the unreachable problem will disappear.

> 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.

This is a no brainer.  However, whilst the firewall knows this, the PC
which just made a web connection to wwww.idont.care doesn't and still
thinks it has a TCP connection to it and will leave it open, incorrectly
hoping for some action.

> 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.

You're forgetting that the firewall will more than likely still have a
record of all the old state information for filters and NAT sessions,
so generating things with the old IP# is not exactly a problem.

Darren