Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1208034 > unrolled thread

Re: [PATCH net-next v5 00/11] ipv6: Only create RTF_CACHE route after encountering pmtu exception

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH net-next v5 00/11] ipv6: Only create RTF_CACHE route after  encountering pmtu exception Alexander Holler <holler@ahsoftware.de> - 2015-08-15 09:50 +0200
    Re: [PATCH net-next v5 00/11] ipv6: Only create RTF_CACHE route after  encountering pmtu exception Alexander Holler <holler@ahsoftware.de> - 2015-08-17 11:50 +0200

#1208034 — 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 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1208502

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web