You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a fairly well known kind of attack on routers/switches, for which most implement some kind of metering on packets before they are sent to the CPU. There are many variations of this, e.g. use a ternary table matching on the packet 5-tuple and perhaps additional packet header fields to match an entry in a table, and each entry has its own meter with an independently configurable rate is one reasonably common example I have seen. There is nothing I can think of that should be added to PSA for this purpose -- just a warning to P4 code writers.
The text was updated successfully, but these errors were encountered:
I do not think this is actually needed, especially since there are so many ways that PSA facilities can be employed to implement the proper protections (if necessary) and there are probably a lot of other ways how these protections can be implemented by the components outside of PSA. There is, obviously, no big harm, but in the specification document I'd rather stick to the definitions and the facts than the opinions and recommendations for the beginner code writers. That's what books and tutorials are for.
This is a fairly well known kind of attack on routers/switches, for which most implement some kind of metering on packets before they are sent to the CPU. There are many variations of this, e.g. use a ternary table matching on the packet 5-tuple and perhaps additional packet header fields to match an entry in a table, and each entry has its own meter with an independently configurable rate is one reasonably common example I have seen. There is nothing I can think of that should be added to PSA for this purpose -- just a warning to P4 code writers.
The text was updated successfully, but these errors were encountered: