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

From: Patrice Calhoun <[email-masked]>
Date: Tue, 10 Apr 2001 09:18:07 -0700

Just to make sure, I *presume* that this proposed text is to belong in the
Mobile IP extension, right?

PatC

ps: for those that saw my "I will not be responding to e-mail this week", I 
happen to be in a city that has metricom service :)

>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: "Fredrik Johansson" <[email-masked]>
Date: Wed, 11 Apr 2001 09:23:19 +0200

>Mobile IP extension, right?

Yes, that's correct

/Fredrik