[radext] Concerns with Operator-NAS-Identifer

[Mohit Sethi <[e-mail]>]

Hi all,

I have been a quiet observer on the radext list because of my interest 
in EAP, RADIUS and DIAMETER deployments.

Recent comments from Adam and Ekr got me to look at this draft and its 
text on Operator-NAS-Identifer in more detail.

Let me preface by first admitting that I certainly do not have as much 
deployment experience as some others on the list. So take my comments 
with tons of skepticism and please be a little gentle when shooting me down.

The draft version -06 says that visited network SHOULD add 
Operator-NAS-Identifer attribute to the Access-Request or 
Accounting-Request packets. And when it is added, other attributes such 
as NAS-IP-Address, NAS-IPv6-Address, NAS-Identifier MUST be deleted. The 
text also says that for meeting the requirements of Section 4.1 of 
[RFC2865], a NAS-Identifier is added anyway.

Finally, the draft says the following "We suggest that the contents of 
the NAS-Identifier be the Realm name of the Visited Network.  That is, 
for everyone outside of the Visited Network, there is only one NAS: the 
Visited Network itself.  For the Visited Network, the identity of the 
NAS is private information, which is opaque to everyone else."

"We suggest" leaves a lot to interpretation in a standards document. 
Besides, this suggestion might break some deployments. Let me explain 
this a bit with an example:

Many enterprises (rightly or wrongly) want to control which users can 
connect to which NAS. For example, employees of ACME should be allowed 
to connect to NAS A which allows access to the internal network and 
resources. Guests of ACME should only be allowed to connect to NAS B 
which allows restricted access to the Internet. Of course the situation 
gets more complex when a shared NAS is used and access separation is 
done with VLANs.

Let's say that ACME has offices in London, Bangkok and San Jose with 
local AAA servers and users in realms acme.uk (for London), acme.th (for 
Bangkok) and acme.com (for San Jose). Employees often roam to different 
sites of ACME. When an employee from San Jose is in London, his/her 
authentication requests are forwarded to the AAA for acme.com based on 
the realm in the Network Access Identifier (NAI)/Radius User-Name 
attribute.

Depending on which NAS the user is trying to connect through, the AAA 
would decide whether to send an Access-Accept or Access-Reject. In cases 
like this, the visited networks belongs to the same enterprise. The 
visited network can choose to hide some its internal network setup by 
using the same NAS-Identifier for a WLAN profile, VLAN interface, or AP 
group. I found Cisco describing this scenario at this page (please see 
the bottom of the page where it says "The NAS-ID is sent to the RADIUS 
server by the controller through an authentication request to classify 
users to different groups so that the RADIUS server can send a 
customized authentication response."):

https://www.cisco.com/c/en/us/td/docs/wireless/controller/7-4/configuration/guides/consolidated/b_cg74_CONSOLIDATED/b_cg74_CONSOLIDATED_chapter_01000111.html

and here I found Juniper describing something similar:

https://www.juniper.net/documentation/en_US/junos/topics/concept/subscriber-management-nas-port-id-overview.html

I know of 1 deployment where such access control is done (the network 
administrator for this deployment has changed jobs and is not a regular 
participant but I can try and ask him to chime in). Of course there 
might be other deployments as well.

In summary, there are situations when the visited network would want to 
differentiate the NAS classes through which a user is trying to connect 
and reveal that to the remote AAA making the access decision. The 
visited network is still in control of what and how much information it 
reveals. The NAS-Identifier string provides a lot of flexibility to 
network operators and suggesting some change to its use perhaps needs 
more thorough reasoning.

--Mohit