Subject: RE: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 3.0

From: "Martin Julien (ECE)" <[email-masked]>
Date: Thu, 25 Jan 2001 12:02:30 +0100

Hi again,

Sorry, I could not be part of yesterday´s discussion, but I'm very happy with the outcome. See enclosed comments.

Martin

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Tuesday, January 23, 2001 6:55 PM
> 
> > 
> > I also have a comment on the idea of including an 
> Extension-ID AVP in STRs
> > and STIs.  I can understand the desire to be able to 
> terminate subsessions
> > of a complex session, but DIAMETER doesn't really support 
> subsessions.  I
> > can also understand the need to free some resources within 
> a session without
> > terminating the entire session.  But to do that, you need 
> real resource
> > management, and DIAMETER doesn't do that either.  I don't 
> think trying to do
> > pseudo-resouce management through the use of the 
> Extension-ID AVP is a
> > particularly good idea.  The Extension-ID does not really indicate
> > resources, nor does it precisely indicate applications 
> either.  Instead it
> > simply indicates which subsets of DIAMETER are being used 
> in the protocol
> > exchange.  So what would it mean if a server receives an 
> STR (or STI)
> > specifying some Session-ID and the NASREQ Extension-ID, but not the
> > Strong-Crypto Extension-ID which was also used in 
> establishing the session? 
> > Or if a server receives an STR specifying the Accounting 
> Extension-ID but
> > not the NASREQ Extension-ID (although maybe we've decided to include
> > accounting in the service extensions)?
> 
> Good argument against extension ID in STRs.
> 
> > 
> > Anyway, I think if we want to do resource management, then 
> we should figure
> > out how to do resource management and not try to slap 
> together a quick fix
> > that uses the wrong data element for the wrong purpose.  
> 
> ok, that works for me as well, since it is the easiest (both 
> in terms of
> documentation as well as implementation).
> 
> PatC
> 
> 

I think you brought a very interesting point and I totally agree with you. IMHO, we should probably think of a well-defined way of doing resource mgmt before we go further on this discussion. So we should use the STR/STA and STI messages to simply release the user session, which automatically means all resources owned by the session, right? That's simple enough for now. I will try to see what we should/could do for resource mgmt in another thread of this ML.

Martin

---

From: "Martin Julien (ECE)" <[email-masked]>
Date: Thu, 25 Jan 2001 15:35:03 +0100

Pat,

I like David's solution, since it seems to handle the case where the Session-Timeout is reached in the AAAH server, as well as the one where a particular policy in the AAAH server triggers a user session termination in the DIAMETER client and server. So, if I understand correctly, it seems that the sending of a STI by the AAAH server to a DIAMETER client (access device) could mean for the client that it could send any other types of DIAMETER message it wants to re-authorize the session or example, not only a STR, right? For example, if a policy in the AAAH triggers a STI, then the DIAMETER client could possibly send a STR to terminate officially the user session or send a re-authorization message to re-authorize the session until the next Session-Timeout. That would mean that the AAAH should expect something back after sending an STI, and should have a local timeout to handle a response from the DIAMETER client to terminate the user session or re-authorize it, for example. I!
 believe it is important for an AAA server to enforce policies, which, IMHO, is one of its major role, right? However, in the case where the DIAMETER client would not answer a STI, it is not clear to me yet what the AAAH should do exactly, especially with regards to accouting.

I think this idea is getting closer to the one I had when we discussed very briefly about the Session-Timeout AVP and the Authorization-Lifetime AVP. As discussed above, we could be using the Session-Timeout AVP for Re-Authentication/Re-Authorization instead of using a new Authorization-Lifetime AVP. However, maybe a small difference would be that the Authorization-Lifetime AVP would be used to trigger a Re-Authentication/Re-Authorization message from the DIAMETER client automatically as an optimization of the NASREQ extension, and the Session-Timeout AVP as a generic request to a DIAMETER client for information about what it wants to do now about the user session: terminate, re-authorize, or whatever would calm down the policies on the AAAH server.

BR,
Martin

> Sent: Tuesday, January 23, 2001 8:06 PM
> To: David Spence
> Cc: Barney Wolff; Pat Calhoun; Martin Julien (ECE); [email-masked]
> Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments
> Sec tion 3.0
> 
> 
> Good, so NAS MUST sent STR, home server MAY sent STI. race 
> conditions are
> handled by the NAS.
> 
> I'll have text written up later today to represent the 
> session state machine.
> 
> PatC
> > I'm o.k. with making it a MUST for the NAS and a MAY for 
> the home server. 
> > If the protocol is specified as I've proposed, it should 
> work either way.
> > 
> > Barney Wolff wrote:
> > > 
> > > I do not think the home server has to run a fine-grained timer,
> > > or any timer at all if it is not doing resource management.
> > > It can do fine-grained timing, if it's anal, but we MUST NOT :)
> > > make it a MUST.
> > > 
> > > Barney
> > > 
> > > On Tue, Jan 23, 2001 at 01:48:43PM -0500, David Spence wrote:
> > > > Actually, both the NAS and the home server have to run 
> a timer.  The home
> > > > server has to because he's the one who cares and he 
> wants to enforce his
> > > > policy.  The NAS has to because it is possible that the 
> home server will be
> > > > (temporarily) unreachable from the NAS at the time the 
> timeout is to occur.
> > > > The NAS has an interest in running the timer because if the home
> > > > organization will refuse to pay for a longer session 
> than the timeout
> > > > specifies, then the NAS wants to make sure it doesn't 
> provide a longer
> > > > session.
> > > >
> > > > This means that both parties will timeout approximately 
> simultaneously so a
> > > > termination collision is likely.  No problem.  The home 
> server is expecting
> > > > an STR in response to its STI, so if it receives the 
> STR generated by the
> > > > NAS' timeout, its happy.  The rule for the NAS is: 
> ignore an STI received in
> > > > STR-sent state.  So the NAS avoids sending a second 
> STR.  The home server
> > > > will send STA in response to STR and everyone is happy.
> > > >
> > > > Barney Wolff wrote:
> > > > >
> > > > > I'd say the NAS does it, as it should have the primary timing
> > > > > responsibility.  The server's timing is to avoid 
> getting stuck in
> > > > > a state, and can be quite coarse, or nonexistent if the server
> > > > > does not track session state.
> > > > >
> > > > > If the server had the primary
> > > > > timing responsibility, we wouldn't need the 
> session-timout avp at
> > > > > all, as it could just decide to terminate the session 
> when it wants
> > > > > to.  But I think that's a poor use of server cycles.
> > > > >
> > > > > Barney
> > > > >
> > > > > On Tue, Jan 23, 2001 at 08:39:50AM -0800, Pat Calhoun wrote:
> > > > > > Cool, I think we are nearly there. One more 
> question. Who initiates the STR?
> > > > > > Should it be the NAS, or the home server. We need 
> to provide some guidelines
> > > > > > to reduce the changes of such messages crossing 
> through the network.
> > > > > >
> > > > > > PatC
> > > > > >
> > > > > >
> > > >
> > > > --
> > > > David Spence                            email: 
> [email-masked]
> > > > Interlink Networks, Inc.                phone: (734) 821-1203
> > > > 775 Technology Drive, Suite 200         fax:   (734) 821-1235
> > > > Ann Arbor, MI 48108
> > > > U.S.A.
> > 
> > -- 
> > David Spence                            email: 
> [email-masked]
> > Interlink Networks, Inc.                phone: (734) 821-1203
> > 775 Technology Drive, Suite 200         fax:   (734) 821-1235
> > Ann Arbor, MI 48108           
> > U.S.A.
> 
>