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

From: Joe Lau <[email-masked]>
Date: Thu, 4 Oct 2001 11:11:56 -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: Joe Lau <[email-masked]>
Date: Thu, 4 Oct 2001 15:03:55 -0700 (PDT)

> > > > I am very interested on learning how to achieve this w/o requiring the 
> > > > AAAh to maintain session states because I am facing such a problem right
> > > > now.  Can you give more details on how you can achieve your last 
> > statement?
> > > > 
> > > > 	 "Thus you can extract it for the next amr and use it."
> > > > 
> > > > 
> > > > Please use the following example.
> > > > 
> > > >         AMR(session_id_1) -------------------+
> > > >                                              |
> > > >                                              +------------> AAAh 
> > (stateless)
> > > >                                              |              |  |
> > > >         AMR(session_id_2) -------------------+              |  |
> > > >                                                             |  |
> > > >                                                   HAR(sid_3)|  | 
> > HAR(sid_4)
> > > >                                                             |  |
> > > >                                                             v  v
> > > >                                                             Home Agent
> > > > 
> > > > The two AMR's came from different FA's, so session_id_1 != session_id_2
> > > > But the draft says sid_3 must equal sid_4 on the HAR's.
> > > 
> > > It seems like the HA must be able to deal with receiving different
> > > session-id's for the same session anyway, since the AMRs may go to
> > > different AAAH's.  (Section 1.3 "Support for Mobile-IP Handoffs" says
> > > that "it is quite likely the AMR for a handoff will be received by
> > > a different AAAH".)
> > 
> > The HA is not is the question on the table :=)
> > 
> > The question is the draft says:
> > 
> > 	 ... ,the AAAH MUST use the _same_ session id for _all_ HARs
> > 	initialed on behalf of a given mobile node's session.

I assume there is a technical reason for the above "MUST" requirement.  
Can someone shed some light on this?  This will lead us to the answer
whether AAAh must be stateful or not.

Thanks.

Joe Lau

> > 
> > Since this is a MUST, then we need to know how to achieve this requirement 
> > on a stateless AAAh (if AAAh is not required to be stateful).
> 
> Alternatively, we could question why the above statement is a MUST.  If the
> HA has to deal with receiving different session-id's for the same session
> (in the case where a handoff AMR goes to a different AAAH), then what
> does the above requirement buy you?  This is just a draft, where MUSTs 
> are revised to MAYs and vice versa.
> 
> I think the real question you raised, which is a very good one, is whether
> the AAAH MUST be session stateful, or whether a reasonable implementation could
> be done with a session-stateless server.  Then statements such as the 
> above could be made consistent with that decision.
> 
> Thank you for pushing this stateful-v-stateless question; hopefully
> it will be resolved soon.
>  
> > This is the problem statement for our current discussion. 
>  
> > Joe Lau 
> 
> Take care,
> Bob K.
>  
>

---

From: Thomas Panagiotis-PTHOMAS1 <[email-masked]>
Date: Fri, 5 Oct 2001 17:04:17 -0500

I would also vote for a SHOULD in the "AAAH MUST/SHOULD keep session
state" question. For example, if (i) you don't care about accounting, and
(ii) you don't care about the mobile-foreign, foreign-home auth extensions,
and (iii) you set the mobile-home key lifetime to infinity, then you can
interact with AAA (ok AA) only upon initial registration (for user
authentication and mobile-home key distribution) and then forget about it.

-Panos

-----Original Message-----
From: Mark Eklund [mailto:[email-masked]]
Sent: Friday, October 05, 2001 4:04 PM
To: Joe Lau
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [AAA-WG]: Re: AAAH must be stateful

Joe Lau writes:
 > > > Are there any reasons a server MUST maintain state?
 > > > 
 > > What about this one (as stated on draft 8, alpha)?
 > >  > 
 > I was disappointed to the lack of response/discussion to this important
issue.
 > 
 > Can we all have a discussion on this important issue?
 > 
 > 	1) The reasons for the above MUST requirement on the AAAH

I can't think of a reason for this to be a MUST.  Is there ever a
situation where the HA will not be able to determine if this is a
continuation of a connection or a new connection?  If so, that would
be a reason for the MUST.  I would think the MIP-Mobile-Node-Address
would be a good indicator.  If the HA has a connection established
with the MIP-Mobile-Node-Address, then it is a continuation.

I think the MUST should be at least a SHOULD for one reason.  It will
reduce the number of STRs sent.  Every time the session-id changes
for the connection, a STR will have to be sent for the previous
session-id.  If the session-id doesn't change because of re-auth.

 > 	2) Whether AAAH must be stateful to meet the above requirement

I can think of three reasons that you would get communications for the
same connection.

1. Mobile IP Handoffs
2. Re-authorization
3. Key lifetime expiration and update.

Mobile IP Handoffs always causes generation of a new HAR session ID so
it doesn't count in the session state discussion.

If your server always gives an infinite lifetime for the authorization
and keys, then 2 and 3 shouldn't happen.  Because of this, the AAAH
should not have to keep session state.

Even if there are either re-authorizations, or key lifetime expiration
updates, I think the session id can be preserved without the AAAH
having to keep state.  This can be done with the Class AVP (section
8.20) of the base draft.  You simply send the Home agent session in a
Class AVP in your AMA.  All subsequent AMR re-auths will have to include
it and the stateless AAAH can extract the session-id and use it when
communicating with the HA.

-mark

 > 
 > In addition, it will be very helpful to the AAA server implementors if
 > we can add a section to the Diameter Mobile IP draft describing when the
 > AAA server must be stateful and when not. 
 > 
 > Thanks!
 > 
 > Joe Lau

---

From: Joe Lau <[email-masked]>
Date: Fri, 5 Oct 2001 15:57:37 -0700 (PDT)

At this point, I guess I would like to turn the table around and ask
under what situation will the AAA server (in particular the AAAH), 
MUST maintain session states.   Once we have collected sufficient
information, I recommend that we summary them in a new section on
the Diameter Mobile IP Application draft.

One question I have in mind is will the statefulness of a 
AAA server affect interoperability with other AAA server? 

Please participate, folks.

Thanks.

Joe Lau