Subject: RE: [AAA-WG]: Issue 91: MIP SPI

From: "Martin Julien (ECE)" <[email-masked]>
Date: Thu, 28 Jun 2001 10:52:27 +0200

See comments.

> > > > 11) If there is a problem in the HA or FA with the SPI 
> generated by
> > > > the AAAH or AAAF, how could that be reported?
> > >
> > > reported by whom? The HA? Or one of the AAA servers?
> > >
> > > > 16) Whenever no MIP-*-Preferred-SPI AVP is included in 
> the AMR, can we
> > > > assume that the SPI generated by the AAAH or AAAF can 
> be completely
> > > > random or not? Why can't the HA decide the SPI itself?
> > >
> > > There's no reason why, really :(
> > 
> > I'm still not quite sure to get the complete picture of how 
> the SPI should
> > be
> > handled in the AAA servers. Are we expecting the AAA 
> servers to use the
> > standard 0-255 SPI defined by IANA?, or are the AAA servers 
> expected to
> > handle to concept of SA, which normally contains and 
> defines their own
> > SPI values?
> 
> yes, the AAA creates the SPI values used for an SA. The SPI 
> number provided
> in the *Preferred-SPI AVPs are recommendations from the 
> Diameter agents on
> what values they'd like to see, to minimize the possibility 
> of conflict.
> However, the SPI address space is 32bits long, and therefore 
> clashes should
> be minimal. 

So, if I understand correctly, you are suggesting that the AAA
re-use the Preferred-SPI received in the AMR, right? In the case,
they are not received, then the AAA should generate a random 
32bits long SPI outside the range of the reserved SPI by IANA, right?

The problem here is that we are assuming that we are lucky enough to
not re-use an already defined SPI between the HA-FA, HA-MN and FA-MN.
I must admit that the chance is not great, but still there, unnecessarily.

> To address your other question, no we do not touch the 
> reserved SPIs defined by
> IANA.

OK, then the SPI MUST be outside the range of pre-defined SPIs
from IANA. Can you make that clear in the draft?

> > The thing is
> > that if Diameter needs to support the concept of SA, then 
> it seems to
> > be difficult for the AAA server to select an SPI on behalf 
> of the MN, the HA
> > and the FA.
> 
> but the MN provides its preferred SPI in the Generalized Key 
> Ext, and the FA
> provides its own in the MIP-FA-Preferred-SPI AVP. The Home 
> Agent is the only
> sticky point, and if the AAAH picks one that causes a 
> conflict on the HA, an
> error would be returned, which could include a new SPI, I 
> suppose. The AAAH
> would then try again. I suppose this is what needs to be documented.

Yes, that's my point. How can we inform the AAA that the chosen SPI
is already in use?

The easy solution would be to leave that selection of the SPIs to
the HA, since the AAA does not really care about it. In fact, the AAA
can still put everything it requires for security, in terms of algorithms,
replay-mode, key material, but should not care about the SPI. That would 
mean that the HA would become responsible for looking at the Registration
message, extract the Preferred-SPI itself from the MN, and select the SPI and create
a new one. The thing is that the HA is the one that owns the SA with the
MN and the FA, right? I don't see the point for the AAA to take a chance 
by chosing one that can possibly not be a valid one for the HA's SAs?

That means that HA would be responsible of the SPI field of the 
"Unsolicited MN-HA Key from AAA Subtype" and the "Unsolicited MN-FA Key 
from AAA Subtype". The Preferred-SPI AVPs would become obsolete, since
the HA could extract directly that information from the Registration 
message. Furthermore, the FA does not need to suggest an SPI, since the
HA would know the SPI available for the SA with the FA, if it receives
the MIP-Foreign-Agent-Host AVP. The HA would need to return the selected
SPIs for the FA-HA and the FA-MN Session key AVPs, so that the AAA can return
them to the FA in a secured manner, if required.

Does that make sense or not?

