Subject: RE: [AAA-WG]: A question in NASREQ section 2.1

From: David Mitton <[email-masked]>
Date: Fri, 03 Jan 2003 00:44:30 -0500

On 1/3/2003 11:32 AM +0800, [email-masked] wrote:
>Thanks Dave,
>
>I suppose you mentioned one choice for the NAS that it could terminate the 
>session if it failed to start a NASREQ session context. However I wonder 
>if the NAS will go to extreme to do so,

This is not extreme.  If a NAS cannot support a service it MUST terminate 
it, even if it's authenticated or authorized.  Believe me, NASes do it with 
RADIUS all the time.

>  as neither NASREQ or [BASE] have mentioned what actions shall ACCT 
> server/NAS take after an EVENT_RECORD request/answer message is received.

The drafts do not discuss every possible action.
There are no external actions for an accounting server to take.  It should 
record the event and any implication of that is implementation dependent.

The purpose of the event record is obvious.  ISPs want a record of every 
attempted session and the result.  Failed attempts can offer information 
about user mistakes, or hackers rattling the door knobs.  It's also 
extremely useful when debugging.  The Accounting records should show these.

Dave.

>And this is the reason I invite Aboba to explain possible further behavior 
>of NAS and ACCT server handling such a failure.
>
>Best regards,
>roger
>
>
>-----Original Message-----
>From: ext David Mitton [mailto:[email-masked]]
>Sent: 03. January 2003 10:47
>To: Liu Qing.Roger (Nokia-RD/Beijing); [email-masked]
>Cc: [email-masked]
>Subject: RE: [AAA-WG]: A question in NASREQ section 2.1
>
>
>I'm asking all these questions, so you may perhaps answer yourself.
>
>- If the relay "knows" to send accounting messages to the accounting server
>and not the authentication server, then this accounting message is no
>different.
>
>- If the authentication server did not authenticate or authorize this
>session, (eg: returned a failure) then it need not receive anything further.
>
>- If the NAS decided it could not support an authenticated or authorized
>session,(eg: a AAA with success) then it should also issue an
>Session-Termination-Request (STR) to the Authentication Server to abort the
>session information at that server. [Section 2.3]  As well as the
>Accounting EVENT_RECORD.
>
>Dave.
>
>At 1/3/2003 10:12 AM +0800, [email-masked] wrote:
> >Hi,
> >
> >As a service vendor may have a separated ACCT server, which have the same
> >diameter identity as the AUTH server. The relay will know the accounting
> >messages should be routed to ACCT server after capability negotiation with
> >the ACCT SERVER (the NASes do not need to know where is the servers, they
> >only need to set the destination host/realm AVPs properly).
> >
> >In this case, my question is that should the AUTH server be informed of
> >such a failure ? (Since this notification will be routed to ACCT server.)
> >If not, how to implement the following behavior of NAS, ACCT server?
> >
> >Thanks,
> >roger
> >
> >
> >
> >-----Original Message-----
> >From: ext David Mitton [mailto:[email-masked]]
> >Sent: 24. December 2002 22:24
> >To: Liu Qing.Roger (Nokia-RD/Beijing); [email-masked];
> >[email-masked]
> >Subject: Re: [AAA-WG]: A question in NASREQ section 2.1
> >
> >
> >At 12/24/2002 05:26 PM +0800, [email-masked] wrote:
> > >In NASREQ section 2.1,
> > >"The failure to start a session SHOULD cause an Accounting EVENT_RECORD
> > >message."
> > >
> > >But regards to the following scenario, where will the Accounting
> > >EVENT_RECORD message be addressed to?
> > >
> > >      +--------+        +-------+        +-------------+
> > >      |  NAS   |--------| Relay |--------| Auth Server |
> > >      +--------+        +---+---+        +-------------+
> > >                            |
> > >                            |
> > >                     +------+------+
> > >                     | Acct Server |
> > >                     +-------------+
> > >
> > >Best regards,
> > >roger
> >
> >Where would a successful Accounting message go?
> >What criteria is the Relay using to split the streams?
> >How would the source know that?
> >Who configured this?
> >
> >Dave.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 2 Jan 2003 21:51:58 -0800 (PST)

> it, even if it's authenticated or authorized.  Believe me, NASes do it with

That's preferrable to attempting to provide a different service than
what was requested -- which happens sometimes with RADIUS (I've seen
RADIUS implementations that ignored Filter-Id attributes they didn't
understand, instead of dropping the call).

> extremely useful when debugging.  The Accounting records should show these.

One of the most annoying things about RADIUS is that you don't
see Accounting records for failed calls -- just the information that you
want in the early phases of a deployment, particularly when interoperability
issues may still be shaking out -- as they are with 802.11
implementations, for example.

In the early phases of a rollout, I like to be able to access *all* of the
available information -- and to wring as much information out of the
failed call records as is available, until the failure rate is low enough
to consider the service operational.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 2 Jan 2003 22:05:34 -0800 (PST)

AAA WG last call has concluded on draft-ietf-aaa-diameter-nasreq-10.txt,
which is being considered for advancement as an IETF Proposed Standard.
The draft is available at:

http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-10.txt

Two issues were raised in last call (389, 395), and are available for
inspection at:

http://www.drizzle.com/~aboba/AAA/issues.html

As NASREQ is a dependency of 3GPP2, and we are already late, getting this
document ready for IESG review is an important goal for the month of
January 2003.

The goal is to start 2003 by getting NASREQ into the hands of
the IESG within a few weeks. Here's the game plan:

a. Address the AAA WG last call comments, as well as IESG NITs.

b. Post a strawman -11 document for review.

c. Incorporate any other last minute comments (if you haven't done your
review now, time is running out...)

d. Get a -11 draft out on the IETF archive and ready for IESG review by
January 17, 2003 (in time for the IETF/3GPP meeting).