netdev - RE: [PATCH net 2/2] sctp: not copying duplicate addrs to the assoc's bind address list

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: <063D6719AE5E284EB5DD2968C1650D6DB00EF186@AcuExch.aculab.com>
Date:   Fri, 2 Sep 2016 13:22:05 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Xin Long' <lucien.xin@...il.com>,
        Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
CC:     Neil Horman <nhorman@...driver.com>,
        network dev <netdev@...r.kernel.org>,
        "linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>,
        davem <davem@...emloft.net>, Vlad Yasevich <vyasevich@...il.com>,
        "daniel@...earbox.net" <daniel@...earbox.net>
Subject: RE: [PATCH net 2/2] sctp: not copying duplicate addrs to the
 assoc's bind address list

From: Of Xin Long
> Sent: 25 August 2016 05:04
...
> But I still prefer the current patch.
> 1. This issue only happens when server bind 'ANY' addresses.
>     we don't need to add any new members to struct sctp_sockaddr_entry.
>     especially if it's a really corner issue,  we fix this as an improvement.
> 
> 2. It's yet two issues  here, the duplicate addrs may be from
>    a) different local NICs.
>    b) the same one NIC.
>    It may be unexpectable to filter them in NETDEV_UP/DOWN events.
> 
> 3. We check it only when sctp really binds it, just like sctp_do_bind.
> 
> What do you think ?

I want to know what kind of weed the SCTP authors were smoking when they
decided it was appropriate to put all of a systems IP addresses in the
cookie and cookie-ack messages.

It would be nice to have the local addresses selected by the kernel on the
basis of the remote address - removing the necessity of the application
to know the current network topology (and IP addresses) in order to bind
to the correct local addresses before making an outward call.

This sort of requires that local addresses for a connection are more of a
property of the routing table than anything else.

Consider the following network:

    ----+---------------+----------------------+---------
        |               |                      |
     x.x.1.1         x.x.1.2                y.y.1.2
    10.1.1.1        10.1.1.2               10.1.1.2
        |               |                      |
    ----+---------------+                      +---------

A connection from x.x.1.1 to x.x.1.2 needs to specify the 10.1.1.* addresses,
but a connection for x.x.1.1 to y.y.1.2 must not.

I'm not at sure whether it is possible to setup listener(s) on x.x.1.1
that can accept connections from both x.x.1.2 and y.y.1.2.

	David