Our IPsec implementation already supports dynamic SA acquisition by notifying a key management daemon like isakmpd [4] using the PF_KEY interface. SA acquisition occurs in the following two cases:
We can use the same mechanism inside the bridge to dynamically establish SAs: when an IP packet (rather, an ethernet frame containing an IP packet) reaches the bridge and is about to be ``transmitted'' over an enc interface, an SPD lookup is made. If an SA appropriate for this packet already exists, it is used. Otherwise, the packet is dropped and a notification is sent to the key management daemon to establish such an SA. The granularity of the SA may be configured by the administrator (the same SA may be used for all traffic between the protected and the remote host, or just the specific TCP connection may be protected). Future packets with the same characteristics as the original packet will make use of the newly-established SA. Fortunately, no changes to the SPD are necessary.
This mechanism may be used to perform automatic re-keying for the virtual LAN or the simple ``bump in the wire'' configurations described in the previous two subsections.
However, left to its own devices, key management will establish an SA using the IP address of the bridge (and thus end up being functionally equivalent to an encrypting gateway). To really hide the bridge from the remote host, the source address of the protected host must be used. Thus the key management daemon, isakmpd, has to operate in the ``bridge mode,'' wherein it asks the kernel to use a non-local IP address. This requires a minor change in the bind() system call code, to allow for socket binding to non-local addresses. To capture the responses, all UDP traffic to port 500 (the port used by the IKE protocol) is diverted to the bridge isakmpd. This is also necessary when remote hosts attempt to initiate an IKE exchange with a protected host. In both cases, isakmpd must be informed of and use the ``local'' address associated with the incoming packet. isakmpd also needs the ``local'' address so as to select the appropriate authentication information (e.g., secret DSA [15] or RSA [12] key when doing X.509 or DNSSEC authentication). The changes to this effect are fairly minimal.
Incoming IPsec packets are processed as described in the previous subsection. Other incoming packets may cause an SA acquisition, depending on the security policy set by the administrator. Again, isakmpd needs to be informed of what IP address to use as the source address during the exchange.
The combination of packet filtering through ipf and SA-on-demand can be used effectively to enforce network security policy for the protected host(s). One particularly interesting configuration involves the bridge establishing SAs for unencrypted-only traffic; if end-hosts use IPsec or SSL for end-to-end packet security, the bridge simply forwards the packets. In another configuration, the bridge permits all packets through, but attempts to establish SAs for such communications and uses them if the remote hosts can do IPsec (also known as ``opportunistic encryption'').