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

From: "Fredrik Johansson" <[email-masked]>
Date: Thu, 12 Apr 2001 10:04:20 +0200

No, no additional AVPs is required. However, I believe some explanations
should be provided on how to treat the  request in different nodes. I'll
give you some text after the weekend that hopefully will give you some ideas
what I mean. Untill then I will enjoy a couple of days skiing :-)

/Fredrik

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On Behalf
>Of Patrice Calhoun
>Sent: den 11 april 2001 19:32
>To: Fredrik Johansson; Martin Julien (ECE); Tony Johansson
>Cc: AAA Listan
>Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>
>
>and no additional protocol text (read AVPs) is required???
>
>PatC
>>>
>>>Just to make sure, I *presume* that this proposed text is to
>belong in the
>>>Mobile IP extension, right?
>>
>>Yes, that's correct
>>
>>/Fredrik
>>
>>>
>>>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: Patrice Calhoun <[email-masked]>
Date: Wed, 11 Apr 2001 10:31:57 -0700

PatC
>>
>>Just to make sure, I *presume* that this proposed text is to belong in the

---

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

Hi Pat,

here is the suggested text as promised.

11.7  Session Movement

   When a user moves between different access devices it may be desirable
   to keep the Session Id unchanged. It is therefore possible for a
   server to send the original Session Id back to the requester in the
   Original-Session-Id AVP. If the AAA server already has a
sessionidentifier

11.7.1  Original-Session-Id AVP

   The Original-Session-Id AVP (AVP Code 261) is of type OctetString and
   MAY be sent in a message of type Response or Answer if the Home AAA
   server already has a session identifier for the user, and wishes to
   keep the existing Session-Id. All further messages from the Access
   Device for this session MUST use the session identifier in this AVP.
   This shouldn't be viewed as a new session, but rather renaming the
   old session.

11.8  Session Termination

   The Diameter Base Protocol provides a set of messages that MUST be
   used by any peer to explicitly request that a previously
   authenticated and/or authorized session be terminated. Since the
   Session-Id is typically tied to a particular service (i.e. Mobile IP,
   NASREQ, etc), the session termination messages are used to request
   that the service tied to the Session Id be terminated.

>Sent: den 12 april 2001 10:04
>To: [email-masked]; Martin Julien (ECE); Tony Johansson
>Cc: AAA Listan

---

From: "Fredrik Johansson" <[email-masked]>
Date: Tue, 17 Apr 2001 15:01:01 +0200

Ok, let's see if I can write the entire message this time before sending it
:-)
There might be a problem with the possiblity to reuse the old session id,
and
that is that there can only be one session per user. I don't know if this
limitation
is to harsh.

/Fredrik

11.7  Session Movement

   When a user moves between different access devices it may be desirable
   to keep the Session Id unchanged. It is therefore possible for a
   server to send the original Session Id back to the client in the
   Original-Session-Id AVP. An old session is identified by the User Name
   Nai.

   The Original-Session-Id AVP (AVP Code 261) is of type OctetString and
   MAY be sent in a message of type Response or Answer if the AAA
   server already has a session identifier for the user, and wishes to
   keep the existing Session-Id. All further messages from the Access
   Device for this session MUST use the session identifier in this AVP.
   This shouldn't be viewed as a new session, but rather renaming the
   old session. Any message not using the Session Id in this AVP will be
   treated as an unrecognized Session Id.

11.8  Session Termination

---

From: "Fredrik Johansson" <[email-masked]>
Date: Tue, 17 Apr 2001 16:55:12 +0200

Hi,

Here's some additional text that tries to describe the problem,
that might provide some hints on what can be included in the
MIP extension draft.

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.

7.6 Retreiving Mobility Session Keys from AAAF

  In the case that a user moves between two FAs under the
  same administrative domain it may be possible for the AAAF
  to distribute the mobility session keys for the old FA to
  the new FA. To do this the client will send an AMR to the
  AAAF with the Previous-FA-FQDN or Previous-FA-Address AVP.
  AAAF will retreive the keys based on the User-Name NAI and
  the information about the previous FA and send them back
  to the client in an AMA. The AMA will also include the
  MIP Registration Request AVP to indicate to the client that
  it need to forward the request directly to the HA in order
  to update the mobile ip tunnel.

7.6.1 Home Agent Behaviour

  The HA will use the SPI to understand what key to use when
  authenticating the received registration request. Since the
  request is received from a new FA but with the SPI used with
  the old FA the HA will not find the Security Context. Thus
  the search sequence of the HA must be extended to handle this
  scenario. If the HA failes to find a Security Context when it
  looks in the Mobility Security Association it shares
  with the sending node, it MUST look for a Previous-FA-FQDN or
  Previous-FA-Address extension in the request. If one is
  available it must look for the Security Context under the
  previous FA mobility SA and copy it to the new SA.

/Fredrik

>Sent: den 17 april 2001 15:01