netdev - Re: TCP 2MSL on loopback

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: <20070306145403.6be2c437@freekitty>
Date:	Tue, 6 Mar 2007 14:54:03 -0800
From:	Stephen Hemminger <shemminger@...ux-foundation.org>
To:	Howard Chu <hyc@...as.com>
Cc:	David Miller <davem@...emloft.net>, rick.jones2@...com,
	dada1@...mosbay.com, netdev@...r.kernel.org
Subject: Re: TCP 2MSL on loopback

On Tue, 06 Mar 2007 14:07:09 -0800
Howard Chu <hyc@...as.com> wrote:

> David Miller wrote:
> > From: Rick Jones <rick.jones2@...com>
> > Date: Tue, 06 Mar 2007 13:25:35 -0800
> > 
> >>> On the other hand, being able to configure a small MSL for the loopback 
> >>> device is perfectly safe. Being able to configure a small MSL for other 
> >>> interfaces may be safe, depending on the rest of the network layout.
> >> A peanut gallery question - I seem to recall prior discussions about how 
> >> one cannot assume that a packet destined for a given IP address will 
> >> remain detined for that given IP address as it could go through a module 
> >> that will rewrite headers etc.
> > 
> > That's right, both netfilter and the packet scheduler actions
> > can do that, that's why this whole idea about changing the MSL
> > on loopback by default is wrong and pointless.
> 
> If the headers get rewritten and the packet gets directed elsewhere, 
> then we're no longer talking about a loopback connection, so that's 
> outside the discussion.
> 
> If the packet gets munged by multiple filters but still eventually gets 
> to the specified destination, OK. But regardless, if both endpoints of 
> the connection are on the loopback device, then there is nothing wrong 
> with the idea. Those filters can only do so much, they still have to 
> preserve the reliable in-order delivery semantics of TCP, otherwise the 
> system is broken.
> 
> It may not have much use, sure, I admitted that much from the outset.
> 
> So I'll leave it at this, thanks for the feedback.


TCP can not assume anything about the path that a packet may take.
We have declared a moratorium on loopback benchmark foolishness.
Go optimize the idle loop instead ;-)

-- 
Stephen Hemminger <shemminger@...ux-foundation.org>
-
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