- sg16-avd - lists.packetizer.com

Annex G Conference Call
by Orit Levin 09 Jul '98

09 Jul '98

Hello again! What happened to the Conference Call? Was it my fault? Did I talk too much (sorry about that)? My last words were (I am not sure you could hear) there are two things to do: 1. Intel's proposal can be adopted (as "an interim" solution for specific "address resolution" problem) , but in order to be interoperable and useful it should be, in my opinion, more tide: - less flexible syntax - defined push mechanism Jim, do you mind send to you some concrete remarks? What do you think about using NAI instead? 2. In parallel, I believe, we have start working towards the more complete solution, starting from the "architectural" definition and things that we want to accomplish "as far as we can see now". Orit Levin RADVision Inc., 575 Corporate Drive - Suite 420 Mahwah, NJ 07430 Tel: 201-529-4300 (230) Fax: 201-529-3516

2 1

H.235 & Implementors Guide
by Orit Levin 09 Jul '98

09 Jul '98

Jim! Just before the closure of Implementors Guide regarding the 4.2 EP-GK Authentication (Non-Subscription Based) Is our understanding of the XOR'ing algorithm right? See below: 1. Take the GK Id (GKID) as a sequence of BMP characters (each 16 bit long) of length N. 2. Take the 16 bit long Random value (RND) N times to build the string of the same length as GKID above. 3. Take the 16 bit long requestSeqNum (SQN) N times to build the string of the same length as GKID above. 4. XOR bitwise three of these same length bit strings. GKID !BMP1 !BMP2 !BMP3 !BMP4 !BMP5 ! XOR RND 16 bit !RND16!RND16!RND16!RND16 !RND16! XOR SQN 16 bit !SQN16!SQN16!SQN16!SQN16!SQN16! May be it would be useful to put such an explanation into the Implementors Guide? Orit Levin RADVision Inc., 575 Corporate Drive - Suite 420 Mahwah, NJ 07430 Tel: 201-529-4300 (230) Fax: 201-529-3516

1 0

Re: H.225 clarifications
by Orit Levin 08 Jul '98

08 Jul '98

Glen! (1) and (2) together (filled with zeros) Definitely not (3), since V.2 is already deployed. Orit Levin RADVision Inc., 575 Corporate Drive - Suite 420 Mahwah, NJ 07430 Tel: 201-529-4300 (230) Fax: 201-529-3516 >>Item 2: >>The callIdentifier field is not currently optional in the IRQ. I see >>these possibilities for callIdentifier in the case of a request for >>information about all calls: >> >>1) state that if callReferenceValue is 0, this field is to be ignored >>but filled with some data >> >>2) state that callIdentifier should be set to some dummy value, such as >>all zeros >> >>3) change the ASN.1 definition so that callIdentifier is OPTIONAL, and >>add appropriate text regarding its use in the field definition >> >>Since callIdentifier is defined as a SEQUENCE to allow possible future >>expansion, I'd suggest option 1. >> >>Please comment. >>

1 0

Re: H.324 and laptop kits
by Jong Kim 07 Jul '98

07 Jul '98

Dear Mathieu: If you got some information on teleconferencing camera, would you possibly forward it to me? I am developing teleconferencing product on PC, so your information will be very appreciated. Thanks. Jong-il Accelerix Inc., http://www.accelerix.com Austin Texas > -----Original Message----- > From: Mathieu Weill [SMTP:Mathieu_Weill@INMARSAT.ORG] > Sent: July 1, 1998 10:39 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.324 and laptop kits > > 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

ICV: A request for closure...
by Jim Toga 07 Jul '98

07 Jul '98

All interested parties.... I feel as though we are quite far from reaching a solution to the ICV coding problem. There were a number of proposals made some providing solutions that may or may not have been backward compatible. As I have approximately 72 hours to get this into the white paper of the Implementers guide... we need to come to closure. An alternative is to 'fix' this in rev3 of H.225.0 (when and/if we include non-repudiation). One argument for this is that if you want ICV/non-repudiation you may run IPSec or some other security 'tunnel' which keeps the complexitites from H.225.0 and ASN.1 Thoughts?.... (clock is ticking) jimt. ***************************************************** *** +1-503-264-8816(voice) Intel - Hillsboro, OR. *** *** mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 *** *****************************************************

