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.olssonat_private
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:57:34 PDT