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

[Hal Purdy]

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