Subject: Re: Last Call On NAS Package (Revisited for November)

From: Julian Mitchell <[email-masked]>
Date: Thu, 2 Nov 2000 14:32:06 -0000

Hi,

I think that we should keep the AUTHRES (or AUTHEX) event simple so that it
indicates just service denied, callback service authorized and outgoing
service authorized.

If the service is denied, then we would expect a NASREL event to be
triggered. I would therefore suggest adding this list of reasons to the list
of possible reason values for the NASREL event, and maybe noting this
behaviour in the procedures for the NAS INCOMING PACKAGE. This has the
advantage of keeping all the NAS release reasons in one event.

Thanks

Julian

> -----Original Message-----
> From: Whitton, Alan  [SMTP:[email-masked]]
> Sent: Wednesday, November 01, 2000 4:08 PM
> To:   [email-masked]
> Subject:      Last Call On NAS Package (Revisited for November)
>
> Folks,
>
> OK, so after looking things over the AUTHRES (or AUTHEX) event looks like
> it needs a little more information returned in it other than success or
> failure.
>
> Once a  "call" is UP, the Modems have trained and now the End User's PC is
> connected to the ISP's Radius Server more than simply "authorization
> failure" can occur. Port limiting can occur (not enough virtual modems
> available to that customer's domain), or there can be a RADIUS server
> failure (and thus the user cannot log in).
>
> What I'd like to propose is either adding a reason code for the AUTHRES
> (or
> AUTHEX), or expand the reason codes for AUTHRES (or AUTHEX). The following
> reasons, come to mind:
>   1 other, unspecified
>   2 CLID was unacceptable (rejected by CLID filter)
>   3 CLID was blocked (rejected because blocked CLIDs not allowed)
>   4 dialed number is not acceptable
>   5 port limit or overflow port limit reached
>   6  no IP address available
>   7 all home gateways at capacity or admin state locked
>   8 port guarantee prevented call from being taken proxied to
>   9     RADIUS server rejected the request
>
>
> Cheers,
> Alan Whitton
>
> Holistic Metaservices Architect
> CVX SS7 Gateway
> Nortel Networks,

---

From: "Whitton, Alan" <[email-masked]>
Date: Fri, 3 Nov 2000 08:41:33 -0500

Agreed,

Cheers,
Alan

> From:         Mitchell, Julian [MDN05:CV04:EXCH]
> Sent: Thursday, November 02, 2000 9:32 AM
> Cc:   Whitton, Alan [CAR:5Z00:EXCH]
> Subject:      RE: Last Call On NAS Package (Revisited for November)
>
> Hi,
>
> I think that we should keep the AUTHRES (or AUTHEX) event simple so that
> it indicates just service denied, callback service authorized and outgoing
> service authorized.
>
> triggered. I would therefore suggest adding this list of reasons to the
> list of possible reason values for the NASREL event, and maybe noting this
>       What I'd like to propose is either adding a reason code for the
> AUTHRES (or

---

From: "Whitton, Alan" <[email-masked]>
Date: Sat, 4 Nov 2000 08:22:15 -0500

Ilya,

How does a Controller reflect a problem connecting to an ISP's Radius
server, if that Controller chooses not to implement Radius (prefers keeping
that functionality in the Gateway)?

There a few different models possible in H.248, where the Controller could
use this information (and reflect it in messages or tones to the End User).
If the Controller is unable to (or chooses not to) use Radius for this
information, how does it reflect this information back to the End User?

Cheers,
Alan

-----Original Message-----
From: Ilya Akramovich [mailto:[email-masked]]
Sent: November 3, 2000 6:26 PM
To: Whitton, Alan [CAR:5Z00:EXCH]
Cc: [email-masked]
Subject: Re: Last Call On NAS Package (Revisited for November)

Alan,

That is a nice list and I can come up with a dozen more reasons why a
session-level authorization may fail.

However, do we really want to dump all of this information to the MGC?
Does the latter really need to know specifically what kind of
authorization failed at the user level?  I don't think so. Besides,
information like this is already communicated in, for example, Radius
accounting and/or other logging facilities.

So I vote for keeping AUTHRES (or, better, AUTHEX) simple.

--
Ilya Akramovich                    Tel: (510) 747-2926
Sr. Software Engineer              mailto:[email-masked]
Lucent InterNetworking Systems     http://www.lucent.com/ins

(or

---

From: "Whitton, Alan" <[email-masked]>
Date: Sat, 4 Nov 2000 08:28:15 -0500

List,

Apologies, I also forgot that Julian and I had agreed that AUTHRES (or
AUTHEX) would stay "as is" (i.e. only reflecting whether the call failed or
not,  etc.,) and that the failure conditions I look for will be reflected in
the following NASREL event that is sent as part of the authorization
failure.

Apologies, I should remember not to answer things on Saturday mornings.

Cheers,
Alan

-----Original Message-----
From: Ilya Akramovich [mailto:[email-masked]]
Sent: November 3, 2000 6:26 PM
To: [email-masked]
Subject: Re: Last Call On NAS Package (Revisited for November)

Alan,

(or

---

From: Matt Holdrege <[email-masked]>
Date: Sat, 4 Nov 2000 11:11:46 -0800

RADIUS is the IETF Draft Standard for communicating that information.
Furthermore the AAA WG is working on a new standard for such info. So if a
service provider or vendor chooses to not use the IETF standard they can
always use a proprietary scheme. But we shouldn't create yet another
standard for doing the same thing. It's too confusing and as Ilya mentioned
you may end up missing out on the wealth of RADIUS experience already
generated.

At 08:22 AM 11/4/00 -0500, Whitton, Alan wrote:

>server, if that Controller chooses not to implement Radius (prefers
>keeping that functionality in the Gateway)?
>
>use this information (and reflect it in messages or tones to the End
>User). If the Controller is unable to (or chooses not to) use Radius for
>this information, how does it reflect this information back to the End User?
>
>Cheers,
>Alan
>
>From: Ilya Akramovich
>[<mailto:[email-masked]>mailto:[email-masked]]
>Sr. Software
>Engineer              <mailto:[email-masked]>mailto:[email-masked]
>Lucent InterNetworking
>Systems     <http://www.lucent.com/ins>http://www.lucent.com/ins
>
>Alan Whitton wrote:
> >
> > Folks,
> >