Check out the new USENIX Web site. next up previous
Next: Layer-3 Filtering Up: Transparent Network Security Policy Previous: Paper Organization

Bridge

  Bridges are devices that operate at the data link layer, tying together different ethernet (or other LAN) segments. In OpenBSD, the bridge is implemented as a pseudo-network interface inside the kernel. Real ethernet interfaces are added to the bridge interface as ``bridge members,'' and for the purpose of using IPsec with the bridge, enc interfaces can be added on as members. The enc interfaces contain the security association (SA) for communication to remote LANs. In all ethernet drivers under BSD, received frames are assembled into mbufs [11], a data structure that provides for easy insertion and deletion of data with little or no data copying. The ethernet header is removed and passed along with a reference to the receiving interface and the mbuf containing the frame data to ether_input(). The bridge intercepts the frame early in this function, after a small amount of bookkeeping is performed.

On entry to the bridge code, the frame is checked to see if it is a broadcast, multicast, or unicast frame (Figure 1). Broadcast and multicast frames are copied and queued on the bridge (so they can be forwarded in all member interfaces), and the original frame is returned to ether_input(), so that it can be processed by the bridge machine itself. Unicast frames are checked to see if the destination matches any of the MAC addresses of ports on the bridge; if so, the frame is returned to ether_input() for local processing. If the frame is unicast and addressed to the bridge machine, the frame is queued and not passed back to ether_input(). When a packet is queued, a software interrupt is scheduled so that bridge processing will occur outside of the interrupt context of the ethernet card.


  
Figure 1: Frame flow from driver to bridge and layer-3 protocols.
\begin{figure*}
\begin{center}
\includegraphics{bridge1.eps}\end{center}\end{figure*}

The bulk of the frame processing occurs in the software interrupt handler, bridgeintr() (see Figure 2). This routine loops through each bridge interface, pulling frames from their input queues. The source ethernet address and source interface are recorded into the bridge's address cache for each frame (after some address spoof-checking). The destination ethernet address is looked up in the cache; if the interface returned by the lookup is the same as the interface where the frame originated, no further processing is done. If the destination interface differs from the source, the frame must be forwarded (bridged). If the frame is for a multicast or broadcast destination, the frame must be forwarded to all member interfaces of the bridge. To avoid overloading enc interfaces with multicast traffic from fast ethernet interfaces, it is possible to disallow multicast packet and/or frame forwarding over the bridge. Currently, this is specified for the whole bridge. In the future, we would like to be able to specify this on a per-member interface basis.


  
Figure 2: Frame flow from within bridgeintr() with Layer-2 and Layer-3 handling.
\begin{figure*}
\begin{center}
\includegraphics{bridge2.eps}\end{center}\end{figure*}



 
next up previous
Next: Layer-3 Filtering Up: Transparent Network Security Policy Previous: Paper Organization
Angelos D. Keromytis
4/21/2000