next up previous
Next: Compile-time checks Up: FFPF Packet Languages Previous: FPL

Monitoring application with dynamic ports

Many existing packet filters are not well suited for handling applications with dynamic ports. Such applications use control channels with well-known port numbers, while data transfer takes place over ports that are negotiated dynamically. Examples are found in peer-to-peer networks and multimedia streams that employ control protocols like RTSP, SIP and H.323  [,]to negotiate port numbers for data transfer protocols such as RTP [].

These flows are complex to monitor and the problem was considered important enough to develop a special-purpose tool (mmdump, not unlike tcpdump) to tackle it [32]. Like xPF [19], mmdump adds statefulness to the pcap/BPF architecture and in addition allows filters to be self-modifying. A filter may capture and inspect all control packets and if they contain the port number to be used for data, modify itself to also capture these packets.

While the same behaviour is supported in FFPF which allows an external function to extend the FPL-1 expression from which it was called (subject to authorization constraints), this may not be best way of handling the problem: self-modifying code is difficult to trace and debug. Moreover, there is a simpler way to monitor dynamic ports. For example, given that RTSP packets are sent on port 554, the filter in Figure 7 filters out all such packets and passes them to an external function GetDynTCPDPortFromRTSP. When called, the function scans all RTSP session packets for the occurrence of `Transport', `client_port' and `server_port' to find the port numbers that will be used for data transfer (e.g., audio and video). These ports are stored in \ensuremath{MBuf} (lines 4-5). If the packet is not RTSP, we check if the destination port of the packets is in the array of port numbers and if so, return the value TRUE (lines 7-9), so that the packet is sent to userspace. In other words, only data packets of streams that are set up using RTSP are sent to userland. Note that the example is for illustration purposes only. It is a simplified version of what real applications would use. For instance, we only deal with transfers that use TCP (also for the data) and extract just a single destination port (while the traffic is likely to be bi-directional).

Figure 7: Monitoring dynamic flows
\begin{scriptsize}\begin{verbatim}1. // R[0] ini...

next up previous
Next: Compile-time checks Up: FFPF Packet Languages Previous: FPL
Herbert Bos 2004-10-06