- sg16-avd - lists.packetizer.com

Test
by Roy, Radhika R, ALTEC 02 Jul '98

02 Jul '98

Please ignore it.

1 0

Re: ASN.1 accross revisions
by Orit Levin 02 Jul '98

02 Jul '98

Hello all! Sorry for joining the discussion just now. We are aware of the mentioned problem and have been listening to the discussion. Since we have an access to our ASN.1 compiler, we were thinking of implementing "Solution 2" (although using a more precise definition). Saying that, we would be glad to find a more correct approach both from academic and efficiency points of view. - The new definition (i.e. the V.2 correction) indeed has to be done very quickly. - Our additional concern is, that the solution should be backward compatible with already deployed V.1 products. Did anybody check "Solution 4" in this light? Across different Compilers? Best Regards, Orit Levin RADVision Inc., 575 Corporate Drive - Suite 420 Mahwah, NJ 07430 Tel: 201-529-4300 ext. 230 Fax: 201-529-3516

1 0

H.225.0 corrections
by Glen Freundlich 02 Jul '98

02 Jul '98

At the Yokosuka meeting, some corrections were identified in H.225.0 to use the Information message instead of the User Information message (see APC-1362). There were 2 remaining references to User Information that should be changed to Information. The first is in the h323-message-body structure, where "userInformation" should be changed to "information". The second is in the UUIEsRequested structure, where "userInformation" should be changed to "information". These corrections will appear in the Implementors Guide. Please let me know if you see any problems with these changes. Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

1 0

Re: Report of the Cannes meeting
by Roy, Radhika R, ALTEC 01 Jul '98

01 Jul '98

