Hi,
> I know Babel can now run over unicast addresses.
Yes, and I would welcome help testing this feature.
> How can I improve my babeld configuration to utilize the new feature?
First, you need to switch to branch "unicast":
git checkout unicast
Then, rebuild babeld, and put the following
>> Please be also aware that it currently doesn't do source-specific
>> routing (if you don't know what that is, it's not a problem for you.)
> What a pity. SADR is exactly the reason I'm using Babel for.
Give me two-three weeks, then.
-- Juliusz
___
Hi,
I've just spent four days in Osijek, a small city in the East of Croatia,
invited by Valent Turković (in copy of this mail). It was an interesting
stay.
For those of you who are not up to scratch in European Geography, the part
of Croatia that everyone knows about is the west, on the Adriati
> Using master / 1.8.1 really does improve the situation with triggered
> updates. They happen consistently and quickly.
Thanks for the info.
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailma
Babeld-1.8.1 breaks redistribution of IPv4 routes (but not of IPv4 local
addresses). Sorry for that.
Here's the bug report:
https://github.com/jech/babeld/issues/13
I've committed a quick fix into master:
https://github.com/jech/babeld/commit/157e44a4a507786f5626070d9b1f3e371389
The f
> it works!
Thanks for the info. It's a serious bug, so I'll make a release this
week-end -- please let me know if you see anything bad.
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bi
/
This version fixes a bug introduced in 1.8.1 that prevented IPv4 routes
from being redistributed. There are no other changes.
Enjoy,
-- Juliusz Chroboczek
pgpF4ODGV1yUo.pgp
Description: OpenPGP Digital Signature
___
Babel-users mailing list
Babel
Dear all,
Clara Dô and Weronika Kołodziejak, in copy of this mail, are currently
working on adding symmetric authentication (à la RFC 7298) to babeld.
We're wondering how to provision the keys.
My current choice would be have a new configuration statement
hmac 1 sha1 bcd329fa7d180067709a03ae1e
Dear all,
I've just rebased the "unicast" branch over 1.8.2. This means that:
- if you're tracking branch "unicast", you'll need to "git pull --rebase";
- if you've got a branch based on "unicast", you'll need to rebase
(Antonin, Clara, Weronika -- that means you).
Happy rebasing,
-- J
Dear all,
Clara Dô et Weronika Kołodziejak (in copy of this mail) have just pushed
their work on HMAC authentication for babeld to Github:
https://github.com/wkolod/babeld branch hmac
It's a very early prototype, and has received almost no testing. To use,
checkout and compile the hmac branc
Dear all,
While working on the HMAC security mechanism, we have found an off-by-two
error in the packet parser which could cause babeld to read two octets
after the end of the read buffer. The overflow is not believed to be
exploitable -- a maliciously crafted packet will merely cause two octets
>> If I am building a network now that utilises source-specific routing,
>> how can I best prepare for a migration path?
> If you can just deploy the new version everywhere and reboot the
> network, that would be the best. The 1.9.0 branch (and all future
> versions) are not experimental and will
> For multi-homed devices it would be interesting being able to specify
> a preferred source address for routes exported via babel. If the preferred
> src address is not specified, the kernel will select the src address and
> thus will leak ipv6 addresses into a network where they are foreign.
The
>> [babel 1.9.0 will introduce incompatible wire-format for src-specific
>> routing]
> If I am building a network now that utilises source-specific routing, how
> can I best prepare for a migration path?
Make sure you run 1.8.2 or later, not an earlier version. Deploy your
network with no fear.
> The packets never traverse the 2a02-network yet it is showing up in the
> traceroute and that way the 2a02 addresses are leaking into the mesh
> revealing information about the node that should not be revealed.
> Sacondly packets originating from the node like DNS may leave the node
> with an ina
Hi, and sorry for the massive cross-posting. I suggest followups should
go to babel@ietf.
The mails that I'm receiving indicate that we (Babel@IETF) have confused
some people with our crypto plans. Thanks to all for your questions, and
let me please try to clarify things publicly.
Considering s
> 2a02 is assigned to br-wan 2a06 is assigned to local-node which is
> a veth-pair bridged into br-client. The mesh is mesh0, mesh1 and so on.
> The node can be addressed by its 2a06 address. This is the default setup
> of gluon. When now communicating over the mesh, neither the 2a02 nor
> the 2a0
Dear all,
The Babel working group of the IETF will be meeting on Tuesday 17 July at
9:30 Montréal time (EDT, UTC-4)
1:30 UTC
3:30 Paris time (UTC+2)
Highlights include a presentation by David Schinazi about DTLS security
for Babel (joint work with Antonin Décimo), and a presentation by mys
> I see a seprate repo for the new hmac code, the revised source
> specific stuff is where?, the rfc-bis stuff is in a branch. etc. It's
> confusing. can it all get rolled up into one thing now? :)
Yeah, it's a mess. I badly need a technician to give me a hand.
We've got the following branches:
> This is confusing to me as well. I direct my patches towards
> https://github.com/jech/babeld
You do well.
> Though I have to say I am not sure what the policy for merges is
There's no policy :-/ I take care of the merges as soon as I have some
time at the office (it's the testing that takes
Hi,
A number of fixes have accumulated in the master branch. I'd like to
release a 1.8.3 fairly soon, so if anyone has time to do some testing, I'd
appreciate the help.
Thanks.
babeld-1.8.3 (unreleased)
* Fixed a read-only two byte buffer overflow in the packet parser.
This is a read-onl
> in https://github.com/jech/babeld/pull/16 I provided a small patch that
> fixes a crash on ipv6-only nodes
The issue, I believe, was with interfaces that don't have a link-local
address (yet) when they are being monitored over the local interface. It
was triggered by your netlink patch -- since
> (I ran across this babelweb pic from my old c.h.i.p + rtod experience,
> which cracked 16sec of delay in the mcast queue:
Bufferbloat in the driver queues?
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.ne
> Recently I tried to deploy a few babel 1.8.2 nodes with the latest
> openwrt, which I had to back out rapidly because I was dropping so many
> babel packets under contention.
That's interesting. Could I please see a log?
> A patch to universally enable babel ecn in net.c "solves" this problem,
>> Interesting. AFAIK, ECN is only considered by AQM queues, so this implies
>> there's a queue in the way that's dropping Babel packets.
> There's fq_codel on every queue, which does FQ, and codel assumes
> everything is at least moderately TCP friendly (and/or reasonably
> responsive to ecn mar
> I also discussed issues with tim (cc'd) was having on his raspberri pi
> (arm) based version. He seems to have got a much stabler result after
> reverting to 1.7.1.
Correct. In 1.7.1, babeld got more stable and less reactive. We tweaked
the logic again in 1.8.0 to make it more reactive again.
>> I tested the babel-1.8.3 release under some extreme loads with 90
>> routes present (30 ipv6 total)
> BTW, I disagree with the word "extreme".
We should have no problem with this kind of load on wired. OTOH, it's
rather extreme for wireless -- 802.11 doesn't behave well in dense
networks.
>
> One of my environments uses BGP full-table from 3 upstream ISPs (each
> with 785k routes currently).
Well, that's a lot. BGP is designed with that in mind -- it uses
incremental updates layered over a reliable protocol, and therefore scales
beautifully in a stable network. Babel uses unreliabl
> but when I tested it yesterday, it was still uninstalling routes that
> were reachable on a regular basis after the metric went to 2^16. Then
> about 2-5 seconds later, it would put them back in.
So the routing protocol is doing fine, it's the link quality estimator
that's unstable. Good.
Firs
>> 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?
-- Juliusz
___
> It happens with almost no data at all being passed except the babel overhead.
> I
> can watch it in wireshark.
Could you please try reproducing this with "babeld -d2", and send me the
logs by private mail?
___
Babel-users mailing list
Babel-users@ali
Dear all,
Babeld-1.8.3 is available from
https://www.irif.fr/~jch/software/files/babeld-1.8.3.tar.gz
https://www.irif.fr/~jch/software/files/babeld-1.8.3.tar.gz.asc
For more information about the Babel routing protocol, please see
https://www.irif.fr/~jch/software/babel/
The main news is
>> B) you run out of cpu - babeld uses linked lists,
Not quite -- the route table is a flat array, with per-destination
linked-lists. We don't walk the linked lists often, we mostly walk the
flat arary.
>> and tries to recalc bellman-ford every 4 seconds also.
No, it doesn't. It only does the
Your config looks fine to me. Perhaps I've missed something.
Please run babeld with "-g 33123" and do
echo dump | nc ::1 33123
and send us the output.
Also send us the output of "ip route show".
-- Juliusz
___
Babel-users mailing list
Babel-users
> What exactly are you suggesting? Babeld should not set unreachable when
> removing routes? I have always wondered about that specific behavior of
> babeld.
https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-05#section-3.5.5
___
Babel-users mailin
> 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 :)
I'm working on merging the Matthieu's new source-specific code into
the unicast branch of babeld. Please hold your breath
> Well, I took a stab at some of that. In particular, babeld has to compare
> a lot of bytes, and while profiling it on these loads, was totally
> bottlenecked on memcmp.
Yep, the code in xroute.c is pretty pessimal, since I wan't expecting
people to have massive numbers of redistributed routes.
> 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 retrac
>>> 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 necessar
> I used to have a patch to update_neighbour that logged late hellos. The
> new update_neighbor code in 1.8.3, well, in a half hour of staring at it
> I didn't figure out a good place to stick this. But it was a useful
> patch to have. you can't fix what you can't measure.
Try the "missed_hellos
> -const int ds = 0xc0;/* CS6 - Network Control */
> +const int ds = 0xc2;/* CS6 - Network Control + ECN */
Nope. If we start lying about ECN, people will start disabling ECN in
routers, which would not be a good thing.
___
Babe
> --- a/kernel_netlink.c
> +++ b/kernel_netlink.c
> +static int ipv4_metric = 0;
> +static int ipv6_metric = 1024;
That's exactly the wrong layer at which to do that. Policy should be
happening at least 17 layers higher.
What problem is that intended to solve?
_
> BPF magic courtesy Stephen Hemminger - from 2008.
That's pretty cool, but I'd rather solve the issue with xroutes being slow
rather than doing micro-optimisations such as this one.
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https
> BABEL 1.0
> version babeld-1.8.2
> host XNode-HUB
> my-id f0:0a:0d:8d:14:34:94:99
> ok
> add interface eth0 up true ipv6 fe80::6f0:21ff:fe40:520 ipv4 192.168.1.103
> add interface eth0.1 up false
> add interface eth0.2 up true ipv6 fe80::6f0:21ff:fe40:520
> add interface wlan0 up true ipv6 fe80::
> I think I agree with Juliusz here, I'd prefer Babel stay truthful and
> instead change how fq_codel reacts to it.
Yeah, perhaps fq_codel is not tolerant enough of bursts of packets. But
I think we should work around that on the application side -- babeld
shouldn't be sending updates as a burst
>>> I think I agree with Juliusz here, I'd prefer Babel stay truthful and
>>> instead change how fq_codel reacts to it.
>> Yeah, perhaps fq_codel is not tolerant enough of bursts of packets.
> Heh, I'm not sure there's a proper response to a large burst of
> back-to-back packets that won't suck f
> And yes, reverting the apu2 to 1.7.1 fixed the default route issue.
Can you confirm that 1.8.2 didn't work? There was a bug in 1.8.[01] that
could be what you're seeing.
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth
> I can confirm now that this has been happening for quite some time, both
> my lab gws are 1.8.0.
Cool, known bug then. Fixed in 1.8.2.
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/l
> Well, I will go test in the lab. You are saying that even relaying
> routes through a 1.8.0/1 box will mess things up?
No, it's redistribution that's broken.
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.
> deploying 18.06.1 (with 1.8.2) on the remaining 4 routers on that
> portion of the topology made an enormous jump in reliability.
Good to hear that, and sorry for the bug in 1.8.0.
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debi
> And I'm *not* importing proto 51 of this list into babeld, but when it
> does a kernel dump, it gets it all, hits an internal memory limit
> processing the netlink data and doesn't manage to import *any* kernel
> routes.
Right. As I've mentioned previously, the redistribution code in babeld is
> Also it would be really helpful if that remaining PR (prefsrc) could be
> considered. I am not sure if anything is missing there. A merge would be
> the driver for me to take steps to get the version bumped in openwrt.
The plan is for the patch to get into 1.9.0 -- I'm only merging bug fixes
in
> Following a more-or-less recent trend, I wrote some time ago a Meson
> build file for babeld.
I'm an old man, Antonin, and I've learnt to avoid recent trends.
> On my laptop, a clean build takes 5s with Meson+Ninja, from 10s with
> make.
Are you running "make -j"?
> The pull-request lives on
>> Over my dead body.
> Soon enough, then?
The point I'm making is that we want to avoid introducing dependencies.
With Meson, we would depend on Meson itself, on Ninja, and on Python --
three technologies that I don't fully understand and that I'm unable to
fix if something goes wrong. What's m
> I keep seeing people talk about running tunnels via babel. Is there a howto
> about how to do it? With wireguard? ipsec ? ssh? Or ?
We've had good success with both GRE (insecure) and OpenVPN over UDP.
In both cases, it's pretty trivial:
- start the tunnel;
- make sure the tunnel endpoints
> is your preferred workflow still patches to the mailing list?
I now know how to generate a patch from a github pull request (ghi --patch),
so either is fine.
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-l
> 92.52 18.1718.17 38243948 0.00 0.00 find_resend
Thanks, that's helpful.
> fix with binary search? timer wheel? ?
Binary heap?
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.
> * Unless you want to setup unicast Babel you need an individual port and
> tunnel for every Babel connection.
(You mean every Babel neighbour association. Babel is an unconnected protocol.)
> Wireguard's secure IP's feature won't allow you to use the peer
> discovery broadcast address twice
0. Pro memoria, babeld-1.8.1 and later are safe to use in networks with
the new source-specific code.
1. I've added a new per-interface flag "rfc6126-compatible" to the babeld
config file. It's a noop in the 1.8 branch, in the 1.9 branch it
prevents sending of packets that might confuse
> I figure you want to sleep,
Eat, then sleep.
> Tue Oct 23 14:38:53 2018 daemon.err babeld[11651]: Assertion failed:
> buf->len >= bytes + 2 && buf->buf[buf->len - bytes - 2] == type &&
> buf->buf[buf->len - bytes - 1] == bytes (message.c: end_message: 966)
diff --git a/message.c b/message.c
in
> struct babel_addrs { // could use a better name
> unsigned char src_prefix[16]
> unsigned char prefix[16];
> unsigned char src_plen;
> unsigned char plen;
> unsigned short nexthop; // an index, not a ptr, into the nexthop
> table, sometimes unused
> };
> struct resend *f
> the box doing the injection ate a cpu for all of the 5 minutes the
> test ran
How did the BIRD box behave?
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-user
> Also it would be really helpful if that remaining PR (prefsrc) could be
> considered.
Christof, are you willing to send me a clean patch against the rfc6126bis
branch, or shall I do the merge myself?
-- Juliusz
___
Babel-users mailing list
Babel-user
> Being a meshy protocol, though, if something escapes, usually over
> a "backup" link, suddenly a whole bunch more specific routes end up
> going through that backup link and life goes to hell quickly.
Yeah, that's a common user interface issue.
Now that we have mandatory bits, though, this coul
Dave,
If you look at the branch xroute-nlogn, there's some code to update
xroutes in n logn time. It's almost completely untested.
If you've got time, I'd be grateful if you could have a look.
___
Babel-users mailing list
Babel-users@alioth-lists.debi
> * I hit the nlogn branch with the same stuff... it's cpu barely ticks
> over, thousands of routes get distributed... it gets knocked off the
> network... and all end up unreachable, after everybody else runs out of
> some resource or another
Dave, I'm planning to merge nlogn into master, so
> since, what the heck, I have 7 different versions of babel in the lab,
> I figured why not add in the unicast branch on two boxes and see what
> else breaks.
The unicast branch is obsolete -- the rfc6126bis branch is based of it.
So if you're running rfc6126bis (or nlogn), you're already running
> 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 m
> ah, ok, so the nlogn branch I've been running was derived from the
> unicast branch? which in turn was derived from the rfc-bis branch? and
> I've been running that all along?
The other way around (unicast branched into rfc6126bis which branched into
xroute-nlogn), but yes.
> So all that's lef
> is there an updated tcpdump or wireshark for the newer subtlvs?
Not yet. It's an easy hack, unless somebody beats me to it, I may offer
it as a first- or second-year project next spring.
> there are no timestamps in the multicast hello according to wireshark.
I may have broken something. I'l
>> there are no timestamps in the multicast hello according to wireshark.
> I may have broken something. I'll have a look.
Works for me (TM).
22:41:33.171052 IP6 (class 0xc0, flowlabel 0x27d4c, hlim 1, next-header UDP
(17) payload length: 52) fe80::8aa8:f6d:d885:2851.6696 > ff02::1:6.6696:
> It doesn't show up in my version of wireshark, but does in tcpdump.
> sorry for the noise
It's a useful report, it indicates that Wireshark doesn't correctly
indicate unknown sub-TLVs. Needs fixed.
___
Babel-users mailing list
Babel-users@alioth-list
> #0 0x0040c1d4 in start_message (buf=buf@entry=0x171e5b8,
> type=type@entry=10, len=len@entry=22) at message.c:957
> #1 0x0040c568 in send_multihop_request (buf=0x171e5b8,
> prefix=0x1cf66b8 "\374c\311/S\266)j", plen=,
> src_prefix=0x1cf66c9 "", src_plen=, seqno=,
>
Dear Volodymyr,
> default via 192.168.2.1 dev eth0.2 proto static
If you look at /etc/iproute2/rt_protos, you will see that "proto static"
is a protocol number of 4. Now your redistribution rule says:
option 'proto' '3'
This says that only routes with "proto boot" are redistributed. The r
> I remove "option 'proto' '3'" from redistribution rule and it is not working.
> Here is routing tables on Box1 after changes:
On the box that fails to redistribute the routes, do:
killall -USR1 babeld
logread
and send the relevant lines of the log to the list.
-- Juliusz
___
Dear all,
This is to remind you that the Babel working group will be meeting
tomorrow at
15:40 Bangkok (UTC+7)
9:40 Paris (UTC+1)
3:30 New York, NY
0:30 San Luis Obispo, CA
Remote participation is free and warmly welcome. Please see
https://www.ietf.org/how/meetings/103/remote/
a
Thanks for all the patches, Dave.
> the nlogn branch has a bug in that redistribute local deny does not work.
This should be fixed now.
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin
> Oh, thank you! I stared at this bit of code for hours, trying
> different things, printfing, stepping through a debugger... trying to
> figure out where infinity was missed.
Except it's completely wrong ;-)
Careful, I'm going to rebase the branch.
-- Juliusz
__
>> Except it's completely wrong ;-)
> yes, I just tried it. :(
Fixed. (Hopefully, I really need to take a couple of days off.)
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman
> Would you like me to try merging this against head?
No need, it should be an easy merge. Please continue testing, you're
being very helfpul.
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/
> things fall apart at about 32k in this case.
That's pretty good. We'll reach your 64k target when we get around to
fixing the resend data structure and implement pacing in the buffer
flushing code.
What happens if you disable all forms of AQM on the outgoing interface?
I.e. use large FIFO queu
Dear all,
Babeld-1.8.4 is available from
https://www.irif.fr/~jch/software/files/babeld-1.8.4.tar.gz
https://www.irif.fr/~jch/software/files/babeld-1.8.4.tar.gz.asc
This is hopefully the last release in the babeld-1.8 branch, and the last
release to implement the old source-specific protocol
Hi,
I've just merged a bunch of stuff into master:
- branches xroute-nlogn and rfc6126bis are now obsolete;
- please track master instead.
This means that master now implements the new revision of the protocol,
temporarily known as RFC 6126bis. Please see
https://datatracker.ietf.org/me
> Received prefix with no router id.
> Couldn't parse packet (8, 12) from fe80::230:18ff:fec9:de9c on eno1.
Dave, this is concerning, as it indicates that either BIRD or babeld is
violating the spec. I'll try to reproduce it, but if you manage to
capture the paket that's causing this message, tha
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...
You'r
> both ifconfig and bird show a mtu of 1500.
> given the interest in tunnels and perhaps not in the spec, (?) a peak
> size no more than wireguards 1420 would be good.
No, we're supposed to stay below the MTU whatever its value.
> should DF be set?
This is IPv6, there's no DF.
-- Juliusz
_
> babeld is hard coded I believe to no more than 1500.
No, it determines the interface's MTU and derives buffer sizes from that.
See interface.c starting at line 309.
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://a
> In looking over the bird patch, it looks like I merged the wrong
> thing.
Yes, it looks like it. hmac-challenge is the right code.
Weronika, perhaps you could rename the branch hmac to something less
exciting?
Dave, please be aware that the HMAC code is not quite finished yet. Once
we got a
> +rc = setsockopt(s, SOL_SOCKET, SO_MAX_PACING_RATE, &rate, sizeof(rate));
It's only effective on TCP sockets, and only when using the FQ scheduler.
-- Juliusz
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists
>> do loop-free routing.
> Hah. :)
> I note that babel doesn't actually do that, any more.
Pick a pair (p, id), where p is a prefix and id is a router id. Consider
the graph defined by all route table entries indexed by (p, id). Then
Babel guarantees that at any time this graph is acyclic.
Si
>>> +rc = setsockopt(s, SOL_SOCKET, SO_MAX_PACING_RATE, &rate,
>>> sizeof(rate));
>> It's only effective on TCP sockets, and only when using the FQ scheduler.
> I am under the impression that since linux 4.12 it works on udp, and I
> forget when it started working outside the fq scheduler...
No router-ID and next-hop before first Update?
>>> The updates are retractions, so those are not needed...
>> You're right. Babeld always sends a router-id, even for a retraction, so
>> the code that parses retractions in babeld might be too strict.
I can confirm it's babeld not being comp
>> Yeah, we should just include an implementation of SHA-256 in the code.
> There's also the option...
Given that the main selling point of HMAC vs. DTLS is that it has no
dependencies, it wouldn't be particularly wise to make the reference
implementation depend on a Linux-specific library.
Of c
> At the moment I am struggling babeld's notion of active interfaces
Yeah, I've struggled a lot myself. Any help with this part of the code
would be appreciated.
> Interfaces are not recognized as up, while they actually are.
> Interestingly on the interfaces itself I cannot spot a difference of
> 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:
> 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?
___
Babel-users mailing list
Babel-users@
> 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.
HMAC only protects the control traffic, not the data traffic. I'm not
convinced that performance is particularly critical
> 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".
Is there any evidence that there are devices that can reasonably run Babel
and that are too weak to use SHA256 for protecting cont
>> 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
>> (1) leave the document as it is;
>> (2) add a mention that implementation of Blake2S is RECOMMENDED (SHOULD);
>> (3) add a mention that implementation of Blake2B is RECOMMENDED;
>> (4) add a mention that implementation of both 2B and 2S is RECOMMENDED.
> I'm in favour of (2).
Where is Blake2S-
1 - 100 of 340 matches
Mail list logo
