Can P4 encode or encrypt a field in the header?

Can the p4 program encrypt or decrypt one or more fields in the received header?
For example, if I receive an ipv4 message, I would like to encrypt or encode the source address of the message in some way so that a third party cannot access the source address of the message, and then recover the source address by some means when it reaches its destination.
Are there any case studies or materials you can learn from?

Or how to send certain fields in a packet out to a generic cpu, encrypt them and then send them back to that packet. Does the packet waiting to be forwarded stop waiting while the cpu is processing that field?

You may have a look at GitHub - uni-tue-kn/p4-macsec: P4-MACsec and GitHub - uni-tue-kn/p4-ipsec (Papers: P4-MACsec: Dynamic Topology Monitoring and Data Layer Protection With MACsec in P4-Based SDN | IEEE Journals & Magazine | IEEE Xplore P4-IPsec: Site-to-Site and Host-to-Site VPN With IPsec in P4-Based SDN | IEEE Journals & Magazine | IEEE Xplore)
which use a self written extern to send packets to the cpu for encryption / decryption.

I believe there were also attempts to port these externs in the general bmv2 repo.

Thank you very much for the information, I read the source code and the paper of p4-MACsec, the gain is very huge, but still have some doubts and want to ask you for advice。

The external object is called in line 427 of the basic.p4 file. I can see that the object is declared before ingress, and I can guess that it is implemented in the simple_switch.cpp file, but I still can’t understand the call relationship, because I found that the beginning of the p4 program contains core.p4 and v1model.p4 two files, but not the cpp file which implements the encryption function


the extern is registered in the simple_switch.cpp via BM_REGISTER_EXTERN(ExternCrypt).

You may also have a look at: extern implementaion · Issue #697 · p4lang/behavioral-model · GitHub

Thank you for your help, it’s very useful.

if only the source ip needs to be encrypted (that is not a full packet encryption that you’re seeking) then imho you’re better off with an out-of-the-p4-band channel where you distribute a 32bits number, that later you’ll use as xor… on sending, it encrypts the source ip, on transmit, it decrypts it…

one thing to note well, isps nowadays are almost forced to check the source ip against the assigned subnets, that is, your packets most probably wont go through a real internet… this is the same that happens when you forget to enable nat and have 2 interfaces on a router connected to a consumer telco line…