Subject: RE: (radius) Re: Globally unique NAS-Identifier (was: Matching NA S-IP-Address to a ctual real-life NAS IP address)

From: "Nelson, David" <[email-masked]>
Date: Thu, 25 Feb 1999 11:26:21 -0500

Alan DeKok writes...
 
> <snip> ...but my original problem was that people were advocating
> the use of NAS-IP-Address as a (potentially globally) unique NAS ID,
> for tracking/database keying purposes.  I think such use is incorrect.

Reasonable arguments have been advanced that the RADIUS attribute
NAS-IP-Address is not sufficient to identify a NAS, for purposes of
looking up it's shared secret, et. al.  This has been demonstrated for
the RADIUS Proxy Service case.

Assertions have been made that the source IP address of the UDP datagram
containing a RADIUS request is the only correct way to identify the NAS,
or more generally the RADIUS client, at least in the most general case.
This was, I believe, the rough consensus that last time this issue was
debated on the RADIUS WG mailing list, although there was not uniform
satisfaction with this approach.

There are some cases, I think, in which the source IP address of the
RADIUS packet might not suffice either.  For example, (a) the RADIUS
client obtains it's IP address from some local DHCP server, and thus the
IP address for this particular RADIUS client varies from time to time,
or (b) the RADIUS client is hiding behind a NAT or NAPT gateway, and thus
it's apparent IP address is the same as other similarly configured RADIUS
clients.  These examples may well be considered as improper or unwise
network configurations for deploying RADIUS, and I would be among the
first to agree.  My point is that source IP address is not a panacea for
globally unique identification.  There may be times in which the
NAS-IP-Address could be used to help resolve ambiguities inherent in the
source IP address.

Given that we are documenting the RADIUS protocol as currently implemented,
the best current practice may well be to use the source IP address of
the RADIUS request packet to identify the RADIUS client.  I think that
scheme has some practical configuration limitations, and a better use of
the existing RADIUS "identification" attributes, NAS-IP-Address and NAS-
Identifier, may be fruitful areas for ongoing research.  Perhaps the Roaming
Operations WG would have some advice to lend in this regard. 
 
>   Then they should remove all NAS specific information from the
> packet, and replace it with information about the proxy server.
> 
>   In fact, if they're using private IP addresses for their NASes, this
> requirement should probably be mentioned in the RADIUS RFC as a MUST.
> Polluting the global information space with private IP's is a Bad
> Thing.
> 
> >  In my opinion, issues relating to global uniqueness and a "world of
> > proxies" would seem to belong properly to the Roaming Operations
> > working group, where I have cc'ed this message.
> 
>   When in doubt, avoid the issue by redefining the problem. :)
> 
>   If RADIUS proxies don't advertise private IP's from the NASes, we
> don't need global uniqueness other than public proxy IP address.

The above discussion addresses the RADIUS Proxy Service issues, but does not
address the DHCP or NAT examples I have cited.

Regards,

Dave

David B. Nelson                          Cabletron Systems, Inc.
Software Engineer V                      50 Minuteman Road
(978) 684-1330                           Andover, MA 01810

-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: "Dale E. Reed Jr." <[email-masked]>
Date: Thu, 25 Feb 1999 09:23:34 -0800

> the RADIUS Proxy Service case.

I think you are missing what he is asking, though.  He's not asking
about
the secret (key), he is asking about a what to define a primary key 
constraint in an RDBMS.  For accounting purposes we use the following
combination:

NAS-Identifier (either NAS-IP-Address or NAS-Identifier)
Acct-Session-ID
Acct-Status-Type

You can add in NAS-Port and User-Name if you need to make the key more
dense, though.
 
> satisfaction with this approach.

Again, this is not what he is talking about. :(

-- 

Dale E. Reed Jr.      Emerald and RadiusNT
__________________________________________
IEA Software, Inc.    www.iea-software.com
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.