Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions

From: David Spence <[email-masked]>
Date: Mon, 03 Jun 2002 15:45:45 -0400

I've had my head buried in NASREQ too long.  I let this one slide by 
without picking up on it.  Johan has identified a real problem in issue 
336, but I believe he has proposed the wrong solution to it.  There is a 
very important reason why the accounting Session-Id should be the same as 
the authorization Session-Id.  It's to facilitate auditing.  It ought to 
be possible to verify in an audit that sessions accounted for were, in 
fact, authorized.  Including the same Session-Id in authorization and 
accounting messages has been a key concept of Diameter since the 
beginning.  We should not even propose changing something this basic 
this late in the process.  But in this case, we really can't.  The 
Session-Id MUST be the same for both the authorization and accounting 
messages.

However, since the issue is a real one, it must be solved somehow.  The 
following is my proposal.

1) In the MIP draft, we should require that the HAR has the same 
   Session-Id as the AMR that caused it to be generated.  As a result of 
   this protocol change, 
   
      a) the session scope seen by the HA will match the session scope 
         seen by the FAs, the AAAFs, and the AAAHs,
      
      b) the AAAH does not need to be session-stateful, and
      
      c) it makes no difference whether all the HARs are issued by the 
         same AAAH or not.
   
   This change also allows us to remove the following nonsensical 
   statements from section 1.2 of the MIP draft:
   
      If the AAAH is session-stateful, it MUST send the same session 
      identifier for all HARs initiated on behalf of a given mobile 
      node's session. Otherwise, if the AAAH is session-stateless, it 
      will manufacture a unique session-id for every HAR.
      
   The nonsense consists of making a protocol requirement conditional on 
   an implementation decision (if session-stateful, then MUST send same 
   Session-Id).  And of what use is the MUST if the HA can't depend on 
   it?
   
2) When an HA receives an HAR for a given multi-session that has a 
   different Session-Id from previous HARs for the same multi-session, 
   the HA MUST generate an ACR with an Accounting-Record-Type of 
   STOP_RECORD containing the old Session-Id followed by an ACR with an 
   Accounting-Record-Type of START_RECORD containing the new Session-Id.
   
   As a result of this protocol change,
   
      a) HA accounting sessions will have the same scope as FA 
         accounting sessions so that the records could be matched by an 
         accounting server if desired, and
         
      b) FA and HA accounting records will contain the same Session-Id 
         to facilitate such matching as well as to facilitate auditing.

David S.

[email-masked] wrote:
> 
> Hi all,
> 
> I have made the changes, so issue 336 is closed.
> 
> John
> 
> > -----Original Message-----
> > From: Loughney John (NRC/Helsinki)
> > Sent: 02 May, 2002 10:32
> > To: [email-masked]; [email-masked]
> > Subject: RE: [AAA-WG]: [issue] Clarify relationship between auth and
> > accounting sessions
> >
> >
> > Hi Johan,
> >
> > > Requested change:
> > >
> > >    The Diameter protocol's Session-Id AVP, which is
> > globally unique (see
> > >    section 8.8), is used during the authorization phase to
> > identify a
> > >    particular session. Services that do not require any
> > authorization
> > >    still use the Session-Id AVP to identify sessions.
> > >
> > > to
> > >
> > > The Diameter protocol's Session-Id AVP, which is globally
> > unique (see
> > > section 8.8), is used during the authorization phase to identify a
> > > particular session. Services that do not require any authorization
> > > still use the Session-Id AVP to identify sessions.
> > Accounting messages
> > > MUST use a different Session-Id from that sent in
> > > authorization messages.
> >
> > Somehow, the "MUST use" part of the last sentence worries me.  I think
> > that it may be more application specific.  I'd prefer to
> > state something
> > more like:
> >
> >   Accounting messages MAY use a different Session-Id from
> > that sent in
> >   authorization messages.  Specific applications MAY require different
> >   a Session-ID for accounting messages.
> >
> > Then, the application (for example MIP) could use a MUST.
> >
> > Comments?
> > John
> >
> >

-- 
David Spence                            email: [email-masked]
Interlink Networks, Inc.                phone: +1 734 821 1203
775 Technology Drive, Suite 200         fax:   +1 734 821 1235
Ann Arbor, MI 48108           
U.S.A.