Dear Mr. Cordell: I fully agree with you. This is what heard in the Cannes meeting. I would have been somewhat happier if I would see this viewpoint that has been expressed in your email would have been included in the Cannes meeting report (APC-1425). My question is: Will Mr. OKUBO be pleased to include at least this viewpoint in the final Cannes report? Sincerely, Radhika R. Roy AT&T USA Tel: + 1 732 949 8657 email: rrroy@.att.com > ---------- > From: Pete Cordell[SMTP:pete.cordell@BT-SYS.BT.CO.UK] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Wednesday, July 01, 1998 12:20 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Report of the Cannes meeting > > My understanding of the meeting was that APC-1422 was considered as good > a place as any to start with a development, but there was acceptance > that the final result may differ radically from what is in APC-1422, and > we didn't want to preclude any other solution that we might find that > was either already written, so somehow fitted our needs better than the > framework that was out lined in APC-1422. It's my recollection that it > was the view of the Intel delegates that this was a satisfactory > situation. > > Regards, > > Pete > ================================= > Pete Cordell > BT Labs > E-Mail: pete.cordell(a)bt-sys.bt.co.uk > Tel: +44 1473 646436 > Fax: +44 1473 645499 > ================================= > > > >---------- > >From: Jim Toga[SMTP:jim.toga@INTEL.COM] > >Sent: 29 June 1998 21:51 > >To: ITU-SG16(a)MAILBAG.INTEL.COM > >Subject: Re: Report of the Cannes meeting > > > >Dear Mr Roy, > > > >Although I was unable to attend the meeting in Cannes, I have read all > >the > >previous reports and have spoken to a number of people that attended. > >There were many discussions during the meeting, which are summarized > >in > >the meeting report without re-hashing every detail. My understanding is > >that there were no objections from _anyone_ else at the meeting to > >progressing the work that has been started in APC-1422. The intent > >will be > >to have both telephone and email exchanges to further develop this > >work. > >I would look forward to having your constructive input as we move > >forward. > >In the spirit of this, I would like to elicit your input here. > > > >I would like to point out a couple of misconceptions you might have > >based > >upon the text below and ask you for some concrete proposals in areas > >where > >you feel they're needed... > > > >Best Regards, > >jimt. > > > > > >[SNIP] > > > >> > >>Section 5.5.4 H.225.0 V3 Annex G (GK to GK Communications) > >> > >>APC-1385 [AT&T] "Framework for H.323 Inter-Gatekeeper Communications" > >> > >>Mr. Roy also pointed out the following: > > > >If these points were raised in the APC document and covered during the > >meeting why do they need to be called out explicitly in the meeting > >report? > > The list of contributed documents is part of the meeting. > > > >> > >> * H.323 signaling schemes that were developed for > >>H.323v1 in view of the LAN-based single GK model > > > >Both v1 and v2 have never limited GK deployment to one entity (on the > >LAN > >or any other topology) The defined signalling for address resolution > >allows for N gatekeepers. > > > >>(signaling schemes in > >>H.323v2 also remain almost the same so far the inter-GK communication is > >>concerned) may not be good enough to satisfy all needs when it is > applied in > >>the context of multiple gatekeeper environment with different inter-GK > >>architectures: Distributive, Centralized, and Hybrid (Distributive + > >>Centralized). > > > >(I think you mean 'Distributed' above) In any case, these different > >modes > >of operation define models with respect to _media_ distribution, not > >control. In this case they would (and do) affect the operation of an > >MCU. > >(this is not to say that the MCU can't be co-located with the GK). > > > >V1 and V2 (and certainly the intent with V3) allow for many different > >GK > >topologies with hierarchical being one of the more general ones. Flat > >peer-peer models may be accomplished by having a degenerative > >'hiearchy' > >with a depth of 1. > > > >> * Each inter-GK architecture may need different > >>signaling schemes in order to optimize the use of communication > resources > >>especially in the context large networks for both connectionless and > >>connection oriented networks. > > > >Can you eloborate on this? Are you simply saying that we need to allow > >both UDP and TCP signalling (which is in fact specified in section 4 of > >APC-1422). > > > > > >> > >>APC-1422 [Intel] "Proposal and General Comments for Inter-Gatekeeper > >>Communications" > >> > >>During the discussion of Intel's contribution, Mr. Roy also pointed out > that > >>this proposal appears to have the following limitations: > >> > >> * The relationship between the zone (or internal) > and > >>the border (or domain) gatekeeper is not defined: is it hierarchical or > >>what? > > > >As described in section 2 of APC-1422 the only difference (in terms of > >protocol interactions) between a GK acting as 'border GK' and an > >'internal' GK is that fact that the border GKs may communicate with > >border > >GKs from other administrative domains. There are no specific models of > >deployment within an admistrative domain. Some organizaitons will > >choose > >to develop a hierachical model, others may choose to have a star > >topology, > >or perhaps a flat domain. It makes no difference to the signalling > >between > >administrative domains and the current signalling can facilitate all of > >these models. Can you offer any specific topologies that you believe > >will > >not work and cannot exploit this signalling? > > > >> * Does it mandates the use of proprietary > protocols > >>between the zone (or internal) and domain (or border) gatekeeper? > > > >It certainly does not _disallow_ proprietary protocols, but the intent > >would be to support standard messages internal to an adminstrative > >domain > >(which may be made up of a number of zones BTW...) as well as using > >these > >standard messages between administrative domains. > > > > > >> * The relationship between the multiple domain > >>gatekeepers has not been defined: how communications occur in view of > the > >>multiple domain gatekeepers? > > > >The definition of 'relationship' is multi-faceted. Many of the aspects > >of > >a 'relationship' may in fact be business related, and outside this > >realm. > >One of the points of annex G is to provide some signalling which will > >allow > >administrative domains (again an organizational term, not a formal > >H.323 > >topology term) to exchange information so that they can define the > >"relationship between the multiple domain..." > > > > > > > >> * As if it mandates a specific implementation > scheme > >>that may limit its scalability once one starts to use the gatekeeper > >>discovery, address translation, admission control, and/or bandwidth/QOS > >>control signaling messages for this particular architecture while a > large > >>network that may use highly distributive, centralized, and hybrid > inter-GK > >>architecture. > > > >I'm really not sure what you asking/saying here...can you clarify this? > > > >> > >>Therefore, Mr. Roy has the following view: > >> > >> * It requires a fundamental understanding of the > >>logical relationships for inter-GK communications in view of the > >>distributive, centralized, and hybrid inter-GK architecture that might > be > >>scaleable in view of large networks for both connectionless and > connection > >>oriented networking environment. > > > >I think you mixing a number of things here (some of which have no > >relevance). Can you break this up unto a number simple points - so > >that a > >simple person such as I can understand? :-) > > > > > >> * AT&T's contribution (APC-1382) has been the > first > >>step in that direction. > > > >You may note that a number of the definitions and clarificaitons from > >Yokuska to Cannes were a direct result of APC-1382 - thank you. > > > >> > >>------------------------------------------------------------------------ > ---- > >>------------------------------------------------------------------------ > ---- > >>--- > >> > >>I would appreciate a prompt action from your end. > >> > >>Sincerely, > >> > >>Radhika R. Roy > >>AT&T > >>Room 1K-330 > >>101 Crawfords Corner Road > >>Holmdel, NJ 07733 > >>Tel: +1 732 949 8657 > >>Fax: + 1 732 949 8569 > >>e-mail: rrroy(a)att.com > >> > >> > >>> ---------- > >>> From: Sakae OKUBO[SMTP:okubo@GITI.OR.JP] > >>> Reply To: Mailing list for parties associated with ITU-T Study > Group > >>> 16 > >>> Sent: Thursday, June 25, 1998 11:49 PM > >>> To: ITU-SG16(a)MAILBAG.INTEL.COM > >>> Subject: Report of the Cannes meeting > >>> > >>> Dear Q.12-14/16 experts, > >>> > >>> I have uploaded draft report of the Cannes meeting (APC-1425) at the > >>> /Incoming directory. > >>> > >>> ftp://standard.pictel.com/avc-site/Incoming/APC-1425_w97.zip > >>> /APC-1425_w95.zip > >>> > >>> w97 is original, editing TD-20 (Q.12), TD-21 (Q.13) and TD-22 (Q.14) > >>> with Word 97. w95 is a version converted into Word 6/95; there are > >>> obvious errors in section numbering and figures. > >>> > >>> Please review it in a week time, and give me any comments. I will then > >>> complete it, uploade it at /9806_Can directory and send its copies to > >>> the SG16 management. > >>> > >>> Best regards, > >>> > >>> Sakae OKUBO (Mr.) > >>> *********************************************************** > >>> Waseda Research Center > >>> Telecommunications Advancement Organization of Japan (TAO) > >>> 5th Floor, Nishi-Waseda Bldg. > >>> 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo > >>> 169-0051 Japan > >>> Tel: +81 3 5286 3830 > >>> Fax: +81 3 5287 7287 > >>> e-mail: okubo(a)giti.or.jp > >>> *********************************************************** > >>> > >> > >> > > > >***************************************************** > >*** +1-503-264-8816(voice) Intel - Hillsboro, OR. > > *** > >*** mailto:jim.toga@intel.com mailto:james.toga@itu.ch > >*** > >*** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 *** > >***************************************************** > > >

