On Sun, Oct 28, 2018 at 1:48 PM Juliusz Chroboczek <j...@irif.fr> wrote: > > > One of my issues with crypto, rather than auth, is I'd wanted a way to > > have a partially untrusted network to bootstrap off of and/or to allow at > > least some unauthed or uncrypted nodes to participate with filters or > > inflated > > metrics. > > The important thing to understand is that both security mechanisms that > we're currently developing protect Babel messages. We're not attempting > to secure Babel updates end-to-end. > > Both security models use auth per-interface. Either you allow anyone to > associate on a given interface, or you require crypto on that interface.
Basically, you have to do setup in your lab, and not in the forest. I get by on just installing a static default route in the forest 'cept on p2p links. > > So in order to build a partially untrusted network: > > - set up security for your backbone links, either at the application > layer (DTLS or HMAC), or at the link layer (WPA2, 802.1X) or at the > physical layer (a guy or gal with an AK47 (Chinese clones will do) in > front of every Ethernet socket); It is my hope that all this stream of consciousness traffic during a deployment will lend itself one day to a better, more coherent bcp for folk to leverage. While AK47s are readily available on the aftermarket at low cost, the glock 43 is far more transportable, and when used in the hands of an experienced operator, in single shot mode, causes less damage to other valuable pieces of equipment. Toxins spread liberally around the outlet work 24x7 until they evaporate and don't require payroll or a health benefit plan. > - set up strict filtering rules for your guest interfaces; Do you have recommendations? > - set up ingress firewall rules for your guest interfaces; I currently run with firewalls only at the edges. I found deploying the bcp38 package internally on every router to ultimately cause breakage when something changed, and the sanest thing to do in ipv6-land is limit what protocols you run in the first place (it's almost entirely "just ssh" now, and I may kill snmp off too). I probably will push the basic ipset or route based bogon filter out to the APs this time around (no 10, 169, 192) firewalling dynamic ipv6 is nearly an impossible task. I already talked about filtering out public ipv4 in this message. This is all a good topic for a bcp. > - allow anyone to associate on the guest interfaces. Although babel will be available on several bridged devices I do plan to secure it via hmac in the long run. Until then, security through obscurity. Very few people walk onto the campus with attack tools in hand, and there's so many other basic attacks (arp spoofing, ra spoofing, etc, etc) that it is kind of pointless. The basic goal, though, is when exposing a private network at all to a larger interconnected mesh outside the campus, is to keep those vulnerabilities at a minimum. Physical security is hard, even with a glock. > To restate -- there is no way in Babel currently to have end-to-end > signatures on route announcements. Doing that properly is difficult, > and as far as I'm aware nobody is working on it. yep. The core thing that I somehow wanted was to make available a source specific addr/60 to share with other folk, while forcing other attempts at my address space out through the regular internet. I believe that is possible (with or without hmac) at this point.... > > -- Juliusz -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 _______________________________________________ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users