> > Of course, the AAA can count on the Preferred-SPI from the FA
> > and the MN, in which case the AAA simply agrees with the 
> value. However,
> > if there is no Preferred-SPI AVPs in the AMR, then the AAAH needs to
> > generate
> > them, at the risk that they might already be used in the SA 
> defined between
> > the MN and the HA, or between the HA and the FA, or between 
> the FA and the
> > MN.
> > I think that it makes more sense for the HA to select the 
> required SPI
> > between
> > the HA-MN and HA-FA, if no Preferred-SPI is included in the AMR.
> 
> No, IMHO, if not Preferred-SPI is present, then no key is 
> generated. So,
> perhaps some associated text in the Feature-Vector is needed?

That seems to contradicts what you were saying earlier about the
need for the AAA to generate new SPIs, right?, or am I understanding
you wrong?

> PatC

Martin

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 28 Jun 2001 06:33:04 -0700

> 32bits long SPI outside the range of the reserved SPI by IANA, right?

correct

> I must admit that the chance is not great, but still there, unnecessarily.

Well, we have to play a probability game here, but with 2^32, the chances
are quite small, even more so if one actually binds the SPI to the destination
address.

> from IANA. Can you make that clear in the draft?

ok.

> by chosing one that can possibly not be a valid one for the HA's SAs?

This is a possibility.

> Does that make sense or not?

ok, so the Diameter draft could state that the AAAH still inserts an SPI, but
the HA is allowed to override that value if it is deemed necessary. Would this
work?

> need for the AAA to generate new SPIs, right?, or am I understanding

Not sure. I think that the Preferred-SPIs MUST be present for key request,
since the SPIs are present in the MIP Key Request extension, so it is 
trivial for an FA to include these values in the Diameter message. I think
that we should mandate that the FA include these values. What do you think?

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 28 Jun 2001 17:26:25 -0700

> > from IANA. Can you make that clear in the draft?

I have added a sentence to the end of the paragraph below:

6.2.5  MIP-Peer-SPI AVP

   The MIP-Peer-SPI AVP (AVP Code 342) is of type Unsigned32, and
   contains the Security Parameter Index to use to reference the key in
   the associated MIP-Session-Key AVP. The SPI created MUST NOT be a
   value between zero (0) and 255, which is the reserved namespace
   defined in [4].

> the HA is allowed to override that value if it is deemed necessary. Would this

But if the HA doesn't like the SPI assigned for the FA-HA, how could it 
change the SPI and inform the AAAH? I believe that if the HA could simply
refuse the request with an error such as "BAD SPI", and include the
Peer-SPI in an AVP, then the AAAH could try again with a new SPI. This
would lead to multiple round trips between the AAAH and the HA when such
an error occurs, but again, the probability is quite low, considering we
have 2^32 to play with (and SPIs are bound to destination addresses).

> that we should mandate that the FA include these values. What do you think?

I have added sentences to the end of all of the following paragraphs:

4.7  MIP-Feature-Vector AVP

   [...]
   Whenever the Foreign Agent sets either the Mobile-Node-Home-Address-
   Requested flag or the Home-Agent-Request flag to one, it MUST set the
   MN-HA-Key-Request flag to one. The MN-HA-Key-Request flag is also set
   to one if the mobile node includes a Generalized MN-HA Key Request
   [15] extension, with the subtype set to AAA. If set, the MIP-MN-HA-
   Preferred-SPI AVP MUST be present.

   If the mobile node includes a Generalized MN-FA Key Request [15]
   extension with the AAA subtype in its Registration Request, the
   Foreign Agent sets the MN-FA-Key-Request flag to one in the MIP-
   Feature-Vector AVP. If set, the MIP-FA-MN-Preferred-SPI AVP MUST be
   present.

   [...]
   If the Foreign Agent's local policy allows it to receive AAA Session
   Keys, and it does not have any existing keys with the Home Agent, it
   MAY set the FA-HA-Key-Request flag. If set, the MIP-FA-HA-Preferred-
   SPI AVP MUST be present.

and just for clarity, I have added a sentence to the end of the paragraph:

6.5  MIP-MN-HA-Preferred-SPI AVP

   The MIP-MN-HA-Preferred-SPI AVP (AVP Code 323) is of type Unsigned32
   and is sent in the AA-Mobile-Node-Request by the Foreign Agent. The
   AVP contains the SPI that the Mobile Node would prefer to have
   assigned by the AAAH in the MIP-MN-to-HA-Key AVP, taken from the
   Generalized MN-HA Key Request [15] extension.

Is this better?

PatC