- sg16-avd - lists.packetizer.com

Re: [VideoPhone:828] [wg5-3: 1153] Bonding Manufacturers Code
by Bob Webber 01 May '98

01 May '98

Mr Holdrege's comment is partially correct: the original BONDING document had no status recognizable by ITU-T. However, ISO has specified BONDING in ISO/IEC 13871-x (corrections were made to the original ISO version of this document, so it exists for more than one value of "x"). I don't, unfortunately, have the answer to Mr Thom's question. Bob Webber PictureTel Corporation matt(a)ASCEND.COM on 05/01/98 10:37:46 AM Please respond to ITU-SG16(a)MAILBAG.INTEL.COM To: ITU-SG16(a)MAILBAG.INTEL.COM cc: (bcc: Bob Webber) Subject: Re: [VideoPhone:828] [wg5-3: 1153] Bonding Manufacturers Code BONDing is not a standard. It's an old industry specification regaring syncing multiple bearer channels. MP or Multilink PPP is IETF RFC 1990 but there are no manufacturer codes for MP. BACP is a control protocol for adding/removing links for MP. At 10:57 PM 5/1/98 +0900, Yuichiro-Tuck-Takagawa wrote: >You means Bonding for ISDN? >That is discussed by IETF:Internet Engineering Task Force. >BACP:Bandwidth Allocation Control Protocol is very common in ISDN Terminal >Adaptors or ISDN Routers in Japan. > > >Regards > > >Takagawa > > >At 09:34 98/05/01 -0800, Gary A. Thom wrote: >> Can any one point me to the person/organization that >> assigns manufacturer codes for the Bonding standards??? >> >> Thanks >> Gary >> ------------------------------------------------------ >> Name : Gary A. Thom >> Company: Delta Information Systems, Inc. >> Address: 300 Welsh Rd., Bldg 3 >> Horsham, PA 19044 USA >> Phone : +1-215-657-5270 Fax : +1-215-657-5273 >> E-mail : gthom(a)delta-info.com >> ------------------------------------------------------ >> >> >************************************************************* >Yuichiro "Tuck" Takagawa Tel:+81-30-248-6357 >Executive Manager Fax:+81-3-5359-5788 >NTT Multimedia Business Dept. takagawa(a)mbd.mbc.ntt.co.jp > >Emergency Internet Pager: 0361241374(a)page.docomonet.or.jp >Private Home Page: http://village.infoweb.or.jp/~fwbc7006/ > >Post:3-19-2 Nishi-Shinjuku, Shinjuku-ku, Tokyo163-8019, Japan > >Find my location on the "MAPION" of Cyber Map Japan by... >http://www.mapion.co.jp/cgi-bin/m?no=2b036m-22nuwy&xy=132,516 >************************************************************* > Matt Holdrege http://www.ascend.com matt(a)ascend.com

2 1

Re: [VideoPhone:828] [wg5-3: 1153] Bonding Manufacturers Code
by Bob Webber 01 May '98

01 May '98

