## 3 Methodology
### Programming the Controller  
The SDN controller (POX controller) was programmed to implement a data encryption policy. The controller centrally managed and orchestrated all network traffic within an SDN environment [43]. Encryption and decryption were integrated directly into the controller. This allowed the application of security policies to be deployed according to dynamic flow rules and policies, thus ensuring that transmission of data took place in encrypted form and were decrypted upon reception. This centralized functionality increased network security and data integrity while enabling the communication of encryption processes without requiring configuration on individual network devices [44]. The functionalities that were considered in order to enable the encryption policy through the SDN controller are explained below:  
1. Topology Discovery and Network Configuration: The SDN controller needs to understand the network topology to make informed decisions. In this case, static routing tables can provide this topology information. The steps for topology discovery are as shown in Figure 3. The process in this study began by loading a static routing table into the SDN controller through the manual configuration of information, such as the destination network, next-hop address, and corresponding interfaces. The configurations were then parsed to identify the relationships and connections between different nodes. The parsed routing table was used by the controller to construct a network graph that provides the global view of the network. Once the graph was constructed and the configurations were obtained, they were pushed to the data plane devices through the southbound API (Openflow) that dynamically enforces policies, updates routing information, and manages network behavior [45]. Figure 2: Working mechanism of the hybrid encryption. The arrows in the figure represent the direction and flow of the hybrid encryption process while the symbols are a symbolic representation of key components such as the algorithm, optimal key, public and private keys, and encoded and encrypted messages, as illustrated in the figure. 2. Flow Rules for Packet: In SDN, the deployment of flow rules is an important part of configuring network behavior and managing traffic flows across OpenFlow switches. For this study, deployment started with converting the numerical identifiers of switch ports into string format for consistency, ease of reference, and standardization. The switch IDs were verified in routing entries, where the route table stores routing details specific to each switch. For each valid switch ID, the search proceeded to iterate through each entry in the destination IP and output port. For each destination IP, a match criterion was created using of.ofp_match(). The criterion triggered the associated flow rules, and nv_dst() was set to the destination IP. A flow modification message was then initiated with of.ofp_flow_mod() that encapsulated the specifics of flow rules intended for installation on the switch. Upon receiving the modification signals, the SDN controller dispatched the modification to the respective nodes through the southbound API. 3. Packet Handling:  
a. At the Switch: Packet handling at the switch began immediately upon the packet's arrival. At the ingress stage, the switch examined the packet's header against the flow table entries and flow rules. Upon a match, the switch took the corresponding actions based on the rules. However, if there was no match, the packet was forwarded to the controller, which had a broader view of the network and its configurations. Based on the controller's settings, it then decided how the packet should be handled and updated the flow rules for similar packets in the switch. b. At the Controller Side: The packet handling process at the controller began with receiving and parsing the incoming packet from the network. The controller identified the datapath ID (dpid) and the port on which the packet arrived.