| 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
| ||
|
Date: Wed, 4 Dec 2013 17:25:40 +0100 From: Michael Tuexen <Michael.Tuexen@...chi.franken.de> To: Vlad Yasevich <vyasevich@...il.com> Cc: David Laight <David.Laight@...LAB.COM>, Sun Paul <paulrbk@...il.com>, netdev@...r.kernel.org, linux-sctp@...r.kernel.org, Karl Heiss <kheiss@...il.com>, Neil Horman <nhorman@...driver.com>, linux-kernel@...r.kernel.org Subject: Re: Supporting 4 way connections in LKSCTP On Dec 4, 2013, at 5:12 PM, Vlad Yasevich <vyasevich@...il.com> wrote: > On 12/04/2013 11:01 AM, Michael Tuexen wrote: >> On Dec 4, 2013, at 4:41 PM, Vlad Yasevich <vyasevich@...il.com> wrote: >> >>> On 12/04/2013 09:50 AM, David Laight wrote: >>>>>> In normal operation, IP-A sends INIT to IP-X, IP-X returns INIT_ACK to >>>>>> IP-A. IP-A then sends HB to IP-X, IP-X then returns HB_ACK to IP-A. In >>>>>> the meantime, IP-B sends HB to IP-Y and IPY returns HB_ACK. >>>>>> >>>>>> In case of the path between IP-A and IP-X is broken, IP-B sends INIT >>>>>> to IP-X, NODE-B uses IP-Y to return INIT_ACK to IP-B. Then IP-B sends >>>>>> HB to IP-X, and IP-Y returns HB_ACK to IP-B. In the meantime, the HB >>>>>> communication between IP-B and IP-Y follows the normal flow. >>>>>> >>>>>> Can I confirm, is it really valid? >>>>> >>>>> As long as NODE-B knows about both IP-A and IP-B, and NODE-A knows about >>>>> both IP-X and IP-Y (meaning all the addresses were exchanged inside INIT >>>>> and INIT-ACK), then this situation is perfectly valid. In fact, this >>>>> has been tested an multiple interops. >>>> >>>> There are some network configurations that do cause problems. >>>> Consider 4 systems with 3 LAN segments: >>>> A) 10.10.10.1 on LAN X and 192.168.1.1 on LAN Y. >>>> B) 10.10.10.2 on LAN X and 192.168.1.2 on LAN Y. >>>> C) 10.10.10.3 on LAN X. >>>> D) 10.10.10.4 on LAN X and 192.168.1.2 on LAN Z. >>>> There are no routers between the networks (and none of the systems >>>> are running IP forwarding). >>>> >>>> If A connects to B everything is fine - traffic can use either LAN. >>>> >>>> Connections from A to C are problematic if C tries to send anything >>>> (except a HB) to 192.168.1.1 before receiving a HB response. >>>> One of the SCTP stacks we've used did send messages to an >>>> inappropriate address, but I've forgotten which one. >>> >>> I guess that would be problematic if A can not receive traffic for >>> 192.168.1.1 on the interface connected to LAN X. I shouldn't >>> technically be a problem for C as it should mark the path to 192.168.1.1 >>> as down. For A, as long as it doesn't decide to ABORT the association, >>> it shouldn't be a problem either. It would be interesting to know more >>> about what problems you've observed. >>> >>>> >>>> Connections between A and D fail unless the HB errors A receives >>>> for 192.168.1.2 are ignored. >>> >>> Yes, this configuration is very error prone, especially if system B and >>> system D are up at the same time. Any attempts by system A to use >>> LAN Y will result in an ABORT generated by system B. I have seen >>> this issue well in production and we had to renumber system D to solve >>> it. >> The point is that address scoping should be used. When sending an >> INIT from 10.10.10.1 to 10.10.10.4 you should not list 192.168.1.1, >> since you are transmitting an address to a node which might or might >> not "be in the same scope". We had IDs for that in the past, but >> they never made it to RFC state, because they were not progressed enough >> by the authors. Maybe we should push them again... > > But these 2 are technically in the same scope. They are both private > address types. Also, this will not solve the problem either since That is correct. But I think you should not transfer a private address to another private address belonging to a different network. I don't think this was specified in the older IDs... > the configured addresses could be: > System A) 10.0.0.1 on Lan X, 10.10.0.1 on Lan Y > System B) 10.0.0.2 on Lan X, 10.10.0.2 on Lan Y > System C) 10.0.0.3 on Lan X, 10.10.0.2 on Lan Z > > Same problem will occur. Depending on the subnet masks, it might work not not. Are you configuring them with /8? > > Btw, were there any IDs other then draft-stewart-tsvwg-sctp-ipv4? Yes, one for IPv6. http://tools.ietf.org/html/draft-stewart-tsvwg-sctpipv6-01 They need to be integrated and improved... Best regards Michael > > Thanks > -vlad > >> >> Best regards >> Michael >>> >>> -vlad >>>> >>>> Of course the application could explicitly bind to only the 10.x address >>>> but that requires the application know the exact network topology >>>> and may be difficult for incoming calls. >>>> >>>> David >>>> >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in >>> the body of a message to majordomo@...r.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> > > -- 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
Powered by blists - more mailing lists