Subject: [AAA-WG]: Comments on draft-mobileip-06

From: "Martin Julien (ECE)" <[email-masked]>
Date: Fri, 22 Jun 2001 18:22:09 +0200

Hi Pat,

I have a few comments on the Mobile IPv4 Application draft-06.
If you believe that some of those worth an official issue,
then let me know. I must say that it is definitely the best MIP-app
draft I've seen so far, and I'm quite happy about it. Thanks!

1) Section 1.2, on top of page 7, I was wondering if it would be better
to use the DIAMETER_ERROR_AUTH_FAILURE defined in the MIP draft,
or to re-use the one already defined in the Base draft? The one in the
Base could possibly be more generic, what do you think?

2) Section 2.1, I guess we could mention that the MN-AAA
Authentication Extension information is carried by the
(MIP-MN-AAA-Auth AVP), and that the Foreign Agent Challenge
Extension information by the (MIP-FA-Challenge AVP).

3) Section 2.1, I don't think the paragraph starting with
"If the MIP-Previous-FA-Host AVP...." is still applicable
in this draft. Can that AVP be useful at all in the current
solution proposed in the draft? At least, I don't see how
we could make use of that MIP-Previous-FA-Host AVP in the 
AAAH and the AAAF. Is it for future considerations?

Furthermore, I thought we had agreed that the User-Name
was not enough for the purpose of retrieving keys in the AAAF,
but would rather require the User-Name, the Home-Address and
the Home-Agent?

4) Section 2.1, in the message format, I am questionning the
necessity of the MIP-Previous-FA-Host and MIP-Previous-FA-Addr AVPs.

5) Section 2.2, the command-code should be 260, instead of 261.

6) Section 2.2, in the message format, should the
MIP-HA-to-FA-Key AVP be included as [], in the case where the
the Multi-Round-Auth is used?

7) Section 2.3, could we add the [MIP-Feature-Vector] as a possible
AVP of the HAR message, since I see it very useful in the case where
the AAAF needs to allocate an Home Agent in the foreign domain?

8) Section 2.4, I don't think it is very clean, with regards to the
specification, to expect that the HA will be responsible of forwarding the
Session-Timeout, the Authorization-Lifetime, the MIP-FA-to-MN-Key and the
MIP-FA-to-HA-Key AVPs in the HAA. When I see those attributes in the HAA,
I always have to remind me that they are meaningless to the HAA, but only
meaningful to make easier the conversion of the HAA into a AMA in the AAAH,
which I consider not very useful anyway, since the AAAH still needs to check
that they have been included properly. Well, my opinion is that we should
remove them from there, since they are meaningless to the AAAH that receives
the HAA. 

Also, note that the Session-Timeout AVP is {} in the HAA, but [] in the HAR, 
which seems inconsistent. What the HA is supposed to put in there if not 
received in the HAR?

9) Section 2.4, the Filter-Rule and the MIP-Foreign-Agent-Host AVPs should
be removed from the message format. They are not useful at all. Maybe they
could be in the message as *[AVP], which would mean that their presence is
not a problem, but not useful neither.

10) Section 3.1, can the HA return the DIAMETER_ERROR_HA_NOT_AVAILABLE 
when the can not provide the HA service? In that case, the AAAH, or 
the AAAF, would be responsible for allocating an other HA, if it had 
allocated it previously. That is the only reason why I would see the
DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE useful, since the AAAH changes 
the DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE into a 
DIAMETER_ERROR_HA_NOT_AVAILABLE when answering to the FA, as described 
in page 12.

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?

12) Section 4.0, the Filter-Rule AVP should be referenced to section 
4.11 instead of 4.10. It should also be of type UTF8String, instead of 
OctetString. The thing is that there are 2 sections 4.10, which should 
be corrected. Also, the MIP-Foreign-Agent-Host and MIP-Previous-FA-Host 
AVPs should be of type DiameterIdentity, instead of OctetString.

13) Section 4.7, the last paragraph, we should read "Only the AAAF may 
set the Foreign-Home-Agent-Available and Home-Agent-In-Foreign-Network 
flags to one."

14) Section 5.1, 4th par. last word, should be HAA instead of AMA.

