Subject: Is provisioning services in Accounting-Request packets bad?

From: Alan DeKok <[email-masked]>
Date: Tue, 15 Jun 2010 17:58:53 +0200

When a RADIUS server returns Access-Accept, some systems also request
that it send an Accounting-Request packet to a provisioning system.
This provisioning system requires information such as Framed-IP-Address,
or copies of some VSAs from the Access-Accept.

  Quote "This is not unusual, and several vendors are providing such a
solution".

  RFC 2866 doesn't forbid this, as it expects accounting packets to be
sent by the NAS.  The guidelines document contains minimal text about
accounting.

  Is it worth adding a line in the "guidelines" document saying that
accounting packets are to be used for... accounting?  And that
provisioning services via Accounting-Request is bad?

  Alan DeKok.

--
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: "David B. Nelson" <[email-masked]>
Date: Tue, 15 Jun 2010 12:13:28 -0400

> or copies of some VSAs from the Access-Accept.

What does the provisioning system do with the information and how does it relate the result back to the NAS?

What entity sends the Accounting-Request, the NAS or he RADIUS server.  You use "it" and I'm unclear what "it" refers to.

> provisioning services via Accounting-Request is bad?

Well, I personally think that provisioning services via an Accounting-Request is bad, but I don't yet see how the NAS is actually being provisioned by a request message.  What is fairly common practice is to build resource management systems around RADIUS Accounting.  Is that the sort of thing you're talking about?

Regards,

Dave

David B. Nelson

Elbrys Networks, Inc.
282 Corporate Drive, Unit 1
Portsmouth, NH 03801

+1.603.570.2636
www.elbrysnetworks.com
[email-masked]

---

From: Avi Lior <[email-masked]>
Date: Tue, 15 Jun 2010 13:58:32 -0400

On one hand we may need more information as David is mentioning.

But there is nothing wrong with a Back office system using information contained in an accounting message.

A back office system can be used for billing but it can also be used to do other things like generate triggers for Intrussion Detection/Prevention systems, Firewalls etc etc....

And thus some of the information could be used for provisioning of some service by a back office system.

We should not be concerned about this.  It has nothing to do with the over the wire protocol.  As long as the information is valid to be sent in the Accounting Messages we should be fine.

> 282 Corporate Drive, Unit 1

Avi Lior
[email-masked]
office: +1 613-591-9104x6417
    cell: +1 613-796-4183

---

From: Alan DeKok <[email-masked]>
Date: Tue, 15 Jun 2010 20:06:16 +0200

> What does the provisioning system do with the information and how does it relate the result back to the NAS?

  It creates FW rules for the user.  It does *not* relay the result back
to the NAS.

> What entity sends the Accounting-Request, the NAS or he RADIUS server.  You use "it" and I'm unclear what "it" refers to.

  The NAS sends an Access-Request to the RADIUS server.  The RADIUS
server originates the Accounting-Request.

  The *intent* appears to be that waiting the extra 1/10s for the NAS to
originate the Accounting-Request would be a catastrophic delay.  The
"network setup" side of the user session needs to be done before the
Access-Accept is received by the NAS.

  The "simplest" way to do this is to overload RADIUS.

> Well, I personally think that provisioning services via an Accounting-Request is bad, but I don't yet see how the NAS is actually being provisioned by a request message.  What is fairly common prac…

  I can understand making decisions (e.g. Disconnect-Request) on
reception of an Accounting-Request packet.  i.e. "user is over 2G, kick
them off of the net".

  The above discussion isn't that.  It's the RADIUS server *fabricating*
an Accounting-Request packet for a user session, because it's faster to
do it that way than to wait for the NAS.

  Alan DeKok.

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 15 Jun 2010 14:37:53 -0400

> It creates FW rules for the user.  It does *not* relay the result back

OK, I think I get it.

> The NAS sends an Access-Request to the RADIUS server.
> The RADIUS server originates the Accounting-Request.

To a RADIUS Accounting Server?

Let's see if I've got this....

The NAS (Node A) sends an Access-Request to the RADIUs Server (Node B) which then sends an Accounting-Request to the RADIUS Accounting Server (Node C), and subsequently the RADIUS Server (Node B) sends an Access-Accept to the NAS (Node A)?  The RADIUS Accounting Server (Node C) by some means creates access rules for the user and sends them to the Firewall (Node D)?

Yikes.

