p4lang / pna

Portable NIC Architecture
Apache License 2.0
55 stars 21 forks source link

Example: crypto_accelerator object extern #53

Closed pbhide closed 1 year ago

pbhide commented 2 years ago

This example demonstrates a definition of a crypto_accelerator engine as an extern object and its use.

The example assumes that inline accelerators are at the end of a pipeline and operate on the packet after it is deparsed. The packet is recirculated after decryption so that the original packet can be processed again.

On encryption, the packet is sent out after encrypt w/o a need for recirculation.

The example shows the use of get_results() method in parser() as well as MainControl()

jfingerh commented 1 year ago

@pbhide Would it be reasonable to give a specific example of the behavior of encryption, by showing an example packet after it has been deparsed, but before the decrypt block begins processing the packet, and then also the modified contents of the packet just after the decrypt block finishes processing the packet?

Similarly for an encrypted packet.

jfingerh commented 1 year ago

@pbhide For IPSec decryption, would your proposal include the behavior that the decrypt block does the anti-replay attack detection check? Or would you propose that such a check must be done explicitly in P4 code somehow, before sending the packet to the decryption block?

If the decryption block does the anti-replay attack detection, would one of the reasons for failing to decrypt the packet be that this check failed?

jfingerh commented 1 year ago

@pbhide For decryption of packets that also have an message digest authentication, e.g. an IPsec AH header, does your proposal include that the decryption block would check the contents of this AH header, and one of the possible error conditions during decryption would be a failure of the authentication?

pbhide commented 1 year ago

@pbhide Would it be reasonable to give a specific example of the behavior of encryption, by showing an example packet after it has been deparsed, but before the decrypt block begins processing the packet, and then also the modified contents of the packet just after the decrypt block finishes processing the packet?

Similarly for an encrypted packet.

You mean show packet in the comments? From programmers point of view ipsec_esp_decrypt() action adds a recirc header to the packet. set_auth_data_xxx apis may add some information to packet that is specific to target implementation.. so it cannot be show here. If you follow the parser path on recirc, that indicates all the header that are present after decrypt.

Similarly, if we look at ipsec_esp_encrypt() new headers (outer header of a tunnel) are added by this action. ICV and trailer that is specified by AES-GCM related rfc are added by crypto engine if instructed to do so by using set_icv_xxx methods.

pbhide commented 1 year ago

@pbhide For IPSec decryption, would your proposal include the behavior that the decrypt block does the anti-replay attack detection check? Or would you propose that such a check must be done explicitly in P4 code somehow, before sending the packet to the decryption block?

If the decryption block does the anti-replay attack detection, would one of the reasons for failing to decrypt the packet be that this check failed?

SA specific random number and extended sequence numbers are expected to be handled in the P4 code.

jfingerh commented 1 year ago

@pbhide wrote "You mean show packet in the comments?"

If there is a more convenient way to show such documentation, e.g. text and a figure in the PNA specification, or a separate document that is in this pna repository, that sounds like it might be much more convenient to write and maintain than trying to do ASCII art in comments. Whatever is easiest for you. If it is not in comments, the comments could mention where a P4 developer can go to get more details, e.g. "see section of document for more details".

jfingerh commented 1 year ago

@pbhide wrote "SA specific random number and extended sequence numbers are expected to be handled in the P4 code."

Do you mean that you expect P4 code to extract the sequence number, or the extended sequence number, and pass them as separate parameters to the decryption block?

Or do you mean that you expect the P4 developer to write P4 code that performs anti-replay attack protection, because the decryption block will not do this feature in any way?

pbhide commented 1 year ago

@pbhide For decryption of packets that also have an message digest authentication, e.g. an IPsec AH header, does your proposal include that the decryption block would check the contents of this AH header, and one of the possible error conditions during decryption would be a failure of the authentication?

This example assume ipsec ESP which provides both authentication and confidentiality, not AH.

jfingerh commented 1 year ago

