Re: How should NAT terminate ?

From: Darren Reed (darrenrat_private)
Date: Wed Dec 31 1969 - 15:59:59 PST

  • Next message: Darren Reed: "Re: How should NAT terminate ?"

    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 2b30 : Fri Apr 13 2001 - 13:57:05 PDT