1 0

Re: Report of the Cannes meeting
by Pete Cordell 01 Jul '98

01 Jul '98

My understanding of the meeting was that APC-1422 was considered as good a place as any to start with a development, but there was acceptance that the final result may differ radically from what is in APC-1422, and we didn't want to preclude any other solution that we might find that was either already written, so somehow fitted our needs better than the framework that was out lined in APC-1422. It's my recollection that it was the view of the Intel delegates that this was a satisfactory situation. Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Jim Toga[SMTP:jim.toga@INTEL.COM] >Sent: 29 June 1998 21:51 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: Report of the Cannes meeting > >Dear Mr Roy, > >Although I was unable to attend the meeting in Cannes, I have read all >the >previous reports and have spoken to a number of people that attended. >There were many discussions during the meeting, which are summarized >in >the meeting report without re-hashing every detail. My understanding is >that there were no objections from _anyone_ else at the meeting to >progressing the work that has been started in APC-1422. The intent >will be >to have both telephone and email exchanges to further develop this >work. >I would look forward to having your constructive input as we move >forward. >In the spirit of this, I would like to elicit your input here. > >I would like to point out a couple of misconceptions you might have >based >upon the text below and ask you for some concrete proposals in areas >where >you feel they're needed... > >Best Regards, >jimt. > > >[SNIP] > >> >>Section 5.5.4 H.225.0 V3 Annex G (GK to GK Communications) >> >>APC-1385 [AT&T] "Framework for H.323 Inter-Gatekeeper Communications" >> >>Mr. Roy also pointed out the following: > >If these points were raised in the APC document and covered during the >meeting why do they need to be called out explicitly in the meeting >report? > The list of contributed documents is part of the meeting. > >> >> * H.323 signaling schemes that were developed for >>H.323v1 in view of the LAN-based single GK model > >Both v1 and v2 have never limited GK deployment to one entity (on the >LAN >or any other topology) The defined signalling for address resolution >allows for N gatekeepers. > >>(signaling schemes in >>H.323v2 also remain almost the same so far the inter-GK communication is >>concerned) may not be good enough to satisfy all needs when it is applied in >>the context of multiple gatekeeper environment with different inter-GK >>architectures: Distributive, Centralized, and Hybrid (Distributive + >>Centralized). > >(I think you mean 'Distributed' above) In any case, these different >modes >of operation define models with respect to _media_ distribution, not >control. In this case they would (and do) affect the operation of an >MCU. >(this is not to say that the MCU can't be co-located with the GK). > >V1 and V2 (and certainly the intent with V3) allow for many different >GK >topologies with hierarchical being one of the more general ones. Flat >peer-peer models may be accomplished by having a degenerative >'hiearchy' >with a depth of 1. > >> * Each inter-GK architecture may need different >>signaling schemes in order to optimize the use of communication resources >>especially in the context large networks for both connectionless and >>connection oriented networks. > >Can you eloborate on this? Are you simply saying that we need to allow >both UDP and TCP signalling (which is in fact specified in section 4 of >APC-1422). > > >> >>APC-1422 [Intel] "Proposal and General Comments for Inter-Gatekeeper >>Communications" >> >>During the discussion of Intel's contribution, Mr. Roy also pointed out that >>this proposal appears to have the following limitations: >> >> * The relationship between the zone (or internal) and >>the border (or domain) gatekeeper is not defined: is it hierarchical or >>what? > >As described in section 2 of APC-1422 the only difference (in terms of >protocol interactions) between a GK acting as 'border GK' and an >'internal' GK is that fact that the border GKs may communicate with >border >GKs from other administrative domains. There are no specific models of >deployment within an admistrative domain. Some organizaitons will >choose >to develop a hierachical model, others may choose to have a star >topology, >or perhaps a flat domain. It makes no difference to the signalling >between >administrative domains and the current signalling can facilitate all of >these models. Can you offer any specific topologies that you believe >will >not work and cannot exploit this signalling? > >> * Does it mandates the use of proprietary protocols >>between the zone (or internal) and domain (or border) gatekeeper? > >It certainly does not _disallow_ proprietary protocols, but the intent >would be to support standard messages internal to an adminstrative >domain >(which may be made up of a number of zones BTW...) as well as using >these >standard messages between administrative domains. > > >> * The relationship between the multiple domain >>gatekeepers has not been defined: how communications occur in view of the >>multiple domain gatekeepers? > >The definition of 'relationship' is multi-faceted. Many of the aspects >of >a 'relationship' may in fact be business related, and outside this >realm. >One of the points of annex G is to provide some signalling which will >allow >administrative domains (again an organizational term, not a formal >H.323 >topology term) to exchange information so that they can define the >"relationship between the multiple domain..." > > > >> * As if it mandates a specific implementation scheme >>that may limit its scalability once one starts to use the gatekeeper >>discovery, address translation, admission control, and/or bandwidth/QOS >>control signaling messages for this particular architecture while a large >>network that may use highly distributive, centralized, and hybrid inter-GK >>architecture. > >I'm really not sure what you asking/saying here...can you clarify this? > >> >>Therefore, Mr. Roy has the following view: >> >> * It requires a fundamental understanding of the >>logical relationships for inter-GK communications in view of the >>distributive, centralized, and hybrid inter-GK architecture that might be >>scaleable in view of large networks for both connectionless and connection >>oriented networking environment. > >I think you mixing a number of things here (some of which have no >relevance). Can you break this up unto a number simple points - so >that a >simple person such as I can understand? :-) > > >> * AT&T's contribution (APC-1382) has been the first >>step in that direction. > >You may note that a number of the definitions and clarificaitons from >Yokuska to Cannes were a direct result of APC-1382 - thank you. > >> >>---------------------------------------------------------------------------- >>---------------------------------------------------------------------------- >>--- >> >>I would appreciate a prompt action from your end. >> >>Sincerely, >> >>Radhika R. Roy >>AT&T >>Room 1K-330 >>101 Crawfords Corner Road >>Holmdel, NJ 07733 >>Tel: +1 732 949 8657 >>Fax: + 1 732 949 8569 >>e-mail: rrroy(a)att.com >> >> >>> ---------- >>> From: Sakae OKUBO[SMTP:okubo@GITI.OR.JP] >>> Reply To: Mailing list for parties associated with ITU-T Study Group >>> 16 >>> Sent: Thursday, June 25, 1998 11:49 PM >>> To: ITU-SG16(a)MAILBAG.INTEL.COM >>> Subject: Report of the Cannes meeting >>> >>> Dear Q.12-14/16 experts, >>> >>> I have uploaded draft report of the Cannes meeting (APC-1425) at the >>> /Incoming directory. >>> >>> ftp://standard.pictel.com/avc-site/Incoming/APC-1425_w97.zip >>> /APC-1425_w95.zip >>> >>> w97 is original, editing TD-20 (Q.12), TD-21 (Q.13) and TD-22 (Q.14) >>> with Word 97. w95 is a version converted into Word 6/95; there are >>> obvious errors in section numbering and figures. >>> >>> Please review it in a week time, and give me any comments. I will then >>> complete it, uploade it at /9806_Can directory and send its copies to >>> the SG16 management. >>> >>> Best regards, >>> >>> Sakae OKUBO (Mr.) >>> *********************************************************** >>> Waseda Research Center >>> Telecommunications Advancement Organization of Japan (TAO) >>> 5th Floor, Nishi-Waseda Bldg. >>> 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo >>> 169-0051 Japan >>> Tel: +81 3 5286 3830 >>> Fax: +81 3 5287 7287 >>> e-mail: okubo(a)giti.or.jp >>> *********************************************************** >>> >> >> > >***************************************************** >*** +1-503-264-8816(voice) Intel - Hillsboro, OR. > *** >*** mailto:jim.toga@intel.com mailto:james.toga@itu.ch >*** >*** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 *** >***************************************************** >

