Design - Ryuretic/SecRev GitHub Wiki

A. Controller

As shown in Fig. 3, the controller for our framework is comprised of the Event Handler, Policy Enforcer, and Policy Table. This framework also uses a RYU [16] controller supporting OpenFlow 1.3 [2]. The components implemented on this controller are written using Ryuretic [4].

  1. Event Handler: The Event Handler serves as the primary interface for the controller, responding to network events from the switch, security events from the Policy Enforcer, and security policy transitions from the Trusted Agent. It also handles insert and delete messages for the controller’s Policy Table to maintain state for each connected client. Once a client is flagged, the Event Handler creates a unique passkey and a keyID for the client and enters this information into the controller’s Policy Table along with the client’s MAC, input port, and violation. When revocation messages arrive from the Trusted Agent with the appropriate keyID, the Event Handler removes the associated client entry from the controller’s Policy Table, and its security policy transitions to allow the client access to network privileges.

  2. Policy Enforcer: The Policy Enforcer handles events passed to it from the Event Handler. It first confirms that arriving packets are not already flagged in the Policy Table. If not, the Policy Enforcer next applies selected security policies against the arrived packet. If the packet passes specified checks, then it is passed to the Event Handler for normal forwarding. Otherwise, the Policy Enforcer returns fields and ops hash tables3 to the Event Handler resulting in the client’s traffic being redirected to the network’s Trusted Agent. The Policy Enforcer also generates the randomized passkey and a unique keyID, which is passed back to the Event Handler with the client’s other unique flow information (i.e., input port, MAC, and violation).

  3. Policy Table: The Policy Table simply stores the identification and flag state information for each client. As shown earlier in Fig. 2, the Policy Table stores keyID (primary identification key), passkey (for client authentication), MAC address, input port, and violation code for flagged clients (all of which is forwarded to the Trusted Agent).

B. Trusted Agent The Trusted Agent serves as an intermediary between the client and network operator. For instance, the Trusted Agent is able to send revocation messages to the controller and reinstate the client’s privileges in lieu of the network operator once the passkey is provided. It can also provide clients with instructions for regaining network access. Its components are shown in Fig. 3 and discussed next.

  1. Client Policy Handler: The Client Policy Handler establishes a communication link with the controller to receive policy activation notices and submit revocation requests. When the Trusted Agent is first notified of a policy activation, it records the provided keyID, passkey, MAC, and violation associations in its Client Table as indicated in Fig. 2 and Fig. 3. The Client Policy Handler also periodically queries the Revocation Table for keyIDs belonging to clients who have submitted a passkey and are awaiting the reinitialization of client privileges.

  2. Client Table: The Client Table allows the Trusted Agent to maintain state for flagged clients. As shown in Fig. 2, this table maintains the client’s keyID, passkey, MAC, and violation. It is also queried by the Client Table Handler to confirm client MAC and passkey pairs. Furthermore, the Client Table provides violation information to the Handler, so the Trusted Agent renders appropriate instructions to the client.

  3. Revocation Table: The Revocation Table allows the Trusted Agent to queue the keyIDs of clients awaiting the reinstatement of their privileges. The Client Policy Handler then periodically queries the table for keyIDs and sends them in revocation messages to the controller.

  4. Client Table Handler: The Client Table Handler queries the Client Table to verify the client’s passkey and MAC address. When successful, the Handler loads the client’s keyID to the Revocation Table where it is queued for delivery to the controller. As a security measure, the Client Table Handler can only query the Client Table and write to the Revocation Table.

  5. Data Processor: The data processor is a Common Gateway Interface (CGI) module that provides server side scripting for the Trusted Agent’s web server. It provides MAC and passkey associations to the Client Table Handler, and it renders feedback information to the client’s web interface via HTML.

  6. Web Server: The web server presents a web interface to clients and captures their MAC address via a PHP script.

C. Communication Channel While the controller generates ICMP packets with complete payloads for the Trusted Agent, we choose to limit the Trusted Agent’s responses to what can be contained in the ICMP packet’s data field, which allows for the insertion of an additional 64 bits (or eight characters) of data. This choice makes are solution easily adaptable to other controllers. Hence, messages from the Trusted Agent are action, keyID strings. The action value is a single letter abbreviation as shown in Table I and identifies the message type (i.e., initialize, acknowledge, update, or delete) sent by the Trusted Agent. For messages that do not require a keyID, the action value is simply followed by a zero (e.g., ”i,0”). However, messages from the controller may have additional data. For instance, rule insertion methods destined for the Trusted Agent’s Client Table will include MAC, srcport, passkey, violation, and keyID values. The format is recognized by the Trusted Agent and handled appropriately.