OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
NFR Wizards Archives: Re: How should NAT terminate ?

Re: How should NAT terminate ?

Subject: Re: How should NAT terminate ?
From: Darren Reed (darrenrreed.wattle.id.au)
Date: Wed Jan 12 2000 - 22:17:08 CST

In some email I received from Mikael Olsson, sie wrote:
>
>
> For the sake of clarity, I gather that your network setup is like
> this:
>
> PC -> Firewall with OWN dialup -> POTS -> ISP -> Internet

Yup. Mine and that of countless others. Also, replace POTS with
DSL or cable for a more complete picture.

> Darren Reed wrote:
[...]
> > Whatever the case, there is a period of time in which the original
> > endpoints believe a connection exists, which no longer does. Should
> > a pre-emptive strike be lunched by the firewall to blow these away
> > by doing something like sending TCP RST's ? What about for DNS/NTP
> > queries - are ICMP unreachables appropriate ?
>
> It all really depends on who does the hang up.
>
> 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.
>
[...lets eliminate the firewall orchestrating the hangup for now...]

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.

> I don't think sending ICMP unreachables for UDP connections will
> buy you a whole lot. Most UDP based protocols don't listen a
> whole lot to returned ICMP messages once the "connection" is
> "established"; they use time outs instead. Heck, most don't
> even listen to ICMP messages while they "connect".

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.

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!

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.

> BTW, your copy of ELM has Y2K problems:
> "Date: Sat, 8 Jan 100 01:04:08 +1100 (EST)" *ahem* :-)

I know. It's great, I get to see how many people read email headers :)
So far, my estimate is 1 in every 1000 or so. But then my audience is
probably skewed towards those that do :-)

Darren

p.s. the version of elm with the y2k problem is also mime unaware :)

This archive was generated by hypermail 2b27 : Wed Jan 12 2000 - 22:17:08 CST