This software provides a framework that can be used to build proxies for various (multimedia) protocols. The proxies can be used for the signalling (and media) flow of the multimedia protocols. The framework also provides an api that allows the interaction of the proxies with packet-filters. The software can be used to combine proxies and packet-filters to build (distributed) firewall systems that support multimedia applications.

The following documents are available, but there should be more...

• A documentation of the IP-telephony related research at KOM

• Papers describing the problem scope can be found here: publications

• A small document describing the technical details of the framework is available below.

• Some of the (complex) modules below have their own description

• There is some documentation with the software: copyright, howto build, howto install,

  howto use the config file, history, changes, todo, ...

This version (vers. 1.0.4 KOMproxyd104.tgz) has been tested to compile on FreeBSD3.4 and Linux2.4, using gcc-2.95. To compile the h.323 parts you will need additionally the openh323 protocol stack. To compile the packet filter module for Darren Reed's ip filter you need the ip filter package. To compile the sip parts you will need the oSIP open source SIP stack.

current version:

• vers. 1.0.4 KOMproxyd104.tgz

past versions:

• vers. 1.0.3 KOMproxyd103.tgz

• vers. 1.0.2 KOMproxyd102.tgz

Ralf Ackermann and Martin Karsten for discussing/solving/understanding various problems.
Roland Staring and Egon Verharen tested the h.323 parts and reported results/problems.
Markus Schumacher reported problems and bugfixes.

Utz Roedig

The core of the system is able to carry several proxy modules
for different protocols and one module responsible for the
communication with the desired packet-filter. The different modules for
proxies and packet-filters are loaded via shared libs in the core. The
behavior of the whole system (e.g. which modules should be loaded, how
they should behave, ...) is specified by a single configuration file.

A proxy module
loaded in the system might be implemented/configured in different ways.
E.g. the proxy might handle all flows (signalling and media) of a
session or only the signalling flows. Also the treatment of the data
processed by the proxy depends on the implementation/configuration of
the proxy. e.g. the h.323 proxy can be configured which kind of PDUs
should be passed, modified or discarded.
A proxy uses a listener
port (specified in the configuration file) and creates a new session
object if connected on this port. There might be different reasons, why
a client connects to the listener port of the proxy. One reason might
be that the client was configured to use this proxy (e.g. like a www
browser that can be configured to use a www-proxy). An other reason
might be that the packet-filter is able to redirect specific outgoing
connections to the proxy (e.g. ip-filter redirect function). It might
also be possible that an infrastructure component previously told the
client to use this proxy (e.g. an h.323 gatekeeper told the client to
place outgoing calls via the proxy).
After beeing connected on its
listener port, the proxy has to connect to the target system to be able
to relay the data between the communication endpoints. Therefore the
proxy has to know for each incomming connection which system has to be
used as target system. Since there are many possibilities how the proxy
could be connected by the client, many methods might be useful to
identify the target. This work is done by the locators. the
configuration file can be used to specify for each proxy which locators
should be used. One locator points to the configuration file. In this
case the configuration file is used to determine the target. An other
locator points to the packet-filter. If the connection was redirected,
the packet-filter could be asked for the original destination. Other
locators might be implemented by each proxy. E.g. a http proxy can
request the first data from the client which contains the desired
destination. These locators can also be combined. E.g. first the data
is analysed, if it does not contain information about the destination
the packet-filter is asked. If this fails as well, the next locator
could be used or the session is dropped.

The firewall module
is responsible to pass the flow specifications of the used session
flows from the proxies to the packet-filter. E.g. if the proxy uses a
socket or learns about a negotiated flow that is not handled by the
proxy, the flow specification is sent to the packet-filter which
implements an appropriate filter. The communication between the core
and the packet-filter might use different communication principels.
E.g. if the proxy resides on the same machine as the packet-filter,
io-controls might be used for communication. If not, a network protocol
might be used.
The proxies might also be used without a
packet-filter interaction. In this case the nofw module is used. The
packet-filter has to be configured in a static way. The core can be
configured to use a specific port range for the operation of the
proxies. The packetfilter must not be configured to open all ports from
and to the proxy (the remaining problem in this case are the flows that
are not handled by the proxy).

The following figure describes the system:

            ---------------
            |    core     |
            | P1 P2 P3 FW |                            
            ------------*--
                |       *                              
           DMZ  |       *                             
                |       *
            ------------*--
------------| filter      |--------------
INTERN      ---------------    EXTERN (internet)

*  = communication link between core and packet-filter
Px = proxy module
FW = module for the packet-filter

Remarks:

• OS: The code was tested on FreeBSD3.4 and Linux2.4. the code might compile on other os but this was not tested yet.
• Security:

  The code is at present time not optimized for security. More security

  related configuration options are necessary (e.g. allow specific ip and

  port ranges, check which flow descriptions are sent to the

  packet-filter, ...). also a better logging and especially alerting is

  necessary.

• Stability: The software might have bugs. Tests and feedback is necessary.
• Performance: Not all software parts are optimized for performance (e.g. searching in lists, sceduling of socket operations).

The following modules are available for packet-filter interaction:

• nofw:

  This module is used if the proxies are used without packet-filter interaction.

• testfw:

  Used for testing, a dummy packet-filter...

• ipflfw:

  Provides a simple interaction with Darren Reed's IP Filter.
  

  To compile this module, the IP filter package is necessary. This module was developed with ip_fil3.4.8 on

  FreeBSD3.4. but other versions might work too.

Proxy modules are available for the following protocols:

• generic:

  A circuit-level proxy.
  

• ftp:

  A simple ftp proxy for the ftp signalling (and media) flow.
  

• h323:

  A proxy for the ip-telephony protocol H.323. This module handles Q.931, H.245, RTCP, RTP. RAS

  is handled by a specific proxy.

  This proxy is based on the openh323

  project. To compile this module openh323 and pwlib are necessary. This

  module was developed for openh323_1.7.0 and pwlib_1.2.0. Other versions

  of openh323 and pwlib are not tested. Not all scenarios and hardware is

  supported. The module was tested with the following terminals:

  netmeeting, ohphone, siemens lp5100, polyspan viewstation, VCON

  (meetingpoint 4.01). A lot of features are not implemented yet: e.g.

  faststart, tunneling, t.120...
  

• ras:

  A proxy for the RAS protocol.
  

  This proxy is based on the openh323 project (see remarks of the h323

  proxy). The proxy handles the lrq, lcf and lrj messages. These messages

  are exchanged between gatekeepers and are used/modified by the proxy to

  update the locator table for the H.323 proxy. Not all scenarios and

  hardware is supported. The module was tested with the following

  gatekeepers: openh323gk, RADVision.

• test:

  A proxy for my own test multimedia protocol...
  

• rtsp:

  A proxy for the RTSP video streaming protocol.
  

  The work on this part is not finished yet!

• sip:

  A proxy for the SIP protocol. This module handles SIP, SDP, RTCP, RTP.

  This module is a beta!.

  This proxy is based on the oSIP open source SIP stack.

  This module was developed for libosip-0.8.3. Other versions of oSIP are not tested.

  The module was tested with the following User Agents: snom 100, cisco ip phone 7960, pingtel, windows XP messenger.