> The "simplest" way to do this is to overload RADIUS.

Well, RADIUS has a history of being an eminently overload-able protocol.  :-)

I think it's unusual, to say the least, for a RADIUS Server to initiate a request on behalf of a NAS unless that RADIUS Server is acting in the role of RADIUS Proxy Server.  That doesn't seem to be the case here.

Regards,

Dave

David B. Nelson

Elbrys Networks, Inc.

+1.603.570.2636
www.elbrysnetworks.com

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 15 Jun 2010 11:40:18 -0700

Alan DeKok said:

"  The NAS sends an Access-Request to the RADIUS server.  The RADIUS
server originates the Accounting-Request."

So this requires the NAS to act as an Accounting Server?  

What if doesn't respond?  Does the RADIUS server keep retransmitting the
Accounting-Request??

---

From: Alan DeKok <[email-masked]>
Date: Tue, 15 Jun 2010 21:04:51 +0200

> To a RADIUS Accounting Server?

  Nope.  To a provisioning system.  e.g. firewall.  It opens FW rules
for the IP, send an ACK, and otherwise discards the accounting data.

  The normal accounting stream still exists, and uses a completely
different path through the network.

> The NAS (Node A) sends an Access-Request to the RADIUs Server (Node B) which then sends an Accounting-Request to the RADIUS Accounting Server (Node C), and subsequently the RADIUS Server (Node B) s…

  Something like that.

> I think it's unusual, to say the least, for a RADIUS Server to initiate a request on behalf of a NAS unless that RADIUS Server is acting in the role of RADIUS Proxy Server.  That doesn't seem to be…

  Yup.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 15 Jun 2010 21:30:43 +0200

> But there is nothing wrong with a Back office system using information contained in an accounting message.

  Absolutely.

> We should not be concerned about this.  It has nothing to do with the over the wire protocol.  As long as the information is valid to be sent in the Accounting Messages we should be fine.

  My main issue is that accounting packets should be generated by the
system managing the user session. i.e. the NAS.  Anything else in the
network (e.g. RADIUS proxy) has no business "inventing" accounting
packets for a session.

  That strikes me as an odd way of creating a vendor-specific
provisioning API.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 15 Jun 2010 21:35:19 +0200

> So this requires the NAS to act as an Accounting Server?  

  Nope.  A third machine receives the Accounting-Request.

> What if doesn't respond?  Does the RADIUS server keep retransmitting the

  Nope.  The time frames are 'too short' for retransmits to be relevant.

  Alan DeKok.

---

From: Avi Lior <[email-masked]>
Date: Tue, 15 Jun 2010 18:37:01 -0400

Okay.  I think I understand....

The RADIUS server sends an access-accept to the NAS and at the same time more or less, it sends an Accounting Request message to the Back Office to provisiong something (a firewall).

Weird.  This is instead of the NAS generating an accounting request message.

But given that what is wrong with this?

For one, the session may not have started on the NAS so you have provisioned something that may have not happened.  In the case of the FW, this could be bad - you opened a hole for something that isnt really there etc.

But is this still problematic in general.

The general case is:

1) Does the specification require that an Accounting message be generate by a NAS only.  Or can it be generated by a proxy or server?

2) Does the specification allow a Proxy to add attributes to accounting.  

The answer to 2 is yes.

I am not sure what the answer to one should be.  I would think no. But there could be corner cases where the real NAS cant generate accounting and the next hop AAA proxy can.  Certainly in some deployments the NAS is not really a single entity.  So  making a rule could break these corner cases.

But what is the real problem here? Other than potential problems for particular use cases.  I think we should remain silent.

Avi Lior

---

From: Alan DeKok <[email-masked]>
Date: Wed, 16 Jun 2010 08:27:20 +0200

> Weird.  This is instead of the NAS generating an accounting request message.

  Yes. and yes.

> For one, the session may not have started on the NAS so you have provisioned something that may have not happened.  In the case of the FW, this could be bad - you opened a hole for something that i…

  Sure.  But RADIUS isn't really a generic provisioning API.

> 1) Does the specification require that an Accounting message be generate by a NAS only.  Or can it be generated by a proxy or server?

  The "naive" expectation is that accounting messages are tied to
sessions, and generated by the same system that originated the
Access-Request.

> I am not sure what the answer to one should be.  I would think no. But there could be corner cases where the real NAS cant generate accounting and the next hop AAA proxy can.  Certainly in some dep…

  Sure.  If the same "administrative system" creates Access-Requests &&
