Subject: [radext] Concerns with Operator-NAS-Identifer

From: Mohit Sethi <[email-masked]>
Date: Thu, 16 Aug 2018 21:39:20 +0300

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 17 Aug 2018 17:27:00 -0500

On Thu, Aug 16, 2018 at 02:55:00PM -0400, Alan DeKok wrote:
> On Aug 16, 2018, at 2:39 PM, Mohit Sethi <[email-masked]> wrote:
> > Recent comments from Adam and Ekr got me to look at this draft and its text on Operator-NAS-Identifer in more detail.

Thanks for taking a look!

> > 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.
> 
>   I think the situation you're concerned with isn't the use-case defined in coa-proxy.  So that avoids any problems.
> 
>   There is nothing in the coa-proxy that says you *must* remove NAS-Identifier, etc.  I could make that clearer, I suppose.

I see (in both -05 and -07) in the "Operator-NAS-Identifier" section (3.3
or 3.4, respectively):

   [...] When the Operator-
   NAS-Identifer attribute is added to a packet, the following
   attributes MUST be deleted: NAS-IP-Address, NAS-IPv6-Address, NAS-
   Identifier.  The proxy MUST then add a NAS-Identifier attribute, in
   order satisfy the requirements of Section 4.1 of [RFC2865], and
   Section 4.1 of [RFC2866].  The contents of the NAS-Identifier SHOULD
   be the Realm name of the visited network.

Does that not do what you want?

(There isn't exactly anything that precludes the contents of this "newly
added" NAS-Identifier from being the same value that was removed or
something that would fit the use case described by Mohit, though, is
there?)

-Benjamin

---

From: Alan DeKok <[email-masked]>
Date: Fri, 17 Aug 2018 20:49:01 -0400

> I see (in both -05 and -07) in the "Operator-NAS-Identifier" section (3.3

  Yes... I saw that after sending the message

> something that would fit the use case described by Mohit, though, is

  I think it's OK to change that to a SHOULD.  With a comment that not doing so may leak private information.

  Alan DeKok.