In answer to Mr Thom's original question: Annex B of the ISO BONDING document specifies using the standard ITU country code and registering a manufacturer code with the appropriate national standards body. Bob Bob_Webber(a)PICTEL.COM on 05/01/98 04:02:08 PM Please respond to ITU-SG16(a)MAILBAG.INTEL.COM To: ITU-SG16(a)MAILBAG.INTEL.COM cc: (bcc: Bob Webber) Subject: Re: [VideoPhone:828] [wg5-3: 1153] Bonding Manufacturers Code Mr Holdrege's comment is partially correct: the original BONDING document had no status recognizable by ITU-T. However, ISO has specified BONDING in ISO/IEC 13871-x (corrections were made to the original ISO version of this document, so it exists for more than one value of "x"). I don't, unfortunately, have the answer to Mr Thom's question. Bob Webber PictureTel Corporation matt(a)ASCEND.COM on 05/01/98 10:37:46 AM Please respond to ITU-SG16(a)MAILBAG.INTEL.COM To: ITU-SG16(a)MAILBAG.INTEL.COM cc: (bcc: Bob Webber) Subject: Re: [VideoPhone:828] [wg5-3: 1153] Bonding Manufacturers Code BONDing is not a standard. It's an old industry specification regaring syncing multiple bearer channels. MP or Multilink PPP is IETF RFC 1990 but there are no manufacturer codes for MP. BACP is a control protocol for adding/removing links for MP. At 10:57 PM 5/1/98 +0900, Yuichiro-Tuck-Takagawa wrote: >You means Bonding for ISDN? >That is discussed by IETF:Internet Engineering Task Force. >BACP:Bandwidth Allocation Control Protocol is very common in ISDN Terminal >Adaptors or ISDN Routers in Japan. > > >Regards > > >Takagawa > > >At 09:34 98/05/01 -0800, Gary A. Thom wrote: >> Can any one point me to the person/organization that >> assigns manufacturer codes for the Bonding standards??? >> >> Thanks >> Gary >> ------------------------------------------------------ >> Name : Gary A. Thom >> Company: Delta Information Systems, Inc. >> Address: 300 Welsh Rd., Bldg 3 >> Horsham, PA 19044 USA >> Phone : +1-215-657-5270 Fax : +1-215-657-5273 >> E-mail : gthom(a)delta-info.com >> ------------------------------------------------------ >> >> >************************************************************* >Yuichiro "Tuck" Takagawa Tel:+81-30-248-6357 >Executive Manager Fax:+81-3-5359-5788 >NTT Multimedia Business Dept. takagawa(a)mbd.mbc.ntt.co.jp > >Emergency Internet Pager: 0361241374(a)page.docomonet.or.jp >Private Home Page: http://village.infoweb.or.jp/~fwbc7006/ > >Post:3-19-2 Nishi-Shinjuku, Shinjuku-ku, Tokyo163-8019, Japan > >Find my location on the "MAPION" of Cyber Map Japan by... >http://www.mapion.co.jp/cgi-bin/m?no=2b036m-22nuwy&xy=132,516 >************************************************************* > Matt Holdrege http://www.ascend.com matt(a)ascend.com

1 0

Bonding Manufacturers Code
by Gary A. Thom 01 May '98

01 May '98

Can any one point me to the person/organization that assigns manufacturer codes for the Bonding standards??? Thanks Gary ------------------------------------------------------ Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 Fax : +1-215-657-5273 E-mail : gthom(a)delta-info.com ------------------------------------------------------

1 0

Invitation to the Cannes meeting
by Sakae OKUBO 01 May '98

01 May '98

Dear SG16 colleagues, Attached please find Mr. Jean-Pierre Blin's invitation to the next Q.11-14 meeting in Cannes. This will be placed at the new directory /9806_Can of PictureTel ftp site (ftp://standard.pictel.com/avc-site/9806_Can) Best regards, Sakae OKUBO

1 0

Re: denial of service attacks for H.225.0 call signalling using T CP and UDP transport
by Andrew Draper WVdevmt-WS 01 May '98

01 May '98

