Re: [Babel-users] RTT metric in BIRD!
Juliusz Chroboczek writes: > It looks like the RTT metric was released as part of BIRD 2.14. > Congratulations, Toke! Thanks :) Note that the version that was merged lacks the route selection hysteresis that babeld does (but it does have the RTT metric smoothing). -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Babel: Possible segfault in bird unfeasible update handling code
Juliusz Chroboczek writes: >> The problematic bit is, I think, 's' in babel_handle_update can be NULL >> because nothing ensures the babel_source for a particular neighbour >> actually exists here: > > s will be passed to babel_is_feasible, which returns true if s is null. > Later on, s is only used if feasible is false, in which case it cannot be > null. > > See RFC 8966 Section 3.5.1: > > a route advertisement carrying the quintuple (prefix, plen, router-id, > seqno, metric) is feasible if one of the following conditions holds: > > • ... > • no entry exists in the source table indexed by (prefix, plen, > router-id); > • ... > > I agree that the code is a little too subtle for comfort. Pish posh, there's a totally-obvious comment saying /* for feasibility */ next to where 's' is assigned :P >> Perhaps find should just be replaced by babel_get_source here? > > babel_get_source sets the seqno to an arbitrary value (0), so it should > only be used if it is immediately followed by an assignment to s->seqno. > A better API would be to pass the seqno to babel_get_source. Hmm, yeah, possibly from a readability PoV, but, well, there's only the single caller, so it becomes a bit redundant since we have to do the check anyway afterwards. And I don't think switching babel_handle_update() to use babel_get_source() is a good idea either; we'd end up creating new source objects and leave them to be garbage collected just to improve readability a bit; just add a comment explaining why the deref is safe? :) > (I haven't looked at it in detail, but the code in babel_send_update_ looks > incorrect to me, by the way: it's comparing seqnos as integers, where it > should be doing comparisons modulo 2¹⁶, as defined in Section 3.2.1. > Toke?) You're right about this, though; same in babel_is_feasible(). Nice catch! Will send a patch... -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] V4-via-v6, which Linux kernel patches for OpenWrt 22.03?
Juliusz Chroboczek writes: > Hi Linus! > >> Regarding [0] does anyone have an overview of which Linux kernel >> patches might need backporting when trying this v4-via-v6 feature >> of Babel on OpenWrt 22.03's Linux 5.10 kernel? > > Toke will correct me if I'm wrong, but as far as I'm aware, it's just this: > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=321827477360 Ah yes, I was trying to remember which patch we were talking about, but of course it's that one. Note that if you set an IPv4 address on the loopback interface, that patch is not needed either; it's only fixes the last-resort address selection where no address is set on the system at all... -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] [babel] Babel MAC auth fails due to packet reordering
Daniel Gröber writes: > Hi Toke, > > after running with your patch for a short while I'm actually starting to > see frequent crashes. Here's a backtrace for one: Ah, oops; looks like I got my operator precedence wrong, so the code is doing pointer arithmetic instead of adding to the value being pointed to... Pushed a fixed version here: https://github.com/tohojo/bird/tree/babel-ooo-pc Could you try if that works better, please? :) -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] First draft on relaxing Babel HMAC
Juliusz Chroboczek writes: >> I have a conference this week, > > That's not an excuse -- I've seen you write the BIRD implementation of > Babel during a conference, in just five days. That was code! Now you're expecting me to write coherent prose - much harder! ;) -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Babel MAC auth fails due to packet reordering
Juliusz Chroboczek writes: > CC-ing babel@ietf. List, Daniel has reported that multicast packets are > delayed in his network by up to 200ms, which breaks Babel-MAC's PC check. > Toke has determined that the issue is with WiFi powersave, which is > unfortunately not something we can control. Toke has proposed a patch > against his implementation of Babel that implements window-based PC > validation, in the style of RFC 4303 Section 3.4.3. > >> I took a shot at implementing window-based PC verification in Bird, >> patch below (compile-tested only); > > That should work, although I fear that a window size of 64 is not enough, > especially since RFC 8967 Section 4.2 allows increasing the PC by more > than one. So we'd either need to remove that latitude from the spec, or > require the use of a more complicated data structure. My PoC uses a window size of 32, actually, but could be trivially extended to 64 (just by switching from a u32 to a u64 for storing the bitmap), and a bit less trivially to a larger window by using a bitmap spanning several u64s (or some other data structure). > But I've been thinking the issue is that we require a single strictly > monotonic sequence of PCs that mixes up unicast and multicast packet. > What about relaxing the requirement so that the sequence of unicast > packets is monotonic, the sequence of multicast packets is monotonic, but > the two sequences can grow independently? This will still prevent replay: > a unicast packet won't be possibly replayed as unicast, due to the > monotonicity condition, and it cannot be replayed as multicast, since the > MAC covers the pseudo-header > > More precisely, I propose that we maintain two distinct "last PC" fields > in the neighbour table, called PCu and PCm. These behave as follows: > > - when we receive a challenge reply, we set both PCu and PCm to the > value received in the challenge reply; > - when we receive a normal packet, we compare its PC against *either* > PCu or PCm, depending on whether it's unicast or multicast; > - if the packet is accepted, we update *either* PCu or PCm, leaving the > other value unchanged. > > (We could generalise that to having one PC value per destination address, > but I'm not sure it's useful.) Hmm, I certainly see where you're coming from; having separate sequence numbers for unicast/multicast would neatly sidestep this particular problem. However, one problem with this is that it's not straight-forwardly backward compatible. I.e., if a sender starts using separate sequence number spaces for unicast and multicast, they would become incompatible with receivers implementing RFC8967 as it is written today, even on networks that exhibit no reordering. Whereas simply having a reorder window is more of a "be lenient in what you accept" thing on top of the existing spec (i.e., a babel speaker implementing a replay window can interoperate fine with one that doesn't, except for reordering). Also, packets could get reordered for other reasons, not necessarily related to whether they are unicast or multicast; a window-based approach would deal with that as well. As for the size of the window (setting aside the case where an implementation increases the PC by more than one for every packet), I guess we'd need it to be large enough to contain a full routing table dump. A window of 64 packets can fit several thousand routes even in the worst case with no compression; so I'm wondering if this isn't enough for most deployments? -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] babeld slashes kernel route manipulation performance by 17000%
Juliusz Chroboczek writes: >> Probably because babeld subscribes to netlink notifications for all new >> routes, and only filters them on the table name fairly late, >> specifically here: >> >> https://github.com/jech/babeld/blob/master/kernel_netlink.c#L1175 > > Do you see how it can be done better? Hmm, no, not really :( Looked at the Bird code, and it seems like it's doing both the subscribe and parsing quite similar to the way babeld is. So it's actually a bit puzzling why it's hurting performance that much. the only obvious difference that I can see from my admittedly cursory glance is that babeld makes heavy use of indirect calls; but we're not talking millions of operations per second here, so it really shouldn't be taking such a heavy toll... -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Toke's patch in kernel 5.13 !
Juliusz Chroboczek writes: >> Nice, but why is 5.10 missing? > > I have no idea, perhaps I missed it. I just did a web search for the > title of the patch, and reported what I found. It's in 5.10.46: https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.46 (just search that page for the patch title: "icmp: don't send out ICMP messages with a source address of 0.0.0.0") -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
[Babel-users] Babel MAC support merged into Bird master
Hey everyone Following hot on the heels of the merge of MAC support into babeld[0], support has now also landed in Bird[1]. Juliusz re-confirmed interoperability before merging the babeld code, and I have also re-checked just now, with the code merged into Bird. -Toke [0] https://alioth-lists.debian.net/pipermail/babel-users/2021-May/003820.html [1] http://trubka.network.cz/pipermail/bird-users/2021-June/015529.html ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Merging v4-via-v6: need advice
Juliusz Chroboczek writes: > Hi, > > I'm in the process of merging v4-via-v6 into mainline babeld, and I need > some advice about the default configuration. > > V4-via-v6, is described here: > > https://datatracker.ietf.org/doc/html/draft-ietf-babel-v4viav6 > > It's a technique that allows an IPv6-only router to forward IPv4 packets, > which makes it easier to administer a double-stack network, since only > IPv6 addresses need to be allocated inside the network. However, > a v4-via-v6 router needs to be able to originate ICMPv4 packets, and these > packets need to have a source address. > > I haven't done extensive testing yet, but my preliminary investigations > indicate that the Linux kernel behaves as follows: > > - if the router has an IPv4 address on at least one interface, the > address is borrowed as the source of the ICMPv4 packet; > - if the router has no IPv4 address at all, no ICMPv4 packet is sent, > which may cause blackholes. > > The issue is describes in Section 3 of the draft, which suggests using the > IPv4 dummy address 192.0.0.8 when no IPv4 address is available. Using the > dummy address will require some minor surgery to the Linux kernel, and > I haven't implemented it yet. So while we wait for somebody (me or > someone else) to implement support for the dummy address, what should > babeld's default behaviour be? > > 1. Disable v4-via-v6 by default, and assume that an administrator who >enables it knows what they're doing? > 2. Check for IPv4 addresses, and enable v4-via-v6 automatically if there >is at least one IPv4 address? > 3. 3=1+2, behave like (2), but allow overriding the daemon's decision? > > Any better ideas? Not really - 3 would be my preference of the above, I think. Do the right thing by default, but don't second-guess the user if they explicitly ask for a particular behaviour... :) -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] v4-via-v6 and the IPv4 Dummy Address
Juliusz Chroboczek writes: > Hi, > > After I release v4-via-v6, I'll start working on merging HMAC and > v4-via-v6 into babeld. A v4-via-v6 router needs to be able to send ICMPv4 > packets even if it hasn't been allocated an IPv4 address; the simplest way > to achieve that is to use the "IPv4 dummy address". > > https://tools.ietf.org/html/draft-ietf-babel-v4viav6-03#section-3 > > Question: how do we achieve this? The best solution would be to modify > the Linux kernel to use the dummy address for sending ICMPv4 when it has > no IPv4 addresses available. The second best would be to automatically > add the IPv4 dummy address to the loopback interface when Babeld > starts. What does the kernel do currently? And will setting an address on the loopback interface help at all? The documentation for the icmp_errors_use_inbound_ifaddr sysctl[0] says this: Note that if no primary address exists for the interface selected, then the primary address of the first non-loopback interface that has one will be used regardless of this setting. -Toke [0] In https://www.kernel.org/doc/html/latest/networking/ip-sysctl.html ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] status of babel-hmac
Dave Taht writes: > as I am trying to ramp up on openwrt testing in the next month or so, > I am curious if enough of babel-hmac is ready to be merged yet? Current Bird implementations is here: https://github.com/tohojo/bird/tree/babel-mac-04 Submitted upstream here (awaiting review): http://trubka.network.cz/pipermail/bird-users/2021-January/015121.html Babeld branch here: https://github.com/jech/babeld/pull/52 > As best as I recall key rotation was the barrier for inclusion, but I > don't care much about that... What's the issue with key rotation? Isn't that mostly an operational consideration? -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] HMAC: should keys expire?
Juliusz Chroboczek writes: > The thing to undestand about HMAC is that while it can be used directly, > it's really designed to be used with a keying protocol. This could take > one of many forms: > > - a central server periodically (say, every 30 minutes) draws a new >random key, then contacts all nodes over ssh and installs the new key. >a few minutes later, the old keys are removed. > > - every node performs authentified Diffie-Hellman with each of its >neighbours; it installs all the keys negotiated on the relevant >interfaces (this assumes that the number of neighbours on each >interface is small enough); > > - the nodes periodically perform some form of distributed consensus and >agree on a small set of keys. > > In all cases, the old keys must expire after the new keys are installed. > There are two ways to achieve that: > > 1. the keying daemon removes the old keys; > 2. keys are installed with an explicit lifetime, and the routing daemon > itself discards the keys when they expire. > > Approach 2 feels more robust to me, since it ensures keys will expire even > if the keying daemon crashes or is stopped for some reason. Do we need to > equip keys with an explicit lifetime? FWIW the Bird configuration format already supports supplying both a start and end time for key validity: https://bird.network.cz/?get_doc=20=bird-3.html#ss3.3 (see suboptions for "password"). I guess it's not quite the same as key expiry (as the keys will technically still be around in the configuration file), but it does make it possible to have the daemon enforce a time after which they will no longer be accepted. -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] MAC auth. for Babel in babeld
Juliusz Chroboczek writes: >> You could simply reject 'mac true' if no key is configured (i.e., reject >> interface bring-up or reconfig, as appropriate depending on context). > > Suppose you were running Babel together with a keying daemon. Say, one > that periodically performs an authenticated supersingular isogeny > Diffie-Helman exchange and then feeds the resulting key to the Babel > daemon. > > You could of course delay starting the Babel daemon until you got yourself > a non-empty set of keys, but wouldn't it be more robust to start Babel in > authenticated mode with no keys (which would cause it to drop packets) and > then incrementally feed it keys as they are learned? Hmm, not sure I have any opinion about which would be more robust off the top of my head. But I can see your point that someone might implement it that way; and I suppose I could be convinced that such a configuration could be allowed, as long as it fails safe, of course. I think that at least emitting a clear warning on startup would help users avoid the most common configuration errors, though... -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] MAC auth. for Babel in babeld
Juliusz Chroboczek writes: >>> It is standard. If the key length is smaller than the output (block) >>> size, then the key is padded with zeroes. If the key length is bigger, >>> then it is pre-hashed. See https://tools.ietf.org/html/rfc2104#section-2 > >> Ah, good to know! > > It's also not a very good idea. > > MAC exposes large numbers of packets and their signatures to an attacker. > It is therefore vulnerable to dictionary attacks. HMAC keys should either > be drawn randomly using a cryptographic RNG, or generated using a hashing > procedure that is resistant to dictionary attacks. This is expanded upon > in the Security Considerations section of the draft. Yeah, that discussion is why I added the restriction in Bird. > I am of a divided mind on whether babeld should implement the RFC 2104 > procedure, as proposed by Antonin. On the one hand, the procedure in > RFC 2104 Section 2 is extremely naive from a modern point of view, and > implementing it might induce people into deploying MAC in an insecure > manner. On the other hand, it is convenient, and inconvenient security > protocols are less likely to be deployed in production (*cough*PGP*cough). In any case, Blake2 does not have any such mechanism, so keys would have to be a certain size there (or we'd end up inventing something new, which is probably not a good idea). So I think restricting the key size is fine; and, well, if users want to make that key be all zeroes (or something equally insecure) we can't really stop that anyway... > On the gripping hand, MAC only secures Babel traffic -- it does nothing to > protect neighbour discovery, let alone data traffic. One might therefore > argue that Babel-MAC and Babel-DTLS are both pointless, and that Babel > should be deployed over secure links. There is some merit to this position, > and we should consider doing some work on integrating babeld with Wireguard. > Please see the discussion on > > https://github.com/jech/babeld/issues/58 Ah cool, I've been wanting to add wg support to Bird as well; maybe we should write a spec for how that is supposed to work with the Babel protocol (I don't agree with the reporter of that bug that this will need changes to wireguard, if we allow plaintext discovery outside of the tunnel, babel can just to unicast peers on the inside). -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] MAC auth. for Babel in babeld
Antonin Décimo writes:
>> Well, I did test an earlier version of your code against an earlier
>> version of me, so not quite first try ;)
>
> Second first try, then.
Haha, yeah :)
>> >> - You don't enforce a minimum key length.
>> >
>> > This was on purpose, but maybe it was a bad idea.
>> >
>> >> For blake2s this means the key will effectively be zero-padded up to
>> >> the block size of 32 bytes (not sure what hmac-sha256 does).
>> >
>> > hmac-sha256 is the same. Under the block size, the key is padded with
>> > zeroes, above, the key is pre-hashed.
>>
>> Yeah, that's what the Bird implementation is doing too. I'm also
>> limiting the *max* length of keys to avoid the pre-hashing as I figured
>> that would be an interoperability issue. But if it's standard practice
>> maybe that is not necessary?
>
> It is standard. If the key length is smaller than the output (block)
> size, then the key is padded with zeroes. If the key length is bigger,
> then it is pre-hashed. See https://tools.ietf.org/html/rfc2104#section-2
Ah, good to know!
> Right know, babeld requires keys to be of the exact output size of the
> hash.
I ended up with something similar, except for HMAC keys it allows
OUTPUT_SIZE <= key size <= BLOCK_SIZE:
https://github.com/tohojo/bird/blob/babel-mac-02/proto/babel/config.Y#L112
>> The obvious thing would be to assign keys to a "default" keyset if no
>> explicit keyset is configured, and assign that default keyset to all
>> interfaces that don't specify one?
>
> I want to use the 'default' pseudo interface so that each keyset that
> is added to the default interface is automatically added to each
> interface.
Yes, that does make things simpler, but still requires explicit
assignment of a key, even if it's just to the default interface. Maybe
you could add a keyword to the key definition itself ('default'?) that
does this without a separate keyset line?
>> I think that would be safer anyway, as right now it's quite easy to
>> think you've configured authentication, but it's not actually enabled
>> because there was not key assigned. So I think the interface config
>> should be bailing out if 'mac true' is set but no key is available...
>
> It’s not clear when this check should be, because keys could be added
> from another channel, for instance a local socket but not the
> babeld.conf file.
> I can add warnings when signing and verifying packets if there are no
> key available.
Yeah, dynamic config does make things a bit more complicated, but I
still think it's possible to add a check that will prevent most errors.
I don't think warning on processing is enough, it has to be on config
time (or an operator can still restart the daemon, not get an error, and
forget to check the logs).
You could simply reject 'mac true' if no key is configured (i.e., reject
interface bring-up or reconfig, as appropriate depending on context).
This imposes constraints on the ordering of config stanzas, but I think
that is better than allowing an interface to accidentally run without
mac enforcement because there is no key.
If you want to relax the ordering in the config file, you could defer
the check until you've read the whole thing, which would mean the
ordering constraint only exists on dynamic reconfig; but not sure that's
even necessary, forcing people to put the key definition first is not
that onerous...
-Toke
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] MAC auth. for Babel in babeld
Antonin Décimo writes: > Hello Toke, > >> I've done basic interoperability testing with the latest version of my >> MAC implementation for Babel in Bird. They can successfully exchange >> messages with both hmac-sha256 and blake2s hash algorithms configured. > > Yay! Thank you very much! I’m glad it worked (on the first try) :-) Well, I did test an earlier version of your code against an earlier version of me, so not quite first try ;) >> - You don't enforce a minimum key length. > > This was on purpose, but maybe it was a bad idea. > >> For blake2s this means the key will effectively be zero-padded up to >> the block size of 32 bytes (not sure what hmac-sha256 does). > > hmac-sha256 is the same. Under the block size, the key is padded with > zeroes, above, the key is pre-hashed. Yeah, that's what the Bird implementation is doing too. I'm also limiting the *max* length of keys to avoid the pre-hashing as I figured that would be an interoperability issue. But if it's standard practice maybe that is not necessary? >> For Bird I'm enforcing that the key size must match the hash output >> size (32 bytes for both blake2s and hmac-sha256). This is based on >> the security considerations section in the draft; should babeld do >> the same? > > Now babeld requires keys of 32 bytes for both algorithms. Great! >> - I think the configuration is a bit verbose. This was the minimal >> config I needed to enable MAC in babeld: >> >> key name test algorithm hmac-sha256 value >> 7465737474657374746573747465737474657374746573747465737474657374 use >> both >> keyset test >> keyset-add-key test test >> interface veth0 mac true add-keyset test >> >> The two middle lines feel like they are a bit redundant; could we go >> without them for simple configs? > > You’re right; at least the line `keyset test` can go, keysets are now > implicitly created. I don’t see how I can further simplify without > losing the idea that interfaces may share keysets and keysets may > share keys. The obvious thing would be to assign keys to a "default" keyset if no explicit keyset is configured, and assign that default keyset to all interfaces that don't specify one? I think that would be safer anyway, as right now it's quite easy to think you've configured authentication, but it's not actually enabled because there was not key assigned. So I think the interface config should be bailing out if 'mac true' is set but no key is available... > One thing that is still buggy in my implementation is to use the > "default" pseudo-interface with keysets and keys, this may simplify > the configuration for common usecases. Yeah, for more complex configurations that will help, of course. I did not test the config interface extensively, just did the minimum to get things working ;) -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Error when running babeld
"Callahan, David (US)" writes: > Antonin, > > I disabled ipv6 on all interfaces, ifconfig shows no ipv6 on eth0. > And yet, when I run babeld on it, I get the SAME ipv6 error. Babeld requires IPv6 to be enabled, even when only routing IPv4... -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Error when running babeld
Antonin Décimo writes: > Hi, > >> I don't want IPV6 on the system. > > It’s 2020… > > I’m sorry, I’m not sure how to configure babeld to use IPv4 as its > transport layer. > > Juliusz, is that even implemented? > > I think the multicast address need be set to IPv4 too (224.0.0.111) > but that is not implemented in babeld, so you don’t have neighbor > discovery. > > I’m not sure if the Bird implementation https://bird.network.cz/ > supports IPv4 as its transport layer. It does not; I do believe I even argued from removing that bit from the spec at some point ;) -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] MAC rekeying in babeld and information model
Juliusz Chroboczek writes: >>> The second part of my inquiry -- how does the information model enable >>> incremental deployment? Section 5 of draft-ietf-babel-mac. > >> Incremental deployment is enabled through the interfaces object >> babel-mac-verify parameter. Set this parameter to false until all >> routers have key(s). Then set to true. > > Ah, ok. That's fine, then, sorry for missing it. > >> I don't think an additional per-interface parameter is needed. I think >> babel-mac-verify should be fine. > > Agreed. > >> If the group wants to remove the key-use parameters and only support >> symmetrical keying, I have no objection. We could also make those >> parameters optional-to-implement (square brackets), with the expectation >> that an implementation wouldn't implement them if it only supports >> symmetric keying. > > Shall we wait for Toke to express an opinion? As I just replied in the other thread: The Bird implementation is going to have this facility no matter what we specify in the spec, but I'm fine with having it optional, or omitting it from the spec entirely, as long as we don't forbid having a key-use parameter :) -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] MAC rekeying in babeld and information model
Juliusz Chroboczek writes: >> Since that revision has Boolean (true/false) parameters of >> babel-key-use-sign and babel-key-use-verify (but not key-use with values >> of sign/verify/both), I did want to be sure we were talking about the >> right model revision. > > The second part of my inquiry -- how does the information model enable > incremental deployment? Section 5 of draft-ietf-babel-mac. > > Toke, it would be helpful if we could understand what key-use is intended > for. I've asked on the Bird list (cc'ed to babel@ietf). -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] MAC rekeying in babeld and information model
Juliusz Chroboczek writes: > Dear all, > > Antonin and I have spent the afternoon looking at his work on MAC rekeying > in babeld. His code is available in branch hmac-rekeying of > > https://github.com/MisterDA/babeld > > Now... we've got an issue with the information model. > > Following the information model, Antonin adds the following attribute to > keys: > >key-use sign|verify|both > > I'm a little puzzled by the purpose of this attribute. What usage > scenarios is it useful in? In particular, it does not appear to subsume > the sign-only interface attribute, which is useful in incremental > deployment scenarios. Hmm, I think this notion originally comes from Bird's password configuration support? https://bird.network.cz/?get_doc=20=bird-3.html - search for 'password'. I guess you could use it for a kind of asymmetrical verification procedure? I.e., a route server could have its own key that it signs with, that all peers with the route server will accept, but each peer has its own key it signs with, that the route server is set up to accept. That way the peers wouldn't peer with each other, but all go through the route server? This would not prevent malicious actors, of course (they could just start signing with the route server's key), but it could prevent accidental misconfiguration. Dunno exactly what the original intention with the Bird option is, though. I can ask on the Bird list? -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] althea presentation on isp in a box at nanog 76
Justin Kilpatrick writes: >> Hmm... does HMAC alleviate the need for the bottom layer? >> >> https://tools.ietf.org/html/draft-ietf-babel-hmac >> >> (It's implemented, but not merged yet -- I've got two students working on >> making it mergeable.) > > HMAC would resolve the need for the bottom layer. There are advantages to > being able to share keys between the layers though. Not sure I would want to > give up on Wireguard especially since we're so dependent on it for > performance. All this encryption on little passively cooled processors is a > real challenge. > >> It's also only designed to work with link-local addresses, I'm not sure >> how much work it would be to get it work over global addresses. > > Link local is fine. The big kicker for Wireguard is uniqueness. There have been some discussion of adding multicast support in Wireguard. Never went anywhere (yet), though; but I don't think Jason has ruled it out... -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] [babel] Reworked implementation of HMAC authentication
Juliusz Chroboczek writes: >> The info model has the flags that say whether or not a key is used for >> signing (or validating). A key can be "disabled" by setting the flags to >> "false" to indicate it's not used for anything. And keys can be >> added/deleted. > > There's a number of indirections in the information model, and I'm not > sure whether I should be mirrorring that in the config file format: > > interface -> security-obj -> credential-obj -> cred > > The model used by babeld's config file is way simpler: > > interface -> key > > There are two questions that I need to think about (and any contributions > from y'all will be considered carefully before they are discarded): > > 1. How much flexibility am I giving up by having just one level of > indirection instead of three ? FWIW, Bird will also use the simpler mechanism (a key is part of the iface config). But the Bird reload semantics is only "re-read the entire config", so doesn't have the same dynamic reconfig issues... -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Babel over DTLS
Fedor Ryabinin writes: > Recently, I heard a lot of good things about some Babel over DTLS > draft. Is there any chance that it will be somehow publicated? > > Honestly, if someone asks me what I want to see the most, it must be > this very draft. The latest version is on the IETF data tracker: https://tools.ietf.org/html/draft-ietf-babel-dtls-03 -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] [babel] BASE64 and hex encoding HMAC keys for user presentation
Juliusz Chroboczek writes: >> I would like the bird and babel implementations to allow for and use >> BASE64 and hex encodings. > >> This allows for a shorter, more human friendly representation of both >> cryptographically generated keys and the keys humans are more likely >> to remember and type without error. In the latter case, guidelines as >> to length, mixed case and punctuation would be useful. > > I think that the HMAC key should be generated automatically. I'd hope > that any actual production deployment of HMAC would generate HMAC keys > either randomly or by using a suitable KDF (or whatever the right acronym > is) and distribute it automatically. Should we pick a KDF? Not necessarily for the RFC, but at least try to get compatibility between bird and babeld, so users can just input a password and expect things to work? -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] BASE64 and hex encoding HMAC keys for user presentation
Dave Taht writes: > I would like the bird and babel implementations to allow for and use > BASE64 and hex encodings. In Bird's case, the password parsing code is part of the core; not going to special-case it for Babel. -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] [babel] rather than ripemd160...
Markus Stenberg writes: > Here's some raw numbers (clickbait): > > - my Macbook (sanity check) > - Turris Omnia (2016 highend) > - Buffalo WZR-600DHP (2012 midend) > > https://github.com/fingon/go-hashperf > > TL;DR (probably the interesting part): > > 2012 midend home router does 40 bytes: > - 37.5k pps of SHA256 > - bit over 40k pps of Blake2B > - 91k pps of Blake2S That's is awesome, thanks for doing this! > Setup overhead disappears both in SHA256 and Blake2 at ~500 byte mark > (500 and 1200 bytes roughly equal MB/s); with 200 byte packets setup > still wastes ~1/4 of performance (both SHA256 and Blake2) and even > more with 40 byte packets. > > With these numbers, I withdraw my support of including anything else > than SHA256 as MTI. I think specifying Blake2B or 2S as well makes > sense (mostly for crypto robustness reasons for having alternative > that is specified) but making it MAY-SHOULD seems sensible to me. I can probably live with that :) > The code is there, go ahead to test on your own routers if you care. I > didn't bother testing arm64 in the end, as those are even faster than > arm (the ridiculous blake2s number of 460k pps for Blake2s on Turris > Omnia convinced me that it is not really worth it to test on faster > hardware). Yeah, 460k pps ought to be enough for everyone ;) -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] key rotation take #2
Dave Taht writes:
> On Wed, Nov 28, 2018 at 12:23 PM Toke Høiland-Jørgensen wrote:
>>
>> Dave Taht writes:
>>
>> > Toke Høiland-Jørgensen writes:
>> >
>> >> Dave Taht writes:
>> >>
>> >>> so we invent a new keyword "serial".
>> >>
>> >> So what you're trying to express here is the notion of a "receive-only"
>> >> key that is not used for signing outgoing packets, right?
>> >
>> >
>> > No... the old key is retired from active use in the protocol after
>> > concensus is achieved on the new key by the protocol, and not used
>> > again unless a router comes up with an unreadable hmac. In that case
>> > we go back to at least trying to verify (periodically?) that it's not
>> > using the old key (if we still have it around) and if it's using the
>> > old key, we go back to signing stuff with that key.
>> >
>> > Does that concept need to be in the protocol spec?
>>
>> This reads to me like a specific operational procedure for deployment;
>> don't think that should go into the spec, no.
>>
>> >> it would be better to express that explicitly as a property of the key
>> >> config that can be changed on a per-key basis. For one thing, 'serial'
>> >> is misleading as it sounds like something that affects the wire
>> >> format,
>> >
>> > OK. how about "new" and "old" as keywords? That implies two states and
>> > two states only. I liked 0 and X as numbers, so long as the ascending
>> > property is maintained. As for why not 0 and 1, see below.
>> >
>> > Totally open to bikeshedding the name. :) babeltowerno?
>>
>> Don't care what they are called. My point is just that it's a property
>> of a particular key.
>>
>> Bird already has this, BTW: each key can be set to "generate" signatures
>> and "accept" signatures, where the former puts them on the wire, and the
>> latter will accept packets signed with that key. You can set time ranges
>> for each or both. See
>> https://bird.network.cz/?get_doc=20=bird-3.html (search for
>> "password option"). The Babel HMAC implementation inherits this.
>
> That is essentially my first proposal... in bird syntax. :) Aside from
> needing good time, there are really good reasons to stage key
> rotations that way
>
> while the odds are much better that a boot/bootstrapping bird router
> has a working rtc, your typical home router doesn't.
No, but you can use the mechanism without the timeouts to mark keys as
active/passive using whatever provisioning system you are using to
distribute the keys (just use "{generate,accept} from 1970-01-01").
-Toke
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] key rotation take #2
Dave Taht writes: > Toke Høiland-Jørgensen writes: > >> Dave Taht writes: >> >>> so we invent a new keyword "serial". >> >> So what you're trying to express here is the notion of a "receive-only" >> key that is not used for signing outgoing packets, right? > > > No... the old key is retired from active use in the protocol after > concensus is achieved on the new key by the protocol, and not used > again unless a router comes up with an unreadable hmac. In that case > we go back to at least trying to verify (periodically?) that it's not > using the old key (if we still have it around) and if it's using the > old key, we go back to signing stuff with that key. > > Does that concept need to be in the protocol spec? This reads to me like a specific operational procedure for deployment; don't think that should go into the spec, no. >> it would be better to express that explicitly as a property of the key >> config that can be changed on a per-key basis. For one thing, 'serial' >> is misleading as it sounds like something that affects the wire >> format, > > OK. how about "new" and "old" as keywords? That implies two states and > two states only. I liked 0 and X as numbers, so long as the ascending > property is maintained. As for why not 0 and 1, see below. > > Totally open to bikeshedding the name. :) babeltowerno? Don't care what they are called. My point is just that it's a property of a particular key. Bird already has this, BTW: each key can be set to "generate" signatures and "accept" signatures, where the former puts them on the wire, and the latter will accept packets signed with that key. You can set time ranges for each or both. See https://bird.network.cz/?get_doc=20=bird-3.html (search for "password option"). The Babel HMAC implementation inherits this. -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] [babel] rather than ripemd160...
David Schinazi writes: >> >> >> Why not? If it's not MTI you risk the case where you get to pick between >> "good performance on weak devices" and "interoperability with RFC-only >> implementations". >> > > Where are these "RFC-only implementations" of Babel? Anyone who does a from-scratch implementation from the RFC, without being part of the working group process, or looking at the existing implementations. > Remember the IETF does not have a protocol police, MTI is purely > guidance. Implementors build what they (or their customers) need for > their use-case. Implementors will add Blake if they need it, not based > on whether it's MTI or not. If it's MTI, they can't claim compliance with the RFC until it's in there. So the "we need this box checked" type of product development will benefit from this; and while sure, theoretically MTI is a hint, it's a pretty strong one... > Lastly, remember that this is a security solution, so you do NOT want > to interoperate with a future theoretical implementation, because that > will not have the keys. Adding any new node in the network will > require a provisioning step, and that step ensures the new node > supports the required features. You can usually control the config, but not necessarily the features implemented by the device... -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] key rotation take #2
Dave Taht writes: > so we invent a new keyword "serial". So what you're trying to express here is the notion of a "receive-only" key that is not used for signing outgoing packets, right? If so, I think it would be better to express that explicitly as a property of the key config that can be changed on a per-key basis. For one thing, 'serial' is misleading as it sounds like something that affects the wire format, and for another with your proposal it becomes difficult to re-instate a previously retired key (say, if you want to restore connectivity to an old router that dropped off while you were changing keys). -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] [babel] rather than ripemd160...
Dave Taht writes: > David Schinazi writes: > >> I feel strongly against making anything but SHA-256 mandatory to >> implement. It will delay publication and not improve the >> interoperability story. That said, I agree that the Blake2 family is a >> good fit here so it would be nice to have bird and babeld support them >> - but they do not need to be in the spec. > > Are we weeks, months, or years away from publication? Do we have time > to, like, actually code up, and test interoperability, performance, > and methods, before prague? Seeing as we already have prototype implementations in both babeld and bird, I don't see why not; if someone volunteers to do the testing (*hint*) ;) -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] [babel] rather than ripemd160...
David Schinazi writes: > I feel strongly against making anything but SHA-256 mandatory to > implement. > It will delay publication Not if there's already a draft we can simply refer to (like with SHA-256); I do agree that we shouldn't be trying to pull Blake through the IETF process if there isn't... > and not improve the interoperability story. Why not? If it's not MTI you risk the case where you get to pick between "good performance on weak devices" and "interoperability with RFC-only implementations". -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] HMAC Key rotation key format (was ripemd)
Dave Taht writes: > On Mon, Nov 26, 2018 at 1:10 PM Toke Høiland-Jørgensen wrote: >> >> Dave Taht writes: >> >> > To me this leaves the biggest problem remaining is key rotation. Me >> > being me, and remembering just how hard it was to get dnssec working >> > on systems lacking reliable time, >> >> The Babel HMAC extension as currently specified does not rely on wall >> clock time in any way, so not really sure how a comparison to dnssec is >> relevant? > > More below. Relative time is ok, too. 3000 seconds from now, start > rolling over. Stop signing records with the old key as soon as > everyone you can currently hear uses the new key, 6000 seconds from > now, retire the old key unconditionally. Well, you would handle this by whatever mechanism you use to configure your routers in the first place... >> > Setting that aside for the moment, having a standardized file format >> > for babel keys would be a boon and boost interoperability between >> > bird/babel and other possible implementations. >> >> From the point of view of each routing daemon this would just make Babel >> a special snowflake. > > ok. That leaves how to get new keys into nodes running different > daemons. Anyone for IKEv2? > > My out of bound way is via scp and ssh. I think Juliusz' insistence that we shouldn't reinvent key distribution is wise. See above; you need to configure the daemons in the first place anyway... > Also the present babeld cannot rewrite it's entire config file (so far > as I know). I think bird can... Yup, a 'bird reconfigure' will re-read the entire config file and apply it if it parses successfully. > but I don't trust it. Your trust issues are probably best resolved between you and your daemon ;) >> What we can do is to specify the format in the information model if a >> cross-implementation format is really needed (which I'm not really >> convinced of, either)... > > To quote from appendix A: > > "In order to perform key rotation, the new key is added to all the > nodes; once this is done, both the old and the new key are sent in all > packets, and packets are accepted if they are properly signed by > either of the keys. At that point, the old key is removed." > > My key points made here are "the new key is added to *all* the > nodes"... which may or may not be up over the course of days, or weeks > for whatever definition of "all" you have ... "Once this is done" - > how can you tell? - "and packets are accepted if they are properly > signed by either of the keys" hopefully you log this ... "the old key > is removed". > > perhaps "deprecated, no longer actively used for signing, then removed > after a suitable period"? Hmm, having a way to mark a key as "verify only" may be useful for simpler monitoring. But really, you *could* derive the same information from the opposite bit (track how many neighbours don't sign with the new key yet). So then it becomes more of an efficiency issue (you could save one signature on the wire during rotation). Not sure if it's worth specifying another bit in the spec for this? Or if such a configuration mode should even be in the spec at all? > So, if you do a key rotation and X routers are offline or inaccessible > at that particular time... they are going to stay inaccessible > forevermore, unless rekey'd via sneakernet, climbing on trees, and > other forms of manual intervention. Presumably your key rotation policy would take into account the outage schedules of the routers in your network? :) -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] [babel] rather than ripemd160...
"STARK, BARBARA H" writes: > FYI. IETF policies re "downrefs" in standards track RFCs is described in > https://tools.ietf.org/html/rfc3967 (and updated by > https://tools.ietf.org/html/rfc8067). > In short, it's not prohibited, but careful review is required. > Note RFC3967 Section 2 first bullet > >There are a number of circumstances in which an IETF document may >need to make a normative reference to a document at a lower maturity >level, but such a reference conflicts with Section 4.2.4 of >[RFC2026]. For example: > >o A standards track document may need to refer to a protocol or > algorithm developed by an external body but modified, adapted, or > profiled by an IETF informational RFC, for example, MD5 [RFC1321] > and HMAC [RFC2104]. Note that this does not override the IETF's > duty to see that the specification is indeed sufficiently clear to > enable creation of interoperable implementations. Ah, so HMAC itself is already an informational RFC? Great, let's do blake2, then! :D -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] [babel] HMAC and MTI [was: rather than ripemd160...]
Markus Stenberg writes: > On 26 Nov 2018, at 15.46, Juliusz Chroboczek wrote: >>> I'm not sure if we *can* make [blake2s] MTI in the spec as well (does it >>> need to be defined by a standards track RFC for us to do that?), but if >>> we can, I think we should seriously consider it... >> Opinions? > > I like Blake (family of) hash functions so on that front +1; however, > no idea how bureaucracy works. > > Dave had a good point as well though, comparing -2s and -2b > performance on some set of hardware (e.g. arm, mips, intel) might be > in order before picking between the two. I am not convinced -2s is the > way _forward_. Even now most of hardware in my home is already 64bit > .. Right, sure. I guess I can start by putting both into Bird, and we can benchmark that... -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] [babel] rather than ripemd160...
Juliusz Chroboczek writes: >> Anyway, the default hash function is sha256 in the hmac-challenge >> branch. I approve, there's hardware support for it, and if someone >> breaks it, civilization collapses, so an alternate hmac is a "good to >> have", and what's in that branch... is ripemd160. > > From a standardisation point of view: > > - HMAC-SHA256 is Mandatory to Implement; > - implementation may implement other MAC algorithms, and since no > algorithm identifier is carried on the wire, doing that requires no > further standardisation action. > > From the point of view of the implementation, we need to clean up this > code to remove the dependency on OpenSSL. When we do that, we'll probably > remove the HMAC-RIPEMD160 code, and leave just SHA256. (Don't hold your > breath, though -- it's exam season for both the girls and myself.) > > If we add another HMAC algorithm, we'll want to do it in agreement > with Toke, so that both implementations implement the same set of HMAC > algorithms. Bird already supports HMAC using MD5, SHA1, SHA256, SHA384 and SHA512, which is inherited by the Babel implementation. I am planning to add blake2s to that when I get around to revising the HMAC patch (see below). >> Both blake and siphash seem like a superior choice for an alternate hmac >> function to ripemd160. In particular blake is subject of its own RFC, >> and comes in several clean highly optimized versions for x86 and arm >> architectures. > > I hold no opinion on that at the current time, I'd need to consult my > colleagues. I happen to share Dave's concern about sha256. And basically all the crypto people I've been talking to have been of the opinion that blake2s is the way to go for low-powered devices. So I am definitely planning to add an implementation of that to Bird, and may even make it the default for Babel. I'm not sure if we *can* make it MTI in the spec as well (does it need to be defined by a standards track RFC for us to do that?), but if we can, I think we should seriously consider it... -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] bird version interop issues
"Velt, R. (Ronald) in 't" writes: > Hi Toke, > >> -Original Message- >> From: Babel-users > lists.debian.net> On Behalf Of Toke Høiland-Jørgensen >> Sent: vrijdag 9 november 2018 21:46 >> To: Dave Taht ; Juliusz Chroboczek >> Cc: babel-users >> Subject: Re: [Babel-users] bird version interop issues >> >> Dave Taht writes: >> >> > and it's easy to spot. see packet 592 of this: >> > >> > http://www.taht.net/~d/jules.cap >> > >> > I am using the int-new branch of bird... >> >> What's wrong with that packet? Wireshark doesn't seem to have any issues >> parsing it? > > No router-ID and next-hop before first Update? The updates are retractions, so those are not needed... -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] bird version interop issues
Dave Taht writes: > and it's easy to spot. see packet 592 of this: > > http://www.taht.net/~d/jules.cap > > I am using the int-new branch of bird... What's wrong with that packet? Wireshark doesn't seem to have any issues parsing it? -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] 64k routes, bird, babel rfc, rtod, etc
Dave Taht writes: > On Thu, Nov 8, 2018 at 1:40 PM Dave Taht wrote: >> >> On Thu, Nov 8, 2018 at 1:21 PM Juliusz Chroboczek wrote: >> > >> > > things fall apart at about 32k in this case. >> > >> > That's pretty good. We'll reach your 64k target when we get around to >> >> It's a worthy goal, but really excessive. :) I basically wanted to >> know the limits >> of the lowest end hw I had, for real, before daring to try and deploy >> ipv6 willy nilly again. >> >> > fixing the resend data structure >> >> Got any ideas? I enjoyed poking into the latest trie research (source >> specific routing is a new area!) and I really enjoyed learning about >> skiplists last week, am liking the uthash potential long term... >> >> > and implement pacing in the buffer >> > flushing code. >> >> Pacing can be done at the socket layer now and it's been working for >> udp and QUIC since, oh, about 4.12? 4.9? can't >> remember. I tried this at one point. Easy patch to fiddle with to >> "just turn it on" >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=62748f32d501f5d3712a7c372bbb92abc7c62bc7 > > This no longer requires the fq scheduler, btw. Problem is (as the quic > folk are experiencing) is that the kernel doesn't know > (at least not with public patches) that you can send udp at one rate > one way, and another at another. tcp can do it per connection. There is also a socket option that allows you to set an "earliest send time" on each packet... Can't remember what it's called, but it ties into Van's timer wheel idea... -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] 57 forks of babel on github
Dave Taht writes: > I haven't figured out enough of bird to get it to stop announcing all > the local ips, btw, and am quite That part it doesn't actually do by default; I added it to the sample config to match babeld. Just get rid of the "protocol direct" section and they should go away... -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] a better bird config and a survived gnarly rtod test
Dave Taht writes: > does bird's metric 128 inflate that default metric then? The config with the 128 metric adds that to the initial metric, before the routes are announced the first time... > should it just be 0? 96? Well, that would depend on which policy you want to implement :) > Perhaps it would help if I shared my sekret plan. > > In the lab I have 3 routers for test purposes (7 actually, but...) > > labgw -- campusgw > (heavily filtered, I'm crazy but not entirely so) > | | | > FRR Router BIRD router BABELD router > | | | > a switch --- > || | || | > a bunch of devices configured differently > > The routers are apu2s, the devices a misc collection of hackerboards, > with kernels > going back as far as 3.10. > > assuming all these do the right/same things with metrics, my > assumption is the firstmost router to make an announcement will win. > apu2s also have two ports, so each has yet > another device hanging off of that... Hmm, yeah, if they all announce the same routes with the same metrics, I guess the devices will pick whichever one it establishes contact with first, and not switch that route over unless something changes... -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] a better bird config and a survived gnarly rtod test
Dave Taht writes: > Toke Høiland-Jørgensen writes: > >> On 25 October 2018 23:14:20 CEST, Dave Taht wrote: >>>On 10/25/18, Juliusz Chroboczek wrote: >>>>> the box doing the injection ate a cpu for all of the 5 minutes the >>>>> test ran >>>> >>>> How did the BIRD box behave? >>> >>>On the bird front, I'm thinking this is essentially wrong... it should >>>match babel for wired links (96). Does bird have the ability to >>>distinguish between wired and wireless links (inflating txcost as >>>babeld does) >> >> Only through manual config, currently. I'm hoping to add auto-detection at >> some point... > > Still, 96? Better? Wired links have cost 96. Links are wired by default... -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] a better bird config and a survived gnarly rtod test
On 25 October 2018 23:14:20 CEST, Dave Taht wrote: >On 10/25/18, Juliusz Chroboczek wrote: >>> the box doing the injection ate a cpu for all of the 5 minutes the >>> test ran >> >> How did the BIRD box behave? > >On the bird front, I'm thinking this is essentially wrong... it should >match babel for wired links (96). Does bird have the ability to >distinguish between wired and wireless links (inflating txcost as >babeld does) Only through manual config, currently. I'm hoping to add auto-detection at some point... -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] ddns with linode
Dave Taht writes: > Not really. > > * The first couple of linode steps seem to be pretty manual. With > nsupdate it's a bit less manual with bind9 > > * I don't need to register all my boxes in global dns, just a couple > servers. In that case, it's http://ceres.taht.net:8080 > > * Those few that I do, I'd like to register each of the source > specific addresses in dns so as to be able to fall over... > > * it would be good for each to install "the best" ss address as it's > default addr (is that what the prefsrc patch could do?) > > * Ceres is not an openwrt box (no ddns package), it's a fresh upgrade > to ubuntu bionic... and systemd breaks /etc/network/ifup.post rules > nowadays, has no ifup/ifdown commands Hmm, sounds like you could actually use my nsregd for this: https://github.com/tohojo/nsregd Takes a bit of setup the first time around, but after that you can just deploy new boxes by running the client binary on them. It's Go, though, so won't run on MIPS... -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] ddns with linode
Dave Taht writes: > I currently get my ddns from linode. It's a huge pita, because you have > to mentally parse the javascript to find the unique identifiers for each > dns entry. I may try to switch to bind9 and stick it on a subdomain, but > even then a good parse of ip -6 addr is needed. The ddns package in openwrt has code to do this for you; all you need to define is the URL template... -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Babeld vs. BIRD [was: Please test master]
Dave Taht writes: > On Wed, Sep 26, 2018 at 11:01 AM Toke Høiland-Jørgensen wrote: >> >> Juliusz Chroboczek writes: >> >> >>>> Received prefix with no router id. >> >>>> Couldn't parse packet (8, 13) from fe80::eea8:6bff:fefe:9a2 on enp6s0. >> >>>> Received prefix with no router id. >> >>>> Couldn't parse packet (8, 14) from fe80::eea8:6bff:fefe:9a2 on enp6s0. >> >>> >> >>> Toke, are you mis-parsing retractions? No router-id is necessary for >> >>> a retraction. >> > >> >> Weren't these messages in the babeld log? >> > >> > My bad. Yeah, sorry. >> >> Hmm, we did actually fix a bug a few months ago where Bird would send >> out v4 routes even though it didn't have a next hop for it. The fix is >> in commit caa9d03d65ce827ce536d54b26988e70767e032f. >> >> Dave, are you sure you're running the latest git version of Bird? > > I pulled and built and played with your int-new branch which has that > commit in it. Right. Think I got next hops and router IDs confused anyway, so it's probably not related to this... -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Babeld vs. BIRD [was: Please test master]
Juliusz Chroboczek writes: >> Received prefix with no router id. >> Couldn't parse packet (8, 13) from fe80::eea8:6bff:fefe:9a2 on enp6s0. >> Received prefix with no router id. >> Couldn't parse packet (8, 14) from fe80::eea8:6bff:fefe:9a2 on enp6s0. > > Toke, are you mis-parsing retractions? No router-id is necessary for > a retraction. Weren't these messages in the babeld log? From the Bird parser: /* Update must have next hop, unless it is retraction */ if (ipa_zero(state->next_hop_ip4) && (msg->metric != BABEL_INFINITY)) return PARSE_ERROR; So that should be fine... -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Ability to work with massive number of routes? (global full-table)
Dave Taht writes: > And - setting a goal for 64k routes - I thought that switching to a > normalized table structure internally would be useful. Instead of > storing the nexthop as a full address store an 16 bit index pointing > to an array of those nexthops. And so on. Incidentally, it looks like the Linux kernel will start doing this as well: https://marc.info/?l=linux-netdev=153576423232067=2 -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Babeld vs. BIRD [was: Please test master]
Dave Taht writes: > Thank you very much toke! > > Thus far the bird version is interoperating with 1.8.3 and the other 6 > babel versions I have deployed, ipv4 and ipv6 just fine. I don't get > source specific of course I've lost track of where that repo is, but if you find a version of babeld that speaks the new source-specific protocol, bird should interoperate just fine with that :) -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Babeld vs. BIRD [was: Please test master]
Dave Taht writes:
> On Sat, Sep 22, 2018 at 6:39 AM Juliusz Chroboczek wrote:
>>
>> >> I'll point out that the BIRD codebase is cleaner and better designed
>> >> than babeld, and might be able to scale better. I'd be interested in
>> >> seeing a comparison.
>>
>> > Yeah, me too.
>>
>> Toke, perhaps you'd like to post some instructions?
>
> bird now has ipv4 + ipv6 support, yes?
Yup. I'd recommend using the git version from the 'int-new' branch:
https://gitlab.labs.nic.cz/labs/bird/
> If I could get a bird.conf configged for babel that also could do the
> moral equivalent of:
>
> "redistribute proto 50 metric 128"
>
> And another
>
> https://github.com/dtaht/rtod/blob/master/babeld-safe.conf
See below. You can edit the blacklist and import_filter to get the
filtering you want. You'll also need to define the right set of
interfaces near the bottom.
-Toke
Put this in a file and run `sudo ./bird -c name-of-file.conf`:
router id 62.168.0.1;
# Enable debugging output
debug protocols all;
# Need to define table for ipv6 sadr (v4 is implicitly defined as 'master4')
ipv6 sadr table tab1;
# Listen to dev up/down events
protocol device {}
# Blacklisting and filtering from kernel
define blacklist = [
a::/16,
127.0.0.0/8
];
filter import_filter
{
# Filter routes in blacklist
if (net ~ blacklist) then reject "blacklisted";
# Only import kernel protocol 50
#if (krt_source != 50) then reject "wrong protocol";
accept;
}
protocol kernel {
ipv6 sadr {
table tab1;
export all;
import filter import_filter;
};
learn yes;
}
protocol kernel {
ipv4 {
export all;
import filter import_filter;
};
learn yes;
}
# Create routes subnets configured on interfaces
protocol direct {
ipv6 sadr;
ipv4;
}
protocol babel {
ipv6 sadr {
table tab1;
import all;
# Set initial metric for all routes
export filter { babel_metric = 128; accept; };
};
ipv4 {
import all;
# Set initial metric for all routes
export filter { babel_metric = 128; accept; };
};
# Interfaces to listen on and their config
interface "eth0" { type wired; };
interface "wlan0" { type wireless; };
}
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Please test master
Juliusz Chroboczek writes: > I'll point out that the BIRD codebase is cleaner and better designed > than babeld, and might be able to scale better. I'd be interested in > seeing a comparison. Yeah, me too. I know that the Bird daemon itself can easily handle full BGP tables, and I don't *think* there's any reason why the Babel protocol implementation should fall down on this (famous last words). It may kill the *network*, though, as it is going to be bursting out ~10k packets on every update interval (which is ~14 MiB of data)... -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
