[H.323 Mobility:] questions on MTD-016

[Roy, Radhika R, ALARC]

Hi, Vineet and Steve:

I like to add couple of points with respects to your emails as follows:

HLF:

It is interesting to note that there appears to be an "implicit" assumption
that there is only one HLF in a domain (no matter what happens in the
future).

Let us NOT make our protocol "hard-wired" like this.

The protocol should be flexible enough to accommodate one or multiple HLFs
in a domain.

If one wants to choose one HLF per domain, it MUST be left as an
implementation issue, NOT a protocol issue.

Home GK:

In the same token, if one wants to declare a GK as its home GK, this option
MUST be provided to a user. It is a choice that MUST be given to a user. If
anyone does NOT like this option, they MAY not use it.

Home Network/Network Address:

In the same token, if anyone wants to declare a network address as its home
network, this option MUST also be provided.

GK Discovery:

The "old" inefficient GRQ discovery mechanisms may not be the only OPTION to
discover the GK. in a highly mobile cellular environment. An alternative
mechanism, like MGA message can be listened to discover the GK as well.

Best regards,
Radhika R. Roy

> -----Original Message-----
> From: Kumar, Vineet [SMTP:vineet.kumar at INTEL.COM]
> Sent: Thursday, April 13, 2000 4:34 PM
> To:   ITU-SG16 at MAILBAG.INTEL.COM
> Subject:      Re: [H.323 Mobility:] questions on MTD-016
>
> Steve,
>
> Thanks for your reply. My comments are embedded in the email below.
>
> vineet
>
> -----Original Message-----
> From: Stephen Terrill [mailto:stephen.terrill at ERICSSON.COM]
> Sent: Thursday, April 13, 2000 4:42 AM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: [H.323 Mobility:] questions on MTD-016
>
>
> Hi,
>
> I shall try to answer some of these questions below.
>
> Regards,
>
> ..//steve
>
>
>
> "Kumar, Vineet" wrote:
>
> > Stephen,
> >
> > I have a couple of questions on your contribution MTD-016. These are:
> >
> > 1. H.323 already has mechanisms for discovering the gatekeeper. Are you
> suggesting in your contribution that the terminal should discover the VLF
> instead of the visiting gatekeeper ? Or, are you assuming that the VLF is
> integrated in the visiting gatekeeper ?
>
> This can be discussed - I was of the opionion that we should discover the
> VLF and send the registration to the home environment after that.
> However,
> we haven´t agreed on the role of the VLF, and visited gatekeeper, home
> gatekeerp and HLF - when we come to agree on what these are, my proposal
> may
> change.
>
> <vineet:begin> Yes, this could be discussed in the conference call. My
> suggestion is to reinvent as less as possible. Since we are adding
> Mobility
> to H.323, we should just fill in the gaps that are missing.
> <vineet:end>
> >
> >
> > 2. In H.323, authentication of the terminal and the gatekeeper is done
> at
> the time of discovery. In fact, in H.323 all messages between the terminal
> and the gatekeeper can be authenticated and the message integrity
> preserved.
> In your contribution, authentication is done at the time of registration.
> Why is this preferable to what is already in H.323 ?
>
> I would be interested to understand which gatekeeper you were considering
> should do the authentication.  I would assume that the real authentication
> would have to be done at home - as such it would be necessary to find the
> visited network services, and then register/authenticate at home.
>
> <vineet:begin> I agree with your model but my preference is to preserve
> the
> way H.323 works today in that the authentication of both the user (not
> terminal) and the gatekeeper (doesn't matter whether the gk is visisted or
> home) can be done at the time of discovery. The protocol between the
> terminal and the gk does not change regardless of whether it is the home
> gk
> or the visited gk. The terminal sends its hashed password or certificate
> in
> the cryptotoken field of the GRQ message. The visisted gk tunnels the
> entire
> message to the terminal's Home Administrative Domain for authentication
> and
> authorization. There may be an Authentication Function in the Home
> Administrative Domain that authenticates its users. If the user is
> successfully authenticated by the Home Administrative Domain then a new
> temporary password is assigned by the Home Administrative Domain to the
> terminal and the visited gk in GCF for use during that session. This
> exchange is explained in detail in the contribution I made for the last
> conference call. I can't find the MD #. Does anyone know the MD # ?
> <vineet:end>
> >
> >
> > 3. What is the reason for the information flow from the HLF to the home
> gatekeeper, and from the home gatekeeperr to the HLF ? I don't think we
> can
> assume that there is only one home gatekeeper that the terminal may be
> using. In fact, the home gatekeeper may not have any information about the
> user.
>
> I certainly don´t assume that there is only one home gatekeeper.  I assume
> that there will be a number of home gatekeepers, but perhaps only one (or
> few) HLFs.  In this case, we need an function to select the gatekeeper
> that
> the user is going to camp on - and this may depend on load, subscriber
> profile, policy - or a lot of things.
>
> <vineet:begin> I guess I will have to understand the model that you have
> in
> mind regarding the use of a home gk on which the terminal camps on. In my
> model the HLF will send all pertinent information about its user to the
> VLF.
> The home gk is not needed.
> <vineet:end>
> >
> >
> > Regards,
> > vineet