- sg16-avd - lists.packetizer.com

H.235 -rejectReason
by Silvy Samuel 06 Aug '01

06 Aug '01

Hi, In case of an unsecured endpoint sending a RAS/H.225 message to GK , what should the reject Reason be? Is it correct if RAS messages from unsecured EPs also are rejected by GK with securityDenial, and H.225 messages with releaseComplete with reason security Denied)? Thanks and Regards, Silvy. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Question about the reuse of transport addresses in replacementFor
by Lyons, Terry 02 Aug '01

02 Aug '01

Is this restriction on the use of replacementFor generally honored? Is there any mention of the topic in H.323 or H.225.0? Is the Appendix making a normative statement? APPENDIX V / H.245 The replacementFor procedure ... Note also that in H.323 systems, receivers are required to re-use the existing media and media control transport addresses. The switch over point to the new logical channel is marked by the RTP header. - TLyons(a)sonusnet.com +1 732 625-3003 ext 212 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

[Megaco] Purpose Of Annex C
by Tom-PT Taylor 01 Aug '01

01 Aug '01

Before last month's SG 16 meeting I raised the point of the proper use of Annex C values. Today I discovered that we already have it covered. See section 7.2.10, which states unequivocally that Annex C is for the Local and Remote descriptors. One of the open issues on the list is whether we can deprecate the Modem descriptor. If we do so, the corresponding Annex C property can remain there and I would remove mention of it from my SDP-TDM draft. There were some other Annex C properties that I had proposed to remove because they belonged in LocalControl. This wasn't done at the last SG 16 meeting because orderly procedure required list agreement plus alternative packages to put them in. The specific items I would focus on are Mode (tag 1002 in C.1), DialledN (tag 901F in C.9) and DiallingN (tag 9020 in C.9). Mode is in LocalControl already, and the other two are covered by the NAS package. I had also mentioned Gain (tag 100C in C.1) and Jitterbuff (tag 100D in C.1) previously. At this point I'd say Gain might suitably be specified by direction. Jitterbuff should be moved into RTP. Tom Taylor taylor(a)nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) _______________________________________________ Megaco mailing list Megaco(a)ietf.org http://www.ietf.org/mailman/listinfo/megaco

2 1

[Sipping] VoIP Traversal of Non-upgraded Firewall & NATs @ IETF
by Pete Cordell 01 Aug '01

01 Aug '01

Dear All, I would like to have a meeting at the IETF (informal BOF?) discussing methods for VoIP and Multimedia over IP traversing non-upgraded firewalls and NATs. These methods are intended to supplement the firewall architecture, and not require upgrade to existing firewall/NAT components, or clients (and other infrastructure such as proxies). There is a draft discussing one proposal at: http://www.ietf.org/internet-drafts/draft-davies-fw-nat-traversal-00.txt If others have ideas in this area, then please contact me and we can arrange some sort of agenda. (Although note that I will be out of contact until the Sunday before the IETF - i.e. this Sunday! - so we might have to organise this at the IETF.) I hope the format will be something like: - Overview presentation of method - How this is secure and maintains administrator control - (Repeat for each proposal) - Collect issues that need to be addressed before going to a formal BOF. (The modified agenda involves the final item being changed to 'chaos'!) At this stage I would like to avoid discussion about how this compares to MidCom and other approaches - such as Rosenberg's - as I think it will quickly turn into a blood bath. - We should save that for the formal BOF! I'm hoping to hold the meeting in: The King's Suite/Sandringham 1 on Thursday 17:45 -> 18:45, but I obviously haven't had a chance to check this with the organisers. Therefore, please look out for final details on the noticeboard, and probably the door of the King's Suite. I look forward to seeing you all, Pete. (P.S. Sorry for putting this on the SG16 and TIPHON lists, but I'm well aware that many of you attend the IETF and I wanted to make sure you had the opportunity to come along.) ============================================= Pete Cordell Tech-Know-Ware pete(a)tech-know-ware.com +44 1473 635863 ============================================= _______________________________________________ Sipping mailing list http://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors(a)cs.columbia.edu for questions on current sip Use sip(a)ietf.org for new developments of core SIP

1 0