1 0

H.225.0 Annex G discussion
by Glen Freundlich 07 Jul '98

07 Jul '98

There will be a conference call on Thursday, 9 July, at 7:00am Pacific Time (10:am Eastern Time) to discuss H.225.0 Annex G. We've reserved an audio bridge with enough ports to handle the number of people who responded to the first notice of this topic. The bridge number is +1 916 356 9200, passcode 9774794 (conference name is "H.323 Annex G", chair is Jim Toga). This call will be limited to 1 hour. Minutes from the call will be published to the SG16 email list. The goal of this call will be to get work going on Annex G. A tentative agenda is: - review the work that's been done so far - terms of reference - system organization - definitions - APC-1422 - what's up with Diameter - decide what we'd like to see for determination in September (i.e., set the initial scope of work) - enumerate open issues - set some kind of work plan - prioritize open issues - decide who will work specific issues - calls every 2 weeks Good preparation material would be the existing Annex G (APC-1375 from Cannes), APC-1422, APC-1385, APC-1407, APC-1414, TD-27, and the terms of reference from the Yokosuka meeting (TD-17 from Yokosuka). 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

Next pass of Implementers Guide
by Jim Toga 06 Jul '98

06 Jul '98

Greetings, Attached please find the updated Rev2 Implementers Guide. All of the changes highlighted in gray text are post Cannes meeting. I have not incorporated any of the ICV changes as it doesn't seem like we have reached any clear solution...... Please get feedback to me before Thursday PM, as I need to send the white document into the TSB. Best Regards, jimt. ***************************************************** *** +1-503-264-8816(voice) Intel - Hillsboro, OR. *** *** mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 *** *****************************************************

1 0

H.225.0 clarifications
by Glen Freundlich 06 Jul '98

06 Jul '98

A couple clarifications may be needed regarding the IRQ message in H.225.0. Item 1: The definition of callReferenceValue currently states "If zero, this message is interpreted as a request for an IRR for each call the terminal is active on." The IRR defines perCallInfo as a SEQUENCE OF SEQUENCE and I seem to recall that the original intent was to be able to pass information about multiple calls within a single IRR message. So, I'd suggest changing the definition to "If zero, this message is interpreted as a request for perCallInfo for every call that is active at the endpoint, and which may be sent in one or more IRRs". Item 2: The callIdentifier field is not currently optional in the IRQ. I see these possibilities for callIdentifier in the case of a request for information about all calls: 1) state that if callReferenceValue is 0, this field is to be ignored but filled with some data 2) state that callIdentifier should be set to some dummy value, such as all zeros 3) change the ASN.1 definition so that callIdentifier is OPTIONAL, and add appropriate text regarding its use in the field definition Since callIdentifier is defined as a SEQUENCE to allow possible future expansion, I'd suggest option 1. Please comment. 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

2 1

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

03 Jul '98

Bancroft and others, I take your point that putting a second piece of ASN.1 into the UUIE may jeopardize backwards compatibility. I have to admit that I have to try quite hard to read H.225 in such a way that it allows me to do this (but it is possible!!!). The basic issue is whether having read and decoded the ASN.1 in the UUIE, implementations check whether all characters in the UUIE have been used. I guess only a poll of vendors would determine whether this is the case. An alternative to adding on an extra piece of ASN.1 in the case of the Q.931 side would be to hi-jack one of the other IEs that we are unlikely to use, and use that for the signature values. For example one that we might use is "Packet Layer Binary Parameters" which has an IE value of 0x44. 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: Pete Cordell >Cc: '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

H.225.0 Annex G discussion
by Glen Freundlich 02 Jul '98

02 Jul '98

I'd like to get some traction on Annex G, and so would like to propose holding a brief (no more than 1 hour) conference call on Thursday, July 9 beginning at 7:00 am Pacific Time in the U.S. (10:00 am Eastern Time, is that 16:00 in the U.K.?). I'll send out an agenda on Monday, July 6. If you are interested in joining this call, please let me know by Monday, July 6, 14:00 Mountain Time in the U.S. so that I can arrange for a bridge with a sufficient number of ports. 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

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

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

29 Jun '98

