Subject: RE: (radius) Matching NAS-IP-Address to actual real-life NAS IP a ddress

From: Indranil Bagchi <[email-masked]>
Date: Wed, 24 Feb 1999 13:05:16 -0800

I would agree with this point of view. We have a radius
client to authenticate users telnetting into our
ethernet switch. Howver, the switch has no fixed IP
address. It uses the address of the vlan over which the
radius server is reachable. This might change for a
number of reasons including change of IP address
associated with the vlan or if the route to the radius
server changes. Tying the NAS IP address with the vlan
address would make the lookup to fail in the above
scenario.

Regards

-----Original Message-----
From: Nelson, David [mailto:[email-masked]]
Sent: Wednesday, February 24, 1999 8:40 PM
To: 'Alan DeKok'; [email-masked]
Subject: RE: (radius) Matching NAS-IP-Address to actual real-life NAS IP
a ddress

Alan DeKok writes...
 
>   Under what circumstances can a RADIUS client put a NAS-IP-Address
> attribute inside of a packet, which is different than the IP address
> from which the packet is sent?

I suppose if the RADIUS client is a multi-homed host, it might do so.
The primary purpose of the NAS-IP-Address attribute (or the NAS-
Identifier) is so that the RADIUS server may look up the shared secret
of the NAS.  A multi-homed NAS may have it's secret registered on the
RADIUS server by only one of it's IP addresses.  A somewhat contrived
example, perhaps...

>   I'd like to see the draft updated to talk about this issue.  Even
> adding a 'SHOULD' would help, as in:
> 
> ---------------------------------
> 5.4.  NAS-IP-Address
> 
>    Description
> 
>       This Attribute indicates the identifying IP Address of the NAS
>       which is requesting authentication of the user.  It is only used
>       in Access-Request packets.  Either NAS-IP-Address or NAS-
>       Identifier SHOULD be present in an Access-Request packet.
> 
>       If the NAS is originating the packet, then the value of the
>       NAS-IP-Address attribute SHOULD match the IP address of the
>       interface from which the packet is sent.

I don't know that this is important to require or desire.  The
NAS-IP-Address
is just a "name" by which the RADIUS server may know the identity of the
NAS,
and thus know it's shared secret.

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.
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: "Beadles, Mark A." <[email-masked]>
Date: Wed, 24 Feb 1999 20:12:16 -0500

From:	Alan DeKok [SMTP:[email-masked]]
>  Wouldn't that identifier be better handled by using the pre-existing
>NAS-Identifier attribute?
>
>  (ducks the thrown shoe)

How'd you see that shoe coming?  :) Not all NAS vendors support
NAS-Identifier, nor are they required to.  

>  Hmm.. so the NAS-IP-Address isn't necessarily associated with a
>RADIUS client

The NAS-IP-Address is associated with the NAS that originated the chain of
RADIUS requests that led to the current one.  

>The server can get requests from each NAS, with the SAME
>NAS-IP-Address.  e.g.  (ala Livingston 1.16)

Yes, this CAN happen.  It would be a very bad idea to implement a network
this way, since you couldn't keep track of your NAS's.  You could just as
well say, "The server can get requests from each NAS, with the SAME
NAS-Identifier."  It could happen, but it's no way to run a network.

>  So NAS-IP-Address CANNOT be used as a unique NAS identifier.  That's
>why I asked my original question.

Yes it can.  If you care to use it this way (and that is an operational
choice, not a protocol requirement), then as long as the NAS-IP-Address is
unique within the space of concern to your RADIUS servers, you're golden.

>  I think I've argued successfully that your suggested use of
>NAS-IP-Address as a unique identifier has its problems.  

Heck, I didn't think of it all by myself, but thanks.  People use
NAS-IP-Address for this all the time.

>Therefore,
>the proper methods for implementating and handling that attribute are
>not obvious.

Right, which is why Carl may want to make a note about.  Aydin's suggestion
would do.