1 0

H.324 and laptop kits
by Mathieu Weill 01 Jul '98

01 Jul '98

Currently testing some H.324 and H.323 applications, and how they interwork, I am looking for H.324 compliant videoconferencing kits, with camera, software, modem and so on that would be available in Europe. Has anyone details about such products? I also want to set up a demonstration of H.323 or H.324 using a notebook and I'm looking for a kit that could be adapted to both standards, the main concern being the H.324 compatibility of the modem and its tying to the software. Any information would be most valuable Thanks Mathieu Weill Mathieu_Weill(a)inmarsat.org Reply by email please

1 0

Re: ASN.1 accross revisions
by Pete Cordell 01 Jul '98

01 Jul '98

Bancroft, Security is an optional feature, so no endpoint should be required to send ICVs. Does that help, or ruin your plan!? Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Bancroft Scott[SMTP:baos@OSS.COM] >Sent: 30 June 1998 21:21 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: ASN.1 accross revisions > >On Tue, 30 Jun 1998, Pete Cordell wrote: > >> I admit that I am only just hanging in there with this debate, but I >> think I have a possible solution 5 to throw in as a contender. >> >> Looking at the problem a bit laterally, we have RasMessage in UDP >> packets that we want to sign, and H323-UserInformation in the UUIE that >> we want to sign. Currently these are the only chunks of ASN.1 in these >> fields. >> >> We could add a second piece of ASN.1 into these fields (UDP packet and >> UUIE) that contains the signatures, such as: >> >> H323Extra ::= CHOICE >> { >> icv ICV, >> ... >> } >> >> This would be a separate ASN.1 tree. Therefore in a RAS UDP packet you >> would get: >> >> RasMessage chunk of ASN.1 >> H323Extra chunk of ASN.1 typically containing signature >> >> Similarly in the UUIE, you would have >> >> H323-UserInformation chunk of ASN.1 >> H323Extra chunk of ASN.1 >> >> Note that all the key ids and time stamps etc., would remain in the >> RasMessage and H323-UserInformation parts (so they get signed). >> >> I agree this is not beautiful, but it does not require multiple ASN.1 >> encodings, and doesn't radically change the format of the message >> depending on whether you want to sign it or not (as solution 4 seems >> to). > >This crossed my mind a couple days ago, but it is not clear how this >would >be backward compatible. That is, how would an older version handle >this >added information that comes after the H323-UserInformation? I like >the >general idea, but if I am not mistaken it is not backward compatible. > >I have an idea as to how to do as you suggest in a backward compatible >manner, but before I go down that path I need to know the answer to >the question: Are the most recent implementations that know of H.323 >required to transmit an ICV with each RasMessage or >H323-UserInformation? > >------------------------------------------------------------------------ >-- >Bancroft Scott Toll Free >:1-888-OSS-ASN1 >Open Systems Solutions, Inc. >International:1-609-987-9073 >baos(a)oss.com Tech Support >:1-732-249-5107 >http://www.oss.com Fax >:1-732-249-4636 >

