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@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
- 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@research.att.com AT&T Laboratories w: (973) 360-8636 180 Park Avenue, Room C147 fax:(973) 360-8077 Florham Park, NJ, 07932-0971