Dear Mr. OKUBO: With respect to the report (APC-1425) of the Cannes meeting, I would appreciate if you would add the following for the completeness of the report: ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---------- 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: * H.323 signaling schemes that were developed for H.323v1 in view of the LAN-based single GK model (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). * 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. 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? * Does it mandates the use of proprietary protocols between the zone (or internal) and domain (or border) gatekeeper? * The relationship between the multiple domain gatekeepers has not been defined: how communications occur in view of the multiple domain gatekeepers? * 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. 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. * AT&T's contribution (APC-1382) has been the first step in that direction. ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- --- 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 > *********************************************************** >

2 1

Re: Report of the Cannes meeting
by Jim Toga 29 Jun '98

29 Jun '98

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: ASN.1 across revisions
by Paul Long 29 Jun '98

29 Jun '98

>From: Bancroft Scott[SMTP:baos@OSS.COM] >On Sun, 28 Jun 1998, Paul Long wrote: >> So, Bancroft, are you saying that it would be an error if FooGone, >> below, were encoded where Foo was called for? >> Foo ::= SEQUENCE >> { >> bar INTEGER (0..127), >> ..., >> baz INTEGER (0..255) OPTIONAL, >> integrityCheckValue ICV OPTIONAL, >> importantExtension SomeType OPTIONAL, >> criticalExtension OtherType >> } >> FooGone ::= SEQUENCE >> { >> bar INTEGER (0..127), >> ..., >> baz INTEGER (0..255) OPTIONAL, >> integrityCheckValue ICV OPTIONAL, >> importantExtension SomeType OPTIONAL >> } >X.691:1997 clause 24.14 (X.691:1994 Amd.1 clause "11 >Changes to SEQUENCE") stipulates that if you are originating an encoding >(i.e., not relaying it) you are required to encode criticalExtension. Right, that's what I meant. I should have said, "Are you saying that--if originating the encoding--it would be an error if FooGone were encoded where Foo was called for?" With this qualification, your answer would apparently be, "Yes, it would be an error." > >> Likewise, are you saying that it would be an error if FooOpt, below, >> were encoded, without the value of criticalExtension present, in place >> of Foo, because the extension addition is mandatory in Foo? >> FooOpt ::= SEQUENCE >> { >> bar INTEGER (0..127), >> ..., >> baz INTEGER (0..255) OPTIONAL, >> integrityCheckValue ICV OPTIONAL, >> importantExtension SomeType OPTIONAL, >> criticalExtension OtherType OPTIONAL >> } >This change to the type is transparent to the communicating peer. Indeed, >unless you go out of your to indicate to the encoder whether you are >originating and encoding it is impossible in ASN.1:1994 for an encoder to >know whether the absence of criticalExtension is an error. Hey, I just realized something. When you say, "encoder," you are referring strictly to the ASN.1 encoder, right? I often think of the encoder as the larger, "encoding entity," such as an H.323 endpoint, which usually knows more than the encoder. I think you call this the "sender." So if the encoder, using your definition, is presented with FooOpt, above, and a value is not provided to the encoder for criticalExtension, the encoder does not, of course, know that this is an error. What I'm saying is that if the sender, or encoding entity, uses FooOpt in place of Foo, and the value for criticalExtension is not present, the encoder is not at fault for producing an encoding, but the sender is at fault, because it is not using the prescribed definition of Foo for the version of the Recommendation of which it is an implementaion and which is identified in the protocolIdentifier field(s). To look at it from the other direction, the receiver, or decoding entity, doesn't care whether the encoder or the sender is at fault--it just knows that the sender is producing an incorrect encoding. >it is impossible in ASN.1:1994 for an encoder to >know whether the absence of criticalExtension is an error. In ASN.1:1997 >this imprecision is resolved by the use of version brackets. For example, >if you wrote: > > Foo ::= SEQUENCE > { > bar INTEGER (0..127), > ..., > [[, > baz INTEGER (0..255) OPTIONAL, > integrityCheckValue ICV OPTIONAL, > importantExtension SomeType OPTIONAL, > criticalExtension OtherType, > ]] > } > >it would be clear that baz - criticalExtension were all added in the same >version, so if any of the optional items are present then criticalExtension >must also be present. Can't the same thing be done in ASN.1:1994 by encapsulating the extension additions of a particular version within a SEQUENCE like this? FooEncap2 ::= SEQUENCE { bar INTEGER (0..127), ..., SEQUENCE { baz INTEGER (0..255) OPTIONAL, integrityCheckValue ICV OPTIONAL, criticalExtension OtherType } } and this? FooEncap3 ::= SEQUENCE { bar INTEGER (0..127), ..., SEQUENCE { baz INTEGER (0..255) OPTIONAL, integrityCheckValue ICV OPTIONAL }, SEQUENCE { importantExtension SomeType OPTIONAL, criticalExtension OtherType } } Seems like this would allow one to produce the same encoding with ASN.1:1994 as what would be produced by the version brackets in ASN.1:1997, or am I missing something? Perhaps this is how we should extend ASN.1 types in the future. > >> So are you saying that if an ASN.1 type in a Recommendation contains an >> extension addition, such as criticalExtension in Foo, above, an >> implementation of that Recommendation _must_ represent that extension >> addition in all encodings of that type? >It is in error only if you are originating the encoding in which >criticalExtension is defined. Okay, yes, I meant that one is originating the encoding. That's really the only way I think about encoding. Again, with this qualification, your answer would be, "Yes, it would be an error." >ASN.1:1994 does not have syntax that makes >it possible for an encoder to determine whether criticalExtension is >unconditionally mandatory (it would be if all four extension additions >were added in the same version), or if it were added after the other >extension additions (in which case it would be mandatory only if the >sender is originating the message.) I'm saying that all four are defined in the same version of ASN.1 syntax and that the sender is originating the message. > >> If so, I assume this would be because, technically, >> another type was being encoded, not the one defined in the >> Recommendation, as in "Let the number of extension additions in _the >> type being encoded_ be 'n'..." >I don't follow what you mean here. Sorry. I meant that this citation from 18.7/X.691:1994 indicates to me that, for an originator, all extension additions defined for a type must be represented--one cannot simply leave off one or more trailing extension additions from a type that is defined in the version of the Recommendation that the sender has implemented, as would be the case if FooGone were used in place of Foo, for example. Likewise, for an originator, Foo is "the type being encoded," and an invalid encoding would be produced if FooOpt was used in place of Foo, and a value was not provided for criticalExtension. Paul Long

