Copy Link
Add to Bookmark
Report
Phrack Inc. Volume 09 Issue 55 File 17
-------[ Phrack Magazine --- Vol. 9 | Issue 55 --- 09.09.99 --- 17 of 19 ]
--------------------[ Alternative Thinking in H.323 Capable Firewall Design ]
--------[ Dan Moniz <dnm@neith.net> ]
To wit:
"Thus it is said that one who knows the enemy and knows himself will not
be endangered in a hundred engagements. One who does not know the enemy but
knows himself will sometimes be victorious, sometimes meet with defeat. One
who knows neither the enemy nor himself will invariably be defeated in
every engagement"
- Sun Tzu
Chou Dynasty, Warring States period of China (circa 403 BC).
"If your own power of insight is strong, the state of affairs of everything
will be visible to you. Once you have obtained complete independent mastery of
martial arts, you will be able to figure out the minds of opponents and thus
find many ways to win. This demands work."
- Shinmen Musashi no Kami, Fujiwara no Genshin (Miyamoto Musashi)
Tokugawa Era, Third Tent Government of Japan (circa 1643 AD).
"Better one blow with a pickax than a thousand taps with a mattock."
- Tran Thai Tong (first king of the Tran Dynasty)
Tran Dynasty of Vietnam (1225-1400 AD)
Abstract:
This paper illustrates some basics about the H.323 standard, then touches on
H.323 security in the context of network mapping, and posits a possible
solution, and then compares it with other existing ideas, and ends by
developing a basic idea framework for said solution.
Extended Abstract:
Using H.323 applications leads to severe firewall security and scalability
issues on all sides. This paper describes a compromise solution, between
using HFCI (a one-time Internet Draft work-in-progress [now since expired])
and a generic but equally function solution such as SOCKS. The prime points
focused upon include network disclosure and fundamental access control, as
well as managing the very complicated nature of H.323 connections and contents.
The paper finishes by presenting an annotated reference list and encourages
the reader to investigate further into the issue. The author also proposes
to develop the proxy noted in the paper and set-up his goals for the project,
with source code and other notes to be released at a later date in a follow-up
paper.
Introduction:
H.323, an ITU-T standard, is the dominant standard for Voice-over-IP (VoIP)
that the telecommunications community is considering to build IP based data
networks for telephony. The multiplexing ability, the self-healing nature
of IP networks, and the potential for new value-add services are the main
reasons telephony is being merged into the data sphere.
All IP networks are insecure. Because of the ease in which rouge elements
could be introduced, open network designs are obviously not feasible. Closed
network designs also benefit no one, especially when using H.323 since the
standard is very intensive in the number of connections and the care with
which they must be handled.
Further information about H.323 is available in the resources we denote at
the end of this paper. We assume a basic familiarity with the standard and
common implementations and H.323 applications.
Issue:
H.323 is very port intensive, necessitating four UDP streams (two for RTP and
two for RTCP), and also has specific guidelines for which ports these have
to be. The RTP ports must be adjacent even numbered ports, while the RTCP
must be adjacent odd numbered ports. These streams are also very ephemeral,
so maintaining correct state is a large issue with the UDP end. H.323 also
has TCP connections involved with the H.323 call setup and associated parts of
the call.
This standard was never intended to connect large scale networks, handle
issues of local number portability, or to interconnect to untrusted networks.
When an untrusted network is used in an H.323 peering context, care must be
taken to note that dial plans are encoded in ASN.1, and the IP network
architecture must be communicated to every gateway and gatekeeper that will be
receiving and controlling calls. For a paranoid RBOC or LEC, this is
unacceptable. Therefore, NAT and ASN.1 cleansing must be performed. A viable
way to perform accounting of CDR, as well as VAS must be taken into account,
but it is out the scope of this paper.
Common solutions for H.323 involved opening all UDP ports, obviously a very
scary situation. In 1997, Intel wrote a whitepaper (noted in the bibliography)
which expresses the issues involved in proxying H.323 in an effective, secure
fashion. Recently, an Internet Draft authored by S. Mercer and A. Molitor
along with M. Hurry and T. Ngo described the H.323 Firewall Control Interface
(HFCI). This Internet Draft expired in June 1999, and it was referenced here
only as a work once in progress.
The HFCI posed the idea of developing a generic API for proxying H.323 in a
specialized H.323 Gateway system. The overall idea was to develop the HFCI
in such a way that H.323 would be able to open up "pinholes" in the firewall
rather than necessitating an all-open state on all UDP ports.
Current research and thought into the issue with people in the industry points
to a growing deprecation of HFCI as a specialized proxy solution and using
something more generic like SOCKS, since the design of HFCI replicates much of
SOCKS functionality.
The author poses the idea that a gateway more in the style of FWTK is an
agreeable and arguably more manageable solution than either a customized
interface or a generic use proxy solution. The advantages to this model,
later explained in detail in this paper, include a compromise between a
completely generic solution and tailored gateway, easy integration with
existing firewall installations, and retention of central control.
Synthesis:
Having said the above, a (very) brief explanation is needed. As D. Brent
Chapman and Elizabeth D. Zwicky illustrate on pp. 200-205 of _Building
Internet Firewalls_, some specific differences exist between SOCKS and FWTK
style proxying systems. For the purpose of this paper, it is assumed that
the details of the proposed HFCI project replicate much of SOCKS'
functionality applied to a specific environ (that of H.323 and pals), which
is what research and current discussion with industry engineers suggests.
Furthermore, some are of the belief that an RFC standard like SOCKS benefits
H.323 in a more direct fashion, seeing no need for a specialized stand-alone
solution, and that SOCKS is malleable enough to handle H.323 with a minimum
of hassle.
This is sound thinking. Organizations running SOCKS based proxies could
integrate H.323 applications into their enterprise without having to support
an entirely new product or interface. By using existing standards, a lot
of the overhead is cut down, with the trade off of a little custom
configuration.
Returning to the differences inherent in SOCKS and FWTK, the following
comparative checklist is provided:
> SOCKS is a generic serv-all solution. Every SOCKS-ified client runs
through the SOCKS proxy and connects to the server at the backend.
> FWTK uses multiple, smaller, application-specific proxies. Clients
connect to their respective FWTK proxy and then connect to the server at
the backend.
> SOCKS relies on modified client code for use with SOCKS.
> FWTK provides (out-of-box) the ability to use modified client code or
modified user procedures for some of the common applications (such as FTP)
and specifies one or the other for other (such as modified user procedures
only with telnet).
> SOCKS is an RFC standard
> FWTK is an unsupported toolkit distributed under a liberal license from
TIS.
There are other differences as well -- the reader is encouraged to download
freely available copies of both systems and tinker.
The idea is that H.323 lends itself to a FWTK style application gateway;
that is, a gateway could be coded to fit into the FWTK in such a way as to
support H.323. This provides some considerable benefits over using either
HFCI or SOCKS:
> FWTK has established the philosophy that a small, provably secure proxy
for each common service works well.
> FWTK's methodology provides for a easily managed firewall setup. HFCI is
a completely new interface, while FWTK and it's commercial derivative,
Gauntlet, have been tested in the field.
> Load balancing systems could be put in place to have multiple-system
firewalls. Since the FWTK construction is to have an application specific
gateway rather than a generic catch-all gateway, one could implement a
number of machines, one handling each particular application and its
proxy. This would especially make sense in large organizations who have to
field a large amount of H.323 traffic.
> FWTK could be implemented on both (all) ends of the network. Incoming
proxies can hand off traffic to the important internal H.323
infrastructure which in turn could hand off the "finished product", such
as it is, to outgoing only proxies (although this is not necessarily a
FWTK specific idea, and could be applied to SOCKS).
> FWTK's model leans itself to central control, but also to survivability
and fault tolerance. Having a "one proxy to one app" structure ensures
that should, say, ftp-gw go down, h323-gw (hypothetical name) would stay
up.
> FWTK promotes a specialized focus in each gateway by the fact that it
uses the "one proxy to one app" method. This means that a highly effective
proxy could be coded to support H.323 in the most efficient manner possible,
which was one of the goals of the HFCI proposal, and still integrate nicely
with common firewall solutions, which is behind the drive to use SOCKS.
Issues such as the ability to do the required on-the-fly packet
destruction/reconstruction to avoid network disclosure are addressed in this
paper only in the context that the proposed FWTK-model proxy solution will
accomplish this goal, given fast enough hardware and optimized routines.
The real bottleneck here is in the packet engine. SOCKS also provides this
ability. Hardware issues and the amount of projected traffic are the main
variables.
The author believes, however, that this proposal shows an acceptable
compromise between adopting a completely new and specialized interface
(such as HFCI) and a overly generic solution (SOCKS) whilst still staying
within the bounds of traditional firewall methodology.
A project is underway now between the author of this paper and a valued
colleague to develop the solution proposed in this paper and to test it to
see if the assumptions made above hold true. Barring licensing restrictions
and the expanse of time, a new paper will be published disclosing the
project's results and any new findings, along with the source code to the
proposed proxy at the conclusion of the endeavor.
As always, comments are welcomed and encouraged on this work and on the idea
in general.
Caveats:
This paper does not touch on such other standards competing with H.323 such
as SIP. While research was indeed conducted on SIP and other related
standards/protocols, they remain outside the scope of this paper. SIP may
very well be a better choice for those who wish to enter the world of VoIP
services. The author encourages all readers to research the field and develop
their own solutions.
This paper does not expressly touch on the issue of full network disclosure,
one of the bigger concerns when using H.323. The reader is directed to the
reference list for suitable material. Having said that, the dual gateway
architecture (one handling in traffic and one handling out traffic) lends
itself easily to suffice in this concern. Again, the main problem is in
handling the ASN.1 issue, and its lack of fixed byte offsets. The author
suspects this becomes a larger issue only in high-yield situations, and that
new packet engines are being developed to optimize performance as well as
correctness which will work to make this less of a concern.
References:
1. _H.323 Peering Proxies_ by Kiad <cameo@kiad.net>
(URL: http://neith.net/h.323/kiad/proxies.txt)
This paper lays the groundwork for the network disclosure issue and also
explains the troubles with ASN.1. Kiad was originally contacted to co-author
this paper, but elected to aid the author with supplementary research and
act as a sounding board, which proved invaluable. Kiad also contributed by
lending her expertise to some of the material above. Without her, this
paper would not exist. This work is dedicated to her -- thank you so much,
Kiad.
2. _Building Internet Firewalls_ by D. Brent Chapman and Elizabeth
D. Zwicky.
(ISBN: 1-56592-124-0)
Used as a canonical reference for the differences between SOCKS and
FWTK. Unwittingly served as impetus for the FWTK model idea.
3. _The Problems and Pitfalls of Getting H.323 Safely Through Firewalls_ by
Intel.
(URL: http://support.intel.com/support/videophone/trial21/h323_wpr.htm)
(URL: ftp://ftp.intel.com/pub/H.323/DOCS/h323_and_firewalls_wp.doc)
(Also: http://support.intel.com/support/videophone/trial21/h323faq.htm)
Preliminary whitepaper describing the core issues with H.323 and interaction
with firewalls.
4. _H.323 Firewall Control Interface (HFCI)_ by S. Mercer, et. al.
(I-D title: <draft-rfced-info-mercer-00.txt>
Please note that this I-D expired in June of 1999 and is referred to here only
as a work once in progress, not as an official standard.
5. The _Art of War_ by Sun Tzu (translated by Ralph D. Sawyer)
(ISBN: 0-8133-1951-X)
6. _The Book of Five Rings_ by Miyamoto Mushashi (translated by Thomas Cleary)
(ISBN: 0-87773-868-8)
7. _Zen Keys_ by Thich Nhat Hanh
(ISBN: 0-385-47561-6)
Inspirational materials, all worth reading.
----[ EOF