---

From: Tony Johansson <[email-masked]>
Date: Mon, 03 Jun 2002 15:54:32 -0700

Hi David,

> Session-Id MUST be the same for both the authorization and accounting

Since the nature of MIP is that you move between FAs and as stated in the MIP
draft:

"
   ....
   A mobile node's session is identified via its identity in the User-
   Name AVP, the MIP-Mobile-Node-Address and the MIP-Home-Agent-Address
   AVPs. This is necessary in order to allow the session state machine,
   defined in the base protocol [DIAMBASE], to be used unmodified with
   this application. Therefore, an STR from a foreign agent would free
   the session from the foreign agent, but not the one towards the home
   agent (see figure 3).

           STR, Session-Id = foo       STR, Session-Id = bar
           --------------------->      <--------------------
      +----+      +------+      +------+                    +----+
      | FA |      | AAAF |      | AAAH |                    | HA |
      +----+      +------+      +------+                    +----+
           <---------------------      --------------------->
           STA, Session-Id = foo       STA, Session-Id = bar
            Figure 3: Session Termination and Session Identifiers "

>    Session-Id as the AMR that caused it to be generated.  As a result of

This was discussed about a year a go and  identified that the Session-Id for the
AMR and the HAR MUST be different. What you are raising here is an old issue, so
I really don't see why we should go here again.

Furthermore, the functionality that you mention in bullet 1 and 2 are already
fulfilled today, with help of the Acct-Multi-Session-Id, see e.g. section 1.3
Support for Mobile IP Handoffs:

"...
   Since the AAAH may be session-stateless, it is necessary for the
   resulting HAR received by the HA to be identified as a continuation
   of an existing session. If the HA receives an HAR for a mobile node,
   with a new session identifier, and the HA can guarantee that this
   request is to extend service for an existing service, then the HA
   MUST be able to modify its internal session state information to
   reflect the new session identifier.

   It is necessary for accounting records to have some commonality
   across handoffs in order for correlation to occur.  Therefore, the
   home agent MUST send the same Acct-Multi-Session-Id AVP value in all
   HAAs for the mobile's session.  That is, the HA generates a unique
   Acct-Multi-Session-Id when receiving an HAR for a new session, and
   returns this same value in every HAA for the session. This Acct-
   Multi-Session-Id AVP will be returned to the foreign agent by the
   AAAH in the AMA. Both the foreign and home agents MUST include the
   Acct-Multi-Session-Id in the accounting messages.

           ACR, Session-Id = foo         ACR, Session-Id = bar
           Acct-Multi-Session-Id = a     Acct-Multi-Session-Id = a
           --------------------->      <--------------------
      +----+      +------+      +------+                    +----+
      | FA |      | AAAF |      | AAAH |                    | HA |
      +----+      +------+      +------+                    +----+
           <---------------------      --------------------->
           ACA, Session-Id = foo       ACA, Session-Id = bar

            Figure 4: Accounting messages w/ Mobile IP Application
..."

So, the HARs session-Id may change, but the acct-multi-session-id stays the same
for both the HA and FAs. You can also look at issue Issue 290: Handling of
Acct-Multi-Session-Id AVP, which was discussed and solved in February.

Again, the draft has already this functionality (by the Acct-Multi-Session-Id
AV.), so MHO I really don't see why we should discuss this any further, and most
likely postpone the time line for this draft even further.

/Tony

---

From: David Spence <[email-masked]>
Date: Mon, 03 Jun 2002 21:21:33 -0400

Tony,

I am aware of the function of the Acct-Multi-Session-Id, and you are correct
that it binds the sessions of the multi-session together.  What I was trying to
do was to preserve Diameter's notion of a session and salvage the function of a
Session-Id, which ought to bind the messages within a session together and ought
to be useful for purposes such as auditing, independent of application. 
Session-Id should not work differently for MIP than it does for other Diameter
applications.  Acct-Multi-Session-Id is not a substitute for Session-Id in MIP. 
The Acct-Multi-Session-Id AVP is not included in every MIP message.  The
Session-Id AVP is.

You are correct that my proposal failed to address the termination of the
individual authorization sessions.  Unfortunately, MIP, as it is, is simply
broken.  Not only don't HA sessions correspond to FA sessions.  In mobileip-10,
they also have no identifier that appears in every message of the session.  And
there is no mechanism to identify sessions between the HA and the various AAAH's
that may be involved.  I believe MIP is a faulty extension of Diameter if HA
sessions cannot be identified using the base protocol.