+ Mark Anthony Beadles +        MCI WorldCom         +
+  [email-masked]   +     http://www.wcom.net     +
+  Voice 614.723.1941  +       Fax 614.723.8407      +

-

---

From: "Nelson, David" <[email-masked]>
Date: Thu, 25 Feb 1999 14:02:47 -0500

Carl Rigney writes...
 
> Excellent idea.  How about this for NAS-IP-Address:
> 
>   This Attribute indicates the identifying IP Address of the 
>   NAS which is requesting authentication of the user, and 
>   should be unique to the NAS within the scope of the RADIUS
>   server.  Note that NAS-IP-Address MUST NOT be used to select
>   the shared secret used to authenticate the request, the
>   source IP address of the access-request MUST be used.

To this I would recommend adding an operational note, to the 
effect of the following:

The source IP address of the access-request packet MUST be known
to the RADIUS server, possibly precluding network configurations
in which the source IP address is variable (e.g. assigned by DHCP)
or not unique (e.g. that of a NAT proxy server).   

Regards,

Dave

-

---

From: "Beadles, Mark A." <[email-masked]>
Date: Thu, 25 Feb 1999 14:14:57 -0500

From: Carl Rigney [mailto:[email-masked]]
>  This Attribute indicates the identifying IP Address of the NAS which is
>  requesting authentication of the user, and should be unique to the NAS
>  within the scope of the RADIUS server.  Note that NAS-IP-Address MUST
>  NOT be used to select the shared secret used to authenticate the
>  request, the source IP address of the access-request MUST be used.

This looks right on.

---

From: "Beadles, Mark A." <[email-masked]>
Date: Thu, 25 Feb 1999 14:30:38 -0500

>or not unique (e.g. that of a NAT proxy server).   

I don't think that this text belongs in the description of NAS-IP-Address,
since we have already established that this attribute is not used for shared
secret checking.  It may be appropriate to put this text somewhere else,
like in the security considerations.

I would also note as a nit that just because an address is assigned by DHCP
does not mean it is variable.

-

---

From: "Mun, Mike" <[email-masked]>
Date: Mon, 1 Mar 1999 10:06:08 -0500

Both NAS IP and NAS Id do not give any better way to identify a NAS if
private NAS IP addresses can be used.  I propose a structure way such as
[email-masked] <mailto:[email-masked]>  for NAS ID to identify a NAS in
global scope.

Mike  

	----------
	From:  Jeff Weisberg [SMTP:[email-masked]]
	Sent:  Monday, March 01, 1999 9:50 AM
	To:  [email-masked]
	Subject:  Re: (radius) Matching NAS-IP-Address to actual real-life
NAS IP address

	| Why bother to provide both?  Either identifies the NAS, so what's
the
	| good of carrying redundant information in the request?

	well, since I send both, I guess I'll say what/why.

	when I proxy a request off, I figure that the NAS address and FQDN
	are fairly meaningless to the remote ISP, so I set the NAS-ID
	to something along the lines of "OpNet Philadelphia NAS #4", as a
	convenience aid.

		--jeff

	-

---

From: "Beadles, Mark A." <[email-masked]>
Date: Mon, 1 Mar 1999 10:36:16 -0500

From: Mun, Mike [mailto:[email-masked]]:
>[email-masked]  for NAS ID to identify a NAS in
>global scope.

I fail to see why the RADIUS protocol WG needs to define internal structure
of the NAS-ID attribute in order to enhance communication between
administrative domains. I do not see that as a RADIUS protocol issue.  The
RADIUS protocol says, here is an attribute and its on-the-wire format.  

Contents and administrative use of that attribute WITHIN a single scope
should be left up to the operator.  I don't see how anybody would argue with
that: within a single administrative domain, an operator can stuff whatever
they want to in there and interpret it however they operationally see fit.
If they want to use NAS-IP-Ads or use some implementation specific code that
is meaningless outside, so be it.

Contents and administrative us of that attribute BETWEEN scopes, IMHO,
belong elsewhere, like roamops.

-