Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!aramis.rutgers.edu!geneva.rutgers.edu!hedrick From: hedrick@geneva.rutgers.edu (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: IP based authentication of hosts Message-ID: Date: 11 Apr 89 03:46:47 GMT References: <376@ists.ists.ca> <29416@bu-cs.BU.EDU> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 22 Yes, with source routing you can fake IP addresses in such a way that you get a two-way conversation going to the wrong place. For that reason, our gateways drop any packet that uses source routing. I'm looking into a more selective approach, but for the moment this seems the safest. However even the ability to fake source addresses leaves the possibility of some damage. Some servers (e.g. some options of YP, maybe also named) may allow you to change a database with a single packet. The fact that you don't get an ACK doesn't necessarily prevent the damage from being done. This suggests that RPC servers that make significant changes should require passwords or some other validation. Furthermore, I'll bet I could find a way to open a TCP connection even if I don't get the ack's back. Probably I couldn't keep it open very long, but I might get enough data through to do an rsh. It would require some intelligent guessing of what sequence numbers you're using, and probably a good deal of redundant traffic. Eventually I'm probably going to make our external gateways check source addresses of packets they forward. The idea would be to refuse to allow packets into Rutgers from the outside with Rutgers source addresses. However in the end we're probably going to want encryption-based validation for everything. I think even with kludges in the gateways, the days are numbered for security based on source addresses.