Subject: [radext] Reporting the Authorization Result back to the RADIUS

From: Sunil Gandhewar <[email-masked]>
Date: Mon, 18 Jan 2016 02:54:55 +0000

Hi All,
When a subscriber logs in after getting authenticated, it sends list of services at login time via Access-Accept. Due to some reason, if one of the services is failed to be applied, NAS cannot apply any of these services and RADIUS has no way to know the Result of the authorization. This Result is needed in many cases especially for extending RADIUS services outside.

Currently one either relies on Accounting START message. It gets complicated when either Accounting server is at remote location or when accounting is not enabled.

Some send services to be provisioned via CoA instead of at login time through Access-Accept. That way it knows the Result via CoA-ACK/NAK.

The problem becomes more prominent with RFC 7499 where RADIUS packet needs to be fragments and as per RFC 7499 it asks to piggyback on pull mechanism via login time.

I am wondering if it makes sense to write a new draft in RADEXT for adding new attribute to report result of the authorization. RADIUS can include this attribute in Access-Accept which indicate NAS that it needs to send the result to the RADIUS. On applying services result can be sent to the RADIUS by Access-Request and then RADIUS can respond back with Access-Accept once it receives the result. So these 2 additional packets if RADIUS needs such a result.

If you think it makes sense to write draft, me being relatively new in IETF, would you be interesting in co-authoring with me? Otherwise can you point me to someoneone experienced who would co-author and help me to proceed?

Regards,
Sunil Gandhewar
Juniper Networks, Inc.
[email-masked]<mailto:[email-masked]>

---

From: Alan DeKok <[email-masked]>
Date: Mon, 18 Jan 2016 21:03:16 -0500

On Jan 17, 2016, at 9:54 PM, Sunil Gandhewar <[email-masked]> wrote:
> 
> Hi All,
> When a subscriber logs in after getting authenticated, it sends list of services at login time via Access-Accept.

  Such as?  There's only one Service-Type allowed.  Maybe you mean something like "set of authorization attributes".

> Due to some reason, if one of the services is failed to be applied, NAS cannot apply any of these services and RADIUS has no way to know the Result of the authorization. This Result is needed in many cases especially for extending RADIUS services outside.

  RFC 2865 Section 5.6 say:

      ... A NAS is not
      required to implement all of these service types, and MUST treat
      unknown or unsupported Service-Types as though an Access-Reject
      had been received instead.

  It doesn't have similar text for (e.g.) Framed-IP-Address, or for most of the other authorization attributes.

> Currently one either relies on Accounting START message. It gets complicated when either Accounting server is at remote location or when accounting is not enabled.

  Yes.  If accounting isn't enabled, you have no idea whether or not the session started.  There is no way around that problem.

  If accounting is enabled, the authorization attributes *might* be echoed back in the Accounting-Request packet.  But there's no requirement for the NAS to do so.

> Some send services to be provisioned via CoA instead of at login time through Access-Accept. That way it knows the Result via CoA-ACK/NAK.

  You mean "authorization" again here, not "services".  Please use vocabulary which is consistent with the RADIUS RFCs.

> The problem becomes more prominent with RFC 7499 where RADIUS packet needs to be fragments and as per RFC 7499 it asks to piggyback on pull mechanism via login time.

  I'm not sure how it's more complicated.  The only issue I see is that the fragmented data can't be sent in an Accounting-Request.

> I am wondering if it makes sense to write a new draft in RADEXT for adding new attribute to report result of the authorization. RADIUS can include this attribute in Access-Accept which indicate NAS that it needs to send the result to the RADIUS.

  The only extensible way to ACK authorization attributes is to send them verbatim from a NAS to a server.  That would require some new packet code, or packet exchanges.

> On applying services result can be sent to the RADIUS by Access-Request and then RADIUS can respond back with Access-Accept once it receives the result. So these 2 additional packets if RADIUS needs such a result.

  It might work.  But there are attributes which can go into Access-Accept, but aren't supposed to be in Access-Request.  So any simple echoing process is not going to work.

  I would suggest instead just echoing back the authorization attributes in the Accounting-Request packet.  Most NASes already do this, so it would involve minimal changes to existing specifications and practices.  It would be worth discussing why a NAS should (or should not) do this, and what should go into the Accounting-Request, and why.

  The larger question, of course, is *why* is this change necessary?  What problem does it solve?  Please describe it.

  Alan DeKok.

---

