netdev - Re: [RFC PATCH] sctp: Don't lookup dst if transport dst is still valid

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, 16 Jul 2013 17:58:52 +0800
From:	Fan Du <fan.du@...driver.com>
To:	David Miller <davem@...hat.com>
CC:	<vyasevich@...il.com>, <nhorman@...driver.com>,
	<nicolas.dichtel@...nd.com>, <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH] sctp: Don't lookup dst if transport dst is still
 valid

On 2013年07月13日 06:58, David Miller wrote:
> From: Fan Du<fan.du@...driver.com>
> Date: Fri, 12 Jul 2013 11:15:10 +0800
>
>> But problem still arise when we attempt to delete address
>> in multi-home mode, deleting an IPv6 address does not invalidate
>> any dst which source address is the same at the deleted one.
>> Which means sctp cannot rely on ip6_dst_check in this scenario.
>
> I still cannot understand why this is an SCTP specific issue.

It's not SCTP specific, it's shared by all all layer 4 protocol IMHO.
The issue of SCTP IPv6 doesn't check IPv6 dst validness has been addressed
using *only* dst_cookie as other layer 4 protocol does for its sock.
But this scheme cannot cover scenario when delete primary address to support
SCTP multi-home feature, this is where the concern is.

Use netsend to send a large file using DCCP, considering the sender
host has two IPv6 address, while sending, delete the one netsend currently
using. Wireshark could catch the sender is still transmit packet out using
the deleted address in a slowly manner.

All of those boils down to one question that I cannot resist to ask:
If delete an IPv6 address(*1*), whether the original rt/dst destinate for a
remote address(*2*) using the deleted address as source address is still legal
for subsequent usage in current kernel IPv6 routing implementation???

btw, (*1*) and (*2*) are on quite different node in the binary tree as well
as different leaf.

> Specifically, I cannot see why address addition/deletion doesn't
> cause problems for cached ipv6 routes in UDP and TCP sockets too.
>

-- 
浮沉随浪只记今朝笑

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