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: <20160902144421.GC11159@localhost.localdomain>
Date:   Fri, 2 Sep 2016 11:44:22 -0300
From:   "'Marcelo Ricardo Leitner'" <marcelo.leitner@...il.com>
To:     David Laight <David.Laight@...LAB.COM>
Cc:     "'Xin Long'" <lucien.xin@...il.com>,
        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

On Fri, Sep 02, 2016 at 02:25:42PM +0000, David Laight wrote:
> From: Marcelo Ricardo Leitner
> > Sent: 02 September 2016 14:47
> ...
> > > 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
> > >         |               |                      |
> > >     ----+---------------+                      +---------
> ...
> > > 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.
> > 
> > You mean without an explicit bind()?
> 
> You might be able to bind one socket to x.x.1.1 and a second to 10.1.1.1
> and x.x.1.1 so that connections to x.x.1.1 are only offered x.x.1.1 and
> those to 10.1.1.1 are offered both addresses.
> 
> But you can't make the init-ack responses for connections to x.x.1.1
> depend on whether the connect came from x.x.1.2 or y.y.1.2.
> 
> If the source and destination ports are fixed (as they usually are for M3UA)
> you can sit trying to make an outward connection, relying on the init collision
> code to work properly. Far from ideal!

Ahh yes, I see now. Yep..

  Marcelo