Re: [PATCH net-next v5 00/11] ipv6: Only create RTF_CACHE route after encountering pmtu exception
From: Martin KaFai Lau Date: Fri, 28 Aug 2015 00:36:38 -0700 > On Mon, Aug 17, 2015 at 11:43:20AM +0200, Alexander Holler wrote: >> That's why I vote to check out if it's possible/reasonable to backport this >> series to the stable kernels. > I have backported to 4.0.y without major issue, so possible. > > I did try on 3.1x and gave up. > > It is a lot of changes, so I don't think it is a good idea for -stable. I am absolutely, firmly, against any of this work going into -stable. It is completely inappropriate, the potential for regressions is enormous. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next v5 00/11] ipv6: Only create RTF_CACHE route after encountering pmtu exception
Am 28.08.2015 um 11:27 schrieb Alexander Holler: Am 28.08.2015 um 09:36 schrieb Martin KaFai Lau: On Mon, Aug 17, 2015 at 11:43:20AM +0200, Alexander Holler wrote: That's why I vote to check out if it's possible/reasonable to backport this series to the stable kernels. I have backported to 4.0.y without major issue, so possible. Sure, as this was likely one of the versions they've used to create the patch. I did try on 3.1x and gave up. It is a lot of changes, so I don't think it is a good idea for -stable. Depends on what you're expecting from a (stable) kernel. The patch description mentions what happens when a system deals with a lot of other ipv6-systems and that problem is easy to exercise and to value. Rating the information leak is harder, some people even won't understand that this might be a problem. And now look at which kernel-versions are now used in new devices (likely something <= 3.10, which is more than two years old), how long they will be used, and make a guess about IPv6 usage in 5 years. Anyway, I've no insights about all the politics happening in the background (e.g. stuff like the LTSI tree) and I've just wanted raise awareness about that (imho important) patch series. Not to speak about phones, but those are most likely a problem of one specific company ;) Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next v5 00/11] ipv6: Only create RTF_CACHE route after encountering pmtu exception
Am 28.08.2015 um 09:36 schrieb Martin KaFai Lau: On Mon, Aug 17, 2015 at 11:43:20AM +0200, Alexander Holler wrote: That's why I vote to check out if it's possible/reasonable to backport this series to the stable kernels. I have backported to 4.0.y without major issue, so possible. Sure, as this was likely one of the versions they've used to create the patch. I did try on 3.1x and gave up. It is a lot of changes, so I don't think it is a good idea for -stable. Depends on what you're expecting from a (stable) kernel. The patch description mentions what happens when a system deals with a lot of other ipv6-systems and that problem is easy to exercise and to value. Rating the information leak is harder, some people even won't understand that this might be a problem. And now look at which kernel-versions are now used in new devices (likely something <= 3.10, which is more than two years old), how long they will be used, and make a guess about IPv6 usage in 5 years. Anyway, I've no insights about all the politics happening in the background (e.g. stuff like the LTSI tree) and I've just wanted raise awareness about that (imho important) patch series. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next v5 00/11] ipv6: Only create RTF_CACHE route after encountering pmtu exception
On Mon, Aug 17, 2015 at 11:43:20AM +0200, Alexander Holler wrote: > That's why I vote to check out if it's possible/reasonable to backport this > series to the stable kernels. I have backported to 4.0.y without major issue, so possible. I did try on 3.1x and gave up. It is a lot of changes, so I don't think it is a good idea for -stable. Thanks, Martin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next v5 00/11] ipv6: Only create RTF_CACHE route after encountering pmtu exception
On Mon, Aug 17, 2015 at 11:43:20AM +0200, Alexander Holler wrote: That's why I vote to check out if it's possible/reasonable to backport this series to the stable kernels. I have backported to 4.0.y without major issue, so possible. I did try on 3.1x and gave up. It is a lot of changes, so I don't think it is a good idea for -stable. Thanks, Martin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next v5 00/11] ipv6: Only create RTF_CACHE route after encountering pmtu exception
Am 28.08.2015 um 11:27 schrieb Alexander Holler: Am 28.08.2015 um 09:36 schrieb Martin KaFai Lau: On Mon, Aug 17, 2015 at 11:43:20AM +0200, Alexander Holler wrote: That's why I vote to check out if it's possible/reasonable to backport this series to the stable kernels. I have backported to 4.0.y without major issue, so possible. Sure, as this was likely one of the versions they've used to create the patch. I did try on 3.1x and gave up. It is a lot of changes, so I don't think it is a good idea for -stable. Depends on what you're expecting from a (stable) kernel. The patch description mentions what happens when a system deals with a lot of other ipv6-systems and that problem is easy to exercise and to value. Rating the information leak is harder, some people even won't understand that this might be a problem. And now look at which kernel-versions are now used in new devices (likely something = 3.10, which is more than two years old), how long they will be used, and make a guess about IPv6 usage in 5 years. Anyway, I've no insights about all the politics happening in the background (e.g. stuff like the LTSI tree) and I've just wanted raise awareness about that (imho important) patch series. Not to speak about phones, but those are most likely a problem of one specific company ;) Regards, Alexander Holler -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next v5 00/11] ipv6: Only create RTF_CACHE route after encountering pmtu exception
Am 28.08.2015 um 09:36 schrieb Martin KaFai Lau: On Mon, Aug 17, 2015 at 11:43:20AM +0200, Alexander Holler wrote: That's why I vote to check out if it's possible/reasonable to backport this series to the stable kernels. I have backported to 4.0.y without major issue, so possible. Sure, as this was likely one of the versions they've used to create the patch. I did try on 3.1x and gave up. It is a lot of changes, so I don't think it is a good idea for -stable. Depends on what you're expecting from a (stable) kernel. The patch description mentions what happens when a system deals with a lot of other ipv6-systems and that problem is easy to exercise and to value. Rating the information leak is harder, some people even won't understand that this might be a problem. And now look at which kernel-versions are now used in new devices (likely something = 3.10, which is more than two years old), how long they will be used, and make a guess about IPv6 usage in 5 years. Anyway, I've no insights about all the politics happening in the background (e.g. stuff like the LTSI tree) and I've just wanted raise awareness about that (imho important) patch series. Regards, Alexander Holler -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next v5 00/11] ipv6: Only create RTF_CACHE route after encountering pmtu exception
From: Martin KaFai Lau ka...@fb.com Date: Fri, 28 Aug 2015 00:36:38 -0700 On Mon, Aug 17, 2015 at 11:43:20AM +0200, Alexander Holler wrote: That's why I vote to check out if it's possible/reasonable to backport this series to the stable kernels. I have backported to 4.0.y without major issue, so possible. I did try on 3.1x and gave up. It is a lot of changes, so I don't think it is a good idea for -stable. I am absolutely, firmly, against any of this work going into -stable. It is completely inappropriate, the potential for regressions is enormous. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next v5 00/11] ipv6: Only create RTF_CACHE route after encountering pmtu exception
Am 15.08.2015 um 09:48 schrieb Alexander Holler: Am 30.07.2015 um 13:57 schrieb Alexander Holler: Am 29.07.2015 um 11:25 schrieb Alexander Holler: Am 23.05.2015 um 05:55 schrieb Martin KaFai Lau: To complete the discussion, that "annoying behaviour" is also a big information leak. Because routes aren't considered confidential and aren't subject to privacy, that broken behaviour enabled *everyone* on the same system to see *all* the remote IPv6 systems to which there have been connection establishment tries. Just in case I haven't described the problem I see clearly enough: "Everyone" means everything (other SW) too, and if "Happy_Eyeballs" algorithms are used (see RFC 6555), this also affects systems which only have an IPv4 connection to the world, as long as IPv6 is enabled. That means it does not only affect multiuser systems and the current behaviour of kernels < 4.2 renders e.g. the private mode of most browsers somewhat useless too (in regard to protection against other SW and/or users running on the same system). That's why I vote to check out if it's possible/reasonable to backport this series to the stable kernels. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next v5 00/11] ipv6: Only create RTF_CACHE route after encountering pmtu exception
Am 15.08.2015 um 09:48 schrieb Alexander Holler: Am 30.07.2015 um 13:57 schrieb Alexander Holler: Am 29.07.2015 um 11:25 schrieb Alexander Holler: Am 23.05.2015 um 05:55 schrieb Martin KaFai Lau: To complete the discussion, that annoying behaviour is also a big information leak. Because routes aren't considered confidential and aren't subject to privacy, that broken behaviour enabled *everyone* on the same system to see *all* the remote IPv6 systems to which there have been connection establishment tries. Just in case I haven't described the problem I see clearly enough: Everyone means everything (other SW) too, and if Happy_Eyeballs algorithms are used (see RFC 6555), this also affects systems which only have an IPv4 connection to the world, as long as IPv6 is enabled. That means it does not only affect multiuser systems and the current behaviour of kernels 4.2 renders e.g. the private mode of most browsers somewhat useless too (in regard to protection against other SW and/or users running on the same system). That's why I vote to check out if it's possible/reasonable to backport this series to the stable kernels. Regards, Alexander Holler -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next v5 00/11] ipv6: Only create RTF_CACHE route after encountering pmtu exception
Am 30.07.2015 um 13:57 schrieb Alexander Holler: Am 29.07.2015 um 11:25 schrieb Alexander Holler: Am 23.05.2015 um 05:55 schrieb Martin KaFai Lau: This series is to avoid creating a RTF_CACHE route whenever we are consulting the fib6 tree with a new destination. Instead, only create RTF_CACHE route when we see a pmtu exception. That even helps on systems without an IPv6-connection to world because it avoids the IPv6 route add/delete pairs which happened before whenever an IPv6-connection was tried (e.g. by Happy Eyeballs algorithms). I think that's worse a laud. thanks. Of course, I meant worth. Sorry, but the left part of my brain seems to be sometimes in a (maybe forced) power save mode. ;) Also I wonder how the previous algorithm went into the kernel at all or why it wasn't fixed earlier. Anyway, it's great that someone took the time to fix that annoying behaviour (I've had on my radar since quiet some time). To complete the discussion, that "annoying behaviour" is also a big information leak. Because routes aren't considered confidential and aren't subject to privacy, that broken behaviour enabled *everyone* on the same system to see *all* the remote IPv6 systems to which there have been connection establishment tries. E.g. I can see the following on a system when browsing to facebook.com and google.com: [aholler@krabat snetmanmon.git]$ ./snetmanmon snetmanmon.conf.simple_example snetmanmon V1.3-5-g9f06 (C) 2015 Alexander Holler (...) New route 2a00:1450:4001:80c::100a (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' New route 2a03:2880:2130:cf05:face:b00c:0:1 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' New route 2a00:1450:4001:80c::1007 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' New route 2a00:1450:400f:803::101f (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' New route 2a00:1450:4001:80c::1008 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' New route 2a00:1450:4001:80c::1017 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' New route 2a00:1450:4016:804::200d (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' New route 2a00:1450:4001:80c::1000 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' New route 2a00:1450:4001:80c::1016 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' New route 2a00:1450:400f:803::1013 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' New route 2a00:1450:4001:80c::1006 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' New route 2a00:1450:4001:80c::1018 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' New route 2a00:1450:4016:804::2009 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' New route 2a00:1450:4001:80c::1005 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' Route 2a00:1450:4001:80c::100a (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' was deleted Route 2a03:2880:2130:cf05:face:b00c:0:1 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' was deleted Route 2a00:1450:4001:80c::1000 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' was deleted Route 2a00:1450:4001:80c::1005 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' was deleted Route 2a00:1450:4001:80c::1006 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' was deleted Route 2a00:1450:4001:80c::1007 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' was deleted Route 2a00:1450:4001:80c::1008 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' was deleted Route 2a00:1450:4001:80c::1016 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' was deleted Route 2a00:1450:4001:80c::1017 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' was deleted Route 2a00:1450:4001:80c::1018 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' was deleted Route 2a00:1450:400f:803::1013 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' was deleted Route 2a00:1450:400f:803::101f (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' was deleted Route 2a00:1450:4016:804::2009 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' was deleted Route 2a00:1450:4016:804::200d (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' was deleted (those deletes happen because I've no IPv6 connection to the outside world on
Re: [PATCH net-next v5 00/11] ipv6: Only create RTF_CACHE route after encountering pmtu exception
Am 30.07.2015 um 13:57 schrieb Alexander Holler: Am 29.07.2015 um 11:25 schrieb Alexander Holler: Am 23.05.2015 um 05:55 schrieb Martin KaFai Lau: This series is to avoid creating a RTF_CACHE route whenever we are consulting the fib6 tree with a new destination. Instead, only create RTF_CACHE route when we see a pmtu exception. That even helps on systems without an IPv6-connection to world because it avoids the IPv6 route add/delete pairs which happened before whenever an IPv6-connection was tried (e.g. by Happy Eyeballs algorithms). I think that's worse a laud. thanks. Of course, I meant worth. Sorry, but the left part of my brain seems to be sometimes in a (maybe forced) power save mode. ;) Also I wonder how the previous algorithm went into the kernel at all or why it wasn't fixed earlier. Anyway, it's great that someone took the time to fix that annoying behaviour (I've had on my radar since quiet some time). To complete the discussion, that annoying behaviour is also a big information leak. Because routes aren't considered confidential and aren't subject to privacy, that broken behaviour enabled *everyone* on the same system to see *all* the remote IPv6 systems to which there have been connection establishment tries. E.g. I can see the following on a system when browsing to facebook.com and google.com: [aholler@krabat snetmanmon.git]$ ./snetmanmon snetmanmon.conf.simple_example snetmanmon V1.3-5-g9f06 (C) 2015 Alexander Holler (...) New route 2a00:1450:4001:80c::100a (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' New route 2a03:2880:2130:cf05:face:b00c:0:1 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' New route 2a00:1450:4001:80c::1007 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' New route 2a00:1450:400f:803::101f (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' New route 2a00:1450:4001:80c::1008 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' New route 2a00:1450:4001:80c::1017 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' New route 2a00:1450:4016:804::200d (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' New route 2a00:1450:4001:80c::1000 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' New route 2a00:1450:4001:80c::1016 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' New route 2a00:1450:400f:803::1013 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' New route 2a00:1450:4001:80c::1006 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' New route 2a00:1450:4001:80c::1018 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' New route 2a00:1450:4016:804::2009 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' New route 2a00:1450:4001:80c::1005 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' Route 2a00:1450:4001:80c::100a (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' was deleted Route 2a03:2880:2130:cf05:face:b00c:0:1 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' was deleted Route 2a00:1450:4001:80c::1000 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' was deleted Route 2a00:1450:4001:80c::1005 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' was deleted Route 2a00:1450:4001:80c::1006 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' was deleted Route 2a00:1450:4001:80c::1007 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' was deleted Route 2a00:1450:4001:80c::1008 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' was deleted Route 2a00:1450:4001:80c::1016 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' was deleted Route 2a00:1450:4001:80c::1017 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' was deleted Route 2a00:1450:4001:80c::1018 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' was deleted Route 2a00:1450:400f:803::1013 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' was deleted Route 2a00:1450:400f:803::101f (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' was deleted Route 2a00:1450:4016:804::2009 (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' was deleted Route 2a00:1450:4016:804::200d (gateway fe80::21f:7bff:feb4:d13, type v6, scope universe) on interface 'virbr0' was deleted (those deletes happen because I've no IPv6 connection to the outside world on that
