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

[Thomas Graf]

On 11/21/2013 01:40 AM, Jesse Gross wrote:
> 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.

I agree. Fixing this in skb_flow_dissect() makes more sense to me as
well. I'm pointing it out in the context of this patch because
previously LISP did not have this vulnerability.