Subject: Re: Final call for consensus poll for IANA #409959 NAS-Port-Type value request

From: Stefan Winter <[email-masked]>
Date: Wed, 08 Jun 2011 14:48:44 +0200

Hi,

> I think we need to get these question marks discussed before saying no.
>
> Historically, the NAS-port-type is associated with the L1/L2 port over
> which the “access” service is provided. But with the new use of
> RADIUS, this view is no longer applicable. Again, consider a Mobile IP
> Home Agent node implementing RADIUS client for AAAing the MN’s
> registration requests. The L1/L2 port that receives the MN
> registration request has no significance, and it can be one of many
> types. Here, our thinking is, the “logical” port is the “Mobile IP
> Home Agent”, and that has nothing to do with the L1/L2 port.
>
> What do people think?
>
>

If the use of RADIUS has nothing to do with giving access to real
NAS-Ports - then why overload the NAS-Port-Type attribute for this
unrelated business? NAS-Port-Type is optional, so if you don't provision
service on a NAS port leave the attribute out.

RFC2865 says: An Access-Request SHOULD contain a NAS-Port or NAS-Port-Type
attribute or both unless the type of access being requested does
not involve a port or the NAS does not distinguish among its
ports.

Sounds clear to me :-)

I understand the need for signalling for what kind of service the user
is being authenticated. I have same at home where our RADIUS server does
IMAP, SMTP, 802.11, Jabber, Dialup, etc... logins. These are different
services; so it would sound natural to use Service-Type for it:

RFC2865 says: This Attribute indicates the type of service the user has
requested, or the type of service to be provided.

Which is, BTW, extremely similar to how I solved the problem for me. I
defined a VSA "RESTENA-Service-Type" (string) and put things like "IMAP"
into it. That makes server-side per-service processing easy.

Of course, WiMAX could get a "real" Service-Type value instead and
wouldn't need to hide behind a VSA :-)

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

---

From: Avi Lior <[email-masked]>
Date: Wed, 8 Jun 2011 12:12:05 -0400

You cant use Service-Type because service type is also indicating
authorize only or authenticate only and call-check etc. and thus you cant
express the Type of Service as well.  I pointed this out oh it seem like
30 years ago when we were doing Chiba work.

-- Avi Lior
--Bridgewater Systems

On 08-06-11 08:48 , "Stefan Winter" <[email-masked]> wrote:

>> which the ³access² service is provided. But with the new use of
>> Home Agent node implementing RADIUS client for AAAing the MN¹s
>> types. Here, our thinking is, the ³logical² port is the ³Mobile IP
>> Home Agent², and that has nothing to do with the L1/L2 port.
>>
>> What do people think?
>>
>>
>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Stefan Winter <[email-masked]>
Date: Thu, 09 Jun 2011 11:03:50 +0200

Hi,

>> into it.
> What else was in the request message?  Was there an instance of
> Service-Type, and if so what was it's value?

The requests were generated by a pam_radius_auth module, which sends
Service-Type = Authenticate-Only.

That module doesn't even send VSA's, so I had to trick like "if the
sending client was IP adress x.y.z.a, add RESTENA-Service-Type = IMAP
prior to further processing". And there I was lucky that this IP address
has only *one* process that uses RADIUS. Well, standard ugly hacks.

> I see the argument for using Service-Type for this application.  OTOH,
> there are two minor issues with that path: (a) allocation requires
> IETF Consensus, and (b) it tends to clutter up what's currently a
> concise list of options.

That's true (and that's why I just took a VSA and went my merry way). Of
course, having an IETF-allocated string attribute of sorts
"Extended-Service-Type-Info" that people could fill with whatever is
needed inside their AAA infrastructure would be not so bad. Better than
cluttering Service-Type with hundreds(?) of possible RADIUS-speaking
applications IMHO; where the list would be necessarily incomplete.

Greetings,

Stefan Winter

> Regards,
> Dave
> David B. Nelson
> Sr. Software Architect
> Elbrys Networks, Inc.
> www.elbrys.com
> +1.603.570.2636

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Thu, 09 Jun 2011 11:08:09 +0200

Hi,

> 30 years ago when we were doing Chiba work.

Well... would an IETF attribute like the "Extended-Service-Type-Info" as
I mentioned earlier help you? I.e. your requests could be tagged:

Service-Type = Authorize-Only
Extended-Service-Type-Info = "WiMAX IP Mobility"

or so?

Stefan

Tel: +352 424409 1
Fax: +352 422473

---

From: Avi Lior <[email-masked]>
Date: Thu, 9 Jun 2011 09:40:26 -0400

If we would invent a new attribute then I would vote for Application-Id.

This is more inline with Diameter etc....

If we have support for that I would be more than happy to write it up.

-- Avi Lior
--Bridgewater Systems