North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Suggestion for improved identD

  • From: Adrian Chadd
  • Date: Fri May 22 15:20:28 1998 
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