Re: Comment on draft-giaretta-mip6-authorization-eap-01.txt

Giaretta,

Comments marked with jak>>.

>
>
> This approach seems like an architecturally sound one, and
> would work either during the initial AAA exchange or during a
> subsequent IKE exchange using IKEv2, since it gets the
> configuration information to the MN.
>
> One concern I have is that there is an AAA-HA interface
> identified in Fig. 1 between the Home AAA and the HA. This
> interface is conveniently declared out of scope for the
> document. I believe this interface needs to be defined for
> completeness. The document does provide an abbreviated
> outline about what the interface must support, in Section 6.
>

You are right, the definition of the AAA-HA interface is an important
piece of work that I think has to be done in a separate I-D. Our initial
idea was to implement this interface through a new Diameter application
(a preliminary specification of this application was included in version
-00 of the draft). However, during the last months we had a few off-line
discussions on this topic and the outcome was that Diameter may not be
the only viable solution. Another option could be the usage of SNMPv3,
as done in PANA wg for the interface between PAA and EP. Therefore,
before publishing a solution I-D I think we should agree on the
requirements and on the best approach. What do you think?

jak>> As mentioned in a previous email, I favor Radius and Diameter.

> If the V flag is intended to indicate whether
> the MN can obtain an HA address in a foreign domain, I don't
> believe the AAAH should be assigning HA addresses in the
> visited domain. Rather, I think the V flag should indicate
> that the MN can obtain an HA address, possiblity by
> contacting the AAAF. The only way I can see this work is if
> the AAAH contacts the AAAF in real time, obtains the address,
> then passes it along to the MN. That's a lot of plumbing to
> get something to the MN that it could just ask for itself. I
> can't see the AAAH storing these addresses, because, who
> knows when they may change? I think it makes more sense for
> the MN to contact the AAAF itself. But I believe 3GPP2 is
> planning on using dynamic HA assignment for MIPv4, perhaps we
> could get someone from 3GPP2 to tell us how they plan on
> doing it. Anybody from 3GPP2 want to comment?
>

I agree. The HA in the foreign domain should be assigned by the AAAF,
eventually interacting with the AAAH. But, how could the MN contact the
AAAF itself to retreive this data?

jak>> Dunno. The MIPv4 dynamic HA assignment draft also allows the initial
HA to assign the address. To do that would require protocol between the home
and foreign HA. Perhaps the NAS could handle it somehow?

          jak