|
|
|
|
|
Description
|
|
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.
|
Documentation
|
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, ...
|
Download
|
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:
past versions:
|
New in this Release
|
- SIGHUP to reload config
- h323: reverse H.245 connections, default routing entry, ...
- sip: A new module to handle SIP.
|
Acknowledgements
|
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.
|
Contact
|
|
Utz Roedig
|
Framework Description Part I: Core
|
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 | * = communication link between core and packet-filter
------------*--
| * Px = proxy module
DMZ | * FW = module for the packet-filter
| *
------------*--
------------| filter |--------------
INTERN --------------- EXTERN (internet)
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).
|
Framework Description Part II: Firewall Modules
|
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.
|
Framework Description Part III: Proxy Modules
|
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.
|
|
webmaster·
Stand:
28.02.2002
