Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP

From: "Fredrik Johansson" <[email-masked]>
Date: Tue, 10 Apr 2001 13:50:47 +0200

true, or at least partly, I don't believe there is anything in the standard
that prevents it from being done, it's just a matter of describing it
clearly enough so that we all can be interoperable.

I'm in the process of reading the new drafts and will try to come up with
some clarifying text

/Fredrik

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On Behalf
>Of Martin Julien (ECE)
>Sent: den 10 april 2001 12:09
>To: Martin Julien (ECE); 'Fredrik Johansson'; 'Tony Johansson'
>Cc: 'Patrice Calhoun'; 'AAA Listan'
>Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>
>
>It remains that the Session-ID and the Accounting issues
>related to a MN roaming between FAs are not resolved yet, right?
>
>> -----Original Message-----
>> From: Martin Julien (ECE)
>> Sent: Tuesday, April 10, 2001 11:10 AM
>> To: 'Fredrik Johansson'; Martin Julien (ECE); Tony Johansson
>> Cc: 'Patrice Calhoun'; AAA Listan
>> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>>
>>
>> Cool! I was about to send you something very similar to know
>> if it was what you meant in your previous mail.
>> I agree with your solution. Thanks!
>>
>> > -----Original Message-----
>> > From: Fredrik Johansson [mailto:[email-masked]]
>> > Sent: Tuesday, April 10, 2001 10:27 AM
>> > To: Martin Julien (ECE); Tony Johansson
>> > Cc: 'Patrice Calhoun'; AAA Listan
>> > Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>> >
>> >
>> > After a closer look at the problem we have a suggestion on
>> a solution.
>> > If the AAAH always assigns a SPI that is unique in the HA for
>> > the FA-HA key,
>> > and a SPI that is unique in the Mn for the MN-FA and MN-HA keys, the
>> > security contexts will automatically be unique in every SA.
>> >
>> > 7.5 SPI Allocation
>> >   To ensure that the SPI is unique for each pair of nodes,
>> >   the AAAH SHOULD keep track of assigned SPIs per HA and MN.
>> >   The SPI assigned to the MN-FA key MUST be allocated from
>> > the MN SPI pool,
>> >   the SPI for the FA-HA key MUST be allocated from the HA SPI
>> > pool, and the
>> >   SPI for the MN-HA key MUST be allocated from the MN SPI
>> > pool. Note that
>> >   SPI values 0 through 255 are reserved and MUST NOT be used in any
>> >   Mobility Security Association.
>> >
>> > /Fredrik
>> > >-----Original Message-----
>> > >From: [email-masked]
>> > [mailto:[email-masked]]On Behalf
>> > >Of Fredrik Johansson
>> > >Sent: den 10 april 2001 08:40
>> > >To: Martin Julien (ECE); Tony Johansson
>> > >Cc: 'Patrice Calhoun'; AAA Listan
>> > >Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>> > >
>> > >
>> > >>
>> > >>> >>
>> > >>> >> Another thing that needs some clarification, if there is a
>> > >>> solution. How
>> > >>> >> will the HA know which SA to use. In the case where a mobile
>> > >>> >moves from one
>> > >>> >> Fa to another under the same administrative domain it may
>> > >>> receive the
>> > >>> >> session keys for the old Fa from the AAAF. It will
>> then proceed
>> > >>> >to send the
>> > >>> >> mip reg req to the HA. The HA will see that the message came
>> > >>> >from the new FA
>> > >>> >> and try to locate the SA shared with that FA. It
>> will not find
>> > >>> >it since it
>> > >>> >> was established with the old FA. Eventhough the HA can see
>> > >>> the address of
>> > >>> >> the old Fa in the previous-fa-XXXX it is not clear
>> that it can
>> > >>> >establish a
>> > >>> >> SA with the new Fa because it has to use the same
>> SPI as before
>> > >>> >and that one
>> > >>> >> might be busy. Or have I missed something here?
>> > >>> >
>> > >>> >You also have the user NAI in the MIP registration
>> > request sent to
>> > >>> >the HA and
>> > >>> >the user NAI is globally unique....
>> > >>>
>> > >>> Yes, but this is not the security association shared with the
>> > >>> mobile node
>> > >>> but the one shared between the FA and HA, thus has nothing to
>> > >>> do with the
>> > >>> user.
>> > >>
>> > >>I think you are assuming that there exists only 1 mobility
>> > SA between
>> > >>a FA and a HA for all the MIP sessions, right?
>> > >
>> > >YES, one mobility SA, ceveral security context within a mobility
>> > >SA. See rfc
>> > >2002,
>> > >
>> > >"Mobility Security Association
>> > >               A collection of security contexts, between a pair
>> > >               of nodes, which may be applied to Mobile IP protocol
>> > >               messages exchanged between them.  Each
>> > context indicates
>> > >               an authentication algorithm and mode
>> (Section 5.1), a
>> > >               secret (a shared key, or appropriate public/private
>> > >               key pair), and a style of replay protection in use
>> > >               (Section 5.6)."
>> > >
>> > >Each context is indexed with a unique SPI within that SA, if
>> > there exist a
>> > >SA between the HA and the old FA and one SA between the HA
>> > and the new FA
>> > >there might exist security context with the same SPI in both
>> > of these.
>> > >
>> > >"Security Parameter Index (SPI)
>> > >               An index identifying a security context
>> between a pair
>> > >               of nodes among the contexts available in
>> the Mobility
>> > >               Security Association.  SPI values 0 through 255 are
>> > >               reserved and MUST NOT be used in any
>> Mobility Security
>> > >               Association."
>> > >
>> > >>When a first AMA is received
>> > >
>> > >I guess you mean AMR :-)
>> > >
>> > >>in the AAAH from a MN, is the AAAH supposed to issue a new
>> > registration
>> > >>FA-HA key, in the case the HA is in the home domain? The
>> > spec says "yes",
>> > >>if it is required by the MN. However, how can the MN know
>> about the
>> > >>mobility SA between the FA and the HA? I guess it can not,
>> > which means
>> > >>that it will ask for a new key, which should be transferred
>> > to the FA and
>> > >>the HA from the AAAH. Is there a way for the HA to notify the AAAH
>> > >>that it does not need
>> > >>a new key and a new SPI for its mobility SA with the FA, since it
>> > >>already has one? I guess
>> > >>not, right? Then, it looks like your idea could be very
>> > interesting, but
>> > >>I don't know how to deal with it using Diameter, unless the
>> > AAAH and AAAF
>> > >>would keep a list of mobility SAs between each FA and HA.
>> > >
>> > >In some way the AAAH must keep track of what SPIs it has
>> > assigned to the
>> > >home agent, if it does it per SA or make the SPI unique over all
>> > >SA's in the
>> > >HA is up to the implementation
>> > >
>> > >>
>> > >>> You can not guarantee that a security between the HA and
>> > the old FA is
>> > >>> unique between the HA and the new FA. The same SPI must be
>> > >>> used in the first
>> > >>> request in order for the HA to be able to distinguise between
>> > >>> different
>> > >>> security contexts it shares with the FA. What we can do is to
>> > >>> have the new
>> > >>> FA add a <MIP-Preferred-SPI Ext> in the first request from
>> > >>> the new FA to the
>> > >>> HA, the HA can then use the <Previous-FA-XXXX Ext> together
>> > >>> with the old SPI
>> > >>> to retreive the context and store it under the Preferred SPI
>> > >>> under the SA
>> > >>> with the new FA.
>> > >>
>> > >>I was wondering whether or not a mobility SA between a FA
>> > >>and a HA was based on a particular MIP session? My understanding
>> > >>_IS_ that an existing SA is based on a MIP session. That means
>> > >>that between a FA and a HA, there exists several mobility SAs
>> > >>depending on each MIP session.
>> > >
>> > >No, there is only one SA between two nodes, but there are
>> > several security
>> > >context within each SA. Each security context can
>> > corresponde to a mip
>> > >session. It is the security context that has a lifetime, the
>> > SA can be
>> > >removed when the last security context is removed.
>> > >
>> > >>By MIP session, I mean an AAA
>> > >>authorized session for MIP. The SPI is already included in the
>> > >>key transferred between the AAAF and the new FA. I don't see
>> > >>why a HA could not use the SPI stored under its MN User-Name
>> > >>state to retrieve the mobility SA between the new FA and itself?
>> > >
>> > >Because the SA between the FA and HA does not realy have anything
>> > >to do with
>> > >the Mn. It is something setup between the FA and HA. Thus
>> > when the HA will
>> > >look for the key to use it will do the lookup on the FA address.
>> > >
>> > >/Fredrik
>> > >
>> > >>
>> > >>Regards,
>> > >>Martin
>> > >
>> >
>>

---

From: "Martin Julien (ECE)" <[email-masked]>
Date: Tue, 10 Apr 2001 12:09:03 +0200