Therefore, I'm afraid issue 336 is still unresolved, and now we have a new issue
regarding the brokeness of HA sessions.  That's more than I want to try to fix
tonight so, in the words of Scarlett O'Hara, I'll worry about that tomorrow.

Dave

---

From: Tony Johansson <[email-masked]>
Date: Tue, 04 Jun 2002 10:11:49 -0700

Hi David,

David Spence wrote:

> applications.

Well, MIP is very different then NASREQ, since you do have to deal with the fact that
the MN moves between different FAs, but stays anchored in the same HA in MIP. So, to
be able to use Base functionality such as STR/STA, the Session-id is split between the
FA and AAAH, and the HA and AAAH. This was decided over a year ago.

> Acct-Multi-Session-Id is not a substitute for Session-Id in MIP.
> The Acct-Multi-Session-Id AVP is not included in every MIP message.

Yes it is! The Acct-Multi-Session-Id is always sent in HAA and AMA, see my previous
text below. However, the ABNF in MIP-10 for HAA and AMA is wrong, should be {} and not
[]. I will fix that in -11.

/Tony

> The

---

From: David Spence <[email-masked]>
Date: Tue, 04 Jun 2002 15:00:59 -0400

> FA and AAAH, and the HA and AAAH. This was decided over a year ago.

Yes.  I see now that the HA Session-Id needs to be different than the FA
Session-Id.

> []. I will fix that in -11.

No it isn't!  The Acct-Multi-Session-Id is not always included in the HAR and
AMR, but the Session-Id is.  My statement is correct.

By the way, if the Acct-Multi-Session-Id is always included in the AMA as you
claim, then your Command-Code table in section 8.1 is in error:

                                 +-----------------------+
                                 |      Command-Code     |
                                 |-----+-----+-----+-----+
   Attribute Name                | AMR | AMA | HAR | HAA |
   ------------------------------|-----+-----+-----+-----+
   Acct-Multi-Session-Id         | 0-1 | 0-1 | 0   | 1   |

---

From: Tony Johansson <[email-masked]>
Date: Tue, 04 Jun 2002 14:53:45 -0700

David,

> Yes.  I see now that the HA Session-Id needs to be different than the FA

Good that we agree.

> AMR, but the Session-Id is.  My statement is correct.

I'm lost?! The Acct-Multi-Session-Id is used to make sure that we can synchronize the
ACR/ACA from the FAs and the HA. So, why would you need the Acct-Multi-Session-Id in the HAR
and AMR?

> claim, then your Command-Code table in section 8.1 is in error:

Good catch. Fixed in -11.

Thanks,

/Tony

---

From: Johan Johansson <[email-masked]>
Date: Wed, 05 Jun 2002 00:09:15 +0200

>claim, then your Command-Code table in section 8.1 is in error:

Well, when Tony said that it was always included he didn't really mean 
always. An AMA that signals an error does not contain an 
Acct-Multi-Session-Id. Neither should the HAA I guess. It was noted at 
the Diameter Bakeoff last fall that messages with another result code 
than DIAMETER_SUCCESS rarely followed or could follow the ABNFs unless 
dummy AVPs were added. The resolution to this problem was to weaken the 
ABNFs. Personally I would have prefered ABNFs depending on the result 
code, but it was not the wish of the editor at the time.

>>>>>336, but I believe he has proposed the wrong solution to it.  
>>>>>

Actually I didn't propose *a* solution but a number of them. My main 
wish was that the conceptual relationship between the authorization 
session and the accounting session would be resolved. This was not 
fulfilled by the accepted solution and I wonder what parts of the text 
make what assumptions in this regard as well as in a few others. It 
would have been good in my opinion if more care had been taken to define 
the basic concepts involved in the protocol as well as more willingness 
to discuss them among a broader selection of the workgroup members.

But the world is imperfect and I expect the first interop after the 
drafts becomes rfcs to be very interesting and very educational.

j

---

From: Johan Johansson <[email-masked]>
Date: Wed, 05 Jun 2002 00:39:52 +0200

