On 11/21/2013 01:40 AM, Jesse Gross wrote:
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.
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.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
