netdev - Re: [RFC PATCH net-next] sctp: fix src address selection if using secondary addresses

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 10 Jul 2015 13:17:18 -0300
From:	Marcelo Ricardo Leitner <mleitner@...hat.com>
To:	Vlad Yasevich <vyasevich@...il.com>
Cc:	Michael Tuexen <tuexen@...muenster.de>, netdev@...r.kernel.org,
	linux-sctp@...r.kernel.org, Neil Horman <nhorman@...driver.com>
Subject: Re: [RFC PATCH net-next] sctp: fix src address selection if using
 secondary addresses

On Fri, Jul 10, 2015 at 11:35:28AM -0400, Vlad Yasevich wrote:
> On 07/10/2015 07:53 AM, Marcelo Ricardo Leitner wrote:
> > On Thu, Jul 09, 2015 at 09:55:19PM +0200, Michael Tuexen wrote:
> >>> On 09 Jul 2015, at 18:54, Marcelo Ricardo Leitner <mleitner@...hat.com> wrote:
> >>>
> >>> Cc'ing Michael too.
> >> I'm not familiar with the Linux kernel code, so I can't comment on it.
> >> But making sure to use a source address belonging to the emitting
> >> interface makes sense for me.
> >>
> >> Best regards
> >> Michael
> > 
> > That's pretty much what I was looking for, in case I missed something on
> > SCTP RFCs. 
> > 
> 
> Well, the RFCs do not really specify what the source address should be, and there

That's why I was afraid of having missed something ;)

> have been numerous times where I've seen weak host model in use on the wire
> even with a BSD peer.
> 
> This also puts a very big nail through many suggestions we've had over the years
> to allow source based path multihoming in addition to destination based multihoming
> we currently support.
> 
> It might be a good idea to make rp-filter like behavior best effort, and have
> the old behavior as fallback.  I am still trying to think up different scenarios
> where rp-filter behavior will cause things to fail prematurely...

The old behavior is like "if we don't have a src yet and can't find a
preferred src for this dst, use the 1st bound address". We can add it
but as I said, I'm afraid it is just doing wrong and not worth. If such
randomly src addressed packet is meant to be routed, the router will
likely drop it as it is seen as a spoof. And if it reaches the peer, it
will probably come back through a different path.

I'm tempted to say that current usual use cases are handled by the first
check on this function, which returns the preferred/primary address for
the interface and checks against bound addresses. Whenever you reach the
second check, it just allows you to use that 1st bound address that is
checked. I mean, I can't see use cases that we would be breaking with
this change. 

But yeah, it impacts source based routing, and I'm not aware of previous
discussions on it. I'll try to dig some up but if possible, please share
some pointers on it.

  Marcelo

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