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

From: Tomas Goldbeck-Löwe (ERA) <[email-masked]>
Date: Mon, 9 Apr 2001 15:51:22 +0200

> >
> > 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....
> 

...but the SA between the HA and the FA doesn't necessarily have to be connected to the user NAI.
I agree with Fredrik that this is an issue.

Regards,
	--> Tomas

---

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

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
> >
> >
> >>
> >>> >>
> >>> >> will the HA know which SA to use. In the case where a mobile
> >>> >moves from one
> >>> >> 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
> >>> >> 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
> >>> >You also have the user NAI in the MIP registration 
> request sent to
> >>> >the HA and
> >>> 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 09:06:03 -0700

>> 11.7  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.
>
>Maybe it just needs to be clarified that the Original-Session-Id AVP MAY be
>sent
>in a message of type Response or Answer from a AAA (like the AAAF or the AAAH)
>server that already has a valid session identifier for the user, and wishes to
>keep the existing Session-Id.

Such text will be present in -03.

PatC

---

From: "Martin Julien (ECE)" <[email-masked]>
Date: Wed, 18 Apr 2001 14:52:23 +0200

In the case where the MN is roaming within a foreign domain,
a Registration is sent and an AMR is be sent to the AAAF. Then the
AAAF returns the keys to the new FA without authenticating
the MN. That seems to be a "problem". However, if it would reach 
the Home server, then the MN could be authenticated based on
the MIP-MN-AAA-Auth AVP, which could decide if it is a valid
request for reporting a roaming situation.

Then, should we define a new MIP-MN-AAAF-Auth AVP?, or should every 
registration reach the Home server each time?

Martin

> Sent: Wednesday, April 18, 2001 1:26 PM
> To: Martin Julien (ECE); [email-masked]; Tony Johansson
> Cc: AAA Listan
> Looks like it would work, the only question is what happens 
> when a second MN
> tries to register with the same Nai, home address and home 
> agent address?
> 
> /Fredrik
> 
> >
> >Ok, let me try again.
> >
> >More than one session need to be supported for each MIP user, which
> >means that a user might want to register several MNs on the
> >network at once.
> >That would lead to several separate MIP sessions in the Home 
> server. AFAIK,
> >each MIP session can be uniquely identified by using both its Home
> >Agent address
> >and its Home address. We could also add the User-Name, to 
> easily link all
> >sessions for a particular user. That means that each MIP 
> session would be
> >keyed on User-Name, Home Agent and Home Address. That takes 
> into account
> >private addresses as well.
> >
> >Then a first MN registers with a User-Name. Since it is the first
> >registration in a foreign domain, then no 
> MIP-Previous-FA-XXXX is present,
> >neither Home Agent nor Home address. Then the FA creates a 
> new Session-ID,
> >which is sent to the AAAF, which forwards it to the Home 
> server, since
> >it is the MN's first registration. Then the MN is registered 
> successfully.
> >
> >Then the MN moves to a new FA within the same domain. The MN 
> will send the
> >User-Name, the Home Agent and Home address, along with the
> >MIP-Previous-FA-XXXX.
> >Then the new FA will send the AMR to the AAAF, which will check if
> >there is
> >any existing session linked to a similar registration, based on the
> >User-Name, the Home Agent and Home address. Since there is, the
> >AAAF returns
> >the Original-Session-ID, along with the FA keys.
> >
> >I guess that the same could apply when the node moves to a 
> third domain, in
> >which case it would be the Home server that would be responsible
> >of returning
> >the Original-Session-ID and FA keys. The same for moving to its
> >Home domain.
> >
> >If there is a second MN that registers for the same user, 
> then it would
> >register without a Home Agent and Home Address. Or if it 
> does, I guess
> >that the Home address should be already defined as unique for that
> >particular MN, right? That means that a new session would be created
> >by the new FA, which would trigger a new session in the Home server.
> >That new session would be uniquely identifiable by the User-Name,
> >the Home Agent and the Home address of the MN.
> >
> >If ever we need to control
> >the number of allowed sessions per user, the Home server can 
> reject the
> >AMR when it receives a new registration request from a new MN.
> >
> >Does that make a bit more sense?
> >
> >Martin
> >
> >> Sent: Tuesday, April 17, 2001 4:53 PM
> >> To: Martin Julien (ECE); [email-masked]; Tony Johansson
> >> Cc: AAA Listan
> >> Hi Martin,
> >> How would generating a session id from User-Name and
> >> MIP-Previous-FA-XXXX
> >> help you to have several MIP sessions for the same user if the have
> >> different MNs? The user may still use the same User-Name on
> >> all of its MNs,
> >> thus causing the same session id to be created.
> >>
> >> So, I don't believe it will solve the problem. If it is a
> >> problem that you
> >> cannot have several session with the same nai, isn't that 
> one of the
> >> problems with radius that there is no way to limit a user
> >> from login in
> >> from several places at the same time using the same user name
> >> and password?
> >>
> >> /Fredrik
> >>
> >> >
> >> >Hej Fredrik,
> >> >
> >> >If the Session-ID would be generated and handled by the MN, I
> >> >guess it would be a lot easier. At least, we could propose a way
> >> >of generating a Session-ID in the FA, such as the concatenation of
> >> >the User-Name and the Care-Of address (FA), which would lead to a
> >> >predictable Session-ID. In the case where the MN would move to a
> >> >new FA, then the new FA would need to generate a Session-ID based
> >> >on the User-Name and the MIP-Previous-FA-XXXX. Would that make any
> >> >sense? Then, I guess we could have several different MIP sessions
> >> >for the same User, as long as it is using different MNs. To
> >> >support more than one session per MN, I guess the MN would need to
> >> >include additional info about that.
> >> >
> >> >We are having the same kind of problems WRT SIP, I believe.
> >> >
> >> >Martin
> >> >
> >> >> From: Fredrik Johansson 
> [mailto:[email-masked]]
> >> >> Sent: Tuesday, April 17, 2001 3:01 PM
> >> >> To: [email-masked]; Martin Julien (ECE); Tony Johansson
> >> >> Cc: AAA Listan
> >> >> 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.
> >> >>
> >> >> 11.7.1  Original-Session-Id AVP
> >> >>
> >> >>    MAY be sent in a message of type Response or Answer 
> if the AAA
> >> >>    old session. Any message not using the Session Id in this
> >> >> AVP will be
> >> >>    treated as an unrecognized Session Id.
> >> >>
> >> >> 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
> >> >> >>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
> >> >> >>
> >> >> >>>Of Patrice Calhoun
> >> >> >>>Sent: den 11 april 2001 19:32
> >> >> >>>To: Fredrik Johansson; Martin Julien (ECE); Tony Johansson
> >> >> >>>Cc: AAA Listan
> >> >> >>>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 :)
> >> >> >>>>>
> >> >> >>>>>>> From: Fredrik Johansson
> >> >> [mailto:[email-masked]]
> >> >> >>>>>>> After a closer look at the problem we have a
> >> suggestion on a
> >> >> >>solution.
> >> >> >>>>>>> >>> >> session keys for the old Fa from the 
> AAAF. It will
> >> >> >>then proceed
> >> >> >>>>>>> >>> >to send the
> >> >> >>>>>>> >>> >> 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
> >> >> >>>>>>> >>if it is required by the MN. However, how can 
> the MN know
> >> >> >about the