From: Sunil Gandhewar <[email-masked]>
Date: Tue, 19 Jan 2016 12:41:30 +0000

Thanks Alan for responding. Please see my answers inline with [SMG]

Regards,
Sunil M Gandhewar
Juniper Networks, Inc.
[email-masked]

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Tuesday, January 19, 2016 7:33 AM
To: Sunil Gandhewar <[email-masked]>
Cc: [email-masked]
Subject: Re: [radext] Reporting the Authorization Result back to the RADIUS

  Such as?  There's only one Service-Type allowed.  Maybe you mean something like "set of authorization attributes".
[SMG] Yes, that's right. These include filter-names, policies with parameters in case of dynamic subscribers.

      ... A NAS is not

  It doesn't have similar text for (e.g.) Framed-IP-Address, or for most of the other authorization attributes.
[SMG] Again what I meant here is authorization data e.g. could not apply a policy or filter for some reason e.g. it was not pre-configured so does not exist. Or even for that mater there is no way to indicate whether the session started or not.

  You mean "authorization" again here, not "services".  Please use vocabulary which is consistent with the RADIUS RFCs.
[SMG] Yes, sorry about that.

  I'm not sure how it's more complicated.  The only issue I see is that the fragmented data can't be sent in an Accounting-Request.
[SMG] Complicated because now the large amount of authorization data cannot be sent in CoA-Request, it has to be sent in Access-Request, but there is no way to report back the status of that.

  The only extensible way to ACK authorization attributes is to send them verbatim from a NAS to a server.  That would require some new packet code, or packet exchanges.
[SMG] New packets will work. Instead of new packet types how about, if RADIUS can add a new attribute e.g. Result with value as Result-Required. Then NAS can send addition Access-Request with Result and Radius can respond Access-Accept with Result as Result-Received. Something of this sort, this will be executed only if RADIUS requires the Result of authorization or to know if the session started.

  The larger question, of course, is *why* is this change necessary?  What problem does it solve?  Please describe it.[SMG] 

[SMG] This is needed for the cases where RADIUS need to know if session start or failed and it's reason. That could be for multiple purposes e.g. to take corrective action, fix the error or it could be for extending session service outside the radius to service-gateway. These service gateways may want to provide additional subscriber services based on the authorization data.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Jan 2016 09:06:53 -0500

On Jan 19, 2016, at 7:41 AM, Sunil Gandhewar <[email-masked]> wrote:
> [SMG] This is needed for the cases where RADIUS need to know if session start or failed and it's reason.

  That's a much simpler problem statement.  Right now, a server can send an Access-Accept, and have no way of knowing whether or not the session started.

  Some NASes will send an Accounting-Request packet with a session time of zero.  But there's no standardization here.  I agree that would be useful.

  Being able to signal *why* the session was failed by the NAS  is a separate item.  As we're talking about RADIUS... the simplest possible approach would be best.

  Alan DeKok.

---

From: Sunil Gandhewar <[email-masked]>
Date: Tue, 19 Jan 2016 16:22:54 +0000

Hi Alan,
I am glad that you agree to have a standardization of the solution.

With NAS sending the status time of zero, these 2 packet exchanges will always be there. It won't be based on only if RADIUS needs it. Also there will not be a way for additional information for reason or what failed.

Regards,
Sunil M Gandhewar
Juniper Networks, Inc.
[email-masked]

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Tuesday, January 19, 2016 7:37 PM
To: Sunil Gandhewar <[email-masked]>
Cc: [email-masked]
Subject: Re: [radext] Reporting the Authorization Result back to the RADIUS

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Jan 2016 14:08:24 -0500

> With NAS sending the status time of zero, these 2 packet exchanges will always be there. It won't be based on only if RADIUS needs it. Also there will not be a way for additional information for re…

  All these issues need to be discussed before anything is standardized.

  The two important procedural items are:

- is it needed by many people?

- are people willing to work on it?

  Alan DeKok.

---

From: Sunil Gandhewar <[email-masked]>
Date: Wed, 20 Jan 2016 00:41:48 +0000

That's right we shall discuss the issues before any standardization.

Regards,
Sunil M Gandhewar
Juniper Networks, Inc.
[email-masked]

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Wednesday, January 20, 2016 12:38 AM
To: Sunil Gandhewar <[email-masked]>
Cc: [email-masked]
Subject: Re: [radext] Reporting the Authorization Result back to the RADIUS

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 20 Jan 2016 11:09:48 -0500

You need to convince people here that it's important.  How you do that is up to you.