1 0

Re: Q11-14 Joint Rapporteur Meeting
by Sakae OKUBO 01 Jul '98

01 Jul '98

Dear Mr. Tosco, >>I confirm the possibility of having the Q11-14 joint Rapporteur meeting >>at CSELT. >>...... Thank you very much for your kind offer. Rapporteurs of Q.11-14/16 would like to gratefully accept this offer. The date will be 17 (Tuesday) - 20 (Friday) November 1998. Let us fix further details when we meet at the September SG16 meeting. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Re: ASN.1 accross revisions
by Pete Cordell 30 Jun '98

30 Jun '98

Dear All, I admit that I am only just hanging in there with this debate, but I think I have a possible solution 5 to throw in as a contender. Looking at the problem a bit laterally, we have RasMessage in UDP packets that we want to sign, and H323-UserInformation in the UUIE that we want to sign. Currently these are the only chunks of ASN.1 in these fields. We could add a second piece of ASN.1 into these fields (UDP packet and UUIE) that contains the signatures, such as: H323Extra ::= CHOICE { icv ICV, ... } This would be a separate ASN.1 tree. Therefore in a RAS UDP packet you would get: RasMessage chunk of ASN.1 H323Extra chunk of ASN.1 typically containing signature Similarly in the UUIE, you would have H323-UserInformation chunk of ASN.1 H323Extra chunk of ASN.1 Note that all the key ids and time stamps etc., would remain in the RasMessage and H323-UserInformation parts (so they get signed). I agree this is not beautiful, but it does not require multiple ASN.1 encodings, and doesn't radically change the format of the message depending on whether you want to sign it or not (as solution 4 seems to). I hope this sounds vaguely as though I know what I'm talking about!!! Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Bancroft Scott[SMTP:baos@OSS.COM] >Sent: 28 June 1998 17:35 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: ASN.1 accross revisions > >On Wed, 24 Jun 1998, Pekka Pessi wrote: > >> The current H.225.0 algorithm for calculating the ICV does not work well >> with the PER extension mechanism. > >Agreed. > >> The above algorithm (AFAIK I have understood it correctly) assumes that >> the sender and receiver can encode the PDU exactly in the same way. >>It is >> a reasonable assumption, as PER produces only one possible (canonical) >> encoding for given PDU. > >PER is not inherently canonical. To get canonical behavior you have to >either do as this set of standards have been doing and stay away from >types REAL and SET OF, or you have to use Canonical PER Aligned or >Canonical PER Unaligned. > >> However, there is a serious problem: the >> canonical representation changes if the ASN.1 SEQUENCE type is extended >> later. > >Correct. > >> When encoding this, the length of extension bitfield is 2. However, >> recipient B is using extended version of Foo like this: >> >> Foo ::= SEQUENCE >> { >> bar INTEGER (0..127), >> ..., >> baz INTEGER (0..255) OPTIONAL, >> integrityCheckValue ICV OPTIONAL, >> importantExtension SomeType OPTIONAL >> } > >A lot of research has gone into how to most effectively create ICV's >by the designers of the Secure Electronic Payment protocol (SET), >e-check protocol and others. That's why in SET you see the likes of: > > UnsignedCertificate ::= SEQUENCE { > version [0] CertificateVersion, > serialNumber CertificateSerialNumber, > signature AlgorithmIdentifier >{{SignatureAlgorithms}}, > issuer Name, > validity Validity, > subject Name, > subjectPublicKeyInfo >SubjectPublicKeyInfo{{SupportedAlgorithms}}, > issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, > subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, > extensions [3] Extensions -- Required for SET >usage > } > > -- Compute the encrypted hash of this value if issuing a >certificate, > -- or recompute the issuer's signature on this value if validating >a > -- certificate. > -- > EncodedCertificate ::= TYPE-IDENTIFIER.&Type (UnsignedCertificate) > > Certificate::= SIGNED { > EncodedCertificate > } ( CONSTRAINED BY { -- Verify Or Sign Certificate -- } ) > > SIGNED { ToBeSigned } ::= SEQUENCE { > toBeSigned ToBeSigned, > algorithm AlgorithmIdentifier {{SignatureAlgorithms}}, > signature BIT STRING > } > >The key thing to notice is that they DO NOT attempt to sign the >unencoded >certificate (i.e., UnsignedCertficate). The actual signing occurs on >an >open type which has been constrained to carry the value of the >particular >type that is to be signed (TYPE-IDENTIFIER.&Type >(UnsignedCertificate)). >In so doing, a) they clearly identify that the type should be encoded >independently of the ICV, b) they avoid having to do a re-encode of the >data after the CRV has been calculated, c) the type to which the ICV is >to >be applied can be extended with no problem, and d) they prepared >themselves for the possible use of PER by utilizing an open type to >carry >the value to be signed - something that is *crucial* to signing >PER-encoded data. > >> Problems with Non-OPTIONAL Extensions >> >> Another problem with some ASN.1 compilers is inclusion of non-OPTIONAL >> extensions. Let us assume that software C uses following ASN.1 >>definition >> for Foo: >> >> Foo ::= SEQUENCE >> { >> bar INTEGER (0..127), >> ..., >> baz INTEGER (0..255) OPTIONAL, >> integrityCheckValue ICV OPTIONAL, >> importantExtension SomeType OPTIONAL, >> criticalExtension OtherType >> } >> >> There are two kinds of problems with an extension like >>criticalExtension. >> First, the encoder may try to ensure that all encoded PDUs conform >>to the >> specification and signal an error when a PDU without >>criticalExtension is >> encoded. > >That's the correct behavior only if you are originating a message. >Encoders should not complain about criticalExtension being absent >if they are not originating the message. > >> Another problem is that the intermediate representation produced >> by the ASN.1 compiler may not provide means for application to express >> that criticalExtension is not present. (In other words, the produced >> structure usually contains a flag telling whether an optional field is >> present or not. Such flags are not included when the field is not >> optional.) > >It is an error for encoders not to encode extension additions that are >mandatory but missing if such extension additions do not occur within >an >extension addition group and if no other extension addition values >follow >the missing but mandatory extension. (I don't believe H.225 employs >extension addition groups (i.e., the "[[" and "]]" notation.)) This is >indicated in X.680:1997 clause 7.1 (X.680:1994 Amd.1 clause 6.1) which >unconditionally mandates that it be possible for decoded components >that >are defined to both the sender and receiver be re-encodable by the >receiver. > >> The presense or absence of the OPTIONAL flag in an extension does not >> change the PER encoding of the SEQUENCE. In order to avoid previously >> mentioned problems, application may use a version of ASN.1 notation that >> has extra OPTIONAL keyword after each extension. > >Neat! A nice and simple solution for use with such compilers. > >> Solution 1: Clarification to the PER Encoding Process >> >> The text in PER document (X.691, 1994) is somewhat ambiguous how many >> bits should be included in the extension present bitfield of >>SEQUENCE. To >> quote verbatim: "Let the number of extension additions in the type being > >Note that it says the *type* being encoded, not the value. That's >distinct from the value. > >> encoded be "n", then a bit-field with "n" bits shall be produced for >> addition to the field-list." (Is the "type being encoded" the abstract >> syntax or an actual value like { bar 1, baz 2 }?) However, the 0 >>bits at >> the end of extension present bitfield can be left out without changing >> the resulting semantics: the corresponding extensions are not present. > >It is true that they can be left out without changing the semantics, >but >this is not what PER mandates (It should have mandated what you >suggest, >but hindsight is 20-20.) Unless everyone encodes according to PER its >canonical nature will be lost. > >> As a result, the PER encoding does not change after a new extension >> is added to the ASN.1 specification. >> This solution, while leaving H.225.0 v2 protocol as it is, requires >> however changes to some existing ASN.1 compilers, and in a pessimal >>case, >> to the X.691 standard text, too. > >Yes, this would work, but as you point out, it requires that PER be >changed. > >> Solution 2: Hack >> >> The receiving application does not decode and the re-encode the PDU, but >> rather removes the ICV from the encoded PDU. In practice, this >>requires that >> application can identify PER-encoded fields within the PDU and it can >> regenerate them, i.e. it has effectively the same functionality as >>a PER >> encoder/decoder. >> >> Solution 3: Calculating ICV Differently >> >> The following algorithm for generating and checking the ICV makes it >> possible to avoid all the previously mentioned problems. The >>problems are >> avoided by breaking the protocol layering, the application changes >>directly >> the PER-encoded PDU: >> >> integrityCheckValue - provides improved message integrity/message >> authentication of the RAS messages. The cryptographically based >> integrity check value is computed by the sender applying a >> negotiated integrity algorithm and the secret key upon the entire >> message. Prior to integrityCheckValue computation an ICV with a >> previously agreed magic value (or key when using MDC) will be >> inserted to this field. The magic value will contain same >> algorithmOID and exactly as many bits in the icv BIT STRING as the >> computed value. After computation, the sender replaces the magic >> value with the computed integrity check value and transmits >> message. The receiver decodes message, replaces the received >> integrity value with the magic value, calculates the ICV and >> compares it with the received value. >> >> NOTE: The sender or receiver can encode the ICV separately and replace >> it directly within the encoded PDU, when the magic ICV and computed >> ICV have exactly the same length. When replacing ICV value within >> an encoded PDU, re-encoding the whole PDU can be avoided. > >I don't like this too much because of the possibility, though low, >of the data containing the magic ICV value. Still I prefer it to >solutions 1 and 2. > >> Solution 4: >> >> Fourth alternative is to treat encoded RasMessage as octet string. IVC >> can be calculated over that octet string and appended to the PDU on >> separate layer. E.g., RAS PDU could be defined as follows: >> >> RasMessage ::= CHOICE { >> -- all previous RasMessage CHOICEs are here >> authenticatedRasMessage SEQUENCE { >> plainRasMessage OCTET STRING, >> ivc IVC, >> ... >> } >> } > >This is effectively what is done in SET and other security-conscious >protocols, though they typically use open type instead of octet string. > >Alternate Solution 1: > >To do exactly as is done in SET, you would define RasMessage without an >ICV, and define a container, AuthenticatedRasMessage, say, that carries >the encoded RasMessage as an open type value (i.e., octet-aligned, and >padded with 0-bits at the end to ensure that it is an integral multiple >of >8 bits) followed by the ICV value. In other words: > > AuthenticatedRasMessage ::= SEQUENCE { > plainRasMessage TYPE-IDENTIFIER.&Type (RasMessage), > ivc IVC > } > >Using this approach, the RasMessage (which would be defined without an >ICV) would be encoded, then the ICV would be calculated using the >encoded >RasMessage, then AuthenticatedRasMessage would be encoded. This >approach >is efficient because RasMessage does not have to be encoded without >the ICV value then re-encoded with it, nor does it require that the >encoded value be tinkered with in any way. > >This technique is good only if backward compatibility is not an issue >(i.e., if you don't already have a deployed version of H.225), for the >open type carries a length component than an ordinary encoded >RasMessage >does not have. > >Alternate Solution 2: > >If backward compatibility is an issue then Solution 4 above is a better >alternative, though I would change it to: > > RasMessage ::= CHOICE { > -- all previous RasMessage CHOICEs are here > authenticatedRasMessage AuthenticatedRasMessage > } > >Open type and octet string produce identical encodings, but I have a >preference for the open type notation because it allows you to clearly >identify what the value is - in this case an encoded RasMessage, and >because it can simplify implementations that may not have a need to >authenticate the RasMessage upon decoding (e.g., line monitors.) > >I am not intimate with H.225, so I don't know for sure of Solution 4 >or this minor variation is backward compatible. It is if the ICV was >just introduced, else I don't think it is. > >------------------------------------------------------------------------ >-- >Bancroft Scott Toll Free >:1-888-OSS-ASN1 >Open Systems Solutions, Inc. >International:1-609-987-9073 >baos(a)oss.com Tech Support >:1-732-249-5107 >http://www.oss.com Fax >:1-732-249-4636 >

2 1

Re: Report of the Cannes meeting
by Roy, Radhika R, ALTEC 30 Jun '98

30 Jun '98

Dear Mr. Toga: Yes, I agreed to bring more concrete proposals along the line that I stated. A good amount of work is needed in this area. Sincerely, Radhika R. Roy AT&T > ---------- > From: Jim Toga[SMTP:jim.toga@INTEL.COM] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Monday, June 29, 1998 3:51 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Report of the Cannes meeting > > Dear Mr Roy, > > Although I was unable to attend the meeting in Cannes, I have read all the > previous reports and have spoken to a number of people that attended. > There were many discussions during the meeting, which are summarized in > the meeting report without re-hashing every detail. My understanding is > that there were no objections from _anyone_ else at the meeting to > progressing the work that has been started in APC-1422. The intent will > be > to have both telephone and email exchanges to further develop this work. > I would look forward to having your constructive input as we move forward. > In the spirit of this, I would like to elicit your input here. > > I would like to point out a couple of misconceptions you might have based > upon the text below and ask you for some concrete proposals in areas where > you feel they're needed... > > Best Regards, > jimt. > > > [SNIP] > > > > >Section 5.5.4 H.225.0 V3 Annex G (GK to GK Communications) > > > >APC-1385 [AT&T] "Framework for H.323 Inter-Gatekeeper Communications" > > > >Mr. Roy also pointed out the following: > > If these points were raised in the APC document and covered during the > meeting why do they need to be called out explicitly in the meeting > report? > The list of contributed documents is part of the meeting. > > > > > * H.323 signaling schemes that were developed for > >H.323v1 in view of the LAN-based single GK model > > Both v1 and v2 have never limited GK deployment to one entity (on the LAN > or any other topology) The defined signalling for address resolution > allows for N gatekeepers. > > >(signaling schemes in > >H.323v2 also remain almost the same so far the inter-GK communication is > >concerned) may not be good enough to satisfy all needs when it is applied > in > >the context of multiple gatekeeper environment with different inter-GK > >architectures: Distributive, Centralized, and Hybrid (Distributive + > >Centralized). > > (I think you mean 'Distributed' above) In any case, these different > modes > of operation define models with respect to _media_ distribution, not > control. In this case they would (and do) affect the operation of an MCU. > (this is not to say that the MCU can't be co-located with the GK). > > V1 and V2 (and certainly the intent with V3) allow for many different GK > topologies with hierarchical being one of the more general ones. Flat > peer-peer models may be accomplished by having a degenerative 'hiearchy' > with a depth of 1. > > > * Each inter-GK architecture may need different > >signaling schemes in order to optimize the use of communication resources > >especially in the context large networks for both connectionless and > >connection oriented networks. > > Can you eloborate on this? Are you simply saying that we need to allow > both UDP and TCP signalling (which is in fact specified in section 4 of > APC-1422). > > > > > >APC-1422 [Intel] "Proposal and General Comments for Inter-Gatekeeper > >Communications" > > > >During the discussion of Intel's contribution, Mr. Roy also pointed out > that > >this proposal appears to have the following limitations: > > > > * The relationship between the zone (or internal) > and > >the border (or domain) gatekeeper is not defined: is it hierarchical or > >what? > > As described in section 2 of APC-1422 the only difference (in terms of > protocol interactions) between a GK acting as 'border GK' and an > 'internal' GK is that fact that the border GKs may communicate with border > GKs from other administrative domains. There are no specific models of > deployment within an admistrative domain. Some organizaitons will choose > to develop a hierachical model, others may choose to have a star topology, > or perhaps a flat domain. It makes no difference to the signalling > between > administrative domains and the current signalling can facilitate all of > these models. Can you offer any specific topologies that you believe > will > not work and cannot exploit this signalling? > > > * Does it mandates the use of proprietary protocols > >between the zone (or internal) and domain (or border) gatekeeper? > > It certainly does not _disallow_ proprietary protocols, but the intent > would be to support standard messages internal to an adminstrative domain > (which may be made up of a number of zones BTW...) as well as using these > standard messages between administrative domains. > > > > * The relationship between the multiple domain > >gatekeepers has not been defined: how communications occur in view of the > >multiple domain gatekeepers? > > The definition of 'relationship' is multi-faceted. Many of the aspects of > a 'relationship' may in fact be business related, and outside this realm. > One of the points of annex G is to provide some signalling which will > allow > administrative domains (again an organizational term, not a formal H.323 > topology term) to exchange information so that they can define the > "relationship between the multiple domain..." > > > > > * As if it mandates a specific implementation > scheme > >that may limit its scalability once one starts to use the gatekeeper > >discovery, address translation, admission control, and/or bandwidth/QOS > >control signaling messages for this particular architecture while a large > >network that may use highly distributive, centralized, and hybrid > inter-GK > >architecture. > > I'm really not sure what you asking/saying here...can you clarify this? > > > > >Therefore, Mr. Roy has the following view: > > > > * It requires a fundamental understanding of the > >logical relationships for inter-GK communications in view of the > >distributive, centralized, and hybrid inter-GK architecture that might be > >scaleable in view of large networks for both connectionless and > connection > >oriented networking environment. > > I think you mixing a number of things here (some of which have no > relevance). Can you break this up unto a number simple points - so that a > simple person such as I can understand? :-) > > > > * AT&T's contribution (APC-1382) has been the first > >step in that direction. > > You may note that a number of the definitions and clarificaitons from > Yokuska to Cannes were a direct result of APC-1382 - thank you. > > > > >------------------------------------------------------------------------- > --- > >------------------------------------------------------------------------- > --- > >--- > > > >I would appreciate a prompt action from your end. > > > >Sincerely, > > > >Radhika R. Roy > >AT&T > >Room 1K-330 > >101 Crawfords Corner Road > >Holmdel, NJ 07733 > >Tel: +1 732 949 8657 > >Fax: + 1 732 949 8569 > >e-mail: rrroy(a)att.com > > > > > >> ---------- > >> From: Sakae OKUBO[SMTP:okubo@GITI.OR.JP] > >> Reply To: Mailing list for parties associated with ITU-T Study > Group > >> 16 > >> Sent: Thursday, June 25, 1998 11:49 PM > >> To: ITU-SG16(a)MAILBAG.INTEL.COM > >> Subject: Report of the Cannes meeting > >> > >> Dear Q.12-14/16 experts, > >> > >> I have uploaded draft report of the Cannes meeting (APC-1425) at the > >> /Incoming directory. > >> > >> ftp://standard.pictel.com/avc-site/Incoming/APC-1425_w97.zip > >> /APC-1425_w95.zip > >> > >> w97 is original, editing TD-20 (Q.12), TD-21 (Q.13) and TD-22 (Q.14) > >> with Word 97. w95 is a version converted into Word 6/95; there are > >> obvious errors in section numbering and figures. > >> > >> Please review it in a week time, and give me any comments. I will then > >> complete it, uploade it at /9806_Can directory and send its copies to > >> the SG16 management. > >> > >> Best regards, > >> > >> Sakae OKUBO (Mr.) > >> *********************************************************** > >> Waseda Research Center > >> Telecommunications Advancement Organization of Japan (TAO) > >> 5th Floor, Nishi-Waseda Bldg. > >> 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo > >> 169-0051 Japan > >> Tel: +81 3 5286 3830 > >> Fax: +81 3 5287 7287 > >> e-mail: okubo(a)giti.or.jp > >> *********************************************************** > >> > > > > > > ***************************************************** > *** +1-503-264-8816(voice) Intel - Hillsboro, OR. > *** > *** mailto:jim.toga@intel.com mailto:james.toga@itu.ch > *** > *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 *** > ***************************************************** >

1 0