Re: How should NAT terminate ?

[Mikael Olsson <mikael.olsson () enternet se>]

Darren Reed wrote:
> > If your ISP terminates the connection (or line noise kills
> > it), your firewall can't do much about it.
> > It COULD conceptually wait until you reconnect and then send
> > out a bunch of RST's using the old IP, but chances are that your
> > ISP will hate you for that.
>
> Why is your ISP going to hate you ?  Most of them do gratuitously
> nothing in the way of source address spoof protection so they're
> hardly going to notice.

It .... depends :-)
ISPs with DSL and other high speed connects tend to be a bit more
fascist (and rightly so) about source spoofing than POTS ones. 
At least this is the case here in Sweden.

> > I don't think sending ICMP unreachables for UDP connections will
> > buy you a whole lot. 
> > [Snip my experiences with UDP]
>
> My experience in programming UDP (I wrote one of the early UDP
> port scanners) tells me that I don't need to listen for them
> specifically.  The next read or write to the UDP socket will
> return an error if an ICMP error packet has been received for it.

This depends on the app (what does it do with an error? retry
the recv() call or drop the "connection"?"), and it also
depends a GREAT deal on the OS.
For instance, the default WinNT stack doesn't return errors
on UDP socket recv()/recvfrom()s if they've received ICMP
errors. This would mean that servers out on the 'net that
you send ICMP errors to would just ignore those errors.

Ahwell, let's leave UDP for now.

> The problem isn't individual protocols, per se, but how should the
> problem itself be delt with ?  Should some form of notification be
> sent or not ?  Thankfully there's no IPv4 ICMP message which tells
> the other end your IP# has changed!

(Actually there IS such a message. It just isn't used anywhere =P )

There was a discussion a long time ago about ARPs for the same reason.
The proposed solution was an "UNARP" protocol (basically an ARP
with zero length hardware fields) that the dial-in server could
send out when the connection is dropped.

However, I've never seen this implemented in any standard equipment.

Implementing a "standard" ICMP_I_DONT_WANT_TO_TALK_TO_YOU_ANYMORE (heh =P ) 
will be a lot harder though, since you'll want to send these to all
nodes you've been talking to. Okay, granted, you still have your state
table, but to get complete assurance that the remote actually understood
your request, you'll have to implement an ICMP_IDWTTTYA_ACK, so that 
you know when you can stop sending your requests to that server.

Hmm, this is beginning to sound to me like we'd be opening up a HUGE
DoS opportunity. (Thinking of sending out illegit requests.)

> Even still, you've only answered this for one side of the connection:
> that out on the Internet.  I'm slowly becoming of a mind that sending
> out RST's and ICMP unreachables, in both directions with the appropriate
> IP addresses, is the correct thing to do.

It _is_ alot easier for your local FW to instruct your local machine
to stop talking. It is also alot easier for your local FW to just NOT
let its traffic through.


Hmm.. I just don't know. It sounds to me like you're trying to fix
something that is already broken in many other WORSE ways. 
To my mind, the correct fix is to get people to use IPsec (or SSL 
for that matter) as soon as something "sensitive" is being done.
(Yeah I know, CPU crunching will be a big bummer =( )

-- 
Mikael Olsson, EnterNet Sweden AB, Box 393, S-891 28 ÖRNSKÖLDSVIK
Phone: +46 (0)660 105 50           Fax: +46 (0)660 122 50
Mobile: +46 (0)70 248 00 33
WWW: http://www.enternet.se        E-mail: mikael.olsson () enternet se