netdev - Re: SCTP's processing of unexpected COOKIE

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]

Date:	Tue, 10 Jun 2014 09:44:19 -0400
From:	Vlad Yasevich <vyasevich@...il.com>
To:	David Laight <David.Laight@...LAB.COM>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: SCTP's processing of unexpected COOKIE_ECHO doesn't seem useful.

On 06/10/2014 05:52 AM, David Laight wrote:
> I'm seeing some unexpected (to me) behaviour of the SCTP stack
> when the remote system restarts.
> 
> I've a socket that has a single association, and I'm rather
> expecting TCP-like behaviour.
> So I'd expect some kind of failure condition on my existing
> connection, and then a new connection be established on a
> different socket - eg though a listening socket.
> This would then go through all my code for correctly
> initialising a new connection.
> 
> What happens is rather different.
> 
> The remote sends an INIT with the same port numbers as the
> previous connection, AFAICT the code sends an INIT_ACK with
> some numbers taken from the existing TCB.
> 
> When the COOKIE_ECHO is received sctp_sf_do_5_2_4_dupcook()
> is called, condition 'A' is detected and sctp_sf_do_dupcook_a()
> called.
> 
> RFC 2960 says that this should be treated as a received ABORT
> followed by a COOKIE echo - this sounds fine, I want the ABORT
> processing to kill the existing connection.
> However it then says that 'RESTART' should be indicated to the ULP
> rather than 'COMMUNICATION LOST'.
> 
> AFAICT this is just silently ignored by the socket layer.
> I've a process sleeping in recv() (actually a kernel thread in
> sock_recvmsg()) and it is not woken up at all.

You haven't subscribed to receive notifications and as a result
you haven't been woken up.

The ABORT treatment above simply resets the state of the original
connection, thus simulating the ABORT and a new connection all
in one.

This is where an application really needs to utilize and process
SCTP notifications.  You can also collect data like which messages
have not been send to the remote, so that you can re-queue them.

> 
> This leaves the 'application' code in completely the wrong state for
> the SCTP connection.
>

I can understand where you are coming from.  There are some useful
cases for association restart, but it could also be turned off
without much adverse effect to the applications.

May be a sysctl or a socket option that allows you control whether you
want association restart or not might be nice to have.

-vlad

> ISTM that the mapping of SCTP to connection-mode sockets should be
> treating this as a disconnect.
> 
> This scenario can be reproduced by disconnecting with ABORT and
> getting iptables to discard the ABORT.
> It can happen with some connection retry algorithms if there is
> message loss.
> 
> 	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
> 

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