MoIP Reliable Transport Internet Draft
by Herb Wildfeuer 31 Jul '01

31 Jul '01

The "MoIP Reliable Transport Requirements and Evaluation" contribution that was discussed and modified at the Baltimore TR.30.1 meeting as 10107061R1.doc is now available as an Internet Draft at: ftp://ftp.tiaonline.org/TR-30/TR301/Public/TR-30.1/2001-07_Baltimore/Draft IETF Contribution.txt There have not been any changes to the document other than converting it to the Internet Draft (I-D) format. This document has been approved by the majority of the participants of the TR30.1 committee. Please provide me with your company name and contact information if you would like to be added to the I-D. The goal of this effort is to provide this I-D to the IETF transport group for discussion in an effort to further the work of a new transport protocol for MoIP. Best Regards, - Herb

1 0

AW: Syntax method of GEF extension definition
by Horvath Ernst 31 Jul '01

31 Jul '01

Pete, I fully agree with Terry. Let me add that the H.450 series use ROSE, which is pure ASN.1, as a formal method for the same kind of specifications as GEF. I admit that the definitions in H.450.1 look repulsively complex, but the individual supplementary service modules in H.450.x are very straightforward even for extensive services. And it's that latter quite intuitive notation that people use when defining new syntax. If there is need for a third formal method for GEF, I would opt for an ASN.1 based mechanism on the lines of H.450. Ernst Horvath Siemens AG > -----Ursprüngliche Nachricht----- > Von: Terry L Anderson [mailto:tla@LUCENT.COM] > Gesendet am: Dienstag, 10. Juli 2001 04:41 > An: ITU-SG16(a)mailbag.cps.INTEL.COM > Betreff: Re: Syntax method of GEF extension definition > > Pete > Sorry for not responding earlier. I am one of those who > expressed concern for > this section of the document during the discussion in Porto > Seguro. I share > your concern about the difficulty of using ASN.1 for these > specification since > I struggled with learning the value specification form for > use in Annex R, but > I believe that your first method (Encoded in Raw Method) is > satisfactory for > this and is what we eventually used in Annex R. I also > believe that the table > method is suitable for simple cases of values without > structure. I am not > convinced that we need a third method and don't believe that > introducing a new > syntax specification language helps make this simpler. If > this method were > used in a future annex it requires all users to learn yet one more > specification language - no matter how well designed, this > adds considerably to > the difficulty of using that Annex. You suggest that since > it is optional > people are not obliged to use it, but if the author of an > Annex chooses to use > it all users of that annex now become obliged to. > > I have not analyzed your new language in detail, but new > languages (and > especially abstract ones) usually take considerable > time/effort before they are > complete and correct and documented unambiguously. Perhaps > you are better than > most language writers and admittedly this is not a large > language but I can > hardly believe that it will not take a few iterations before > it is "done". > > But even if the current form is perfect, my concern is > introducing yet one more > language for a task that has two simpler solutions that I > believe cover the > need. > > My vote is "it goes". > > Pete Cordell wrote: > > > Hi All, > > > > As you may know, the most recent version of H.GEF.1 > included a syntax based > > method of defining GEF extensions. I defined this so that > people wouldn't > > get confused with trying to interpret a syntax based > definition as pure > > ASN.1. My principle is, if you are defining something that > is different to > > something that is already used, then make it obviously different. > > > > I'm fairly comfortable that the syntax is complete. Also, > if people don't > > want to use that method of GEF definition they are not > obliged to. I > > personally would therefore like to keep it in. > > > > However, we live in a democracy. Therefore, the person > that gives me the > > highest bid can decide whether it stays or goes! > > > > Meanwhile, people can vote on whether it stays or goes by > e-mailing me > > directly. I will then summarise and post the results to > the list. In the > > event of a draw I'll keep it in. > > > > All the best, > > > > Pete. > > > > ============================================= > > Pete Cordell > > Tech-Know-Ware > > pete(a)tech-know-ware.com > > +44 1473 635863 > > ============================================= > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > -- > It's not a lie. It's a gift for fiction. > ------------------------------------------------------------ > Terry L Anderson mailto:tla@lucent.com > Tel:908.582.7013 Fax:908.582.6729 > Lucent Technologies/INS/Voice Over IP Access Networks > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: H.235 Security Blues
by Paul, Manoj 27 Jul '01

