Subject: RE: [AAA-WG]: RE: Issue 89: Editorial comments - Mobile-IP draft- 06

From: Thomas Panagiotis-PTHOMAS1 <[email-masked]>
Date: Wed, 11 Jul 2001 09:18:40 -0500

> > So, if the above is the intent, then the Session-Timeout AVP
> > should be included (as optional) in the definition of the AMR/AMA,
> > HAR/HAA messages. In addition, the Authorization-Lifetime AVP must
> > be included (as mandatory) in the HAR message to inform the HA on
> > the lower limit of the [AAAH]-HA:Session-Timeout. Finally, it should
> > be noted somewhere that the trigger for initiating sessions is not
> > always an Auth Request from the Client, but MAY be an application
> > specific message (HAR) coming from a Server.
>
> How could the AAAH cause the FA to force the mobile to re-register? I'm
> not sure that I understand your point here.

Let me try one more time...

AAAH will have at least 2 session state machines (SMs) on behalf of a user.
One for the session with the serving FA (FA-AAAH) and one for the session
with the HA (AAAH-HA). Correct?

Consider the session between the AAAH and the HA. What's the event/action
for the transition from Idle to Pending on the AAAH side? What's the
event/action
for the transition from Idle to Open on the HA side?

> > Diameter entities initiate sessions by sending Application-Specific
> > requests which MAY carry a proposed value for the Session-Timeout.
> > However, the receiver of the request has the last word on the value
> > of the Session-Timeout, which is sent in the corresponding answer.
> > Offering MIPv4 service to a user requires the establishment of
> > more than one sessions: [FA-1]-AAAH, [FA-2]-AAAH,..., [AAAH]-HA,
> > where [ ] indicates the initiator of the session. The sessions
> > are tied together through the Accounting-Multi-Session-Id.
>
> The AAAH, acting as a server, always has the final say on the session
> and authorization timeouts.

I agree. How would this be enforced for the Session-Timeout value?
a) AAAH sends a HAR message to HA with a Session-Timeout value. HA MUST
   accept the value. In this case there is no need to return the value
   to AAAH.
b) AAAH sends a HAR message to HA with the preferred Session-Timeout value
   and the Authorization-Lifetime AVP. If HA doesn't like the
Session-Timeout
   it can propose any value larger than the Authorization-Lifetime AVP. If
   AAAH doesn't like the value it sends back an error.

So, is (a) what you have in mind?

-Panos

-----Original Message-----
From: Pat Calhoun [mailto:[email-masked]]
Sent: 10 July 2001 11:26
To: Thomas Panagiotis-PTHOMAS1
Cc: 'Martin Julien \(ECE\)'; [email-masked]'
Subject: Re: [AAA-WG]: RE: Issue 89: Editorial comments - Mobile-IP
draft-06

> Session Management is generic and defined across applications
> (MIPv4,Dial-up,...). The Session-Timeout AVP is tied to a 
> Session-Id, therefore each session has its own Session-Timeout.

correct.

> Diameter entities initiate sessions by sending Application-Specific
> requests which MAY carry a proposed value for the Session-Timeout.
> However, the receiver of the request has the last word on the value
> of the Session-Timeout, which is sent in the corresponding answer.
> Offering MIPv4 service to a user requires the establishment of
> more than one sessions: [FA-1]-AAAH, [FA-2]-AAAH,..., [AAAH]-HA,
> where [ ] indicates the initiator of the session. The sessions
> are tied together through the Accounting-Multi-Session-Id.
The AAAH, acting as a server, always has the final say on the session
and authorization timeouts.

> 
> So, if the above is the intent, then the Session-Timeout AVP
> should be included (as optional) in the definition of the AMR/AMA,
> HAR/HAA messages. In addition, the Authorization-Lifetime AVP must
> be included (as mandatory) in the HAR message to inform the HA on
> the lower limit of the [AAAH]-HA:Session-Timeout. Finally, it should
> be noted somewhere that the trigger for initiating sessions is not
> always an Auth Request from the Client, but MAY be an application
> specific message (HAR) coming from a Server.

How could the AAAH cause the FA to force the mobile to re-register? I'm
not sure that I understand your point here.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 11 Jul 2001 07:51:20 -0700

> with the HA (AAAH-HA). Correct?
yes

> for the transition from Idle to Pending on the AAAH side? 

Sending the HAR moves it from Idle to Pending, this is the first event in
the state machine. The HAA moves it to Open.

> What's the

Receiving, and successfully processing the HAA. This is the second event in the
state machine.

I am still missing the issue, though :(

correct.

>    AAAH doesn't like the value it sends back an error.

no, the HA cannot increase the Session-Timeout. However, if the HA is in a
foreign network, I *suppose* it (or the AAAF processing the HAR/HAA) should
be permitted to lower the Session-Timeout and/or Authorization-Lifetime AVPs.

> So, is (a) what you have in mind?

That was my initial thought, but (b) now sounds quite feasible.

PatC