H.323 Security Issues
avikal at USA.NET
Mon Jan 18 13:41:33 EST 1999
The problem is that it is a _client_ issue as much as a GK issue. The
(enterprise) site administrator, wants to be assured that no rougue client
will get on the network and simple start conferencing... If he has
'compliant' stacks than he can be assured that GK policy will be followed....
At 05:59 PM 1/18/99 -0000, you wrote:
>Surely this could be left as a configuration option for the administrator.
>If he doesn't want the assurance you describe, why shouldn't he be allowed
>to configure it out of suitably-written gatekeepers? I would expect it to
>be an unusual thing to want to do, bearing in mind your comments, but is it
>the place of the standard to deny such possibilities?
>> -----Original Message-----
>> From: Jim Toga [mailto:jim.toga at INTEL.COM]
>> Sent: 15 January 1999 1:47
>> To: ITU-SG16 at MAILBAG.INTEL.COM
>> Subject: Re: Ambiguity in H.225.0 Appendix D
>> There is a point behind having a GK respond to all GRQ messages.
>> The administrator must be able to be assured that
>> unauthorized endpoints
>> (with compliant stacks) do not conference. H.323 stipulates
>> that _if_ GKs
>> are present, then endpoints must use them.... so if the GK
>> are present and
>> none of them will allow a particular endpoint to register -
>> then it is not
>> supposed to make/receives H.323 calls.
>> The endpoint on the other hand, must be able to reasonably detect the
>> difference between the complete absence of GKs and the
>> absence of 'their'
>> GK (especially if some specific control/policy is in place).
>> If the GK receives a GRQ, it must respond with a (directed)
>> GCF or GRJ.
>> At 10:55 AM 1/13/99 -0800, you wrote:
>> >This is wrt the second problem in the attached mail.
>> >Chris Purvis mentioned that GK needs to know whether
>> >a GRQ or LRQ is received via multicast or unicast so that
>> >the response could be different.
>> >Actually, H.323 V2 specifies different multicast and unicast
>> >responses only in case of LRQ. In case of GRQ, spec specifically
>> >mentions that even in multicast case a response shall be
>> >given (Section 7.2.1 para three which _only_ talks about
>> >multicast GRQs).
>> >I believe spec should not mandate a GK to respond to
>> >a multicast GRQ. It should be left to the implementor whether
>> >a response should be sent out to a multicast GRQ or not.
>> >The GK may have some additional information like redirecting
>> >the endpoint to a different GK with altGKInfo etc, otherwise it
>> >is just plain waste of bandwidth to mandate GK's to respond to
>> >multicast GRQ's. The endpoints would time out if they
>> >haven't received a single GCF.
>> >May be the following line in para 3 of section 7.2.1:
>> >"If a Gatekeeper does not want the endpoint to register to it,
>> >it shall return Gatekeeper Reject (GRJ)"
>> >should be changed to something like:
>> >"On receiving a multicasted GRQ, if a Gatekeeper does not want
>> >the endpoint to register to it, it MAY return Gatekeeper
>> >Reject (GRJ)"
>> >> -----Original Message-----
>> >> From: Mailing list for parties associated with ITU-T Study Group 16
>> >> [mailto:ITU-SG16 at mailbag.cps.intel.com]On Behalf Of Chris Purvis
>> >> Sent: Thursday, January 07, 1999 9:33 PM
>> >> To: ITU-SG16 at mailbag.cps.intel.com
>> >> Subject: Ambiguity in H.225.0 Appendix D
>> >> We have had an ambiguity show up during interoperability
>> >> testing, which
>> >> I would like clarified by means of the implementer's guide
>> and future
>> >> versions of the standard. Any objections, please shout in
>> the usual
>> >> way!
>> >> The problem comes in 220.127.116.11 where UDP port numbers are
>> defined. The
>> >> standard currently (I'm looking at version 2) says:
>> >> Gatekeeper UDP Discovery Port 1718
>> >> Gatekeeper UDP Registration and Status Port 1719
>> >> There are two problems with this. The first is that it
>> >> implies that the
>> >> LRQ message (which is nothing to do with discovery) always
>> needs to be
>> >> sent to port 1719, which is a problem for multicast LRQs,
>> because only
>> >> one IP address and port number pair has been registered with
>> >> the IETF -
>> >> 18.104.22.168:1718.
>> >> The second problem is, if anything, more subtle... The
>> standard also
>> >> seems to imply by the above that GRQ, which is a discovery message,
>> >> should always be sent to port 1718, whether it is sent to the
>> >> multicast
>> >> discovery port or not.
>> >> The reason this is a problem is that gatekeepers need to
>> know whether
>> >> these messages (GRQ and LRQ) have arrived by multicast or
>> by unicast,
>> >> because the failure response is different in the two cases
>> >> (no response
>> >> to a multicast xRQ, but xRJ response to a unicast xRQ). The only
>> >> indication that most IP stacks give as to how a message
>> has arrived is
>> >> by a port number, however, so if all GRQs appear to port
>> 1718 (and all
>> >> LRQs to port 1719), there is no way for the gatekeeper to
>> tell whether
>> >> the message arrived by unicast or multicast.
>> >> Common (but not universal - at least in products under
>> >> usage, driven by these practical considerations, seems to
>> be that the
>> >> most common implementations send both sorts of multicast
>> addresses to
>> >> the registered address - 22.214.171.124:1718, and unicast GRQ and LRQ
>> >> messages to port 1719 (unless there is some private arrangement
>> >> specifying other special usage).
>> >> My suggestion is that this common usage is standardised,
>> initially via
>> >> the implementer's guide, and then when appropriate in future
>> >> versions of
>> >> H.225.0.
>> >> Regards,
>> >> Chris
>> +1-503-264-8816(voice) Intel - Hillsboro, OR
>> mailto:jim.toga at intel.com mailto:james.toga at ties.itu.int
>> PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41
+1-503-264-8816(voice) Intel - Hillsboro, OR
mailto:jim.toga at intel.com mailto:james.toga at ties.itu.int
PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41
More information about the sg16-avd