denial of service attacks for H.225.0 call signaling using TC P and UDP transport

[Moore, Mike]

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 at RESEARCH.ATT.COM]
> Sent: Thursday, April 30, 1998 1:35 PM
> To:   ITU-SG16 at 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 at research.att.com
> AT&T Laboratories   w:  (973) 360-8636
> 180 Park Avenue, Room C147  fax:(973) 360-8077
> Florham Park, NJ, 07932-0971