15) Section 6.0, the MIP-Algorithm-Type and MIP-Replay-Mode AVPs should be
of type Enumeratedm instead of Unsigned32.

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?

Also, when a MIP-*-Preferred-SPI AVP is included in the AMR, I guess 
that the FA has chosen a value that what not already already by any 
of the SAs, right? The thing is that it might not know the HA yet, 
i.e. the SA.

And as another mail in the ML, I've always been wondering if ever the
preferred-HA-MN-SPI would be useful or not? From our last discussions
on the subject, I thought it would be added, but it wasn't so clear.

17) Section 10.4 is no longer needed and should be completely deleted.

18) Section 6.2.7, should the SHA-1 algorithm be also added, as in the
aaa-key-06 draft? BTW, would it be better that the values assigned to
those algorithms match between the 2 drafts? The last comment also 
applies to the Replay-Mode.

19) Section 6.1, could you please explain to me what "The Mobile IP key
described in [15] refers to the AAA SPI, which MUST be set to the value
the AAAH shares with the Mobile Node." Are we talking about a 
pre-configured shared SPI, or a secret key? Can it dynamically change
or not? It is not clear to me how the AAA SPI can help in creating the
FA or HA Security Information. Could you please tell me more?

Best Regards,
Martin

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 22 Jun 2001 14:44:19 -0700

> draft I've seen so far, and I'm quite happy about it. Thanks!

thank you!

> Base could possibly be more generic, what do you think?

I agree, and an issue should be opened. btw, it would only be
necessary to open a single issue emcompassing all of your
editorial comments (reduces the work load on both you and me (the
web page editor :)

> Extension information by the (MIP-FA-Challenge AVP).

that would be useful.

> AAAH and the AAAF. Is it for future considerations?

I am not sure. Others?

> but would rather require the User-Name, the Home-Address and

That rings a bell. I may have missed that one.

> necessity of the MIP-Previous-FA-Host and MIP-Previous-FA-Addr AVPs.

right, again, not sure. Perhaps this one should actually be a separate
issue from the editorial ones.

> the Multi-Round-Auth is used?

hmmmm.... agreed.

> the AAAF needs to allocate an Home Agent in the foreign domain?

yes, I agree.

> remove them from there, since they are meaningless to the AAAH that receives

ok. A few revisions of the base protocol base, less state was required on
the AAAH. Nowadays, though, I agree that the AAAH can easily keep this
state information (or add it to Proxy-State if it really wants to).

> which seems inconsistent. What the HA is supposed to put in there if not 

oops

> not a problem, but not useful neither.

well, we could, but it is sort-of useful to the implementor to know what
to expect in a message. I suspect that filters will unfortunately be more
frequent than we want to admit :(

> DIAMETER_ERROR_HA_NOT_AVAILABLE when answering to the FA, as described 

I would much prefer that DIAMETER_TOO_BUSY be returned by an HA to state
that it cannot handle the request, and an alternative should be assigned.
The error in question should only be used when a specific server is
requested, and it cannot be assigned.

> the AAAH or AAAF, how could that be reported?

reported by whom? The HA? Or one of the AAA servers?

> AVPs should be of type DiameterIdentity, instead of OctetString.

right, well Filter-Rule is now a sub-type, so this will change. The
references, though, do need to be fixed.

> set the Foreign-Home-Agent-Available and Home-Agent-In-Foreign-Network 

right.
> 14) Section 5.1, 4th par. last word, should be HAA instead of AMA.

correct.

> of type Enumeratedm instead of Unsigned32.

correct.

> random or not? Why can't the HA decide the SPI itself?

There's no reason why, really :(

> on the subject, I thought it would be added, but it wasn't so clear.

right, and I've agreed with that comment just minutes ago :)

> 17) Section 10.4 is no longer needed and should be completely deleted.

correct

> applies to the Replay-Mode.

yes, but it really don't matter if there isn't a match. If you think it
would be useful, include it in your issue.

> FA or HA Security Information. Could you please tell me more?

I'd love to explain it, but that would require that I first understand it :(

I believe that what I had originally intended to state here is that the
values created are used in a particular field of the MIP AAA key in [15].
This needs some major cleaning up.

Thanks,

PatC