[P4-design] Packet Validation Checks

Peter Newman (petenewm) petenewm at cisco.com
Tue Aug 11 14:46:00 EDT 2015


Leo,

I hadn’t thought of XORing the two addresses. Its not ugly at all — I’m sure it’s what we’d do in the hardware.

I agree with you about the parser transition. However I’m unwilling to spend a whole parse cycle to perform this check in what will probably turn out to be the critical path. I think I could achieve it if I move a whole load of non-critical path junk out of my ipv4 parse state into its own parse state and then just duplicate everything that remains in the manner you suggest as “proceed_as_normal_state.” I’d rather increase the number of entries in the TCAM than the depth of the longest path in the parse graph.

I feel like I’m doing the job of an optimizing compiler manually.

Thanks

—Peter

On Aug 10, 2015, at 4:25 PM, Leo Alterman <leo at barefootnetworks.com<mailto:leo at barefootnetworks.com>> wrote:

Hi Peter,
Thanks for the feedback! Some suggestions inline:

> Source Address == Destination Address — can be invalid for some protocols

You could try using if() conditions in the control flow or XORing the two and confirming the result is 0. The latter suggestion is certainly ugly but just thrown in there for completeness.

> In IPv4 I’d like to check that if the Don’t Fragment bit is set then the Fragmentation Offset == 0

Parser transition cases can be masked like TCAM entries, so you should be able to create a state with a branch like this:

return (ipv4.fragment_offset, ipv4.dont_fragment) {
   0 mask 1 : proceed_as_normal_state;
   1 :             proceed_as_normal_state;
   default :    deal_with_the_error_state;
}

> One option for terminating MPLS is to define a range of special label values. The parser needs to be able to check whether an MPLS label falls into this range.

Ah, range matching :) . I suppose the issue is that a parser_value_set (or its future blackbox-defined equivalent) only deals with individual case values, which becomes unfeasible if the range is too large? Masked parser cases at the right priority might sort of get you there, but it's definitely not a general solution. Expressing range matches in the language is something we've been tossing around internally for quite a while, both for the parser and elsewhere. We haven't found a particularly nice way to do it.

> There’s also a payload length check I couldn’t implement.

Ah. I'm guessing the issue is calculating the number of bytes after a given header instance in the original packet? That does sound tricky.

P4 doesn't provide too many facilities for working with the payload yet, partially because we're assuming it will start off targeting primarily high-performance forwarding elements which are naturally ill-suited for that kind of stuff. I'm not sure what the best way to do perform this check would be. Good food for thought.

Regards,
~Leo



On Mon, Aug 10, 2015 at 1:01 PM, Peter Newman (petenewm) <petenewm at cisco.com<mailto:petenewm at cisco.com>> wrote:
I erroneously stated at the last meeting that there were a number of packet validation checks I had been unable to express in P4. This was because I was trying to implement them all in the parser. Clearly some of the checks need to be implemented in the match+action tables.

I can implement all of the "Address == Constant" checks using match+action but I am still left with a few packet validation checks I haven’t been able to implement:

Source Address == Destination Address — can be invalid for some protocols

In IPv4 I’d like to check that if the Don’t Fragment bit is set then the Fragmentation Offset == 0

One option for terminating MPLS is to define a range of special label values. The parser needs to be able to check whether an MPLS label falls into this range.

There’s also a payload length check I couldn’t implement.

—Peter


_______________________________________________
P4-design mailing list
P4-design at p4.org<mailto:P4-design at p4.org>
Listinfo - http://mail.p4.org/mailman/listinfo/p4-design_p4.org



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-design_lists.p4.org/attachments/20150811/31f7fc88/attachment-0001.html>


More information about the P4-design mailing list