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

From: "Martin Julien (ECE)" <[email-masked]>
Date: Mon, 22 Jan 2001 16:25:09 +0100

Pat,

Thanks for your answers. See my comments.

/Martin

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Friday, January 19, 2001 11:50 PM
> To: Martin Julien (ECE)
> Cc: [email-masked]'; [email-masked]'
> Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments
> Section 3.0
> > 
> > Section 3.0 - par.2
> > -------------------
> > It is weird to me that we refer to an 
> Authorization-Lifetime AVP in the Base
> > Protocol without having any authorization message in it. 
> Now we have the
> > Session-Timeout AVP and the Authorization-Lifetime AVP 
> which are somehow
> > competing together.
> 
> No, they aren't intended to compete. Dave Mitton was the one 
> that had come up
> with the Authorization-Lifetime AVP in the solutions I-D. The
> Authentication-Lifetime specifies how long before a re-auth 
> should occur. The
> Session-Time, on the other hand, states how long the session 
> can occur. After
> Session-Time, a session MUST be torn down. 
>
> > Should the Authorization-Lifetime AVP be included in a
> > specific extension, such as NASREQ, or is it because it 
> might be used by
> > several extensions without any specific meaning to the base 
> protocol itself,
> > which happens to be pretty much the same as the 
> Session-Timeout AVP? My
> > understanding is that there is not much to do with the
> > Authorization-Lifetime AVP in the base protocol, since the 
> action to take
> > upon its expiration is defined in the NASREQ extension 
> anyway, which is very
> > specific. 
> The reason why it is in the base protocol is to reduce 
> duplicate AVPs in
> extensions. I environ that all access methods will require 
> some session
> lifetime, so since it is used in many extensions, it seems 
> appropriate to put
> it in the base protocol.
>
> > I guess that something more generic would be a Session-Timeout AVP
> > which could trigger an STI when it expires that could lead 
> to another
> > re-authentication or something else in order to avoid the session to
> > terminate right away. Then the NASREQ extension!
> >  could possibly override that meaning by defining its own
> > Authorization-Lifetime AVP which would trigger a more efficient an
> > AA-Challenge-Ind instead.
> 
> Please read the above intended definitions of both AVPs and tell me if
> additional changes are still required. Perhaps the actual 
> definition of both
> AVPs need some work. Is this sufficient?

I think I understand the roles of the Authorization-Lifetime AVP and the Session-Timeout AVP. However, the Session-Timeout AVP is also used by the Mobile-IP extension protocol for the registration keys time-out, which seems to be quite similar to what is required by NAS for re-authentication/re-authorization. Should the Mobile-IP extension also refer to the Authorization-Lifetime AVP instead of the Session-Timeout AVP?

Should the Session-Timeout also trigger a STI? Should we be expecting the Proxies to release resources automatically when the Session-Timeout AVP has been reached? Otherwise, what really happens when the Session-Timeout AVP expires and a session must be torn down in a AAAH and the proxies?

> > 
> > Section 3.2 and 3.3
> > -------------------
> > Can the server return a bigger value?
> 
> bigger than what?

I was simply wondering if it was allowed for the AAAH to return a bigger value then the one that was sent as a hint from the DIAMETER client?

> > What the value 0 means? The same as if it was not there?
> > Which one has priority?
> 0 and not present are the same. They mean infinity (and I 
> fixed the text in
> Authorization-Lifetime)
> 
> > 
> > Section 3.5
> > -----------
> > "Since the Session-Id is typically tied to a particular 
> service (i.e. Mobile
> > IP, NASREQ, etc), the session termination messages are used 
> to request that
> > the service tied to the Session Id be terminated."
> > 
> > It seems to be against last paragraph of section 3.1, which 
> is "Note that a
> > Session-Id MAY be used by more than one extension (e.g. 
> authentication for a
> > specific service and accounting, both of which have 
> separate extensions).
> 
> hmmmm.... I believe that section 3.5 should state that the 
> Extension-Id is
> used to identify which service should be terminated. Does 
> this make more sense?

I guess you meant a Session-ID and an Extension-ID? Yes, that would be OK.

> > Section 3.5.2
> > -------------
> > What the Resource-Owner-NAI AVP used for in the STR? Is it 
> for routing? I
> > guess not, since the User-Name AVP is present. Can it be 
> used in the server
> > for any particular reason I don't see, since I think the 
> active session
> > should be aware of what's going on within itself, right?
> 
> If the home server wishes for the NAS to reliquish resources, then the
> User-name AVP doesn't really help since it would cause the 
> packet to get
> routed to the home server (loop). So something is needed for 
> the message to
> get routed to the NAS, and I envisioned was that the AVP 
> would be used for
> routing purposes (and eventually get to the NAS).

