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

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

Mark,

> Are there any reasons a server MUST maintain state?

What about this one (as stated on draft 8, alpha)?

   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. 

Joe Lau

> -mark
> 
>  > 
>  > 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 15:05:09 -0400

>    initiated on behalf of a given mobile node's session. 

If you send back the Session identifier that you created for the HAR
as a class attribute in the AMA, the FA MUST return it in subsequent
authentications.  Thus you can extract it for the next amr and use it.

I'm not saying this is a good method, just that it is a possible way
of avoiding a stateful server.

-mark