1 0

Re: ASN.1 accross revisions
by Bancroft Scott 29 Jun '98

29 Jun '98

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: ASN.1 across revisions
by Paul Long 28 Jun '98

28 Jun '98

>From: Bancroft Scott[SMTP:baos@OSS.COM] >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. So, Bancroft, are you saying that it would be an error if FooGone, below, were encoded where Foo was called for? Foo ::= SEQUENCE { bar INTEGER (0..127), ..., baz INTEGER (0..255) OPTIONAL, integrityCheckValue ICV OPTIONAL, importantExtension SomeType OPTIONAL, criticalExtension OtherType } FooGone ::= SEQUENCE { bar INTEGER (0..127), ..., baz INTEGER (0..255) OPTIONAL, integrityCheckValue ICV OPTIONAL, importantExtension SomeType OPTIONAL } Likewise, are you saying that it would be an error if FooOpt, below, were encoded, without the value of criticalExtension present, in place of Foo, because the extension addition is mandatory in Foo? FooOpt ::= SEQUENCE { bar INTEGER (0..127), ..., baz INTEGER (0..255) OPTIONAL, integrityCheckValue ICV OPTIONAL, importantExtension SomeType OPTIONAL, criticalExtension OtherType OPTIONAL } > >> 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. So are you saying that if an ASN.1 type in a Recommendation contains an extension addition, such as criticalExtension in Foo, above, an implementation of that Recommendation _must_ represent that extension addition in all encodings of that type? IOW, although it may be "easy" to encode the type without that extension addition (the extension-addition bit-map does not contain a corresponding bit for that extension addition, the bit-map length value reflects this shortening, and the open type containing the value is not encoded), the encoding would be in error? If so, I assume this would be because, technically, another type was being encoded, not the one defined in the Recommendation, as in "Let the number of extension additions in _the type being encoded_ be 'n'..." > Paul Long

2 1