27 Jul '01

Hi Martin, You pointed out that it should be a matter of local policy whether to allow processing of messages that did not conform to the security norms. I think that's what I meant by "a-priori" mechanisms. I want to view this issue for H.235 Annex D. This annexure is applicable only in administered environments. Even the password used for hashing is known through subscription process for ex. Is it correct to say, then, that as a part of this subscription, an endpoint can make a local policy decision whether or not to expect all messages coming from GK in a secured manner? regards Manoj. -----Original Message----- From: Euchner Martin [mailto:Martin.Euchner@icn.siemens.de] Sent: Friday, July 27, 2001 8:13 AM To: 'Paul, Manoj'; Euchner Martin; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: H.235 Security Blues Hi Manoj, the scenario that you described refers to a mixed environment that should cope both with security (entities, protocols) and also with unsecured ones. It is true, that such mixed environments do not provide the same security level as a secure environment without any unsecured entities. The problem with mixed environments is, that a secure entity should also process insecure messages from untrusted entities but has no way to know where such unprotected messages really came from. This issue not new and security experts have always warned people to realize this. Let me note, that exactly this kind of discussion comes up, when people add security later on and seek some way how secure and insecure (= older) systems could interwork in a secure way. Thus, it is exactly this weakness of insecure systems that breaks the entire security. I understand that this situation is unsatisfactory, but we have to live with that as long as dual mode or mixed environments are the case. However, your idea using pre-configured security in the entities (in a mixed environment) would be equal to the situation where all entities have implemented security but no insecure one is permitted to participate (which would then be a non-mixed security environment). Thus, as you see, this is either a contradiction or impossible to fulfill and wouldn't help anyway. As a conclusion, no one should expect to obtain any better security in a mixed environment than in an unsecured environment. If you really want to improve, the only way to achieve this, is to abandon the insecure entities and replace them by secure ones or forbid the secured entities from accepting any insecure message. This however is matter of security policy in your operating environment. It is a local matter how you would or could enforce such a security policy in your systems. Using H.235 you have all the means to determine whether a message has been secured (through the OIDs) and also verify (by checking the cryptographic hash value) whether it origins from a trusted entity. This should be sufficient to decide whether or not to discard a message. Think about! 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: | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Paul, Manoj [mailto:mpaul@trillium.com] Sent: Wednesday, July 25, 2001 7:25 PM To: 'Euchner Martin'; Paul, Manoj; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: H.235 Security Blues Hi Martin, Thanks for your reply. I have a small concern to the fact that GK should let the EP know of GK initiated message security aspects in security tokens. I think an endpoint should a-priori know if it expects messages (RAS and 225) from GK to contain security tokens and hash values. If endpoint determines this at run time using in-band mechanisms, it may potential fall pray to a hostile router which sends it an unsecured message pretending as a GK. An EP, in such a case, would have no way to determine if GK indeed wants it to send unsecured messages. I shall appreciate your comments. best regards Manoj. -----Original Message----- From: Euchner Martin [mailto:Martin.Euchner@icn.siemens.de] Sent: Wednesday, July 25, 2001 1:31 AM To: 'Paul, Manoj'; Euchner Martin; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: H.235 Security Blues Hi Manoj, the GK determines whether to apply mutual authentication; i.e. authenticate and integrity protect the RAS messages towards the EP. This is a matter of security policy and therefore something, that is a local matter. For security reasons, I would recommend applying mutual authentication instead on just single sided authentication. There is no need to negotiate this feature, as an endpoint can always recognize whether messages from the GK are secured or not. The EP does this by looking at the presence of the various OIDs in the security tokens. Missing OIDs = no security. Thus, this feature is always indicated in-band in each message. 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: | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Paul, Manoj [mailto:mpaul@trillium.com] Sent: Tuesday, July 24, 2001 7:55 PM To: 'Euchner Martin'; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: H.235 Security Blues Hi Martin, Thanks for your response. I have an additional question under section D.6.3.1 of H.235V2. Second para of this section states that Gk decides whether to apply Auth/Int in the reverse direction as well. I could not find any IE in GRQ/GCF where GK could inform the endpoint if messages originating from GK will also contain hash values and that EPs should also auth/int them. Does GK tell endpoints to apply Auth/Int in reverse direction also by out-of band mechanisms (something during password subscription etc.)? thanks Manoj. -----Original Message----- From: Euchner Martin [mailto:Martin.Euchner@ICN.SIEMENS.DE] Sent: Tuesday, July 24, 2001 9:39 AM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: H.235 Security Blues Manoj and experts, thanks for pointing out several points in H.235v2 that do deserve clarification. My answers are included below in the original text. I've also attached draft text for the H.323 Implementors Guide, that proposes clarifications and corrections. If you agree, I would send the text "officially" to our H.323 IG editor. With 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/cs27/ | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- 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/cs27/ | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] Sent: Thursday, July 19, 2001 9:15 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: H.235 Security Blues Experts, Could someone clarify following aspects of H.235 V2 Annex D (Baseline Security Profile). 1) Section D.2, last but second paragraph (This profile defines to....). According to this paragraph, the generalId field shall be set to the "called endpoint ID" for H225 signalling messages. Since the calls must be GK routed, shouldn't the generalId refer to the gkId for 225 messages sent by endpoints? Yes, correct. The GeneralID should always be the destination ID. Please see, the section in the Implementors Guide which corrects this. Even if it is the called epId, how the peer endpoint can ever know the called epId, since it does not appear ARQ/ACF messages? I'm not really sure whether I got your question here. When the EP does not have an identifier yet, as might occur in early RAS messages, then D.10 say to fill-in NULL instead. Section D.10 throws some insight into the usage of senderId and generalId, but it does it so only for RAS messages. Do you think it is necessary to make sendersID and generalID explicit in the table in D.9.2? There shouldn't be any exceptions such as in the case of RAS where 2) Section D.9.1 of H.235 V2 states the 225 UUIEs which shall contain cryptoTokens field. H.323 V4 has added new UUIEs (Status, Status Enquiry,...). Ooops, this actually has been an oversight and not any intentional. Of course, the additional H.323 V4 signaling messages such as Status, Status inquiry, Setup-ack and notify-UUIEs etc shall be covered and secured as well. And similar correction is also necessary for Annex E. The IG provides the necessary corrections. Does that mean that H.323 V4 can not possibly use H.235 V2? Absolutely not. H.323 v4 and H.225.0 V4 were designed in such a way that H.235v2 deployment is possible. best regards Manoj Paul. -----Original Message----- From: ssilvy(a)hss.hns.com [mailto:ssilvy@hss.hns.com] Sent: Thursday, May 31, 2001 9:26 PM To: mpaul(a)TRILLIUM.COM; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: Hi, In case of initial RRQ when EPID is not available the table D.10 in H235v2 says that sendersID would be NULL. So the hash would be calculated with sendersID as NULL when the identification information i.e EPID is not available as in initial RRQ. Silvy. Nagesh Kumar B V 06/01/2001 10:40 AM To: Silvy Samuel/HSSBLR@HSSBLR, Ivan T Varghis/HSSBLR@HSSBLR cc: Subject: ---------------------- Forwarded by Nagesh Kumar B V/HSSBLR on 06/01/2001 09:46 AM --------------------------- "Paul, Manoj" <mpaul(a)TRILLIUM.COM> on 05/31/2001 06:35:31 PM Please respond to "Paul, Manoj" <mpaul(a)TRILLIUM.COM> To: ITU-SG16(a)mailbag.cps.INTEL.COM cc: (bcc: Nagesh Kumar B V/HSSBLR) Subject: Hi All, I have a question on the use of H.235 Annex D (Baseline Security Profile). According to this profile, except for GRQ/GCF messages, all other RAS messages shall contain a hash value computed using HMAC-SHA1-96 algorightm on the entire RAS message. Consider an endpoint sending RRQ to the Gk. In the clearToken field of RRQ message, the endpoint shall fill generalId as gkId (which it got in GCF) and senderId as it's own epId. EpId is generally returned to the endpoint by the gatekeeper in RCF. That means that an endpoint may not have an epId while sending RRQ to Gk. In such a case, how it is supposed to fill the senderId and compute the hash value on complete RRQ message? Any pointers are appreciated. thanks Manoj Paul. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.235 Security Blues
by Euchner Martin 27 Jul '01

