netdev - RE: [PATCH net] net: sctp: fix multihoming retransmission path selection to rfc4960

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 for Android: free password hash cracker in your pocket

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

Message-ID: <063D6719AE5E284EB5DD2968C1650D6D0F6C7694@AcuExch.aculab.com>
Date:	Thu, 20 Feb 2014 13:25:31 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Daniel Borkmann' <dborkman@...hat.com>
CC:	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>,
	Gui Jianfeng <guijianfeng@...fujitsu.com>
Subject: RE: [PATCH net] net: sctp: fix multihoming retransmission path
 selection to rfc4960

From: Daniel Borkmann
> On 02/20/2014 01:25 PM, David Laight wrote:
> > I was wondering whether it is valid (or even reasonable) to send
> > the retransmit down multiple paths?  Particularly if they are
> > not known to be working.
> 
> As far as I can see, the RFC says that we should pick one, and
> not broadcast through all paths, besides HB should monitor these
> anyway.
> 
> Future work, however, could select a retransmission path "more
> intelligent" based on further transport path properties, but
> that is certainly not net material, plus it seems we would need
> additional state logic indicating that a path has been used before
> to not exclude other less optimal transports on successive
> retransmits.

Yes, anything like that probably requires a few steps (and testing)
before being finally implemented.

I always like to have a list of 'future work' (mostly in my head).
Sometimes you suddenly think of a cheap way of doing something,
and you also don't want to move in the wrong direction.

> > Or maybe resend heartbeats in a desperate attempt to find a working
> > path?
> 
> Yes, that is done through HBs, see 1.5.7 of RFC4960.

I've managed so far without having to read the SCTP RFCs :-)
But I've implemented enough comms protocols over the years to
know most of the pitfalls.

> > Do you guys know which kernel version(s) have that patch?
> 
> git describe 4141ddc02a92
> v2.6.26-rc4-210-g4141ddc

Thanks.

	David



--
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