Subject: [AAA-WG]: Re: AAAH must be stateful

From: Joe Lau <[email-masked]>
Date: Thu, 4 Oct 2001 11:08:44 -0700 (PDT)

Pat,

> I agree that the AAAh must be statefull anyway so there is no
> gain in sending the FA keys to the HA

Do you agree that AAAh must be statefull?  So far, I have not 
heard disagreement from anyone.  If you agree, can you put in a 
statement on the draft to make this requrirement clear so that 
implementors know that they MUST maintain session states on their
AAAh server?

Thanks!

Regards,

Joe Lau

> so, the key distribution avps will now look like this?
> (adding the key lifetime avp as well)
> 
> MIP-FA-to-MN-Key ::= < AVP Header: 326 >
>                      { MIP-FA-to-MN-SPI }
>                      { MIP-Algorithm-Type }
>                      { MIP-Session-Key }
>                      { MIP-Key-Lifetime }
>                      * [ AVP ]
> 
> MIP-FA-to-HA-Key ::= < AVP Header: 328 >
>                      { MIP-FA-to-HA-SPI }
>                      { MIP-Algorithm-Type }
>                      { MIP-Session-Key }
>                      { MIP-Key-Lifetime }
>                      * [ AVP ]
> 
> 
> MIP-HA-to-FA-Key ::= < AVP Header: 329 >
>                      { MIP-Algorithm-Type }
>                      { MIP-Session-Key }
>                      { MIP-Key-Lifetime }
>                      * [ AVP ]
> 
> MIP-HA-to-MN-Key ::= < AVP Header: 332 >
>                      { MIP-Algorithm-Type }
>                      { MIP-Replay-Mode }
>                      { MIP-Session-Key }
>                      { MIP-Key-Lifetime }
>                      * [ AVP ]
> 
> MIP-MN-to-FA-Key ::= < AVP Header: 325 >
>                      { MIP-Algorithm-Type }
>                      { MIP-Key-Material }
>                      { MIP-Key-Lifetime }
> 			   { AAA-SPI } <--- spi pointing to mn-aaa sec context
>                      * [ AVP ]
> 
> MIP-MN-to-HA-Key ::= < AVP Header: 331 >
>                      { MIP-Algorithm-Type }
>                      { MIP-Replay-Mode }
>                      { MIP-Key-Material }
>                      { MIP-Key-Lifetime }
>                      { AAA-SPI } <--- spi pointing to mn-aaa sec context
>                      * [ AVP ]
> 
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]]On Behalf Of
> >Joe Lau
> >Sent: den 3 oktober 2001 20:54
> >To: [email-masked]
> >Cc: [email-masked]; [email-masked];
> >[email-masked]; [email-masked]; [email-masked]
> >Subject: Re: [AAA-WG]: Section 8.1
> >
> >
> >> We have defined MIP-FA-to-HA-SPI  MIP-FA-to-MN-SPI  two AVPs,
> >why don't we
> >> put these AVPs in the MIP-FA-to-HA-Key  MIP-FA-to-MN-Key to replace the
> >> MIP-Peer-SPI ?    In other words, see below
> >>       MIP-FA-to-MN-Key ::= < AVP Header: 326 >
> >>                            { MIP-FA-to-MN-SPI }
> >>                            { MIP-Algorithm-Type }
> >>                            { MIP-Session-Key }
> >>                          * [ AVP ]
> >>
> >>       MIP-FA-to-HA-Key ::= < AVP Header: 328 >
> >>                            { MIP-FA-to-HA-SPI }
> >>                            { MIP-Algorithm-Type }
> >>                            { MIP-Session-Key }
> >>                          * [ AVP ]
> >> By the way, I don't think we can impletement stateless diameter server by
> >> requesting for example "If the MIP-FA-to-HA-Key is in the HAR it must be
> >> returned in the HAA so it can be inserted into the AMA." and so on.
> >> Because in redirect case, there is no guarantee that whay avps
> >you send, you
> >> will see all of them from the redirect answer. So all the
> >diameter have to
> >> keep the state. please correct me if I am wrong.
> >
> >I agree with Michael that _all_ diameter have to keep state.
> >Another good example would be the following statement on section 1.2.
> >
> >   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). Of
> >   course, the AAAH MUST use the _same_ session identifier for _all_ HARs
> >   initiated on behalf of a given mobile node's session.
> >
> >This will require the AAAH server to be stateful.
> >
> >Anyone disagree on this?
> >
> >Joe
> >
> >
> >> Joe Lau wrote:
> >>
> >> > > The general idea was that the HA modify the SPI value in the
> >> > > MIP-FA-to-HA-Key, and return the updated AVP in the HAA.
> >> >
> >> > But there is no more MIP-FA-to-HA-Key in HAA on the draft
> >version 8, alpha.
> >> > Did you mean MIP-FA-to-HA-SPI instead?  Or, did I miss somthing in this
> >> > discussion?
> >> >
> >> > Joe
> >>
> >> --------------E9A36EF30F9B970D0F625B9D
> >> Content-Type: text/html; charset=us-ascii
> >> Content-Transfer-Encoding: 7bit
> >>
> >> <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
> >> <html>
> >> <tt>We have defined MIP-FA-to-HA-SPI&nbsp;
> >MIP-FA-to-MN-SPI&nbsp; two AVPs,
> >> why don't we put these AVPs in the MIP-FA-to-HA-Key&nbsp;
> >MIP-FA-to-MN-Key
> >> to replace the MIP-Peer-SPI ?&nbsp;&nbsp;&nbsp; In other words,
> >see below</tt>
> >> <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MIP-FA-to-MN-Key ::= &lt;
> >AVP Header:
> >> 326 ></tt>
> >>
> ><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
> >;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> >> { MIP-FA-to-MN-SPI }</tt>
> >>
> ><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
> >;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> >> { MIP-Algorithm-Type }</tt>
> >>
> ><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
> >;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> >> { MIP-Session-Key }</tt>
> >>
> ><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
> >;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> >&nbsp;&nbsp;&nbsp;
> >> * [ AVP ]</tt><tt></tt>
> >> <p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MIP-FA-to-HA-Key ::= &lt;
> >AVP Header:
> >> 328 ></tt>
> >>
> ><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
> >;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> >> { MIP-FA-to-HA-SPI }</tt>
> >>
> ><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
> >;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> >> { MIP-Algorithm-Type }</tt>
> >>
> ><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
> >;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> >> { MIP-Session-Key }</tt>
> >>
> ><br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
> >;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> >&nbsp;&nbsp;&nbsp;
> >> * [ AVP ]</tt>
> >> <br><tt>By the way, I don't think we can impletement stateless diameter
> >> server by requesting for example "If the MIP-FA-to-HA-Key is in the HAR
> >> it must be returned in the HAA so it can be inserted into the AMA." and
> >> so on.</tt>
> >> <br><tt>Because in redirect case, there is no guarantee that whay avps
> >> you send, you will see all of them from the redirect answer. So all the
> >> diameter have to keep the state. please correct me if I am
> >wrong.</tt><tt></tt>
> >> <p><tt>-Michael</tt>
> >> <br><tt></tt>&nbsp;<tt></tt>
> >> <p>&nbsp;
> >> <p>Joe Lau wrote:
> >> <blockquote TYPE=CITE>> The general idea was that the HA modify the SPI
> >> value in the
> >> <br>> MIP-FA-to-HA-Key, and return the updated AVP in the HAA.
> >> <p>But there is no more MIP-FA-to-HA-Key in HAA on the draft version 8,
> >> alpha.
> >> <br>Did you mean MIP-FA-to-HA-SPI instead?&nbsp; Or, did I miss somthing
> >> in this
> >> <br>discussion?
> >> <p>Joe</blockquote>
> >> </html>
> >>
> >> --------------E9A36EF30F9B970D0F625B9D--
> >>
> >>
> 
>