27 Jul '01

Hi Manoj, the scenario that you described refers to a mixed environment that should cope both with security (entities, protocols) and also with unsecured ones. It is true, that such mixed environments do not provide the same security level as a secure environment without any unsecured entities. The problem with mixed environments is, that a secure entity should also process insecure messages from untrusted entities but has no way to know where such unprotected messages really came from. This issue not new and security experts have always warned people to realize this. Let me note, that exactly this kind of discussion comes up, when people add security later on and seek some way how secure and insecure (= older) systems could interwork in a secure way. Thus, it is exactly this weakness of insecure systems that breaks the entire security. I understand that this situation is unsatisfactory, but we have to live with that as long as dual mode or mixed environments are the case. However, your idea using pre-configured security in the entities (in a mixed environment) would be equal to the situation where all entities have implemented security but no insecure one is permitted to participate (which would then be a non-mixed security environment). Thus, as you see, this is either a contradiction or impossible to fulfill and wouldn't help anyway. As a conclusion, no one should expect to obtain any better security in a mixed environment than in an unsecured environment. If you really want to improve, the only way to achieve this, is to abandon the insecure entities and replace them by secure ones or forbid the secured entities from accepting any insecure message. This however is matter of security policy in your operating environment. It is a local matter how you would or could enforce such a security policy in your systems. Using H.235 you have all the means to determine whether a message has been secured (through the OIDs) and also verify (by checking the cryptographic hash value) whether it origins from a trusted entity. This should be sufficient to decide whether or not to discard a message. Think about! 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: | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Paul, Manoj [mailto:mpaul@trillium.com] Sent: Wednesday, July 25, 2001 7:25 PM To: 'Euchner Martin'; Paul, Manoj; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: H.235 Security Blues Hi Martin, Thanks for your reply. I have a small concern to the fact that GK should let the EP know of GK initiated message security aspects in security tokens. I think an endpoint should a-priori know if it expects messages (RAS and 225) from GK to contain security tokens and hash values. If endpoint determines this at run time using in-band mechanisms, it may potential fall pray to a hostile router which sends it an unsecured message pretending as a GK. An EP, in such a case, would have no way to determine if GK indeed wants it to send unsecured messages. I shall appreciate your comments. best regards Manoj. -----Original Message----- From: Euchner Martin [mailto:Martin.Euchner@icn.siemens.de] Sent: Wednesday, July 25, 2001 1:31 AM To: 'Paul, Manoj'; Euchner Martin; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: H.235 Security Blues Hi Manoj, the GK determines whether to apply mutual authentication; i.e. authenticate and integrity protect the RAS messages towards the EP. This is a matter of security policy and therefore something, that is a local matter. For security reasons, I would recommend applying mutual authentication instead on just single sided authentication. There is no need to negotiate this feature, as an endpoint can always recognize whether messages from the GK are secured or not. The EP does this by looking at the presence of the various OIDs in the security tokens. Missing OIDs = no security. Thus, this feature is always indicated in-band in each message. 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: | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Paul, Manoj [mailto:mpaul@trillium.com] Sent: Tuesday, July 24, 2001 7:55 PM To: 'Euchner Martin'; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: H.235 Security Blues Hi Martin, Thanks for your response. I have an additional question under section D.6.3.1 of H.235V2. Second para of this section states that Gk decides whether to apply Auth/Int in the reverse direction as well. I could not find any IE in GRQ/GCF where GK could inform the endpoint if messages originating from GK will also contain hash values and that EPs should also auth/int them. Does GK tell endpoints to apply Auth/Int in reverse direction also by out-of band mechanisms (something during password subscription etc.)? thanks Manoj. -----Original Message----- From: Euchner Martin [mailto:Martin.Euchner@ICN.SIEMENS.DE] Sent: Tuesday, July 24, 2001 9:39 AM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: H.235 Security Blues Manoj and experts, thanks for pointing out several points in H.235v2 that do deserve clarification. My answers are included below in the original text. I've also attached draft text for the H.323 Implementors Guide, that proposes clarifications and corrections. If you agree, I would send the text "officially" to our H.323 IG editor. With 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/cs27/ | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- 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/cs27/ | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] Sent: Thursday, July 19, 2001 9:15 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: H.235 Security Blues Experts, Could someone clarify following aspects of H.235 V2 Annex D (Baseline Security Profile). 1) Section D.2, last but second paragraph (This profile defines to....). According to this paragraph, the generalId field shall be set to the "called endpoint ID" for H225 signalling messages. Since the calls must be GK routed, shouldn't the generalId refer to the gkId for 225 messages sent by endpoints? Yes, correct. The GeneralID should always be the destination ID. Please see, the section in the Implementors Guide which corrects this. Even if it is the called epId, how the peer endpoint can ever know the called epId, since it does not appear ARQ/ACF messages? I'm not really sure whether I got your question here. When the EP does not have an identifier yet, as might occur in early RAS messages, then D.10 say to fill-in NULL instead. Section D.10 throws some insight into the usage of senderId and generalId, but it does it so only for RAS messages. Do you think it is necessary to make sendersID and generalID explicit in the table in D.9.2? There shouldn't be any exceptions such as in the case of RAS where 2) Section D.9.1 of H.235 V2 states the 225 UUIEs which shall contain cryptoTokens field. H.323 V4 has added new UUIEs (Status, Status Enquiry,...). Ooops, this actually has been an oversight and not any intentional. Of course, the additional H.323 V4 signaling messages such as Status, Status inquiry, Setup-ack and notify-UUIEs etc shall be covered and secured as well. And similar correction is also necessary for Annex E. The IG provides the necessary corrections. Does that mean that H.323 V4 can not possibly use H.235 V2? Absolutely not. H.323 v4 and H.225.0 V4 were designed in such a way that H.235v2 deployment is possible. best regards Manoj Paul. -----Original Message----- From: ssilvy(a)hss.hns.com [mailto:ssilvy@hss.hns.com] Sent: Thursday, May 31, 2001 9:26 PM To: mpaul(a)TRILLIUM.COM; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: Hi, In case of initial RRQ when EPID is not available the table D.10 in H235v2 says that sendersID would be NULL. So the hash would be calculated with sendersID as NULL when the identification information i.e EPID is not available as in initial RRQ. Silvy. Nagesh Kumar B V 06/01/2001 10:40 AM To: Silvy Samuel/HSSBLR@HSSBLR, Ivan T Varghis/HSSBLR@HSSBLR cc: Subject: ---------------------- Forwarded by Nagesh Kumar B V/HSSBLR on 06/01/2001 09:46 AM --------------------------- "Paul, Manoj" <mpaul(a)TRILLIUM.COM> on 05/31/2001 06:35:31 PM Please respond to "Paul, Manoj" <mpaul(a)TRILLIUM.COM> To: ITU-SG16(a)mailbag.cps.INTEL.COM cc: (bcc: Nagesh Kumar B V/HSSBLR) Subject: Hi All, I have a question on the use of H.235 Annex D (Baseline Security Profile). According to this profile, except for GRQ/GCF messages, all other RAS messages shall contain a hash value computed using HMAC-SHA1-96 algorightm on the entire RAS message. Consider an endpoint sending RRQ to the Gk. In the clearToken field of RRQ message, the endpoint shall fill generalId as gkId (which it got in GCF) and senderId as it's own epId. EpId is generally returned to the endpoint by the gatekeeper in RCF. That means that an endpoint may not have an epId while sending RRQ to Gk. In such a case, how it is supposed to fill the senderId and compute the hash value on complete RRQ message? Any pointers are appreciated. thanks Manoj Paul. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.323 (8.1) Phase A - Call Setup
by Peter Price 27 Jul '01

