Brett Frankenberger writes:
:: Tom Perrine writes ::
I've been following the "need a better IDENT" thread for a bit, and have some questions and suggestions.
Let's see if we can *really* define what it is we really want, and figure out if IDENT or "son of IDENT" is really the answer.
My two cents: IDENT is fundamentally bad for this application for several reasons, a few of which I will enumerate: -- It requires devices in the middle to intercept packets and masquerade as another device, for the purpose of answering IDENT requests. I philosophically find this unacceptable. Some may disagree, but enough will probably agree to prevent this from ever getting to 100% deployment. Packets from my IP address should be from me, and packets to my IP address should get to me.
What about transparent http proxying? smtp redirecting? Thats examples of connections your clients think are direct to the internet. But they don't know that.
-- It provides no way of knowing the source of the information. That is, if I IDENT you, I might be getting an easily faked response from your PC or a not-so-easily-faked response from some device at your ISP. I have no way of knowing which is which.
Whats the problem with this? I think you can trust your upstream not to be intercepting ident requests not sent to dynamic PPP clients..
-- IDENT was indended to provide port level information -- that is, what user does Machine X think it using Port Y on Machine X. We have to give this up if we go with forged IDENT responses. It would be better to leave this in place, and implement a new means of getting the new information that we now want, which is: Who does the owner of IP address A.B.C.D think is currently using that address. (Port-level information is, of course, useless on a multi-user machine ... but the "Server End" of a connection has no way of knowing if the client-end is multi-user or single-user.)
What difference does this make on a single-user machine? or a multi-user (eg linux) machine? Or, more specifically.. on a dynamic IP client? It was used to get the userid of who owned a port on a machine back when these machines were trusted UNIX boxes and users couldn't change their ident. The question here is 'trust'. Why bother using ident in ANY code anymore if it can't be trusted? Yet it still is. So move the trust demarcation point to where the user has no control over it. Remember, if its a static IP or network client, you don't proxy ident requests - since the static IP is the demarcation point of trust. They can change their ident, but no matter what, their IP or network still stays the same.
ISTM that a much better way to accomplish this would be TXT records (or, if we want to make this more complicated, some new RR type) associated with the IN-ADDR.ARPA domain. Using dynamic updates and very small TTL, the ISP can change these as the address is assigned to a new user. This lets you reasonably get the IP Address Owner's opinion of who has that IP address, without giving up anything we already have, and without creating any ambiguity as to the source of the information -- IDENT comes from whoever owns the machine, IN-ADDR.ARPA comes from whoever has the IP Address Space.
And rewrite all the software that uses ident? DNS wasnt meant to do that. You mean that people have to update their DNS servers to support the new extensions? And upgrade libraries to support this? You're now running two seperate services for much the same thing - identifying usernames. ident was originally designed with multiuser secure UNIX machines in mind. With the advent of ppp stacks and users having their own induvidual IPs, that notion is no longer valid, since the user has control over the ident response. Ident still wins out. Setup transparent redirection to a local box (or boxes depending on your network topology) which can answer the ident request. Only enable transparent redirection *TO* the dynamic IP pool, and not all IPs, and it doesn't affect your static IP clients. Set it up, and forget about it. If the NAS vendors adopt this, well great.. even less work to do. All that is left is for the people who WANT to do this, to agree on a hash algorithm. Adrian