p4rt - how to disable getrpc calls

[Stavan Christian]

Hey team,

Reference: https://p4.org/p4-spec/p4runtime/v1.3.0/P4Runtime-Spec.html#sec-p4-fwd-pipe-config, under section 15  GetForwardingPipelineConfig RPC - points out that certain P4RT servers may not support retrival of the target-dependent config - I understand that they are talking about the binary file running on the switch. Specifically it says : -

"Once a forwarding-pipeline config is installed on the device (either via SetForwardingPipelineConfig or a different mechanism), some P4Runtime servers may not support retrieval of the target-dependent config, in which case config.p4_device_config will be empty / unset in the response, even if response_type in the request was set to ALL. "

Wanted to know the following: -

1. The controller via GetForwardingPipelineConfig RPC call can get the P4 binary that is running on the switch. Thats what I understand. Please correct me if am wrong.

2. If yes, then how can I disable the P4RT server to not share the P4 binary?

Regards,

Stavan

[Andy Fingerhut]

If you want some kind of standard mechanism that determinstically prevents a P4Runtime API server from returning the compiled binary in future GetForwardingPipelineCOnfig RPC calls, that sounds like it would be an extension to the current P4Runtime API specification, e.g. adding a new boolean flag in SetForwardingPipelineConfig that disables reading the compiled binary.

I believe that most people deploy P4Runtime API servers with cryptographic certificate checks on grpc connections, to validate that clients attempting to connect have the proper authorization.  Do you want to disable reading the compiled binary in future GetForwardingPipelineConfig RPC calls because you want to have multiple levels of permissions among authorized clients, e.g. some that should have permission to read the compiled binary, and some that should not?

Or is there some other motivation for your question that you could explain?

Regards,

Andy

--
You received this message because you are subscribed to the Google Groups "p4-api" group.
To unsubscribe from this group and stop receiving emails from it, send an email to p4-api+un...@lists.p4.org.
To view this discussion on the web visit https://groups.google.com/a/lists.p4.org/d/msgid/p4-api/6f320c8e-2e92-4eb6-a88e-cda271376568n%40lists.p4.org.

[Steffen Smolka]

I agree with Andy's comments. Some additional thoughts.

> 1. The controller via GetForwardingPipelineConfig RPC call can get the P4 binary that is running on the switch. Thats what I understand. Please correct me if am wrong.

That's correct.

> 2. If yes, then how can I disable the P4RT server to not share the P4 binary?

Based on the part from the spec that you quoted, it seems like it would already be legal for the P4RT server not to share the P4 binary, if you wish.

Only, there is no standard knob to control this behavior today. This gives you two high-level options:

* Introduce your own proprietary knob to control this. This is totally standard-compliant, just the knob itself won't be standard.

* Extend the standard along the lines that Andy suggested.

Btw, there is an existing notion of "roles" in P4Runtime that can be used to restrict access to certain functionality: https://p4.org/p4-spec/docs/p4runtime-spec-working-draft-html-version.html#sec-arbitration-role-config

You could perhaps use the role as a knob to control whether the config can be read or not.

-- Steffen

To view this discussion on the web visit https://groups.google.com/a/lists.p4.org/d/msgid/p4-api/CAKvLtDaSanbNjZnVeZCavPT93j0BG_7SRfdvz1_WRMM8JZZ2HQ%40mail.gmail.com.

[Stavan Christian]

Hey @Andi, @Steffen

Thanks for your inputs!

My motivation for the question is not to have multiple levels of access permission but rather that, that if an adversary has a control of the switch OS and can make these GetForwardingPipelineConfig RPC calls directly to the  framework (such as the Program Independent framework) that translates such RPC calls to switch SDK and then he/she will can have the access to the binary running on the switch. So if we can disable the facility to make such calls, then it would help my case.

Please let me know your thoughts.

Regards,

Stavan

[Andy Fingerhut]

If an adversary has control at that level, wouldn't you be more worried that the adversary would load their own compiled P4 program into the switch, potentially locking you out of your own network?

Or that the adversary would leave the existing P4 program in place, but change table entries in such a way as to lock you out of your network?  Or send copies of sensitive traffic to the adversary's command/control center?

Why is reading the current P4 program your concern, for such an adversary?

Andy

[Stavan Christian]

yes, we are considering infact all those scenarios. The defense solution we are trying to implement  requires though that the adversary should not ahve access to certain security mechanisms logic implemented in the binary.

Please let me know thoughts on this. (Also, please on my query in previous statement - My motivation for the question is not to have multiple levels of access permission but rather that, that if an adversary has a control of the switch OS and can make these GetForwardingPipelineConfig RPC calls directly to the  framework (such as the Program Independent framework) that translates such RPC calls to switch SDK and then he/she will can have the access to the binary running on the switch. So if we can disable the facility to make such calls, then it would help my case.)

Regards,

Stavan

[Stavan Christian]

Does the framework (such as Program Independent framework) that translates RPC calls or any call from controller to switch driver calls, have some mechanism to ensure that the calls are coming from the controller only and not from switch OS?

[Stavan Christian]

Hey team,

please let me know.

Regards,

Stavan

[Andy Fingerhut]

I do not know the answer to your question, and the set of people that know off the top of their head is probably quite small (maybe 2-3 in the world).

A larger set of people could answer the question by digging into the implementation code, but that would be volunteering their time to you, perhaps hours.

So I think I have already mentioned before that if you make a TCP connection to a P4Runtime API server, including the open source implementations I am aware of, it uses gRPC, which I believe mandates the use of TLS, or at least strongly encourages it, perhaps with special options only intended for local testing that disable the TLS authentication of connecting clients.  Being careful with secret keys is the typical way to prevent an untrusted client from connecting to the server.

I do not even know if it is possible for code running within the same user-space process as the P4Runtime API server can make "P4Runtime API" requests in that same process, or not.  Certainly that process is capable of taking remote P4Runtime API requests and translating them into the necessary local API calls to access the local networking device, which would typically vary from one device to another, and I would think no one in their right mind security-wise would recommend executing untrusted code within the same user space process running the P4Runtime API server code.

Andy