Hal purdy wrote: > With that background, our concern about a UDP based approach for > handling H.225.0 messages is that a server (e.g. a Gateway or > Gatekeeper) could be overwhelmed with H.225.0 Setup messages and thus be > unable to serve legitimate connection requests. I think there is a more important issue here. A UDP setup message sent to a H.323 endpoint will cause a (virtual) telephone to ring, or will leave a message on the answering machine etc. If SETUP messages can be carried over UDP then I can do this with a single packet with a faked IP address. > Applying to H.323 call > signalling the knowledge gained in thwarting TCP SYN attacks, such > attacks can be prevented or at least mitigated by a careful design of > the portion of Q.931 state machine which deals with the initial H.225.0 > Setup message. As far as I can tell the Q.931 state machine has to store state as a result of a SETUP message. It's possible to implement TCP so that it stores no state as a result of a SYN message, instead using a one way function to generate the initial sequence number. An implementation doing this can protect itself against an attack from thousands of faked packets per second. I can see no easy way to do this using the current H.225.0 protocol. Thus, I think the TCP three way handshake is necessary to protect against spoofed source addresses. Setup over UDP can only be made safe by requiring strong authentication in the packets. Of course most strong authentication requires at least a three way handshake (to get the keys)... And then Mike Moore wrote: > most of us are installing firewalls that by definition block udp? This is another good point. Firewalls are not panaceas for everything but are a good fix for keeping insecure protocols away from the Big Bad Internet (tm). If H.225.0 over UDP isn't securable (as I believe it isn't) then no firewall or proxy will let the messages through and so all products will use TCP connections first (removing the point of UDP setups). Andy ps. SIP are thinking of putting an (optional) three way handshake into their UDP setup-like-message. -- Andrew Draper - Principal Development Engineer & Firewall Administrator Madge Networks, Wexham Springs, Framewood Road, Wexham, Berks. pgp fingerprint D6 ED 72 4F 96 BB CA 2D 68 74 4C E0 CB B9 0B 3F

2 1

Re: [VideoPhone:828] [wg5-3: 1153] Bonding Manufacturers Code
by Yuichiro-Tuck-Takagawa 01 May '98

01 May '98

You means Bonding for ISDN? That is discussed by IETF:Internet Engineering Task Force. BACP:Bandwidth Allocation Control Protocol is very common in ISDN Terminal Adaptors or ISDN Routers in Japan. Regards Takagawa At 09:34 98/05/01 -0800, Gary A. Thom wrote: > Can any one point me to the person/organization that > assigns manufacturer codes for the Bonding standards??? > > Thanks > Gary > ------------------------------------------------------ > Name : Gary A. Thom > Company: Delta Information Systems, Inc. > Address: 300 Welsh Rd., Bldg 3 > Horsham, PA 19044 USA > Phone : +1-215-657-5270 Fax : +1-215-657-5273 > E-mail : gthom(a)delta-info.com > ------------------------------------------------------ > > ************************************************************* Yuichiro "Tuck" Takagawa Tel:+81-30-248-6357 Executive Manager Fax:+81-3-5359-5788 NTT Multimedia Business Dept. takagawa(a)mbd.mbc.ntt.co.jp Emergency Internet Pager: 0361241374(a)page.docomonet.or.jp Private Home Page: http://village.infoweb.or.jp/~fwbc7006/ Post:3-19-2 Nishi-Shinjuku, Shinjuku-ku, Tokyo163-8019, Japan Find my location on the "MAPION" of Cyber Map Japan by... http://www.mapion.co.jp/cgi-bin/m?no=2b036m-22nuwy&xy=132,516 *************************************************************

2 1

Re: denial of service attacks for H.225.0 call signaling using T
by Chris Purvis WVdevmt-WS 01 May '98

01 May '98

>If you want to sell product to end users won't you have to take into >consideration most of us are installing firewalls that by definition >block udp? This is what H.323 proxies are for. Chris ---------------------------------------- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. Phone:+44 1753 661359 email: cpurvis(a)madge.com

2 1

needed changes to H.245 V4
by Dale L. Skran 01 May '98

01 May '98

As noted in the revised meeting report of the Yokosuka meeting, an error was made in agreeing to remove T.38 related references from H.245 V4. Doing so creates a set of forward references, and prevents the ITU-T from moving forward both H.323 Annex D and T.38 Annex B. Note the following: Determination Decision H.245 V4 Feb. 98 Sept 98 H.245 V5 Sept 98 April 99 H.323 Annex D Feb 98 Sept 98 T.38 Annex B June 98 Jan-Feb 99 It can be readily seen that, for example, H.323 Annex D cannot refer to H.245 V5 as this would be a forward reference. Please find attached needed changes to H.245 V4 as previously attached to the draft Annex D H.323. These changes *will not* be included in the H.323 Annex D as they should be in the H.245 white paper. Please contact H.245/Q14 Rapporteur Gary Thom with any questions. Dale Skran Rapporter Q13

1 0

Re: denial of service attacks for H.225.0 call signaling using TC P and UDP transport
by Moore, Mike 30 Apr '98

30 Apr '98

I enter this post with trepidation because I am but a lowly end user of products such as yours, certainly not qualifed to design software. I normally just lurk on the side learning what I can. This issue is near and dear to my job however, so I'm coming out today. If you want to sell product to end users won't you have to take into consideration most of us are installing firewalls that by definition block udp? I plan to replace as much private networking as I can with Internet services starting this year and for the forseeable future. I will not select a product or allow communication with a product that uses udp however. While this protocol was acceptable when my network was totally private, it is not acceptable for communications with unsecured networks, like the Internet no matter how feature rich or easy to implement. If you plan to market to customers like myself who want to communicate safely and privately over the Internet, how will you do this using udp? Mike > -----Original Message----- > From: Hal Purdy [SMTP:khp@RESEARCH.ATT.COM] > Sent: Thursday, April 30, 1998 1:35 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: denial of service attacks for H.225.0 call signaling > using TCP and UDP transport > > At the meeting in Yokosuka in April, two contributions were made which > proposed changes to how H.323 call signaling transport would be > accomplished, especially on IP networks. > > The first is APC-1351 authored by Jorg Ott, Gur Kimchi, and David > Gurle. > The other contribution, APC-1363, was made by Glen Freundlich. AT&T > had > two delegates in attendance, Rajiv Kapoor and Radhika Roy. Our two > delegates expressed security concerns about the signaling approach > suggested in APC-1351. > > I would like to elucidate what our concerns are. APC-1351 suggests the > use of a hybrid UDP/TCP based approach as a better (primarily faster) > way to do H.225.0 call signaling. As the authors point out, there are > some definite advantages to the use of UDP for call signaling. We do > have some concerns about the complexity of the approach since it > involves using both UDP and TCP during different stages of a given > call. > However, in this message I'd like to focus on the security concerns we > have which are based on the danger of "denial of service" attacks. > > Denial of service attacks are attacks whose aim is to attack a network > in such a way as to deny service to users of the network. One well > known > example of denial of service attacks are TCP SYN flood attacks which > attempt to prevent a server from being able to handle valid TCP > connection requests by flooding the server with invalid connection > attempts. A malicious party sends a voluminous number of the first > message in the TCP three-way handshake connection establishment to the > attacked server. This first message is known as a TCP SYN message. For > servers not hardened to this form of attack, the attack works for > several related reasons: 1) the queue size for the half-open > connection > queue was small (originally 5; later ~30) 2) the data structure > objects > which resided on this queue were sizable and thus limited in number > (because of general memory constraints) 3) a linear method was used to > search the queue. Consequently, servers attacked in this way either > ran > out of the data structure objects, ran out of queue space, and/or were > bogged down searching the queue. Fixes have been instituted in many > TCP > stacks to address all three of the above limitations. > > With that background, our concern about a UDP based approach for > handling H.225.0 messages is that a server (e.g. a Gateway or > Gatekeeper) could be overwhelmed with H.225.0 Setup messages and thus > be > unable to serve legitimate connection requests. Applying to H.323 call > signaling the knowledge gained in thwarting TCP SYN attacks, such > attacks can be prevented or at least mitigated by a careful design of > the portion of Q.931 state machine which deals with the initial > H.225.0 > Setup message. In particular, such a design must pay close attention > to > 1) the amount of state information stored when receiving a Setup > message, 2) the size of queues/tables/lists where such state > information > is stored, 3) the efficiency of the algorithms used to search those > queues/tables/lists upon fielding subsequent signaling events, and 4) > the efficiency of the methods used to recognize a particular Setup > message as bonafide, or conversely illegitimate. > > The trouble with using UDP packets to carry the H.225.0 Setup messages > is that each implementation of this portion of the Q.931 state machine > must pay close attention to the above design issues. As those of us > who > write software know, it often takes awhile to get these sorts of > things > right. The advantage of TCP based call signaling is that a great deal > of > thought and effort has already gone into defending against SYN flood > attacks, and thus, any Q.931 state machine implementation can benefit > from TCP stack implementations which incorporate the fixes. Please > understand that I'm not asserting that H.323 Terminals, Gateways and > Gatekeepers that use TCP for call signaling are impervious to denial > of > service attacks. There may be new such attacks that we'll need to be > careful of. I'm merely stating that a TCP based approach starts with > an > advantage in warding off denial of service attacks. > > The approach suggested in APC-1363 is to multiplex call signaling over > one (or a small number) of transport (e.g. TCP) connections. For > denial > of service attacks, this approach seems to have the further advantage > especially for GW to GK and GK to GK communication that the two > parties > to the transport connection can authenticate each other when the > connection is first brought up. Then, with some further (fairly > straightforward) protection against transport session hijacking, the > parties are assured of the legitimacy of the signaling received on > those > few transport connections. For this reason, we currently support the > approach outlined in APC-1363. Again, I'm not stating that these same > advantages can't be gained with a good connectionless design, but such > approaches can't take advantage of the store of knowledge already > embodied in good transport protocol implmentations. > > We are of course interested in an open discussion of this topic. I > would > be particularly interested to hear from H.323/GK/GW software providers > any insights they may have regarding the design of the Q.931 state > machine with respect to the design issues raised above. > -- > Hal Purdy khp(a)research.att.com > AT&T Laboratories w: (973) 360-8636 > 180 Park Avenue, Room C147 fax:(973) 360-8077 > Florham Park, NJ, 07932-0971

1 0

denial of service attacks for H.225.0 call signaling using TCP and UDP transport
by Hal Purdy 30 Apr '98

30 Apr '98

At the meeting in Yokosuka in April, two contributions were made which proposed changes to how H.323 call signaling transport would be accomplished, especially on IP networks. The first is APC-1351 authored by Jorg Ott, Gur Kimchi, and David Gurle. The other contribution, APC-1363, was made by Glen Freundlich. AT&T had two delegates in attendance, Rajiv Kapoor and Radhika Roy. Our two delegates expressed security concerns about the signaling approach suggested in APC-1351. I would like to elucidate what our concerns are. APC-1351 suggests the use of a hybrid UDP/TCP based approach as a better (primarily faster) way to do H.225.0 call signaling. As the authors point out, there are some definite advantages to the use of UDP for call signaling. We do have some concerns about the complexity of the approach since it involves using both UDP and TCP during different stages of a given call. However, in this message I'd like to focus on the security concerns we have which are based on the danger of "denial of service" attacks. Denial of service attacks are attacks whose aim is to attack a network in such a way as to deny service to users of the network. One well known example of denial of service attacks are TCP SYN flood attacks which attempt to prevent a server from being able to handle valid TCP connection requests by flooding the server with invalid connection attempts. A malicious party sends a voluminous number of the first message in the TCP three-way handshake connection establishment to the attacked server. This first message is known as a TCP SYN message. For servers not hardened to this form of attack, the attack works for several related reasons: 1) the queue size for the half-open connection queue was small (originally 5; later ~30) 2) the data structure objects which resided on this queue were sizable and thus limited in number (because of general memory constraints) 3) a linear method was used to search the queue. Consequently, servers attacked in this way either ran out of the data structure objects, ran out of queue space, and/or were bogged down searching the queue. Fixes have been instituted in many TCP stacks to address all three of the above limitations. With that background, our concern about a UDP based approach for handling H.225.0 messages is that a server (e.g. a Gateway or Gatekeeper) could be overwhelmed with H.225.0 Setup messages and thus be unable to serve legitimate connection requests. Applying to H.323 call signaling the knowledge gained in thwarting TCP SYN attacks, such attacks can be prevented or at least mitigated by a careful design of the portion of Q.931 state machine which deals with the initial H.225.0 Setup message. In particular, such a design must pay close attention to 1) the amount of state information stored when receiving a Setup message, 2) the size of queues/tables/lists where such state information is stored, 3) the efficiency of the algorithms used to search those queues/tables/lists upon fielding subsequent signaling events, and 4) the efficiency of the methods used to recognize a particular Setup message as bonafide, or conversely illegitimate. The trouble with using UDP packets to carry the H.225.0 Setup messages is that each implementation of this portion of the Q.931 state machine must pay close attention to the above design issues. As those of us who write software know, it often takes awhile to get these sorts of things right. The advantage of TCP based call signaling is that a great deal of thought and effort has already gone into defending against SYN flood attacks, and thus, any Q.931 state machine implementation can benefit from TCP stack implementations which incorporate the fixes. Please understand that I'm not asserting that H.323 Terminals, Gateways and Gatekeepers that use TCP for call signaling are impervious to denial of service attacks. There may be new such attacks that we'll need to be careful of. I'm merely stating that a TCP based approach starts with an advantage in warding off denial of service attacks. The approach suggested in APC-1363 is to multiplex call signaling over one (or a small number) of transport (e.g. TCP) connections. For denial of service attacks, this approach seems to have the further advantage especially for GW to GK and GK to GK communication that the two parties to the transport connection can authenticate each other when the connection is first brought up. Then, with some further (fairly straightforward) protection against transport session hijacking, the parties are assured of the legitimacy of the signaling received on those few transport connections. For this reason, we currently support the approach outlined in APC-1363. Again, I'm not stating that these same advantages can't be gained with a good connectionless design, but such approaches can't take advantage of the store of knowledge already embodied in good transport protocol implmentations. We are of course interested in an open discussion of this topic. I would be particularly interested to hear from H.323/GK/GW software providers any insights they may have regarding the design of the Q.931 state machine with respect to the design issues raised above. -- Hal Purdy khp(a)research.att.com AT&T Laboratories w: (973) 360-8636 180 Park Avenue, Room C147 fax:(973) 360-8077 Florham Park, NJ, 07932-0971

1 0