Is this a lapsus or is it now ok to not follow the ABNF in some cases?

j

---

From: Tony Johansson <[email-masked]>
Date: Tue, 04 Jun 2002 16:04:50 -0700

Sorry, I guess I was way to quick to answer David here :(

Here is how I believe it should be:

The Acct-Multi-Session-Id AVP MUST be added in the HAA and AMA as stated in section
1.2 and 1.3. However, since both AMA and HAA are answers the Acct-Session-Id AVP
should therefore be set as optional in the ABNF (since an error could occur, with
the consequence that no Acct-Multi-Session-Id could be sent back....).

So, in ABNF for AMA and HAA: [ Acct-Multi-Session-Id ]

and table in section 8.1 should be:

 Acct-Multi-Session-Id         | 0   | 0-1 | 0   | 0-1 |

/Tony

---

From: David Spence <[email-masked]>
Date: Wed, 05 Jun 2002 16:14:44 -0400

Without attempting to go through all the scenarios or draft all the text 
to be added to mobileip-10, here is my proposal for how to resolve issue 
336 (Clarify relationship between auth and accounting sessions) in a 
good way.

These are my goals:

   1. Create a one-to-one correspondence between FA sessions and HA 
      sessions so that for each FA session there will be a single HA 
      session for the same MN that starts and ends at approximately the 
      same time as the FA session it corresponds to.
      
   2. Diameter MobileIPv4 accounting sessions should exactly match the 
      authorization sessions and have the same Session-Id.
      
   3. Accounting servers should be able to match the FA accounting 
      records to the HA accounting records for a given MN.
      
   4. AAAH Diameter Servers need not be session stateful.  The protocol 
      should work the same way whether Diameter Servers are session 
      stateful or not.
      
   5. A domain should be able to have more than one Diameter Server 
      fulfilling the AAAH role.

The following are the general principles governing HA sessions.  The 
first two principles exist today.  I am merely restating them to 
emphasize that I am not changing them.

   1. An HA session begins when a Diameter Server sends an HAR command 
      to an HA and receives an HAA command in response.
      
   2. An HA session should normally end when an HA sends an STR command 
      to a Diameter Server and receives an STA command in response.
      
      Discussion:
         
         When an AAAH receives an STR command from an AAAF for an FA 
         session, it does not attempt to terminate the corresponding HA 
         session by sending an ASR command.  The HA will find out via 
         the Mobile IP protocol that the session has ended and will send 
         and STR to the AAAH.  It is important to maintain this 
         principle because the AAAH may not be aware of a pending 
         handoff.  If the HA were to terminate a session before 
         commencing a new session for the pending handoff, the 
         multi-session would terminate and the handoff would then fail.
         
   3. When an AAAH receives an AMR command that represents a new FA 
      session -- whether for a new multi-session or for a handoff within 
      an existing multi-session -- it generates an HAR command with a 
      new Session-Id.
      
   4. When an HA receives an HAR command for a new session within a 
      multi-session, it generates an HAA in response and also generates 
      an ACR command with Accounting-Record-Type of START_RECORD.
      
   5. When an HA terminates a session within a multi-session, it 
      generates an STR command and also generates an ACR command with 
      Accounting-Record-Type of STOP_RECORD.

Principle number 3, above, cannot be implemented without a slight 
protocol change.  First of all, I don't know that there is any way that 
a non-stateful AAAH can distinguish an AMR for a new session from a 
reauth AMR for an existing session.  Furthermore, for a reauth, the AAAH 
must include the Session-Id in the HAR that identifies the 
reauthenticated/reauthorized session.  If the AAAH is stateless, it has 
no way of knowing what Session-Id to use.  Similarly if the AMR for the 
reauth is sent to a different AAAH, the second AAAH will not know what 
Session-Id to use in the HAR.  In both of these cases, this problem is 
currently solved in mobileip-10 in a way that VIOLATES THE DIAMETER 
PROTOCOL.  In both of these cases, the AAAH generates a new value for 
the Session-Id.  The HA cannot rely on the Session-Id in a reauth HAR to 
identify the session being reauthenticated/reauthorized.  It must find 
the session some other way.

In order to fix the Diameter-MobileIPv4 protocol so that it works 
correctly, I propose to define two new AVPs:

   FA-Session-Id
   
      This AVP is inserted in HAR commands by the AAAH to indicate the 
      Session-Id of the corresponding FA session.  It is inserted in ACR 
      commands along with the MIP-Foreign-Agent-Host AVP by the HA to 
      identify the corresponding FA session to the accounting server.
   
   HA-Session-Id
      
      This AVP is inserted in AMA commands by the AAAH to indicate the 
      Session-Id of the corresponding HA session.  It is inserted in 
      subsequent AMR commands for the same session by the FA.  When 
      generating a HAR command, if the corresponding AMR command 
      contains an HA-Session-Id AVP, then the AAAH includes the value of 
      the HA-Session-Id AVP in the Session-Id AVP it inserts in the HAR.  
      Otherwise it generates a new value for the Session-Id it inserts 
      in the HAR.  The FA also inserts the HA-Session-Id AVP in ACR 
      commands to identify the corresponding HA session to the 
      accounting server.

This proposal requires no changes to the base protocol except to remove the 
following stipulation that may have been added in an earlier attempt to 
resolve issue 336:

   Accounting messages MAY use a different Session-Id from that sent in
   authorization messages.  Specific applications MAY require different
   a Session-ID for accounting messages.

---

From: Tony Johansson <[email-masked]>
Date: Fri, 07 Jun 2002 15:50:27 -0700

Hello David,

I'm sorry that I haven't replied earlier.

Before I start to comment on your proposal below. I think we really have to
start by looking at how we define a stateless versus stateful Diameter agent in
the Base protocol.

Looking at section 2.8 Role of Diameter Agents, the following are stated :

"....

   The Diameter protocol requires that agents maintain transaction
   state, which is used for failover purposes. Transaction state implies
   that upon forwarding a request, its Hop-by-Hop identifier is saved;
   the field is replaced with a locally unique identifier, which is
   restored to its original value when the corresponding answer is
   received. The request's state is released upon receipt of the answer.
   A stateless agent is one that only maintains transaction state.
...

   A stateful agent is one that maintains session state information; by
   keeping track of all authorized active sessions. Each authorized
   session is bound to a particular service, and its state is considered
   active either until it is notified otherwise, or by expiration. Each
   authorized session has an expiration, which is communicated by
   Diameter servers via the Session-Timeout AVP.
...."

So, given the above, where it is clearly stated that a "stateless agent is one
that only maintains transaction state", can we really claim that a AAAH can be
stateless? If we both agree that the AAAH can not be stateless according to this
protocol definition, then just have to remove the last sentence from the
following paragraph on page 10 in MIP-10:

"
   During the creation of the HAR, the AAAH MUST use a different session
   identifier than the one used in the AMR/AMA (see Figure 2). If the
   AAAH is session-stateful, it MUST send the same session identifier
   for all HARs initiated on behalf of a given mobile node's session.
   Otherwise, if the AAAH is session-stateless, it will manufacture a
   unique session-id for every HAR. "

Regards,

/Tony

---

From: David Spence <[email-masked]>
Date: Sat, 08 Jun 2002 16:15:27 -0400

Tony,

First of all, I am not sure that I do agree that an AAAH cannot be
stateless.  Our initial implementation of a Diameter server was stateless
and at the time we thought that we could correctly implement the protocol. 
I am not aware of any reason other than this issue that would prevent an
AAAH from being session stateless.  If you know of any, I would very much
appreciate it if you would let me know.

But let's suppose that we did require an AAAH to be session stateful.  In
that case, would you also require that if a domain ran multiple AAAH's, then
they would be required to implement a proprietary mechanism to share state
with each other?  If not, then you would have a problem if an original
authorization were handled by AAAH1 and a subsequent reauth were handled by
AAAH2.  The problem would be that AAAH2 would not know what Session-Id to
put in the HAR.

So let's further suppose that if multiple AAAH's exist in a domain they MUST
be able to access each other's session state database.  In that case, I
think that simply deleting the last sentence ("Otherwise, if the AAAH is
session-stateless, it will manufacture a unique session-id for every HAR")
would technically suffice.  I would probably want to strengthen the last
phrase of the preceding sentence ("on behalf of a given mobile node's
session"), however, to make it clear that "session" means session and not
multi-session.  That is, if an AAAH sends an HAR for a handoff of a mobile
node's session (where the AMR that triggers it bears a different Session-Id
from the AMR that produced the previous HAR), then the AAAH MUST generate a
new Session-Id for the new HAR.  Of course, a stateful AAAH would be able to
do that.

I think, however, that creating the two AVPs I defined below is all that is
needed both to alleviate the AAAH from having to be stateful and to allow
multiple AAAH's in a domain not to have to share state.  Defining these two
AVPs has the added benefit of helping an accounting server to match FA
accounting records to HA accounting records for corresponding sessions.

Dave

---

From: Tony Johansson <[email-masked]>
Date: Sun, 09 Jun 2002 13:07:13 -0700

Hi David, all,

> appreciate it if you would let me know.

Being session stateless according to the Base protocol is that you only maintains
transaction state. However, a MIP AAAH server do have to handle the authentication,
authorization, etc of the user, and furthermore must expect to get STRs or send ABRs
for an expired session-id that an active user may have, so strictly form a protocol
prospective, can you really say that the MIP AAAH server can be a stateless Diameter
agent?

Furthermore, based on all the previous session stateless AAAH discussions,
implementing the MIP application with a *session stateless* AAAH wouldn't you still
store the FA session id and the HA session id in the AAAH (or in away that the AAAH
easily can retrieve them (e.g. through a back ended database)) in order to deal with
STRs from the HA, synchronizing the session id for accounting purposes, not having to
send new session ids in every subsequent HAR, etc etc?

> with each other?

No, that's why we have agree to add support for the AAA NAI for Mobile IPv4 Extension
(http://www.ietf.org/internet-drafts/draft-ietf-mobileip-aaa-nai-02.txt) and added
text through out the MIP application for the support of multiple AAAH's. Please see
further info from previous mail threads on issue 299 and 301, and presentation made at
IETF53.

> If not, then you would have a problem if an original

See above.

> new Session-Id for the new HAR.

Why should you change the session-id between the AAAH and HA just because you changed
from one FA to another FA? IMHO, I would only change the session-id to HA only if you
have move to another AAAH. Then it is very clear to the HA why the session-id is
changed..

> Of course, a stateful AAAH would be able to
> do that.
>

I have no problems of added these new AVPs to the protocol. However, I really want us
once and for all first get consensus on what a session stateless AAAH really means and
based on that decide if the two new AVPs are needed.

Does it make sense?!

Best Regards,

/Tony

---

From: "Fredrik Johansson" <[email-masked]>
Date: Mon, 10 Jun 2002 09:50:19 +0200

David,

Please see comments below

/Fredrik

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> David Spence
> Sent: den 8 juni 2002 22:15
> To: Tony Johansson
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [AAA-WG]: [issue] Clarify relationship between auth and
> accounting sessions
>
>
> Tony,
>

That's why the HA must handle the case where it receives different session
id's for the same session. The HA must recognize that it's the same session
(using MN Address, HA address and NAI), it must then return the
multi-session id to the new AAAH in order to maintain the original
multisession.

---

From: David Spence <[email-masked]>
Date: Mon, 10 Jun 2002 10:36:09 -0400

Tony,

See comments inline.

Tony Johansson wrote:
> authorization, etc of the user, 

I don't think auth/auth mandates being session stateful.

> and furthermore must expect to get STRs 

A session-stateless AAAH doesn't really have to do anything with an
FA-generated STR except perhaps to write it to a log file.  Is the same not
true of an HA-generated STR?  If an AAAH receives an STR from an HA, it is
not required to send an ABR to the FA is it?  The FA will see the tunnel go
down and generate an STR.

> or send ABRs for an expired session-id that an active user may have, 

ABRs and session timeouts are defined in the base protocol.  My
understanding is that the home Diameter server is not required to send an
ABR to enforce a timeout.  That is the responsibility of the Diameter
client.

> so strictly form a protocol

Yes, the AAAH can be a stateless Diameter node!  (It is not a Diameter
agent, strictly speaking.)

> STRs from the HA, 

Once again, I didn't think it was necessary to match Session-Ids in order to
handle HA STRs.  Am I mistaken about this?

> synchronizing the session id for accounting purposes, 

That is a problem for the accounting server and is ordinarily done in the
post processing.  Of course, either an accounting server or an AAAH MAY be
session-stateful if it wishes to keep track of such things in real time
instead of in the post-processing.

> not having to send new session ids in every subsequent HAR, etc etc?

Well, now you're begging the question.  This is the problem I was trying to
solve by defining the HA-Session-Id AVP.  Certainly a session-stateful AAAH
could match FA Session-Ids to HA-Session-Ids without the new AVP.  However,
I still believe that this is the only problem that cannot be solved by a
session-stateless AAAH.

> text through out the MIP application for the support of multiple AAAH's. 

But the AAA NAI does not carry the HA-Session-Id AVP.  So if AAAH's are
session-stateful, but the AAAH's in a domain cannot share session state,
then if a reauth AMR arrives at a different AAAH than the one that processed
the original AMR, the AAAH processing the reauth AMR has no way to know the
value of the Session-Id AVP it needs to insert in the HAR it sends to the
HA.

So your proposed requirement that AAAH's be session stateful fails unless
you also also require that multiple AAAH's in a domain have a mechanism to
share session state with each other.  My proposal, however, correctly
supports multiple AAAH's as well as stateless AAAH's.

> Please see further info from previous mail threads on issue 299 and 301, 
> and presentation made at IETF53.

I am well aware of the discussion on issues 299 and 301.  My colleague Bob
Kopacz submitted those issues, and I followed them closely.  They do not
apply to this case, however.

> > AAAH2.  The problem would be that AAAH2 would not know what Session-Id to

See what, above?  You have not explained how AAAH2 could possibly know what
Session-Id to put in the HAR -- unless you added the HA Session-Id to the
NAI extension when I wasn't looking.

> have move to another AAAH. Then it is very clear to the HA why the session-id is

The reason I would change the Session-Id between the AAAH and HA is so that
the HA accounting records will have the same scope as the FA accounting
records.  I believe that many home service providers will consider this
ESSENTIAL!

Furthermore, you MUST NOT change the Session-Id simply because a second AAAH
got involved.  This is the reauth case discussed above.  Not maintaining
Session-Id in a reauth is a breach of the Diameter base protocol!!!

> based on that decide if the two new AVPs are needed.

I don't think there has ever been a question about what a session-stateless
AAAH really means.

---

From: David Spence <[email-masked]>
Date: Mon, 10 Jun 2002 10:45:46 -0400

Fredrik,

See comments inline.

> multi-session id to the new AAAH in order to maintain the original

No.  It is true that the HA must recognize that it's the same
*multi-session* using MN Address, HA address and NAI in the case where a new
session is being created in the multi-session.  But a reauth of an FA
session does not change the FA Session-Id.  It *should not* change the HA
Session-Id either.  And it *should not* be necessary for the HA to match on
any field other than Session-Id when handling a reauth.

---

From: Tony Johansson <[email-masked]>
Date: Tue, 18 Jun 2002 12:00:33 -0700

Hi David, All,

Finally coming back to this one.

> ABR to enforce a timeout.  That is the responsibility of the Diameter

This is merely one use of the ASR. Another potential use would be to administratively
terminate a user session (yet another reason why you need to remember the session-id and
hence be session-stateful).

> handle HA STRs.  Am I mistaken about this?

Yes, in MIP the AAAH MUST be able receive STRs from both FAs and the HA (which in fact means
match Session-Ids). So, if the AAAH is session-stateless according to the base it would not
be expecting to get any STRs, since it would have announced that it is don't maintain state,
see below:

"8.11  Auth-Session-State AVP

   The Auth-Session-State AVP (AVP Code 277) is of type Enumerated and
   specifies whether state is maintained for a particular session. The
   client MAY include this AVP in requests as a hint to the server, but
   the value in the server's answer message is binding. The following
   values are supported:

      STATE_MAINTAINED              0
         This value is used to specify that session state is being
         maintained, and the access device MUST issue a session
         termination message when service to the user is terminated.
         This is the default value.

      NO_STATE_MAINTAINED           1
         This value is used to specify that no session termination
         messages will be sent by the access device upon expiration of
         the Authorization-Lifetime."

So, my point is again is that the AAAH cannot be session-stateless according to the base,
since it still must be able to keep track of the active sessions.

Again, have in mind that we are addressing the issue of protocol statefulness and *NOT*
implementation statefulness.

Other's comments would be greatly appreciated.

/Tony