[H.323 Mobility:] MD-110 uploaded (new messages to H.225 Anne x G)

[Jaakko Sundquist]

Hi again Martin,

My comments embedded & marked with [Jaakko:].


>         > The other question I have concerns AuthenticationRejection:
>         > Why do you reverse tunnel - that is, feed back -
> the tunneled
>         > message in the reject?
>
>         Well, this was just a thought that maybe it would be
> beneficial, if the
>         originating gatekeeper would receive the (presumably)
> same message it has
>         tunneled, so that it can make sure that the message
> indeed is the one it has
>         sent. On the other hand, since we are talking about
> communications taking
>         place through a route of trusted parties (also
> secured with H.235 methods),
>         maybe this kind of integrity check is unnecessary.
> What do you think?
>
>         Meu:> If the reverse tunnel is solely for security
> purposes, then I do not consider this useful. As you said,
> the entire authentication message including the tunneled
> message is integrity protected on a hop-by-hop basis. Due to
> the principle of chained trust in the security architecture,
> the MT can be certain that the authentication message has not
> been tampered in transit. As a conclusion, the reverse tunnel
> does not make sense from a security point of view.

[Jaakko:] I guess you're right. I'll take this away also.

>
>         I thought, that the reverse tunnel were useful
> perhaps for matching the confirmation with the request
> message. But then, some simpler means than conveying the
> entire message should be sufficient.

[Jaakko:] I also thought about this, but came to the same conclusion that it
should be the GK's responsibility to construct the GCF or RCF (or whatever)
messages to be sent to the MT based on the information received in the
AuthenticationConfirmation.

>         What about the following scenario:
>         Several MTs "attach" to the same GK. All these MTs
> are subscribed to the same AuF. Thus, the GK has several
> outstanding AuthenticationRequests issued for each MT. How
> does the GK associate the related AuthenticationConfirmation then?

[Jaakko:] The purpose of the destinationInfo field is to indicate to which
User's authentication the message is related. Now, thinking of this, I think
the field shouldn't be optional, so I'll make a correction here also.

>         > Finally a general question:
>         > Once there was a discussion that Annex G not only be used
>         > among Border elements as currently defined in the
> H.225 Annex
>         > Gv1 scope, but to extend its usage for mobility purposes. If
>         > this were true, then Annex G could be applied also between
>         > the GK-VLF/BE and between HLF/BE-AuF. What is the current
>         > status of that discussion?
>
>         I guess this issue hasn't been throughly discussed
> yet. My personal opinion
>         is that we should extend the usability of the H.225
> Annex G protocol also to
>         other functional entities besides the BE. On the
> other hand, I would be
>         quite happy also, if we would limit the first version
> of H.323 Annex H by
>         not handling all the interfaces in the architecture
> diagram and concentrate
>         on the VLF - HLF -interface (with or without BEs)
> instead. The reason for
>         the latter argument is that I would assume that
> implementors might be quite
>         happy with co-located functional entities so that
> they would have a
>         GK/VLF/BE and HLF/AuF/BE elements, thus necessitating
> only the mentioned
>         VLF/BE - HLF/BE network interface.
>
>         Meu>: this could simplify things a lot!

I'll include the proposition for only defining this one interface in the
first version of the annex in my contribution "Changes to H.323 Annex H".

Thanks again for the mails, this discussion has rendered the contribution
much better already.

-Jaakko

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com