21 Mar
2018
21 Mar
'18
11:36 p.m.
Dear all,
as some may know I've been working last year [1] in GSoC and like to
repeat that. I checked the Freifunk project page [2] and found the
following project of LibreMesh I liked most: LibreNet6 integration [3].
As discussed on GitHub [4] wireguard [5] could be a slim & fast
replacement for Tinc. Problem is the missing auto provisioning of the
clients, as stated on the official website as well [6]. I came up with
a small PoC [7] as a centralized solution for the following tasks:
* Granting administrators/supporters device access to help with network
issues
* Secure connection over an unencrypted mesh network
* Offer public IPv4/6 to routers
A second approach could be to use bmx7-sms plugin to distribute public
keys within the mesh and enable not only the three points above but
also secure connections between all nodes. The second approach may
become obsolete as bmx7 might use `ip xfrm` [8] to encrypt tunnels
directly.
I'm aware that focus shouldn't be the coolest project but the one most
usable for the (Libre)Mesh community. So please share you thoughts if
you find other (not listed) project ideas I could work on. Please keep
in mind the deadline to apply is within the next weeks.
Best,
Paul
[1] https://github.com/aparcar/attendedsysupgrade-server
[2] https://projects.freifunk.net/#/projects
[3]
https://projects.freifunk.net/#/projects?project=libremesh_librenet6_integr…
[4] https://github.com/libremesh/lime-packages/issues/99
[5] http://wireguard.com/
[6] https://www.wireguard.com/todo/#dynamic-web-app-for-provisioning
[7] https://github.com/aparcar/wireguard-provisioning
[8] http://man7.org/linux/man-pages/man8/ip-xfrm.8.html#DESCRIPTION
23 Mar
23 Mar
8:14 a.m.
I am aware that wireguard is the last cool thing in terms of VPN, but I am
very doubtfull about it's usefulness in our setup, in librenet6 we use tinc in
switch mode, this way we can run any routing protocol on top of it, I already
know that some Routing Protocol has started woking on doing routing on top of
unicast only devices too but that is very limiting in term of RP choice and
still an investigation topic.
In LiMe we always try to be RP agnostic so que can eventually switch to a
better fitting solution without redesign everithing from scratch like we did
(non RP) from adhoc to 80211s that became as easy as to change a line in the
config file.
I would rather investigate how does it fit the new tinc 1.1 with our needs and
if with some configuration we could prevent it from doing L2 routing behing the
scenes as we already need to run an L3 RP on top of it, and also explore how
latency based metrics behave on such setup (mixing both phisical and tunnel
links)
Cheers
Gio
On Thursday, 22 March 2018 00:36:12 CET Paul Spooren wrote:
Dear all,
as some may know I've been working last year [1] in GSoC and like to
repeat that. I checked the Freifunk project page [2] and found the
following project of LibreMesh I liked most: LibreNet6 integration [3].
As discussed on GitHub [4] wireguard [5] could be a slim & fast
replacement for Tinc. Problem is the missing auto provisioning of the
clients, as stated on the official website as well [6]. I came up with
a small PoC [7] as a centralized solution for the following tasks:
* Granting administrators/supporters device access to help with network
issues
* Secure connection over an unencrypted mesh network
* Offer public IPv4/6 to routers
A second approach could be to use bmx7-sms plugin to distribute public
keys within the mesh and enable not only the three points above but
also secure connections between all nodes. The second approach may
become obsolete as bmx7 might use `ip xfrm` [8] to encrypt tunnels
directly.
I'm aware that focus shouldn't be the coolest project but the one most
usable for the (Libre)Mesh community. So please share you thoughts if
you find other (not listed) project ideas I could work on. Please keep
in mind the deadline to apply is within the next weeks.
Best,
Paul
[1] https://github.com/aparcar/attendedsysupgrade-server
[2] https://projects.freifunk.net/#/projects
[3]
https://projects.freifunk.net/#/projects?project=libremesh_librenet6_integra
tions&lang=en [4] https://github.com/libremesh/lime-packages/issues/99
[5] http://wireguard.com/
[6] https://www.wireguard.com/todo/#dynamic-web-app-for-provisioning
[7] https://github.com/aparcar/wireguard-provisioning
[8] http://man7.org/linux/man-pages/man8/ip-xfrm.8.html#DESCRIPTION
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
11:53 a.m.
I was not aware librenet6 uses mesh RPs over tinc to enhance security.
That sounds really strange to me.
Doesnt that:
1. Kill performance (due to tinc user-space tunnels and encryption)?
2. Obfuscate routing decisions which are now done in tinc and again in
the routing protocol on top of it.
3. Did anybody understand how the security implications for routing in
in tinc? Like A,B, and C do mesh and are all parts of the same tinc VPN
cloud. Does tinc guarantee anything for communication between A and B
if attacked by C? Or can this only be achieved if C is always excluded
from joining the tinc VPN. In the latter case you would essentially have
a closed & private network. Not an open one.
/axel
On 23.03.2018 09:14, Gio wrote:
I am aware that wireguard is the last cool thing in
terms of VPN, but I am
very doubtfull about it's usefulness in our setup, in librenet6 we use tinc in
switch mode, this way we can run any routing protocol on top of it, I already
know that some Routing Protocol has started woking on doing routing on top of
unicast only devices too but that is very limiting in term of RP choice and
still an investigation topic.
In LiMe we always try to be RP agnostic so que can eventually switch to a
better fitting solution without redesign everithing from scratch like we did
(non RP) from adhoc to 80211s that became as easy as to change a line in the
config file.
I would rather investigate how does it fit the new tinc 1.1 with our needs and
if with some configuration we could prevent it from doing L2 routing behing the
scenes as we already need to run an L3 RP on top of it, and also explore how
latency based metrics behave on such setup (mixing both phisical and tunnel
links)
Cheers
Gio
On Thursday, 22 March 2018 00:36:12 CET Paul Spooren wrote:
Dear all,
as some may know I've been working last year [1] in GSoC and like to
repeat that. I checked the Freifunk project page [2] and found the
following project of LibreMesh I liked most: LibreNet6 integration [3].
As discussed on GitHub [4] wireguard [5] could be a slim & fast
replacement for Tinc. Problem is the missing auto provisioning of the
clients, as stated on the official website as well [6]. I came up with
a small PoC [7] as a centralized solution for the following tasks:
* Granting administrators/supporters device access to help with network
issues
* Secure connection over an unencrypted mesh network
* Offer public IPv4/6 to routers
A second approach could be to use bmx7-sms plugin to distribute public
keys within the mesh and enable not only the three points above but
also secure connections between all nodes. The second approach may
become obsolete as bmx7 might use `ip xfrm` [8] to encrypt tunnels
directly.
I'm aware that focus shouldn't be the coolest project but the one most
usable for the (Libre)Mesh community. So please share you thoughts if
you find other (not listed) project ideas I could work on. Please keep
in mind the deadline to apply is within the next weeks.
Best,
Paul
[1] https://github.com/aparcar/attendedsysupgrade-server
[2] https://projects.freifunk.net/#/projects
[3]
https://projects.freifunk.net/#/projects?project=libremesh_librenet6_integra
tions&lang=en [4] https://github.com/libremesh/lime-packages/issues/99
[5] http://wireguard.com/
[6] https://www.wireguard.com/todo/#dynamic-web-app-for-provisioning
[7] https://github.com/aparcar/wireguard-provisioning
[8] http://man7.org/linux/man-pages/man8/ip-xfrm.8.html#DESCRIPTION
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
12:05 p.m.
On Friday, 23 March 2018 12:53:31 CET Axel Neumann wrote:
I was not aware librenet6 uses mesh RPs over tinc to
enhance security.
That sounds really strange to me.
It is not to enanche security but to address typical mesh routing problems
that we encounter also in an librenet6 ipv6 mesh tunnelbroker
Doesnt that:
1. Kill performance (due to tinc user-space tunnels and encryption)?
It hasn't be up until now the bottleneck
2. Obfuscate routing decisions which are now done in
tinc and again in
the routing protocol on top of it.
reading tinc 1.1 man it seems to me that the tinc under the hood routing may
be avoided, but again it hasn't be the bottle neck up until now
3. Did anybody understand how the security
implications for routing in
in tinc? Like A,B, and C do mesh and are all parts of the same tinc VPN
cloud. Does tinc guarantee anything for communication between A and B
if attacked by C? Or can this only be achieved if C is always excluded
from joining the tinc VPN. In the latter case you would essentially have
a closed & private network. Not an open one.
tinc security is not our primary focus, actually we even considered the
possibiliy t disable encryption if it constituted a bottleneck
Gio
/axel
On 23.03.2018 09:14, Gio wrote:
I am aware that wireguard is the last cool thing
in terms of VPN, but I am
very doubtfull about it's usefulness in our setup, in librenet6 we use
tinc in switch mode, this way we can run any routing protocol on top of
it, I already know that some Routing Protocol has started woking on doing
routing on top of unicast only devices too but that is very limiting in
term of RP choice and still an investigation topic.
In LiMe we always try to be RP agnostic so que can eventually switch to a
better fitting solution without redesign everithing from scratch like we
did (non RP) from adhoc to 80211s that became as easy as to change a line
in the config file.
I would rather investigate how does it fit the new tinc 1.1 with our needs
and if with some configuration we could prevent it from doing L2 routing
behing the scenes as we already need to run an L3 RP on top of it, and
also explore how latency based metrics behave on such setup (mixing both
phisical and tunnel links)
Cheers
Gio
On Thursday, 22 March 2018 00:36:12 CET Paul Spooren wrote:
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev Dear all,
as some may know I've been working last year [1] in GSoC and like to
repeat that. I checked the Freifunk project page [2] and found the
following project of LibreMesh I liked most: LibreNet6 integration [3].
As discussed on GitHub [4] wireguard [5] could be a slim & fast
replacement for Tinc. Problem is the missing auto provisioning of the
clients, as stated on the official website as well [6]. I came up with
a small PoC [7] as a centralized solution for the following tasks:
* Granting administrators/supporters device access to help with network
issues
* Secure connection over an unencrypted mesh network
* Offer public IPv4/6 to routers
A second approach could be to use bmx7-sms plugin to distribute public
keys within the mesh and enable not only the three points above but
also secure connections between all nodes. The second approach may
become obsolete as bmx7 might use `ip xfrm` [8] to encrypt tunnels
directly.
I'm aware that focus shouldn't be the coolest project but the one most
usable for the (Libre)Mesh community. So please share you thoughts if
you find other (not listed) project ideas I could work on. Please keep
in mind the deadline to apply is within the next weeks.
Best,
Paul
[1] https://github.com/aparcar/attendedsysupgrade-server
[2] https://projects.freifunk.net/#/projects
[3]
https://projects.freifunk.net/#/projects?project=libremesh_librenet6_inte
gra tions&lang=en [4]
https://github.com/libremesh/lime-packages/issues/99 [5]
http://wireguard.com/
[6] https://www.wireguard.com/todo/#dynamic-web-app-for-provisioning
[7] https://github.com/aparcar/wireguard-provisioning
[8] http://man7.org/linux/man-pages/man8/ip-xfrm.8.html#DESCRIPTION
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
24 Mar
24 Mar
2:37 p.m.
I wrote an abstract proposal and once it's accepted I'd be happy to
discuss the details.
Could someone please provide more information on the current Tinc setup?
In general I'm still in favor of a combination of BMX{6,7} for routing
and wireguard for tunneling, however that might be not agnostic enough.
Attached a PDF with the application.
On Fr, Mär 23, 2018 at 1:05 PM, Gio <gio(a)diveni.re> wrote:
On Friday, 23 March 2018 12:53:31 CET Axel Neumann
wrote:
I was not aware librenet6 uses mesh RPs over
tinc to enhance
security.
That sounds really strange to me.
It is not to enanche security but to address typical mesh routing
problems
that we encounter also in an librenet6 ipv6 mesh tunnelbroker
Doesnt that:
1. Kill performance (due to tinc user-space tunnels and encryption)?
It hasn't be up until now the bottleneck
2. Obfuscate routing decisions which are now
done in tinc and again
in
the routing protocol on top of it.
reading tinc 1.1 man it seems to me that the tinc under the hood
routing may
be avoided, but again it hasn't be the bottle neck up until now
3. Did anybody understand how the security
implications for routing
in
in tinc? Like A,B, and C do mesh and are all parts of the same tinc
VPN
cloud. Does tinc guarantee anything for communication between A
and B
if attacked by C? Or can this only be achieved if C is always
excluded
from joining the tinc VPN. In the latter case you would essentially
have
a closed & private network. Not an open one.
tinc security is not our primary focus, actually we even considered
the
possibiliy t disable encryption if it constituted a bottleneck
Gio
/axel
On 23.03.2018 09:14, Gio wrote:
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev I am aware that wireguard is the last cool thing
in terms of VPN,
but I am
very doubtfull about it's usefulness in our
setup, in librenet6
we use
tinc in switch mode, this way we can run any
routing protocol on
top of
it, I already know that some Routing Protocol has
started woking
on doing
routing on top of unicast only devices too but
that is very
limiting in
term of RP choice and still an investigation
topic.
In LiMe we always try to be RP agnostic so que can eventually
switch to a
better fitting solution without redesign
everithing from scratch
like we
did (non RP) from adhoc to 80211s that became as
easy as to
change a line
in the config file.
I would rather investigate how does it fit the new tinc 1.1 with
our needs
and if with some configuration we could prevent
it from doing L2
routing
behing the scenes as we already need to run an L3
RP on top of
it, and
also explore how latency based metrics behave on
such setup
(mixing both
phisical and tunnel links)
Cheers
Gio
On Thursday, 22 March 2018 00:36:12 CET Paul Spooren wrote:
> Dear all,
>
> as some may know I've been working last year [1] in GSoC and
like to
> repeat that. I checked the Freifunk project
page [2] and found
the
> following project of LibreMesh I liked most:
LibreNet6
integration [3].
>
> As discussed on GitHub [4] wireguard [5] could be a slim & fast
> replacement for Tinc. Problem is the missing auto provisioning
of the
> clients, as stated on the official website as
well [6]. I came
up with
> a small PoC [7] as a centralized solution for
the following
tasks:
>
> * Granting administrators/supporters device access to help with
network
> issues
> * Secure connection over an unencrypted mesh network
> * Offer public IPv4/6 to routers
>
> A second approach could be to use bmx7-sms plugin to distribute
public
> keys within the mesh and enable not only the
three points above
but
> also secure connections between all nodes.
The second approach
may
> become obsolete as bmx7 might use `ip xfrm`
[8] to encrypt
tunnels
> directly.
>
> I'm aware that focus shouldn't be the coolest project but the
one
most
> usable for the (Libre)Mesh community. So
please share you
thoughts if
> you find other (not listed) project ideas I
could work on.
Please keep
> in mind the deadline to apply is within the
next weeks.
>
> Best,
> Paul
>
> [1] https://github.com/aparcar/attendedsysupgrade-server
> [2] https://projects.freifunk.net/#/projects
> [3]
>
https://projects.freifunk.net/#/projects?project=libremesh_librenet6_inte
> gra tions&lang=en [4]
> https://github.com/libremesh/lime-packages/issues/99 [5]
> http://wireguard.com/
> [6]
https://www.wireguard.com/todo/#dynamic-web-app-for-provisioning
http://man7.org/linux/man-pages/man8/ip-xfrm.8.html#DESCRIPTION
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
2473
days inactive
2476
days old
4 comments
3 participants
participants (3)
-
Axel Neumann -
Gio -
Paul Spooren