Subject: [MOBILE-IP] Discussion: AAA Requirements

From: Basavaraj Patil <[email-masked]>
Date: Mon, 20 Dec 1999 15:27:21 -0600

My comments below:

>Hello Raj,
>
>Thanks for your note.  I agree that we have to get a new draft
>done.  I'll try to push the process some, and I volunteer to get
>all the editing done for material that is supplied to me.

Thanks for volunteering Charlie. I hope we can get enough comments to
conclusively say we have WG consensus on the requirements.

>For your points...

>>     -  There are scenarios in which an attendant will have to manage
>>        requests for many clients at the same time.
>>
>> BP> I do not see a specific AAA requirement in this statement.

>The intention was to make a scalability specification.  Can you
>suggest more effective wording?

Extrapolating on the above requirement:
       - The AAA entity serving the attendant(s) MUST be able to handle
       these requests without significant degradation of service.

>>     -  The attendant equipment should be as inexpensive as possible,
>>        since it will be replicated as many times as possible to handle
>>        as many clients as possible in the foreign domain.
>>
>> BP> Why is the attendant equipment cost a AAA requirement? Replication
>> BP> of the attendant equipment is an engineering and deployment issue.
>> BP> I disagree with this statement.

>It is possible to engineer protocols that cannot be implemented cheaply.
>For instance, one might require LDAP or full ASN.1; the intention is
>to specify that the AAA draft MUST NOT make such burdensome
>requirements.
>We want to indicate the need for a protocol that does not place
>too much burdensome state management on the attendant.

If that is indeed the message being conveyed by this requirement, then
let's make it specific to the AAA WG. Not expecting the AAA protocol
to place state management on the attendant is a valid requirement, but
equipment cost is not.

>>Assuming that you would agree with the above paragraph, then
>>I hope you can help craft a more effective statement for the
>>requirement.

I do not fully agree with the above statement. The reason I say that
is because the objective of this I-D is to provide requirements from a
Mobile IP perspective and unless we keep these requirements simple and
straightforward, we are not going to see any useful outcome from the
AAA WG.

>>     -  Attendants SHOULD be configured to obtain authorization,
>>        from a trusted local AAA server (AAAL) for Quality of Service
>>        requirements placed by the client.
>>
>> BP> Should we get into the area of QoS when defining the AAA
>> BP> requirements? It's probably best left for a later phase.

>How can we state requirements for a later phase, while not losing
>the discussion that engendered the requirement?

Maybe we can have a section in the document for requirements that
are not of immdeiate concern, but would be good to build support for
such in the protocol for later phases.

>>     -  The local AAA server MUST support anonymous access.
>>
>> BP>Can you clarify this requirement and what you are implying by
>> BP>anonymous access?
>>
>>Help from other authors/committee members?
>>
>> Section 3.1 :
>> -------------------
>>
>>     -  Support a reliable AAA transport mechanism.
>>
>> BP> This requirement is probably a generic AAA requirement and not
>> BP> necessarily specific to Mobile IP. Having this requirement and
>> BP> specifying it as a MUST is leading us nowehere.

>I think there are multiple opinions on this subject.  Perhaps someone
>would like to argue the point?

>>     -  Transport a digital certificate in an AAA message, in order
>>
>> BP> The AAA protocol MUST be capable of transporting any type of
>> BP> information. So why specify certificates as a special requirement?

>Comments, please?

>> Section 4.0:
>> -----------------
>>
>>     -  AAA servers MUST be able to identify the client by some means
>>        other than its IP address.
>>
>> BP>Since the Mobile IP WG has agreed to use the NAI as a form of
>> identifying the MN, why not state it as such in this requirement.

>This is fine with me.

>> Section 5.0:
>> -----------------
>>
>>    All needed AAA and Mobile IP functions SHOULD be processed during
>>    a single Internet traversal.  This MUST be done without requiring
>>    AAA servers to process protocol messages sent to Mobile IP agents.
>>    The AAA servers MUST identify the Mobile IP agents and security
>>    associations necessary to process the Mobile IP registration, pass
>>    the necessary registration data to those Mobile IP agents, and
>>    remain uninvolved in the routing and authentication processing
>>    steps particular to Mobile IP registration.
>>
>> BP> This section leads me to believe that you are combining AAA
>> BP> messaging with Mobile IP messages. I am of the opinion that it may
>> BP> be better to keep them separate even if it requires additional
>> BP> Internet traversals.

>Here is where I finally have a strong personal opinion.

>I believe this is where we have to be very sure to get what we
>need for performance reasons.  Causing multiple Internet traversals
>would, in my opinion, kill our chances to engineer VoIP solutions
>using Mobile IP/AAA.  Thus, I think it would be a terrific mistake
>to eliminate this requirement.

>I agree with previous opinions that give reasons to make the binding
>optional, but I know that support for the binding must be mandatory.

Having support for this in the protocol is probably okay. However
there will be different schools of thought on this item. Other comments?

>>     -  enable authentication for Mobile IP registration
>>
>> BP> Is the responsibility for authenticating a MN moved to AAA from
>> BP> the HA as per this requirement?

>The responsibility is for the AAA to do something to allow the HA
>to
>perform authentication for the mobile node's future registration
>requests.  We want to make sure that a mobile node can get an allocated
>IP address and even an allocated Home Agent; if that happens, AAA has
>to do something to make Mobile IP work.

Okay. I guess I was misinterpreting the "enable" part of this
requirement.

>>     -  use AAA protocol extensions specifically for including Mobile
>>        IP registration messages as part of the initial registration
>>        sequence to be handled by the AAA servers.
>>
>> BP> Or keep the Mobile IP messages separate. I think there has been
>> BP> some discsussion on the mailing list in favor of keeping Mobile IP
>> BP> messages independent of AAA and not having them included as
>> BP> extensions.

>Independent, yes, but sent as part of the same control transaction
>between AAAs in separate domains (thus enabling a single Internet
>traversal).
>Thus, I am specifically advocating making Mobile IP extensions for
>AAA messages.  Furthermore, I think it's the best or maybe even the
>only way to support the needs for TR45.6 architecture, as well as
>others with similar needs.

>This is the same procedure I have shown at four previous IETF meetings.
>Is it now becoming probematic?

Not really. I was just thinking of other possibilities. But in order
to move ahead with getting the requirements completed for the Jan 7th
meeting we should go ahead with this assumption. I'll send some the
discussion part of this e-mail to the Mobile IP mailing list and see
if there is any other opinion on this aspect.

>Regards,
>Charlie P.

-Basavaraj