Accounting-Requests, it doesn't matter which box creates what, so long
as they all communicate.  But that's very different from having the
system sending an Access-Accept create an Accounting-Request packet.

> But what is the real problem here? Other than potential problems for particular use cases.  I think we should remain silent.

  It complicates network design.  It potentially allows for unlimited
growth in the number of RADIUS packets based on a login.  If the
Access-Request is proxied multiple times. and each proxy "invents"
another RADIUS packet... bad things can happen.

  Alan DeKok.

---

From: Avi Lior <[email-masked]>
Date: Wed, 16 Jun 2010 08:36:42 -0400

See inline..

BTW I am not defending the specific use case  - and I am not critizing it either.  I don't have enough information.

I am concerned though that we may put in place rules/guidelines that would hinder good network design.

>   Sure.  But RADIUS isn't really a generic provisioning API.
[AL>] You are right RADIUS isn't a provisioning API or a provisioning system.  But the information obtained from RADIUS is being used to provision something.  Just like RADIUS is not a billing API nor a Billing system but rather the information provided by RADIUS is useful in generating a bill for the subscriber.  
The information being generated by RADIUS is used for many purposes.

In this particular case I think your issue is with using accounting messages to provision a firewall.  I think it is that the accounting message is generated along the proxy chain (okay the extreme end of the proxy chain but nevertheless the proxy chain). Right?

> sessions, and generated by the same system that originated the
[AL>] The accounting message is still being tied to a session in this case.  And it is the same system.  The system appears to be distributed.  The real problem is that it is generated by the "same system that originated the Access-Request" Right?

> 
> > I am not sure what the answer to one should be.  I would think no.
> But there could be corner cases where the real NAS cant generate
> accounting and the next hop AAA proxy can.  Certainly in some
> deployments the NAS is not really a single entity.  So  making a rule
> could break these corner cases.
> 

In the specific use case, the logical entities are all communicating.  I am not sure what you mean by "Administrative System".  Who is to say that the NAS and Server or not in the same adimistrative domain.  I don't know much details about the use case.  I don't know what the Admisitrative Domain has to do with this?

> 
> > But what is the real problem here? Other than potential problems for
> particular use cases.  I think we should remain silent.
> 

Sure.  But who is to say that following a similar approach wouldn't simplify the network design.  We don't know enough details but perhaps in this case this was the best most economical approach to the problem.  It seems weird sitting at the IETF level.  

I am not sure what general guidance you would propose here that would help and not hinder.

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 16 Jun 2010 09:54:29 -0400

> I am not sure what general guidance you would propose here that would help and not hinder.

I'm not sure where such guidance would be delivered.  This is not a matter of RADIUS Attribute design, and it's out scope for the Design Guidelines.  It seems to me this is (or is not) a deviation from the RADIUS operational model, depending on your interpretation.

It may well be a reasonable solution in a given set or circumstances.  It certainly does not follow the "conservative" or "narrow" interpretation of the RADIUS operational model (command level data flow).  This is fine as a proprietary vendor extension to RADIUS.  My only concern would be if this kind of adaptation were to become popular, and customers created a demand to replicate this solution in other use / deployment cases, where it may not be appropriate.  I would not like to see this sort of solution evolve to become a de facto or de jure extension to the RADIUS standard.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 16 Jun 2010 16:53:59 +0200

> In this particular case I think your issue is with using accounting messages to provision a firewall.  I think it is that the accounting message is generated along the proxy chain (okay the extreme…

  Yes.

> [AL>] The accounting message is still being tied to a session in this case.  And it is the same system.  The system appears to be distributed.  The real problem is that it is generated by the "same…

  Yes.

> In the specific use case, the logical entities are all communicating.  I am not sure what you mean by "Administrative System".  Who is to say that the NAS and Server or not in the same adimistrativ…

  What I mean is that the "NAS" functionality may be split across more
than 1 machine.  If so, they are all managed by the same people.

> I am not sure what general guidance you would propose here that would help and not hinder.

  RADIUS isn't a generic provisioning system?

  I could use accounting packets to provision new users, rather than
using direct DB writes.  If the administration system doesn't have write
access to the database, it could use RADIUS to send the new user
credentials to the RADIUS server, which would write them to the DB.

  It's possible, but weird, and likely not recommended.

  Alan DeKok.