Subject: [AAA-WG]: SPI Allocation

From: Pat Calhoun <[email-masked]>
Date: Mon, 30 Apr 2001 10:09:50 -0700

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

Keep in mind that the above text requires that the AAAH maintains
SPI state for all devices, and there will be plenty of devices.

Furthermore, this doesn't scale well when there are many AAAHs
in the network providing services to the HAs. The AAAHs would have
to replicate their SPI state information. There has got to be a
better way....

I believe that if the MN provides what it prefers, and the FA does
the same, then the AAAH would provide the "desired" SPIs to the HA,
which has the option of sending back an error to the AAAH if the
SPI in question doesn't work. So the AAAH could try again.

Also, some text on the randomness of SPI values would be a good
addition to the extension.

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

If a Registration Request is included, then I would MUCH prefer
that we simply do away with retrieving local keys, and always
require a full round trip. This would really simplify the AAAF,
and reduce the amount of state on that box.

However, if and when optimized solutions are developed in Mobile IP
to handle local mobility (e.g. LMMs), then this problem isn't that
bad because the higher level agents could be the ones that communicate
with the Diameter infrastructure, reducing the cases where AAA is 
involved.

Also, if and when Context Transfer occurs, the AAA session identifier
(and other interesting AAA stuff) could be transfered. So I am wondering
that given the work ongoing in other Working Groups, how much of it
does AAA have to handle? I would much prefer to eliminate features that
are difficult to handle.

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

ok, something similar to the above is probably a good idea.

PatC