Subject: [AAA-WG]: Re: New NASREQ text on DynAuth

From: Bernard Aboba <[email-masked]>
Date: Fri, 16 Jan 2004 09:52:39 -0800 (PST)

On Fri, 16 Jan 2004, David Mitton wrote:

> >Since we wrote the "authorize only" stuff in for Diameter compatibility,
> >I'm OK with removing it.  However, I'm still not clear that Diameter Base
> >allows the single transaction model for Reauthorization.
>
> Okay, I think you're on to something.  I've re-read the Base.  RAR really
> doesn't say much, but RAA says:
> "A successful RAA message MUST be followed by an application-specific
>     authentication and/or authorization message."

Yes. My understanding was that the intent was initiate a Request/Response
sequence.

> However, I find DiamNasReq section 2.2 para 3 already says:
> If the Re-Auth-Request-Type is AUTHORIZE_ONLY, the
>     message will contain AVPs to modify the current service.

This seems like a fundamental change in the usage of RAR/RAA, compared to
what is defined in the Base protocol.

> Sooo... I think we (in the more expansive WG sense) have been here before.

As Casey Stengel said "I've made up my mind, but I made it up both ways."
NASREQ & Base seem to be in contradiction on the use of RAR/RAA.
Personally, my vote is with Base.

> Either we extend RAR/RAA explicitly to cover this (which seems to be what
> was done, perhaps weakly and obscurely), or we make the extra message
> exchange something that the Diameter/RADIUS gateway has to provide.

The original discussion on RFC 3576 assumed that an extra exchange was
required to accomodate Diameter RAR/RAA behavior.  Reading Base, that
assumption seems to have be justified.  So unless Base was in error,
RFC 3576 is correct in this instance, the Diameter/RADIUS gateway needs to
accomodate the extra exchange, and NASREQ needs to be compatible with
the operation of RAR/RAA defined in Base.

> summing up: I am in favor of killing the extra exchange on
> Disconnect-Request and declaring it a bug in RFC 3576.

This makes sense because ASR/ASA in Diameter is a single transaction, so I
think that NASREQ is correct here, and RFC 3576 is wrong.

> I'm in favor of this one step RAR message, but perhaps we should test that.
> The text in 2.2 should be beefed up a bit... which segues in to the next
> topic....

Unless the one-step RAR message is defined in Base, I don't think that
NASREQ can change the nature of the Base RAR/RAA exchange this way.

Also, RFC 3576 describes why a one-step RAR message is problematic.  The
issue is semantic ambiguity -- is a given AVP used for session identification or
authorization change?  The two-step exchange is cleaner in that respect.

> More ABNFs?
> Do we want to "describe" all NAS applications usage of Base messages with
> an ABNF?
> This would include: Re-Auth;RAR/RAA, Session-Termination;STR/STA,
> Session-Abort; ASR/ASA, Accounting;ACR/ACA  Adds up real quick.
>
> I don't think it's real hard to write, but it will add several pages of text.
>
> Final summary:
>          With my "Protocol Architect" hat on, I like the completeness and
> clarity this would add.

I agree.  Frankly, the confusion over usage of RAR/RAA and other commands
is likely to become a stumbling block if we don't fix this now.

> I'll work issue 431 until I'm ready to commit on this one.

Let's see what other members of the AAA WG have to say on this one.

---

From: <[email-masked]>
Date: Mon, 19 Jan 2004 12:22:44 +0200

> what is defined in the Base protocol.

Yes, I'm of the same opinion. The RAR/RAA in Base protocol is 
designed to initiate an application specific Request/Answer
sequence.

> Personally, my vote is with Base.

I'm in support of the base as well.

Br
Marco