AW: Security in Inter Gatekeeper Communication
Ivan, it is my understanding that LRQ/LCF for inter GK communication does not scale very well. Thus, H.225.0 Annex G is the more appropriate approach that should be taken. However, it is also true, that H.225.0 Annex G does not run between GKs but rather only between border elements. To be precise, an external protocol between an GK and a BE is currently undefined; better think of a co-located GK/BE entity without any in-between protocol. Regarding security, H.235 Annex G for securing H.MMS.1 mobility is being worked on and will describe also security protection of inter-BE messages similar to H.235 Annex D. To my knowledge, this is currently the only security profile that is of interest between BEs, thus there is no trial and error to be expected. As the shared secret between both BEs has to be administered anyway, so can the security profile be configured as well. Nevertheless, the security profile itself is identified through a set of OIDs. I hope this answers your questions. Kind Regards, Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/sr/pages/122/122_euchner.htm | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany -----------------------------------------------------------------------
-----Urspr> üngliche Nachricht----- Von: Ivan Varghis [SMTP:ivancse@YAHOO.COM] Gesendet am: Samstag, 8. September 2001 14:09 An: ITU-SG16@mailbag.cps.INTEL.COM Betreff: Security in Inter Gatekeeper Communication
Hi
For security in inter Gatekeeper conmmunication, currently there is no authentication capabltiy exchange for selection of a common security profile. This facility is provided in the case of communication between the Endpoint and Gatekeeper using the GRQ GCF exchange.
The field used for this are AuthenticationCapabilty and AlgorithmOIDs in GRQ ( Capabilities of the EP) and AuthenticationMode and AlgorithmOID in GCF ( The capabiltiy selected by Gatekeeper)
Wouldnt it be good to add the " same fields in the LRQ and LCF" as his would help in selection of a common profile between Gatekeepers.
Though the profile which is used can be determined from the TokenIOD and AlgorithmOID in the message, as the number of security profiles increases the Gatekeepers will have to use a trial and error method to arrive at a common security Profile. Wouldnt this be a overhead which can be avoided ?
Cheers H.323 Ivan
__________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Ivan,
it is my understanding that LRQ/LCF for inter GK communication does not scale very well. Thus, H.225.0 Annex G is the more appropriate approach that should be taken. However, it is also true, that H.225.0 Annex G does not run between GKs but rather only between border elements. To be precise, an external protocol between an GK and a BE is currently undefined; better
Martin, I would argue against the notion that LRQs do not scale. Indeed, I have seen this working very well in large networks. Moreover, in order to determine the availability of GWs and to reduce the likelihood that call will be directed to GWs that are over-capacity, per-call transactions are necessary. Both LRQs and Annex G result in about the same amount of signaling on the wire. Paul ----- Original Message ----- From: "Euchner Martin" <Martin.Euchner@ICN.SIEMENS.DE> To: <ITU-SG16@mailbag.cps.INTEL.COM> Sent: Monday, September 10, 2001 6:01 AM Subject: AW: Security in Inter Gatekeeper Communication think of a co-located GK/BE entity without any in-between protocol.
Regarding security, H.235 Annex G for securing H.MMS.1 mobility is being
worked on and will describe also security protection of inter-BE messages similar to H.235 Annex D. To my knowledge, this is currently the only security profile that is of interest between BEs, thus there is no trial and error to be expected. As the shared secret between both BEs has to be administered anyway, so can the security profile be configured as well. Nevertheless, the security profile itself is identified through a set of OIDs.
I hope this answers your questions.
Kind Regards,
Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet:
http://intranet.icn.siemens.de/marketing/sr/pages/122/122_euchner.htm
| D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany -----------------------------------------------------------------------
-----Urspr> üngliche Nachricht----- Von: Ivan Varghis [SMTP:ivancse@YAHOO.COM] Gesendet am: Samstag, 8. September 2001 14:09 An: ITU-SG16@mailbag.cps.INTEL.COM Betreff: Security in Inter Gatekeeper Communication
Hi
For security in inter Gatekeeper conmmunication, currently there is no authentication capabltiy exchange for selection of a common security profile. This facility is provided in the case of communication between the Endpoint and Gatekeeper using the GRQ GCF exchange.
The field used for this are AuthenticationCapabilty and AlgorithmOIDs in GRQ ( Capabilities of the EP) and AuthenticationMode and AlgorithmOID in GCF ( The capabiltiy selected by Gatekeeper)
Wouldnt it be good to add the " same fields in the LRQ and LCF" as his would help in selection of a common profile between Gatekeepers.
Though the profile which is used can be determined from the TokenIOD and AlgorithmOID in the message, as the number of security profiles increases the Gatekeepers will have to use a trial and error method to arrive at a common security Profile. Wouldnt this be a overhead which can be avoided ?
Cheers H.323 Ivan
__________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (2)
-
Euchner Martin -
Paul E. Jones