netdev - Re: [PATCH] SCTP: enable cookie-echo retransmission transport switch

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] [day] [month] [year] [list]

Date:	Fri, 13 Jun 2008 08:57:54 -0400
From:	Vlad Yasevich <vladislav.yasevich@...com>
To:	Gui Jianfeng <guijianfeng@...fujitsu.com>
Cc:	David Miller <davem@...emloft.net>, linux-sctp@...r.kernel.org,
	netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH] SCTP: enable cookie-echo retransmission transport switch

Gui Jianfeng wrote:
> Vlad,
> 
>   Thanks for your comments.
> 
> Vlad Yasevich wrote:
>> Gui Jianfeng wrote:
>>> Vlad,
>>> This patch enables cookie-echo retransmission transport switch
>>> feature. If COOKIE-ECHO retransmission happens, it will be sent to the
>>> address other than the one last sent to.
>>>
>> NAK.
>>
>> You can't blindly choose a different transport since they could
>> be unconfirmed and can't really be used until we confirm them
>> with HBs.  So, you can only do this when the user issued an
>> sctp_connectx() and we have multiple confirmed transports.
>>
>> In this case only confirmed transports are allowed, otherwise
>> there is a possibility of hijacking associations.
>>
>   Choosing a transport here just gives a suggestion for sctp_outq_flush(),
>   sctp_outq_flush() will judge again. If the selected transport is in 
>   INACTIVE or UNCONFIRMED, active_path will be used.
>   So COOKIE-ECHO won't be sent to a unconfirmed address.
> 

Yep, and this completely nullifies the thing you are trying to do.  So, instead
of trying other available transports, we end up just sending on the active path
is at this stage of association is the same as primary.

>> Also, looking at this, the same problem exists in current
>> code for selection INIT transports.
>>
>> We don't correctly treat peers passed to connectx() as confirmed
>> and don't select the correct transport.
>>
>> Once you fix that above, you can just re-use the function and
>> re-use init_last_sent_to.
> 
>   Will do.

Just an FYI, here is a way BSD handles this:
	a.  they assume all destinations passed to connectx() are
	    reachable/confirmed.
	b.  when processing INIT-ACK, they tag all the existing destinations
	    with a flag, and clear the flag if the destination is in INIT-ACK.
	c.  they free all destinations that have the flag set at the end of
	    INIT-ACK.

I think a simpler way would to add another state to the transport that allows 
sending handshakes and correctly transitions to confirmed when association is
fully formed.  In BSD, they end up walking the destination chain 3 times, which
is just a waste.

-vlad
> 
>> -vlad
>>
> 
> 
> 
>>
> 

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