---

From: Mark Eklund <[email-masked]>
Date: Thu, 4 Oct 2001 14:36:57 -0400

> implementors know that they MUST maintain session states on their

I'm trying to think of when you must keep state.  

1. To know which AMR to send when you receive a HAA.  The base spec
   says, "A stateless agent is one that only maintains transaction
   state.".  I would consider this transaction state (including the
   keys sent in the HAR), so this does not make the server stateful.

2. You receive an AMR for a session that you have already authenticated.
   Thus you must remember the previous Session-Id for the communication
   with the HAA.  This would make you have to be stateful.  But...
   If you send the Session-Id back in a Class attribute, you don't have
   to maintain state.

Are there any reasons a server MUST maintain state?

-mark

---

From: Pat Calhoun <[email-masked]>
Date: Sun, 7 Oct 2001 14:49:58 -0700

> I'm trying to think of when you must keep state.  

first, I meant transaction state. Let me explain.

If the AAAh keeps transaction state on both the AMR and the HAR, it can
easily create a pointer to have a relationship with both messages. Furthermore,
part of the transaction state is to maintain the keys.

This isn't rocket science, and it seems like this whole thread evolved
into what is a problem that we fixed quite some time ago. Specifically,
how the HA finds the session when the session-ids has changed. We've 
already handled this problem a long time ago in order to support handoffs
in MIP.

So, after reading the whole thread, and is still unclear to me that any
additional work is required.

>    keys sent in the HAR), so this does not make the server stateful.

ok, my mistake. I meant stateful as in transactions only, not session.

>    If you send the Session-Id back in a Class attribute, you don't have

this is trivial, and is part of transaction state.

> Are there any reasons a server MUST maintain state?

no.

PatC