Then, are you telling me that the message routing can be done using other AVPs than the Routing-Realm AVP and the User-Name AVP? Also, is it really needed in the STR, which is sent from the access device to the Home AAA?

> > 
> > Section 3.5.3
> > -------------
> > What is the purpose of the STA, since the session in the 
> server and in the
> > proxies should be released after the STR? What can the NAS 
> or the server do
> > if the STR is rejected and the resources are already released in the
> > DIAMETER client and the proxies?
> 
> The STA acks the STR. The sender of the STR should wait until 
> the STA is
> received before releases resources.

The paragraph 3.5.2 says:

"Upon receipt of the STR, the Home DIAMETER Server SHOULD release all resources for the session indicated by the Session-Id AVP. Any intermediate server in the Proxy-Chain MAY also release any resources, if necessary."

That's the reason why I asked about the STA. Now you're telling me that it should be the STA that should trigger the release of resources, right?

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 22 Jan 2001 07:38:43 -0800 (PST)

> I think I understand the roles of the Authorization-Lifetime AVP and the
> Session-Timeout AVP. However, the Session-Timeout AVP is also used by the
> Mobile-IP extension protocol for the registration keys time-out, which seems
> to be quite similar to what is required by NAS for
> re-authentication/re-authorization. Should the Mobile-IP extension also
> refer to the Authorization-Lifetime AVP instead of the Session-Timeout AVP?

Correct, and perhaps re-using the Session-Timeout was overloading the AVP.
Either Authorization-Lifetime should be used for the keys, or some new AVP
that is more specific to the keys.

> 
> Should the Session-Timeout also trigger a STI? Should we be expecting the
> Proxies to release resources automatically when the Session-Timeout AVP has
> been reached? Otherwise, what really happens when the Session-Timeout AVP
> expires and a session must be torn down in a AAAH and the proxies?

ok, so in the RADIUS world, it is implicit. No additional signaling is
required. Once the session times out, all nodes simply free resources. Of
course, there is no STI in RADIUS. So, what should we do? Maintain the RADIUS
model, or explicit signaling?

Comments?

> I was simply wondering if it was allowed for the AAAH to return a bigger
> value then the one that was sent as a hint from the DIAMETER client?

Ah, good question. Again, in the RADIUS world, the RADIUS server can return
pretty much what it wants. A hint from a client does not imply a maximum, so I
believe that the server should be able to return anything it wants.

Other comments on this one? Anyone disagree?

> I guess you meant a Session-ID and an Extension-ID? Yes, that would be OK.
correct.

> Then, are you telling me that the message routing can be done using other
> AVPs than the Routing-Realm AVP and the User-Name AVP? Also, is it really
> needed in the STR, which is sent from the access device to the Home AAA?

In the STR no, only in the STI. Can anyone think of a better mechanism? I
really don't know of a better way to do this.

> "Upon receipt of the STR, the Home DIAMETER Server SHOULD release all
> resources for the session indicated by the Session-Id AVP. Any intermediate
> server in the Proxy-Chain MAY also release any resources, if necessary."
> 
> That's the reason why I asked about the STA. Now you're telling me that it
> should be the STA that should trigger the release of resources, right?

I will clean up the text. The sender of the STR cleans up after receiving the
STA, while the receiver of the STR cleans up while receiving the STR.

PatC

---

From: Barney Wolff <[email-masked]>
Date: Mon, 22 Jan 2001 10:45:25 -0500

Why does DIAMETER need to specify such within-node behavior?
Is any of it visible outside the node?

Barney Wolff

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 22 Jan 2001 08:15:26 -0800 (PST)

> Is any of it visible outside the node?

If state is released implicitly, then a sentence explaining the purpose of the
Session-Timeout AVP is sufficient. However, if explicit signaling is used to
release resources, then it is visible outside the node.

PatC

---

From: Barney Wolff <[email-masked]>
Date: Mon, 22 Jan 2001 13:29:43 -0500

I was commenting on language specifying when the server & proxy
must release resources (STR/STA).  I don't believe that has to
be specified.  All that needs to be said is that a server
must respond to STR with STA and a proxy must pass an STA back
to its client.  Specifying exactly when internal resources get
released is overkill, unless it has consequences on visible
behavior.  IMHO.

Barney

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 22 Jan 2001 10:30:29 -0800 (PST)

Ah, sorry for the misunderstanding. I do agree. Does anyone object?

PatC