In general, it would be good to be very precise about the "division of labor" for decrypting and encrypting IPsec packets between what you expect the P4 code to do, and what you expect the decryption/encryption block to do, including any packet modifications made by the block on its own, independent of P4 code, whether the decrypt block does anti-replay attack protection check or not, whether it does authentication checks or not, which options of IPsec ESP and/or AH you expect it will support, versus which it will not.

Of course these details might change in future versions, but it seems worth trying to at least give your expected answer to such questions.

pbhide commented 1 year ago

Of course these details might change in future versions, but it seems worth trying to at least give your expected answer to such questions.

I'll add this information in the comments where the extern object is defined to make it clear wrt assumed functionality of the hardware

pbhide commented 1 year ago

@jafingerhut I have updated the comments in crypto-accelerator.p4 to provide the description/assumptions about crypto engine functionality. PTAL.

pbhide commented 1 year ago

@pbhide Would it be reasonable to give a specific example of the behavior of encryption, by showing an example packet after it has been deparsed, but before the decrypt block begins processing the packet, and then also the modified contents of the packet just after the decrypt block finishes processing the packet?

Similarly for an encrypted packet.

Added ESP packet format.. and text to indicate headers that are present before and after decrypt and encrypt

pbhide commented 1 year ago

@pbhide For decryption of packets that also have an message digest authentication, e.g. an IPsec AH header, does your proposal include that the decryption block would check the contents of this AH header, and one of the possible error conditions during decryption would be a failure of the authentication?

This example does not show AH based auth. But it can be done where P4 pipeline include outerIP header (clear the mutable fields etc), AH header when providing the auth data offset. The engine will compute and compare ICV over it.

jfingerh commented 1 year ago

@pbhide Sorry, a couple of more questions:

For replay attack detection, are you thinking that this would be done in P4 code after the decryption block and packet recirculation? If so, that makes sense, and I would recommend that you mention this somewhere. If you meant before, then that also means before authentication, which would leave you open to attackers that, without knowing your crypto details at all, can make you update your replay attack detection state for packets never sent by the true sender, i.e. a cheap denial of service attack.

Are you planning to create a P4 program example that uses this extern, demonstrating a complete packet decryption code, with all of the things that the P4 should do before and after the decryption block is used? And similarly for packet encryption code? I think those would be very valuable examples, even if they do not demonstrate all of the options.

pbhide commented 1 year ago

@pbhide Sorry, a couple of more questions:

For replay attack detection, are you thinking that this would be done in P4 code after the decryption block and packet recirculation? If so, that makes sense, and I would recommend that you mention this somewhere. If you meant before, then that also means before authentication, which would leave you open to attackers that, without knowing your crypto details at all, can make you update your replay attack detection state for packets never sent by the true sender, i.e. a cheap denial of service attack.

Are you planning to create a P4 program example that uses this extern, demonstrating a complete packet decryption code, with all of the things that the P4 should do before and after the decryption block is used? And similarly for packet encryption code? I think those would be very valuable examples, even if they do not demonstrate all of the options.

I have mentioned that anti-replay checks are not shown in this example... This is not a complete ipsec example wrt P4 pipeline functions.. this has a few short-cuts to just show the usage of the extern. I don't plan to provide a complete working ipsec example here as this proposal is not yet accepted. It it gets accepted, we may invest in it.. but as such it is not necessary to demonstrate the use of the extern.

jfingerh commented 1 year ago

@pbhide wrote: "I have mentioned that anti-replay checks are not shown in this example... This is not a complete ipsec example wrt P4 pipeline functions.. this has a few short-cuts to just show the usage of the extern. I don't plan to provide a complete working ipsec example here as this proposal is not yet accepted. It it gets accepted, we may invest in it.. but as such it is not necessary to demonstrate the use of the extern."

Makes sense. I have created this issue to track the creation of an example P4 program that hopefully demonstrates all of the pieces of a working IPsec decryption case, plus IPsec encryption case, using the extern, once it is merged in: https://github.com/p4lang/pna/issues/72

thantry commented 1 year ago

LGTM

jafingerhut commented 1 year ago

We have a couple of approvals on this, and no objections mentioned, so merging it in. Feel free to create PRs for review with modifications to this, if desired, and they can be considered.