## 3 Methodology
### Programming the Controller
Initially, the controller checked whether the packet was an Address Resolution Protocol (ARP) packet, an ICMP packet, or a non-IP packet. If so, an independent function handled the ARP packet, and no further action was taken for this packet within the current function. Similarly, an exception was made for all non-IP packets. When the packet was recognized as an IP packet, the controller extracted its IPv4 payload, which contained the source and destination IP addresses. If the IP packet contained a TCP payload, the controller checked the payload byte sequence for a match with the contents of the text file. The controller read the content from the text file, which was later used for encryption-decryption operations. If there was no message to be read, the controller ceased encryption processing on the packet. For a new source IP address, the controller logs the message and generates a symmetric encryption key using a GA. The message is then encoded with this key and subsequently encrypted using the controller's public key. The destination IP, encrypted message, and encryption keys are stored in a dictionary for later use. The TCP payload is then updated with the encrypted message, and the packet is patched together. Then, based on the destination IP and dpid, the controller decides the appropriate output port, generates  
Figure 3: Steps for topology discovery with static routing table. a packet-out message, and sends the rules to the switch to forward the packet to the designated port, as shown in Figure 4.  
When the packet reaches the switch at the destination end, the controller retrieves the stored key if the packet has a known source IP address with an existing destination IP in the dictionary. The message will be decrypted using the controller's private key and then decoded using the stored symmetric key. The decrypted message will be recorded and used to update the TCP segment; subsequently, the packet will be reconstructed. The controller will know the correct output switch port and transmit the packet via the port, as shown in Figure 5. In cases where packets do not meet any of the described conditions, the controller decides upon the correct output port without inspecting the packet itself and simply forwards it. Such forwarding includes both packets that require special handling as well as those that do not, thereby allowing for consistent and complete operation throughout the network. 4. Key Management: The SDN controller centrally manages the keys, allowing for the standardization of security policies across the network. This centralization simplifies the management of distinct encryption and decryption entities, reducing complexity [8]. Through the centralization of key management at the controller level, an integrated and scalable security architecture will be established, ensuring that encryption policies are applied uniformly. This reduces the chances of misconfigurations or vulnerabilities associated with decentralized key management [10]. Although the centralized key management in the SDN controller simplifies administration, it also introduces a single point of failure. If the SDN controller is compromised, the entire encryption framework could be at risk. To mitigate this, redundant controllers with distributed key replication strategies will be deployed. Nevertheless, the study focused on controlled experimentation and systematic evaluation of encryption efficiency; the replication strategy is not within the current scope of the study. Figure 4: Ingress encryption logic at the controller. The dashed box represents the group of processes the controller handles to deploy the policy of ingress encryption. “A” within the circle represents the connector.