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] HMAC Key rotation key format (was ripemd)
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. > > 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. Also the present babeld cannot rewrite it's entire config file (so far as I know). I think bird can... but I don't trust it. As for the key format, I wanted a way to test keys and key rollover in the existing daemons to verify this bit would work, and also measure the cpu overhead and failure modes, like those I describe below. > 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"? 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. The case where you want to immediately remove a key is in the event of a security breach. I tried to use the example of dnssec as one way key rotation (on admittedly a much bigger scale) that got done right, but the new keys were distributed a good year beforehand. https://kb.isc.org/docs/aa-00822 ... also "old and new key are sent" should be "old & new keys are used for signing". ... > > -Toke -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
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] rather than ripemd160...
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. Barbara > Dave Taht writes: > > > https://tools.ietf.org/html/rfc7693 is informational. Is that good > enough? > > That's what I'm not sure about; it's neither standards track nor backed by a > working group. So someone with more knowledge of IETF process than me > needs to weigh in here :) > -Toke > > ___ > babel mailing list > ba...@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_mailman_listinfo_babel=DwICAg=LFYZ- > o9_HUMeMTSQicvjIg=LoGzhC-8sc8SY8Tq4vrfog=- > 6LF6X6DzeRccquqfCJFAeSx31uwzB0oM82nApUzuPo=1QakSDy0dO0qZVEb > YiyJb6tj_NKEToWqiVanTi-rv6k= ___ 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...]
> 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 here. -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
[Babel-users] HMAC Key rotation key format (was ripemd)
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, I worry about that part. What we settled on for dnsmasq-dnssec was to write the current time to flash every day (or few hours), boot up without dnssec enabled long enough to get an ntp server... and rely on key rollover taking hours or days to *usually* get a correct result. RTCs with batteries are usually not included. that's still fragile (imagine a power failure lasting days, or a box being down for several days for repair. It happens). In the case of routing... if you don't have the correct time... and you can't get a route so you can get the correct time from ntp... then what? Do we make GPSes MTI also? 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. You would merely declare a key name in the main conf for bird or babel, and reference it in a separate file with a format like this: KEY START_DATE END_DATE TYPE VALUE name\wrfc3339\wrfc3339\wsha256|blake2s\wvalue https://tools.ietf.org/html/rfc3339 administrators would push out this one standard format file to routers, strongly suggesting that UTC times be used universally and that key rollover should be staged over hours or days lest connectivity be lost. Other sanity checks like ensuring there is some form of persistent and correct time on routers using authentication are also needed. alternatives might include certs and other stuff that bears drinking about. -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
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
[Babel-users] HMAC and MTI [was: rather than ripemd160...]
> 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@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] [babel] rather than ripemd160...
> 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. > 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. -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
[Babel-users] rather than ripemd160...
I have been fiddling with the hmac-challenge branch and deeply unhappy at the prospect of how much cpu this may end up consuming on the cheap MIPs routers common today (which are, admittedly, rapidly being replaced by cheap ARM ones). (let's not talk about dtls) 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. 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. https://blake2.net/ - https://www.131002.net/siphash/siphash.pdf ? -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] [PATCH] Fix ifup bug in send_multicast
My followup just created a FOR_ALL_INTERFACES_UP macro which led to
even less code. :)
Elsewhere I've been dithering. The proof of concept for uthash in
resend, was quite satisfying but far too much unneeded overhead (56
bytes per entry on 64 bits!! + the malloc overhead!), so I have been
looking over khash and so forth (
https://github.com/attractivechaos/klib )
the benchmarks were impressive, but like all benchmarks, flawed -
testing an integer hash, where we need 34 bytes of "some hash"
(jenkins? spooky?), and x86 only, where I care mostly about mips, and
I care about startup time for a hash a lot- I figure reworking
those benchmarks to (say) import a BGP route table, and then try to
project how much SADR and p2p routes are used, and a real
lookup/insert ratio in a benchmark would be more useful. But I get
14MOPs/sec on the basic benchmark on my x86 box on a million
integers... lookups take 10ns
Babel has an ordered "slot" concept in it...
Elsewhere I was poking into the the evolution of the kernel's
timerwheel thing ( https://lwn.net/Articles/646950/ ) which makes the
valid point that most babel "timeouts" are really recurring events
And elsewhere, elsewhere, figured out how to switch to 64bit time.
In glibc (not musl so far as I know) the clock_getttime lookup is
incredibly fast because it just maps in the relevant kernel page and
does the work without a syscall, and dealing with a straight 64 bit
quantity would always be a win on 64 bit platforms and probably a win
even on 32 bit ones.
#if __APPLE__
#include
static mach_timebase_info_data_t timebase;
#endif
static s64
monotime(void) {
#if __APPLE__
unsigned long long abt;
abt = mach_absolute_time();
abt = abt * timebase.numer / timebase.denom;
return abt / 1000LL;
#else
struct timespec ts;
clock_gettime(CLOCK_MONOTONIC, );
return (ts.tv_sec * 100L) + (ts.tv_nsec / 1000L);
#endif
} /* monotime() */
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
[Babel-users] [PATCH] Fix ifup bug in send_multicast
Hi Dave,
we could get away with dropping the continue statement altogether and
keeping the comparison as it is. This looks a little clearer to me.
Based on you work, please find below my suggestion
Cheers
Christof
---
message.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/message.c b/message.c
index 043e4b6..e78071c 100644
--- a/message.c
+++ b/message.c
@@ -1747,8 +1747,7 @@ send_multicast_request(struct interface *ifp,
struct interface *ifp_auxn;
FOR_ALL_INTERFACES(ifp_auxn) {
if(if_up(ifp_auxn))
-continue;
-send_multicast_request(ifp_auxn, prefix, plen, src_prefix,
src_plen);
+send_multicast_request(ifp_auxn, prefix, plen, src_prefix,
src_plen);
}
return;
}
@@ -1765,10 +1764,10 @@ send_multicast_request(struct interface *ifp,
if(neigh->ifp == ifp) {
send_request(>buf, prefix, plen,
src_prefix, src_plen);
-} else {
-send_request(>buf, prefix, plen, src_prefix, src_plen);
}
}
+} else {
+send_request(>buf, prefix, plen, src_prefix, src_plen);
}
}
--
2.11.0
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
