[ovs-dev] [PATCH 3/3] datapath: lisp: Use skb rxhash for source port.

Jesse Gross jesse at nicira.com
Thu Nov 21 00:40:25 UTC 2013


On Wed, Nov 20, 2013 at 1:43 AM, Thomas Graf <tgraf at redhat.com> wrote:
> On 11/20/2013 10:14 AM, Jesse Gross wrote:
>> On Wed, Nov 20, 2013 at 1:08 AM, Thomas Graf <tgraf at 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.



More information about the dev mailing list