Initialization Workflow

The daemons send messages to each other using libjipc over TCP sockets.

PED and PSD Initialization

The PSD creates a server-style socket and binds to its service port (7077). When it receives a connection request from a client, the PSD creates a new connection to the client and registers a KCOM message handler for receiving messages.

The PED establishes two connections to the SDK Service Daemon (SSD) on startup:one connection for adding routes that are part of normal policies, and one for a service route to the PFD on the PIC. The second connection is used only if the PED is configured to use the PFD. If so, the PED sends a request to manage the service route when it connects to the PFD.

When the PED starts for the first time, it also registers KCOM message handlers for communicating with the other daemons. On startup, or when it gets a MSG_POLICY_UPDATE message from the PSD, it also queries for all interfaces currently present (using KCOM APIs,) and updates the associated policies. The KCOM message handler also updates the associated policy whenever an interface is added, deleted, or changed for KCOM purposes (enabled or disabled).

To update an interface's policy, the PED compares the interface name received asynchronously from KCOM with the patterns in the PED's configured conditions. The address family must also match the address family specified in the same condition that is used for the interface pattern match (the ANY keyword can be configured in a condition to match any address family, although this application currently supports only inet). The application code for this is in the function update_interface(), in the file ped_services.c.

The PED sends a policy request to the PSD only if a match is found; otherwise, the PED removes the interface and the associated policy for an individual interface from the policy table by acting as if it has received a MSG_POLICY_NA for the interface.

When a policy is requested for an interface and successfully applied, regardless of the filters included in the policy, the PED attaches pfd_filter as the input filter of every managed interface if sync policy-enforcement packet-filter-interface was configured (see Configuring the Application). If an interface becomes unmanaged (the policy is removed), this input filter is also removed.

At startup, the PED also starts a scheduler to schedule regular MSG_HB heartbeat messages that verify the connection to the PSD. The PSD echoes the message back to the PED without data to notify the PED that the server is alive.

PFD Initialization

The PFD must use the PED as an intermediary between itself and the CPD. Therefore, the PFD first connects to the PED upon startup.

The PED could not act as the client at this point because it does not know the connection information for the PFD. The PED waits until it knows the internal connection information for the CPD as well, and then sends this information to the PFD.

The PED is also expected to send the PFD an address to use when re-sourcing ("NATing") packets and the public address of the CPD. This allows the PFD to properly steer packets to the CPD as required.

The PFD then starts a new internal connection to the CPD.

The code for connecting to the PED is in the file pfd_conn.c, in function connect_ped(). connect_ped() is a static function that is calledthrough a timer. The function init_connections() in pfd_conn.c sets up the timer.

Similarly, the connection to the CPD is performed in connect_cpd() in pfd_conn.c. Again, the connection is made through a timer. Once the application connects to the PED and has obtained the PIC information for the CPD (on receiving MSG_PEER), the application starts a timer that calls the function connect_cpd() until the CPD is connected. The function cpd_client_connection() is called when the connection to the CPD changes status (is ESTABLISHED, FAILED, or SHUTDOWN.) The function ped_client_connection() is called in the same way whenever the connection to the PED changes.

Subsequently, the PFD requests the initial list of authorized users. At that point, the PFD goes into listening mode and waits to be notified of new authorized or unauthorized users. Essentially, the CPD configures the filtering list of the PFD via this channel. The request for the list of authorized users happens in the function cpd_client_connection() in file pfd_conn.c.

CPD Initialization

Initial operations of the CPD are as follows:

1. The CPD connects to the PED to send its connection information. This code is in the function connect_ped(), in file cpd_conn.c.

2. The CPD receives the address for its HTTP server from the PFD, which is also its (IFL 102) IP address. It also receives the address that the PFD uses in NAT. This way, it knows that all connections to the HTTP server from this address are in fact from the PFD having performed NAT on a client's packets. The receipt of the address occurs in function client_message(), in file cpd_conn.c.

3. The CPD initializes its HTTP server on port 80 and awaits a connection request from the PFD. This code is in function run_http_server(), in file cpd_http.c.

4. The PFD requests the list of authorized subscribers, and the CPD replies. This code is in function receive_message(), in file cpd_conn.c.

5. The CPD keeps this connection open, and sends the updated list to the PFD.

Policy Enforcement and Policy Server Daemon Workflow

---