netdev - Re: [PATCH] tcp resets are misrouted

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20121012.135343.2054104958323622117.davem@davemloft.net>
Date:	Fri, 12 Oct 2012 13:53:43 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	kuznet@....inr.ac.ru
Cc:	netdev@...r.kernel.org, shawn.lu@...csson.com,
	eric.dumazet@...il.com, sol@....ru
Subject: Re: [PATCH] tcp resets are misrouted

From: Alexey Kuznetsov <kuznet@....inr.ac.ru>
Date: Fri, 12 Oct 2012 18:34:17 +0400

> After commit e2446eaa.. tcp resets are always lost, when routing is asymmetric.
> Yes, backing out that patch will result in misrouting of resets for dead connections
> which used interface binding when were alive, but we actually cannot do anything here.
> What's died that's died and correct handling normal unbound connections is obviously a priority.
> 
> Comment to comment:
>> This has few benefits:
>>   1. tcp_v6_send_reset already did that.
> 
> It was done to route resets for IPv6 link local addresses. It was a mistake to
> do so for global addresses. The patch fixes this as well.
> 
> Actually, the problem appears to be even more serious than guaranteed loss of resets.
> As reported by Sergey Soloviev <sol@....ru>, those misrouted resets create a lot of
> arp traffic and huge amount of unresolved arp entires putting down to knees NAT firewalls
> which use asymmetric routing.
> 
> Signed-off-by: Alexey Kuznetsov <kuznet@....inr.ac.ru>

Applied and queued up for -stable, thanks!
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html