On Mon 10 Jan, 2000, Ben Nagy <bnagyat_private> wrote: >aren't part of an existing connection, and dump them. For TCP, it is >supposed to TCP-RST them, from memory. (teaching grandma to suck eggs...) >a) a sequence number guessing genius (assuming you run a sane OS)and You don't have to guess. Let's take a look at an inbound packet: 23:14:15.830838 server.8080 > client.2366: . 4031436728:4031437240(512) ack 1770624546 win 8192 their sequence number - check, they sent us it. 'our' sequence number - check, they acknowledged it their ip address, their port - check our ip address, our port - check I think we have everything there. Certainly very easy to do as Darren posits and watch the remains of someone's (plaintext) web session, acking as it comes. >b) lucky enough to get your IP address when they dial up, and >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). Lack of routes won't make much difference unless they divert them somewhere which will send back RST. They'll probably just die at the access server with 'No route to host' for a while, until the IP address is reassigned and a route reinstalled. It's been a long time since TCP stacks dropped connections the instant they received one of those. As for maintaining the old session once you've got a new (different) address - you'll never receive the packets as the route will not point to you (and in many situations will be going to a different access server). Yes, some cryptographic protection is good. But I bet many people still aren't doing so (POP3/IMAIL to their ISP - what if you get knocked off in the middle of a large mail download.) Darren asks a valid question about what 'best practice' might be. I don't have the answer, except to say that ISPs should be much better and cleverer about dynamic IP address (re)-assignment than they currently are. We're diverging off the topic of firewalls, alas. James.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:56:58 PDT