27 Jul '01

Paul, I don't feel this tread reached a conclusion. The last comment I saw from you was that the intent was alerting. I asked on July 20 (see below) why that was the intent and received no reply. I also commented in a separate email about you last paragraph > > The ideas are related, but independent. What we have seen some folks do is > > send a Call Proceeding to the caller and then nothing else until the > > connect. The result is that the calling party hears silence for a very long > > time: that's not good. We both agree Alerting should be sent to the caller as soon as the callee's phone is ringing but the text opens the door for someone to send Call Proceeding and then not ever send Alerting. It becomes clearer to me that the original intent was almost certainly "If an endpoint can respond to a Setup message with a Connect within 4 seconds, it is not required to send the Alerting message." Reference to Call Proceeding is incorrect and to Release Complete irrelevent. So was this latter interpretation what was really intended or is my original suggestion that the text should have refereed to Call Proceeding still valid? Thanks Peter > -----Original Message----- > From: Peter Price > Sent: 20 July 2001 14:03 > To: ITU-SG16(a)mailbag.cps.INTEL.COM > Subject: RE: H.323 (8.1) Phase A - Call Setup > > > Paul, > > I don't understand why the intent was Alerting. > > "If an endpoint can respond to a Setup message with a > Connect, Call Proceeding, or Release Complete within 4 > seconds, it is not required to send the Alerting message." > > Why, if an endpoint can respond to a Setup with a Call > Proceeding within 4 seconds, should it not have to send the > Alerting? How will the user get a ringing sound in his ear then? > > I know that Alerting (and Connect) also stops T303. > However, in Table 9-1/Q.931 (refernced by H.225 (7.5)), > receipt of an Alerting starts T301, while receipt of Call > Proceeding starts T310. I realise that T310 is not > explicitly required by H.323 but the second para of (8.1.8.2) > implies that the mechanism it represents IS required (I know > its says should and not shall - perhaps this is a second error) > > "A Gateway should send a Call Proceeding message after it > receives the Setup message (or after it receives ACF) if it > expects more than 4 seconds to elapse before it can respond > with Alerting, Connect, or Release Complete." > > The specific reason for sending Call Proceeding here is to > stop T303 timing out and the call failing. > > The point is that for H.323 endpoints Call Proceeding is > superfluous, if a terminal device cannot respond with an > Alerting or Release Complete within 4 seconds it has problems > [ or it's running windows (-; ] and the call probably should > fail. However, gateways are different. If they interface to > a large network then the Alerting must not be sent to the > caller until an appropriate message has been received [ also > in (8.1) "In the case of interworking through a Gateway, the > Gateway ***shall send Alerting when*** it receives a ring > indication from the SCN." ie WHEN it receives the ring > indication and not before ] and this might take longer than 4 > seconds - hence the need for gateways to send Call Proceeding > and the relevance of 4 seconds in the sentence in question. > > My original assertion that the text in (8.1) is incorrect stands. > > "If an endpoint can respond to a Setup message with a > Connect, Alerting, or Release Complete within 4 seconds, it > is not required to send the Call Proceeding message." > > Alternatively, if an endpoint *cannot* respond to a Setup > message with a Connect, Alerting, or Release Complete within > 4 seconds, it *should* (shall?) send a Call Proceeding message. > > The only other interpretation I can come up with is that the > intent was > "If an endpoint can respond to a Setup message with a Connect > within 4 seconds, it is not required to send the Alerting message." > If it responds with a Release Complete within 4 seconds it's > not going to send an Alerting! > > I've just seen Chris's reply as well - I think my > observations still stand. > I think in fact that the whole paragraph is poorly > structured, mixing a number of different ideas. > I was juts trying to suggest the simplest change. > > Peter > > > -----Original Message----- > > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > > Sent: 20 July 2001 12:48 > > To: ITU-SG16(a)mailbag.cps.INTEL.COM > > Subject: Re: H.323 (8.1) Phase A - Call Setup > > > > > > Peter, > > > > Alerting was the intent. Call Proceeding not produce a > > ringing sound in the > > caller's ear. H.323 devices have to be able to send an > > Alerting, though > > they're not required to do so if they can send a Connect > > within 4 second. > > The 4 seconds is the T303 timeout and the T303 timer is > disabled when > > receiving Alerting, too... not just Call Proceeding. > > > > The ideas are related, but independent. What we have seen > > some folks do is > > send a Call Proceeding to the caller and then nothing else until the > > connect. The result is that the calling party hears silence > > for a very long > > time: that's not good. > > > > Paul > > > > ----- Original Message ----- > > From: "Peter Price" <PeterP(a)VEGASTREAM.COM> > > To: <ITU-SG16(a)mailbag.cps.INTEL.COM> > > Sent: Friday, July 20, 2001 6:54 AM > > Subject: H.323 (8.1) Phase A - Call Setup > > > > > > > Hi folks, > > > > > > I think I may have found some incorrect text in H.323 8.1 > > > > > > The same text appears in both V3 and V4 so I suspect nobody > > has commented > > > before. > > > > > > In the paragraph beginning: > > > "An endpoint shall be capable of sending the Alerting > message. ..." > > > > > > it goes on to say: > > > "If an endpoint can respond to a Setup message with a > Connect, Call > > > Proceeding, or Release Complete within 4 seconds, it is not > > required to > > send > > > the Alerting message. An endpoint sending the Setup message > > can expect to > > > receive either an Alerting, Connect, Call Proceeding, or > > Release Complete > > > message within 4 seconds after successful transmission." > > > > > > I believe the first sentence here should really be discussing the > > > requirement to send a Call Proceeding (not Alerting) message. > > > The period of 4 seconds in the last sentence is related to > > T303 which is > > > specifically terminated by a Call Proceeding message in > > order to extend > > the > > > timeout for the sending endpoint. > > > > > > I think the sentence should read: > > > "If an endpoint can respond to a Setup message with a > > Connect, Alerting, > > or > > > Release Complete within 4 seconds, it is not required to > > send the Call > > > Proceeding message." > > > > > > This is then consistent with the use of Call Proceeding > described in > > 8.1.8.2 > > > (second para). > > > > > > Peter Price > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > For help on this mail list, send "HELP ITU-SG16" in a message to > > > listserv(a)mailbag.intel.com > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Package Dependencies
by Tom-PT Taylor 27 Jul '01

27 Jul '01

I have an interesting situation with the Advanced Audio Server packages (H.248 Annex M.1), and I wanted to check out my proposed solution with the list. The "basic" package currently consists of three functions: play, play and collect digits, and play and collect a recording. It also includes an extensive description of a syntax for specifying individual announcements, including variable elements. This syntax appears to the Megaco/H.248 grammar as a parameter VALUE in quotedString form. One "advanced" package defined in the current draft Annex doesn't change any of the functions, but extends the announcement-specifying syntax. Using past practice as a guide, the package was modelled as an extension of the basic one. However, note that the new functionality is actually hidden below the level that would normally distinguish an extension -- no new signals or events are added, and no new parameters are added. (That last wouldn't be legal in any event.) However, this approach doesn't really work. The first sign of trouble was when I thought to split up the play, play-and-collect, and play-and-record functions, both to clarify the functional definitions and because it would provide more flexibility for product implementation. How would I introduce the "advanced" syntax for each function? Do I need to define an "advanced" package for each, so that the two packages become six? It becomes worse now that more than one advanced syntax feature has been proposed. I now need a package for the basic announcement syntax, one for that plus feature A, one for that plus feature B, and a fourth one for all three features together. You get the idea: an exponential explosion, multiplied by the number of functions if we decide to split them. I have an answer to this, but I thought it might be a good idea to legitimize it. It could even lead to a v2 formalization of the process if accepted (with no change in what goes out over the wire!). My proposal is this: 1) We define the announcement specification syntax itself in a package of its own. Note that this package will have none of the usual content -- no properties, signals, events, or statistics. 2) We define each additional feature of the announcement specification syntax in another package which is an extension of the basic syntax package. 3) Within the functional packages (play, play-and-collect, etc.) we say first that the package USES the syntax of the basic syntax package and secondly that if any extension of the basic syntax package is supported the functional package also USES that extension. An implication is that if a device supports an advanced syntactical feature (e.g. sets) for one function it MUST support that feature for all of the functions it implements. Comments? Is this a legitimate use of packaging? Should we add the USES relationship to our section 12 package description requirements in v2? Please copy follow-ups to the Megaco list, now at megaco(a)ietf.org. Tom Taylor taylor(a)nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490)

2 1