Hi everyone,
I am currently working on implementing attack detection using P4. In my current implementation, when the switch detects an attack packet in the data plane, it pushes an INT header onto the packet and redirects it to the controller (acting as a Packet-In).
However, I started wondering if INT is actually necessary for this. Since a standard Packet-In mechanism can already send the packet to the controller, simply adding an INT header seems redundant if I’m just sending it straight to the controller from the detection point.
I want to research the utility of INT, but I am losing sight of its specific benefits in this scenario. Is my use case a mismatch for INT? I would appreciate it if anyone could explain the advantages of using INT over standard Packet-In for this type of security monitoring.
Thanks!
“standard Packet-in” means that a packet is sent from the data plane to the controller.
There are often multiple different reasons that the data plane sends a packet to the controller via packet-in. If so, the controller needs some way to determine the reason that packet was sent to it from the data plane, because it might need to execute very different code depending upon that reason, e.g. the controller needs to do something completely different with the packet if it was sent from the data plane because it got a miss on a source MAC address lookup in a table, vs. it is a DHCP packet, vs. the packet is IPv4 with TTL=0, etc.
Clearly, sending only the data in the Ethernet frame alone to the controller is not sufficient for the controller to know this reason. Thus typically you have some kind of “punt header” prepended to the packet, by the data plane, with fields indicating the reason why it is being sent to the controller, and typically other information about the packet, e.g.
- which physical port was the packet received on?
- a “punt reason” field, typically a smallish field, e.g. 8 bits in size, with a unique numeric value in the range [0,255] for each of the reasons that the data plane might send a packet to the controller
- Any other data about the packet that is relevant to the controller, and/or useful for a person who is debugging why the packet was sent to the controller.
Should this header be an INT header, or something else? That is really up to you, if you are the developer for both the data plane and controller code. There is no “punt reason” field that I can recall in any standard INT header, so that seems lacking to me.
The reason that INT was created was to try to get some agreement between different interested stakeholders in what fields should be included in a new packet header that can communicate network telemetry information, perhaps going through a network with devices sold by different vendors. If you are willing to buy all your network devices from a single vendor that has its own proprietary way to do this, then you don’t need a multi-vendor solution for that problem.
if your purpose is merely “send suspicious packets to the controller,” INT isn’t necessarily essential. ordinary Packet-In with a basic punt header works properly. INT excels when you require telemetry across many hops — e.g., latency, queue depth, route details — or when you need a vendor-agnostic mechanism to gather per-packet metrics throughout the network.
for single-point attack detection at the switch, adding an INT header is primarily extra overhead. just make sure your punt header specifies the controller why the packet was sent and where port it originated from. It’s not the complete INT telemetry that’s really useful here.