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 system)
Also this doesn't give me the used URLs (or the user). it gives me quiet
some good idea about what happens on a system.
Therefor I think it's worse to think about backporting this patch series
at least to the current long term stable kernel (4.1) too.
Regards,
Alexander Holler
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
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
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
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
From: Martin KaFai Lau <[email protected]>
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.