We've been talking about this for a little while now. It looks like the
babeld folks have been considering it as well:
---------- Forwarded message ----------
From: Dave Taht <dave.taht(a)gmail.com>
Date: Tue, Apr 7, 2015 at 7:25 AM
Subject: [Babel-users] securing default routes and source specific gateways
To: Juliusz Chroboczek <jch(a)pps.univ-paris-diderot.fr>
Cc: babel-users <babel-users(a)lists.alioth.debian.org>
On Tue, Apr 7, 2015 at 3:32 AM, Juliusz Chroboczek
<jch(a)pps.univ-paris-diderot.fr> wrote:
>> Also the diagram above would require a security model that manages to
>> keep things safe with untrusted speakers in between (here you would need
>> an advice from somebody experienced with the problem stated this way).
>
> Looks like SBGP to me.
Well, that died, mutated, came back to life, died again, and I dont
know what is going on today but so far as I know it STILL involves a
lot of phone calls and teeth gnashing when china re-routes the
internet. I think resolving the question whilst babel is still at a
relatively small scale would be good, before people start deploying it
on citywide networks.
The context of the question comes from this part of a post to the
working-group-that-shall-not-be-named that apparently flew over
everyone´s head in the other sturm und drang[1]:
"Security has two meanings here, one of which is not useful, one that
may be. The "lets encrypt and authenticate everything" part is not
terribly useful (particularly in a world that still has arp and ra). I see
no reason for e2e encryption here, do see so a small one for authentication,
but am not sure it needs to be e2e.
A part that *usefully* allowed a network to allow a mixture of authenticated
nodes (injecting default routes), while retaining un-authenticated routing
for other nodes would be nice. I only briefly deployed the HMAC auth,
but as the quagga version fell too far behind the mainline, did not gain
enough operational experience with it to have a feel for it. I look forward
to seeing it in babeld-1.7.
... somewhat related ...
I have a smallish bcp38-ish like document for some best current practices
(like filtering out local announcements of non-rfc1918 addresses,
filtering out route announcements for the hip 1.0.0.0/24, 2001:10::/28,
and advice to not announce local-only vpn routes) which I could maybe
finish by Prague. (On the other hand I think it is easier read if on a
wiki.)
... But it is the prospect of someone with a laptop announcing the lowest
metric possible default route is through them and out via 3G that is
the biggest hole in the "security" of not just babel, but all
non-authenticated
routing protocols (targeted at the home. at least. So far as I know there
are a lot of insecured routing protocol *deployments* in general. Someone
feel free to correct me)."
Now, I like that a malicious (or misconfigured) droid can only damage
the nearest couple hops in the case of sending a default route but I
imagine everyone here has misconfigured a router to announce a default
route, only to suck a goodly portion of their network through a
non-working [2] device.
Having some means to indicate that a default route (in particular) is
honestly such, would lead to a network where a mixture of secured and
insecured devices could exist (think guifi), where individual exit
node owners could publish their willingness to share their source
specific gateway with other exit node operators, and so on.
> -- Juliusz
>
> _______________________________________________
> Babel-users mailing list
> Babel-users(a)lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
[1] Incidentally I did not know the true meaning of the origin of this
phrase before looking it up just now, I had just thought it meant
"conflict". It does seem appropo in context of the
working-group-that-shall-not-be-named.
[2] Probably my biggest failover problem is that links to cable modems
stay up, even when the cable modem is down. I need to beat on
babel-pinger harder.
--
Dave Täht
We CAN make better hardware, ourselves, beat bufferbloat, and take
back control of the edge of the internet! If we work together, on
making it:
https://www.kickstarter.com/projects/onetswitch/onetswitch-open-source-hard…
_______________________________________________
Babel-users mailing list
Babel-users(a)lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
https://github.com/jeffvogelsang/openwrt-vagrant
Uses vagrant w/ virtualbox to create an isolated build environment. We'd
have a lot fewer folks asking us "hey why won't the firmware build on my
[insert corner case distro here] laptop?"
Hey just wanted to mention that I was having an issue flashing the MyNets
with the web UI. I would select a firmware and then select "upload" and
instead of redirecting to the next page where it shows a countdown until
the device is supposed to be ready, the page just sat and attempted to
reload with no effect.
I don't really know why the hell it might be doing this, but it does seem
that using a private browsing window works. Maybe some weird session
thing.....
Anyways - now that I've got the firmware on this device I'm probably not
going to want to flash it again a bunch of times just to test if this
works, but if anyone else wants to check in and let us know if that seems
to work that'd be great.
Thanks!
Max
This seems like an interesting but potentially solvable inefficiency:
https://github.com/sudomesh/makenode/issues/9
Does someone have interest in looking into babel to identify what would be
needed to ensure that the same radio is not used for both inbound and
outbound when relaying (in situations where this is viable) ?
Since most nodes in the network will be dual-radio or better, then this
feature might really make a big difference in the long run, since the delay
incurred for each hop can be greatly reduced when you can receive and
transmit at the same time.
marc/juul
Hey Jenny,
I really wish you wouldn't have publicly walked back April's statement like
this. A number of people have different ideas for the next directions for
this project, and I think one of the things we've realized lately is that
when they don't align, we rely on eachother's good judgement and
communication in order to not shout eachother down. In fact, I don't really
agree with your statement:
Namely, we're not intending to create a free-as-in-beer, fast, high-speed
> network, but rather the focus is on cultivating a community of participants
> sharing their existing bandwidth with a public, open network and developing
> local applications and services- all built by and for the people with
> resiliency in mind.
I, for one, do intend in part to create a fast high-speed network which
would allow folks to join with a sliding scale membership. I don't really
think that anything in the grant proposal that April wrote up fundamentally
contradicts our values or motives, so I'd prefer that if you have your own
constructive additions you voice them without attempting to cancel out
anyone else's.
Thanks
On Fri, Mar 13, 2015 at 12:30 PM, Jenny Ryan <tunabananas(a)gmail.com> wrote:
> Hi Laura!
>
> Please use Marc's reply for the update - the grant application isn't a
> totally accurate portrayal of our goals, current progress and next steps.
> Namely, we're not intending to create a free-as-in-beer, fast, high-speed
> network, but rather the focus is on cultivating a community of participants
> sharing their existing bandwidth with a public, open network and developing
> local applications and services- all built by and for the people with
> resiliency in mind.
>
> Thanks for putting this together!
>
> On 03/13/2015 11:23 AM, Laura Turiano wrote:
> > Thanks Marc and April. This is so exciting and you are really being
> > thoughtful about the build out and testing.
> > Laura
> >
> > On 3/13/15 7:07 AM, April Glaser wrote:
> > > Hi Laura,
> > >
> > > To clarify, the $40 node isn't $40 a month for an Internet connection.
> > > It's the price of the antenna set up to connect to the network.
> > >
> > > So we're still working out the details on how we will distribute
> > > access to the network. Some parts of Oakland still report that less
> > > than 50% of residents have access to a reliable Internet connection.
> > > In those areas we might experiment with other methods of distribution.
> > > To that end, we're doing outreach to local organizations and the like
> > > to discuss how to best expand the network.
> > >
> > > Here's a description of our work that we used recently to apply for a
> > > grant, in case this also helps.
> > >
> > > *What's your project? What's below is about 30 words over. Can someone
> > > tighten it up?*
> > > We are a homegrown, community-owned network in Oakland, California
> > > working toprovide free Internet access at faster speeds than
> > > traditional providers.
> > > The People's OpenNetworkis dedicated to the idea that our community
> > > must have a central role in theoperation of ourcommunications
> > > networks. That is why we are building our own free network that
> > > provides high-speed, open access to the global Internet, while hosting
> > > local applications and services crafted by and for users in the East
> Bay.
> > > We are committed to universal, equitable, and unfettered access, free
> > > of unwanted surveillance and censorship. People's Openuses Sudo Mesh
> > > firmware, a free software project developed by
> > > volunteersenablingrobust, non-hierarchical mesh networks. The firmware
> > > provides a simple way for users to share a configurable portion of
> > > their Internet connection with the network – made relatively safe
> > > because the traffic from the shared connection is notassociated with
> > > the donor's IP address. Sudo Mesh is distinct from other opensource
> > > firmwaresbecause we prioritize both sharing andprivacy.
> > > Every aspect of People's Open is participatory, and every week we host
> > > three open meetings, including firmware development and community
> > > organizing. We're collaborating with local organizations and our
> > > diverse neighbors to co-create the network.
> > > *What assumptions will you test? *
> > > We hope to establish that a small-scale community-run network can
> > > provideservices currently assumed to be the province of large,
> > > top-down Internet providers. Specifically, we are exploring how local
> > > media and applications can be developed on such a network tobenefit
> > > local users. Examples of services include a local bulletin board,
> > > grassroots journalism outlets, local Voice-over-IP, archives,
> > > community asset maps, and Internet radio, all hosted on our local
> > > network.
> > > Instead of paid-subscribers, our goal is to have active participants.
> > > To that end, we currently offer training and hold open hack-nights at
> > > Oakland community hackerspaceSudoroom. Topics range from cryptography
> > > and network administration to antenna design and firmware hacking. We
> > > are actively designing our network through conversations with
> > > community partners, like Media Alliance, AspirationTech,
> > > ICSI/UCBerkeley, and others as part of our long-term outreach strategy.
> > > Access to the Internet is a human right, and we oppose practices that
> > > corner users into paying exorbitant rates to get online. Our network
> > > offers a free connection to anyone within range or willing to host a
> > > node. We challenge the idea that users need to trade personal data to
> > > engage with their community online, and People's Open encourages our
> > > neighbors to support other free software projects.
> > > *Who is the audience/user of this project? How will they be impacted? *
> > > The current model of Internet distribution in the East Bay isn't
> > > working for everyone. Many neighborhoods continue to report that over
> > > fifty-percent of residents lack a reliable home Internet connection.
> > > People's Open is partnering with community anchors, like churches,
> > > neighborhood gardens, schools, small businesses, and libraries, to
> > > mount antennas in underserved neighborhoods.
> > > This is a community network, and we're working with our neighbors to
> > > build and maintain it collectivity. We meet with local leaders and
> > > invite our neighbors to participate, fostering collective expertise
> > > and helping to ensure sustainability of the network.
> > > We are building a captive portal that directs users tolocal
> > > applications, such asa community calendar, grassroots media, maps, and
> > > bulletin boards. Working directly with activist groups to co-design
> > > trustworthy platforms, we're exploring ways to host local social media
> > > and digital classrooms. We are also in conversation with branch
> > > libraries and social service organizations about hosting information
> > > directories on the network. People’s Open is a grassroots media
> > > project, and we want to help meet the information needs of our
> > > communities.
> > > In sum, we provide a faster connection to the global Internet than a
> > > traditional residential ISP, while strengthening our community’s
> > > relationship with technologies that we depend on everyday.
> > >
> > > *What have you made so far? *
> > > For the past year and a half, most of our work has gone into
> > > developing and testing our firmware, which is a heavily modified
> > > version of OpenWRT. Our sources are on GitHub
> > > (https://github.com/sudomesh/) <https://github.com/sudomesh/%29>and
> > > are available for other communities wishing to create a similar
> > > network. We are finally at a point where we can begin to offer a
> > > reliable networking service.
> > > We have also deployed two testbed networks, one in Omni Commons, a
> > > giant community center which houses Sudoroom, and one in West Oakland,
> > > consisting of routers running our firmware.
> > > People's Open also has a long-term outreach and communications
> > > strategy, with the goal that the network will bloom and remain
> > > responsive to our communities. Our outreach strategy focuses on three
> > > tiers: large organizational partners, community anchors like churches
> > > and small businesses, and neighborhood mapping. In working with
> > > existing and trusted community groups, we hope to invite their
> > > networks to join and participate.
> > > Finally, we have a dedicated team in the project for the long-haul. We
> > > have three open hack-nights a week at Sudoroom, a well-known community
> > > center, where anyone is welcome to get involved at every level of the
> > > project. We frequently welcome new participants and keep our website
> > > up-to-date.
> > >
> > >
> > >
> > >
> > > On 3/13/15 3:04 AM, Marc Juul wrote:
> > >> On Thu, Mar 12, 2015 at 3:13 PM, Laura Turiano<scylla(a)riseup.net>
> > >> wrote:
> > >>
> > >>> Hello meshers,
> > >>>
> > >>> I'm writing an update for Oaklandish about the Omni and would like to
> > >>> include info about progress on the mesh network. Can someone tell me
> > >>> how
> > >>> many nodes have been installed, any other accomplishments, what are
> the
> > >>> next steps, etc.?
> > >>>
> > >> Hi. Here are my thoughts. Other mesh folk, please correct or expand
> > >> as you
> > >> please.
> > >>
> > >> Next week we're activating a test network at the Omni to test our
> indoor
> > >> nodes in an apartment-complex-like setting, as well as a small six
> node
> > >> high-speed roof-to-roof network in west Oakland. We have been working
> > >> on a
> > >> new, friendlier, web admin interface as well as features that will
> allow
> > >> people to start out with an entry-level ~$40 node and upgrade their
> > >> coverage later by adding rooftop or street-facing nodes without any
> > >> extra
> > >> configuration.
> > >>
> > >> Over the next month or so we'll be stress-testing our two networks and
> > >> completing these new features. The next phase will be a beta release
> > >> where
> > >> we invite the adventurous to adopt nodes. I would like to see a beta
> > >> test
> > >> network with maybe 50-100 node locations. The beta test will be less
> > >> about
> > >> testing the technology (though there will be some of that) and more
> > >> about
> > >> understanding the problems and opportunities that arise when a diverse
> > >> group of people with diverse skill-sets have to run their own
> > >> network. If
> > >> the network is to succeed as it grows, then it cannot rely only on the
> > >> small group of volunteers that make up sudo mesh. We're going to have
> to
> > >> figure out how to communicate to node operators that this is not a
> > >> traditional ISP with a support line. Instead it is rather like a
> > >> community
> > >> garden where everyone helps out to make it succeed and we want so
> figure
> > >> out how to best facilitate that cooperation. During this phase we'll
> > >> also
> > >> be finalizing our automation tools for receiving orders for new nodes,
> > >> automatically configuring those nodes and shipping them out. Once
> we're
> > >> comfortable that everything is ready for a rapidly expanding network
> the
> > >> next phase might take the form of a large crowdfunding campaign where
> > >> people can get nodes as perks.
> > >>
> > >
> >
> >
>
>
> --
>
> Jenny
> http://jennyryan.net
> http://sudomesh.org
> http://thevirtualcampfire.org
> http://technomadic.tumblr.com
>
> `~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`
> "Technology is the campfire around which we tell our stories."
> -Laurie Anderson
>
> "Storytelling reveals meaning without committing the error of defining it."
> -Hannah Arendt
>
> "To define is to kill. To suggest is to create."
> -Stéphane Mallarmé
> ~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`
>
It seems that there is now preliminary support for nanobeam devices in
OpenWRT:
https://dev.openwrt.org/ticket/16796
So that's nice, but the second to last comment says that speeds are much
lower than for stock firmware. It could be that this person just didn't
configure his node correctly or it could be that this is the case for all
ubiquiti devices.
Lately we've been talking about the possibility of using non-openwrt
routers for point to point bridged links. We've heard from a few people
that performance of ubiquiti M5 gear for point to point links is basically
the same in OpenWRT and stock firmware.
I think we should test that ourselves. I'm ordering some nanobridges and
nanostations right now and we should do a few tests with point to point and
point to multipoint using openwrt and stock firmware.
It'd be nice to have benchmarks on our wiki. I can't find any existing
benchmarks online?
--
marc/juul
