On Wed, Nov 20, 2013 at 1:43 AM, Thomas Graf <tg...@redhat.com> wrote: > On 11/20/2013 10:14 AM, Jesse Gross wrote: >> On Wed, Nov 20, 2013 at 1:08 AM, Thomas Graf <tg...@redhat.com> wrote: >>> I might be missing something but what about the rxhash == 0 case? >>> >>> VXLAN does: >>> hash = skb_get_rxhash(skb); >>> if (!hash) >>> hash = jhash(skb->data, 2 * ETH_ALEN, >>> (__force u32) skb->protocol); >>> >>> Shouldn't we hash the pkt_key then? >> >> >> LISP is an L3 protocol rather than L2 like VXLAN so we're guaranteed >> to have at least IP addresses to hash in skb_get_rxhash(). > > > Right, unless skb_flow_dissect() fails which I think could be triggered > when an invalid GRE header is encapsulated on top of IP inside LISP. > Basically any header violation caught by skb_flow_dissect() that is not > caught by the flow extraction. An attacker could use such packets to > force unhashed source ports to overload a load balancer. > > Same could happen if the RX NIC RSS results in 0, i.e. > (skb->l4_rxhash && !skb->rxhash) > > VXLAN would handle these fine right now.
This seems like a more general problem with skb_flow_dissect() to me - it would be better to extract as much entropy from the packet as possible rather than just giving up and returning 0 if something is invalid. This is effectively what VXLAN is doing - it's using the L2 headers as a last resort, even if the upper layers have a problem. I think this would also apply to other users of the rxhash, such as RPS. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
