Re: [Babel-users] About an authentication extension
>Right, I see. Are you familiar with the HMAC extension to babel >(RFC7298)? That does something different (it prevents nodes that don't >know the shared secret from participating in the network at all, but >does not restrict which prefixes each node can export). However, it may >be useful to read at least parts of it to help you formulate the >requirements for your own scheme. RFC 4593 is a good starting point. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Question about the status of RFC7298
On Fri, 14 Apr 2017 13:25:05 +0100 justin kilpatrick wrote >Hello everyone, I've been working on a implementation of Batman-adv >with asymmetric key signing/verification of overhead packets for a few >months now. I'm not much of a kernel programmer so calling it rough >would be generous. > >I stumbled upon Babel and it's proposed HMAC extension doing my early >research but I could never find a repository, I'm wondering if it was >ever implemented and if so where I could find it? Hello Justin. Yes, there is running code. The Internet-Draft that eventually became RFC 7298 was written at the same time as the code was developed, you can find it in this git repository: https://github.com/Quagga-RE/quagga-RE Specifically, the commits are listed on this wiki page (rounds 5 and 6): https://github.com/Quagga-RE/quagga-RE/wiki/hashes As far as software licences go, this was a GPL contribution to a GPL software if that helps. I don't remember when I ran this code last time, unfortunately. When it was developed in 2012-2014, it was working fine. If you want to debug it on wire, tcpdump can print the TLVs from RFC 7298. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] [babel] SEMTOR mesh security mechanism
On Mon, 27 Jun 2016 14:53:54 +0100 Denis Ovsienko wrote >Hello all. > >Regarding the paper titled "Securely-Entrusted Multi-Topology Routing for >Community Networks" by Axel Neumann (CC'd) et al., I failed to find which of >the mailing lists the PDF link was posted to originally (and by whom), but now >I have looked through my hard copy of the paper and would like to note a >couple things of interest. > Found the link to the PDF: http://bmx6.net/news/22 Originally suggested by Dave: https://www.ietf.org/mail-archive/web/babel/current/msg00312.html >My current understanding of SEMTOR mechanism is that it uses an explicit >pre-agreed list of node IDs that belong to a trusted sub-graph. This list >would then be provisioned into each node, which would then filter non-trusted >nodes out when routing a specific set of network prefixes of concern. > >I have thought about it and it seems to me as the size of the trusted graph >grows, the total combined size of the deployed configuration will grow faster >(n*n). This makes it much more difficult to add the 100th node to a 99-node >graph than it is to add 10th node to 9-node graph. Also as far as I understand >it, the pre-agreed list of the trusted nodes cannot be amended online without >losing the association with the peer nodes because the set is represented by >the hash value of its contents and as soon as one has changed it in one place, >the old [different] hash will be filtered out. In other words, compared to a >pre-shared key method I see operational disadvantages and don't see a gain. If >anyone can point me in a better direction to understand, that would be nice. > Well, obvious things sometimes take time to be understood. In SEMTOR the advantage is each trusted sub-graph only protects its own prefixes of interest. After some thinking this interesting property does not seem to be exclusive to SEMTOR, however. In particular, the RFC7298 authentication mechanism could pass to the main protocol instance the details of successful check together with each accepted Babel packet. Then the main protocol instance could keep a note of which neighbours have successfully worked which security associations and make this information available to the route filtering layer, which then would provide the operator with means to shape the trusted sub-graph using the terms similar to SEMTOR: * accept prefix P1 or longer if worked SA 123 * accept prefix P2 or longer if worked SA 123 * reject prefix P1 or longer * reject prefix P2 or longer The description is not technically accurate but the idea should be clear. I am not sure how much practically useful it can be, but anyway. >Another thing, as the paper explains, is the same old link spoofing attack and >the same attacks things a rogue node can do on the transit payload. For this >SEMTOR doesn't itself claim to be a solution and doesn't refer to some other >ultimate solution but does include a discussion of possible detection by means >of monitoring. So the good news is problem statement is consistently >understood by different people. That said, the solution is still unknown. I >would be glad to hear if anyone has to add to this. > -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
[Babel-users] SEMTOR mesh security mechanism
Hello all. Regarding the paper titled "Securely-Entrusted Multi-Topology Routing for Community Networks" by Axel Neumann (CC'd) et al., I failed to find which of the mailing lists the PDF link was posted to originally (and by whom), but now I have looked through my hard copy of the paper and would like to note a couple things of interest. My current understanding of SEMTOR mechanism is that it uses an explicit pre-agreed list of node IDs that belong to a trusted sub-graph. This list would then be provisioned into each node, which would then filter non-trusted nodes out when routing a specific set of network prefixes of concern. I have thought about it and it seems to me as the size of the trusted graph grows, the total combined size of the deployed configuration will grow faster (n*n). This makes it much more difficult to add the 100th node to a 99-node graph than it is to add 10th node to 9-node graph. Also as far as I understand it, the pre-agreed list of the trusted nodes cannot be amended online without losing the association with the peer nodes because the set is represented by the hash value of its contents and as soon as one has changed it in one place, the old [different] hash will be filtered out. In other words, compared to a pre-shared key method I see operational disadvantages and don't see a gain. If anyone can point me in a better direction to understand, that would be nice. Another thing, as the paper explains, is the same old link spoofing attack and the same attacks things a rogue node can do on the transit payload. For this SEMTOR doesn't itself claim to be a solution and doesn't refer to some other ultimate solution but does include a discussion of possible detection by means of monitoring. So the good news is problem statement is consistently understood by different people. That said, the solution is still unknown. I would be glad to hear if anyone has to add to this. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] WWW Status Page and node name
[...] Hm, OLSR use plugins to deliver this information. For exmaple plugin 'nameserice' https://github.com/servalproject/olsr/blob/master/lib/nameservice/README_NAMESERVICE where we have all information about Node name, lat lon position etc which very useful to show nodes on the maps etc.. Every node have stored in separate files this information /var/run/hosts_oslrd where we have: [...] A simple way to prototype this would be to have on each babel speaker a cron job that would poll a network management server with an HTTP request to register/refresh the facts about itself. This of course means that the server would know only about the speakers that managed to join the same part of the network as the server. But on the other hand you would be able to spend more time on the network map software instead of fusing a discovery protocol and a routing protocol together. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] WWW Status Page and node name
On Wed, 10 Jun 2015 06:16:19 +0100 Waldek wrote I have looking on WWW router status page http://babelweb.wifi.pps.univ-paris-diderot.fr:8080/ Look very nice but I have question. The status generally contains a list of ip addresses and it is useful for people such as administrators. Most of users will when in the list besides IP addresses are the names of nodes. The router id to name resolution is easy to do on the babelweb server side. For this you would need to rename static/js/site-local.js.sample to static/js/site-local.js and make simple changes. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Bebel for hamradio frequency
On Tue, 09 Jun 2015 06:10:52 +0100 wrote Hi, We have hamradio Mesh network (it is 44/8 network) in different country. Local network base on olsrd but I would like try use and maybe recommend to change to use BABEL. Hamradio licence operators have bandplan where we can use to communicate WIFI between 2300 - 2400 Mhz with channel width 5/10 Mhz. We have use Ubiquiti / TP-Link, Mikrotik hardware which use Atheros radio chip. Atheros radio chip allow working on hamradio bandplan. We have modified OpenWRT compat-wireless ATH drivers to use OpenWRT on frequency below channel 1 (below 2400 Mhz). The channel below 1 hvae numbering 0, -1,-2 -3 [...] Hello. There may be other issues here, but the one that is easiest to see is that babeld doesn't expect the channel number reported by the kernel to be 0 or -1 (255). It would be better not to use them in the modified kernel. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
[Babel-users] Babel authentication is now RFC7298
Greetings, list. The specification that used to be draft-ovsienko-babel-hmac-authentication is now RFC7298. Besides the specification there is also a reference implementation (see -09 revision of the I-D, Section 8), both of which I am glad to contribute to Babel protocol development and Free Software. I tried to make it as accurate as possible, but no things are perfect, thus comments and suggestions are welcome. I would like to thank once again Juliusz, Matthieu and Gabriel for their reviews and patience. It was a long way and I wouldn't be able to make it alone. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] TLV and sub-TLV space: allocation policy
| +---+-+--+ | 0 | Pad1| work in progress | | 1 | PadN| work in progress | | 2 | Diversity | work in progress | | 3 | Timestamp | work in progress | | 4-255 | Unassigned | | +---+-+--+ - -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] TLV and sub-TLV space: allocation policy
I'm open to discussion, but I'm planning 0-127: Specification Required 128-144: Experimental Use 145-254: Specification Required 255: Reserved The idea about the Experimental range is that it should be easy to decode by sight in a hexdump. Hence the choice of values. It would also be possible to delegate experimental range detection to protocol analyzers as soon as the registry has been settled. It could be printed like this: Experimental-0xNN, Length MM (that's similar to TCP option codes printing in tcpdump) -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Babel todo list [was: RTT-based metric merged]
20.05.2014, 16:56, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr: Now that the Timestamp TLV encoding is stable it may be a good time to finish the tcpdump decoder for it: https://github.com/the-tcpdump-group/tcpdump/pull/371 Yeah. Here's my current todo list: 1. publish extension draft as RFC; 2a. publish RTT draft (as draft); 2b. tcpdump for RTT; 2c. merge RTT into Quagga-RE; 3a. merge source-specific; 3b. write source-specific draft; 3c. add source-specific to tcpdump. The above are the things for which the plan is clear. There are to issues that are less clear right now. I. Source-specific in Quagga-RE? Olden Fabre will be working on source-specific routing in Quagga this summer, if he's successful merging babels should be trivial. II. Merge Denis' MAC-based authentication into babeld, or make an independent implementation? III. Change the local interface to allow run-time reconfiguration? The nexedi people are clamouring for a way to gracefully shut down a tunnel. (I'm trying to tell them that they're doing it wrong -- they should be downing the interface, which would do the right thing automatically -- but that's apparently inconve- nient for them.) -- Juliusz There seems to be sense in doing tcpdump bits first as that not just requires less new code but adds some cross-checking of the encoding. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] FYI: ahcpd packaging issue on Fedora
28.11.2013, 14:29, Denis Ovsienko infrastat...@yandex.ru: https://bugzilla.redhat.com/show_bug.cgi?id=1035710 This bug is now worked on. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Delay-based routing
Baptiste Jonglez, Matthieu Boutier and Juliusz Chroboczek. A delay-based routing metric. Submitted for publication. 2014. Is this revision different from that posted a few months ago? -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
[Babel-users] FYI: a Babel kit on eBay
http://www.ebay.com/itm/Wifi-Mesh-Network-Kit-OpenWRT-Babeld-/141127938988?pt=UK_Computing_Other_Computing_Networkinghash=item20dbe173ac -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
[Babel-users] FYI: ahcpd packaging issue on Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=1035710 -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
[Babel-users] AHCP decoder
List, the current master branch of tcpdump now supports decoding of AHCP. It produces varying level of details based to the number of -v options (0, 1 or 2). Let me know if you find any issues in it. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Implementing Babel on Bird
2/ Since Babel can use IPv4 to communicate between neighbours (see Section 4. of RFC 6126), the IPv4 implementation could use that. However, it wouldn't be interoperable with all known Babel implementations (babeld and Quagga). RFC6126 defines that IPv6 and IPv4 are both eligible for Babel packets exchange (not to be confused with nexthops). Existing implementations prove the former and the new implementation could prove the latter. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
[Babel-users] Babel authentication I-D version 05
List, the next (05) revision of the Babel authentication I-D is available at: http://tools.ietf.org/html/draft-ovsienko-babel-hmac-authentication-05 The changes against revision 04 are very small, because the document is very close to be finished. Anybody who is interested in the topic should review now. Thank you. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Source-specific routing in babeld
05.09.2013, 19:16, Matthieu Boutier bout...@pps.univ-paris-diderot.fr: Dear all, Here is a small demo of source-specific routing in babeld in a multihomed IPv6 environment: http://www.pps.univ-paris-diderot.fr/~boutier/source-specific-routing.html This page will be updated with our experiments with MPTCP. Currently, it seems to work without any routing configuration, making the configure routing page [1] obsolete for you, babeld users! ;-) Does this extension drive the source-specific tables in kernel? If so, MPTCP and SSR were created for each other. BTW, there is MPTCP support in tcpdump (master branch) by Gregory Detal. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] RTT-aware branch of Babel
There is indeed a tcpdump decoder for Babel (thanks to Pilot), but it does not yet know about this extension. I'll probably implement it at some point. The initial revision of of that decoder is attributed to Juliusz Chroboczek and Grégoire Henry. I only did some updates to it. Adding the support for Timestamp sub-TLV would be worth an additional case block in subtlvs_print() function in print-babel.c. It would also help to add a capture file for a test case (make check) for the sub-TLV. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Babel extension mechanism
I hope to do something with this (hopefully an experimental RFC), so please take the time to review it. There's one point to be articulated in the spec. The Pad1 TLV isn't a regular TLV, i.e. it has no length. Althought it is OK in the base specification (because the parser is aware of the exception), any additional TLV types introduced by extensions MUST contain the length field, even if it is always 0. The same applies to sub-TLVs. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Babel extension mechanism
I hope to do something with this (hopefully an experimental RFC), so please take the time to review it. I would also recommend RFC6709 (Design Considerations for Protocol Extensions) as an informative reference. It is very much relevant for the case and makes the right mind set after reading. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Babel extension mechanism
I hope to do something with this (hopefully an experimental RFC), so please take the time to review it. Hello. Suggested diff against revision 00 is below. A few additional points: * Section 2.3.1 and its subsections would make a good top-level section of its own (3?). This way Section 2 would be focused on one topic consuming less of a reader's stack. * The passages about the Flags field would be much cleaner with a small bitmap. * Uncoordinated use of the unassigned 6 bits is asking for trouble when multiple extensions are in place, unaware of each other. It should be either a registry of sorts, or a big warning, or a statement that Flags are not for future extensions at all. --- draft-chroboczek-babel-extension-mechanism-00.xml.orig 2013-07-02 01:14:34.701697666 +0400 +++ draft-chroboczek-babel-extension-mechanism-00.xml 2013-07-02 01:21:05.024227636 +0400 @@ -7,6 +7,7 @@ ?rfc sortrefs=yes ? ?rfc compact=no ? rfc category=exp docName=draft-chroboczek-babel-extension-mechanism-00 + updates=6126 ipr=trust200902 front title abbrev=Babel Extension MechanismExtension Mechanism for the Babel Routing Protocol/title @@ -27,7 +28,7 @@ date day=30 month=June year=2013/ abstracttThis document defines the encoding of extensions to the -Babel routing protocol xref target=BABEL/./t +Babel routing protocol, updating, but not superceding RFC 6126./t /abstract /front @@ -64,7 +65,7 @@ arise./t tIn the rest of this document, we call base protocol the protocol -defined in RFC 6126, and extended protocol any extension of the +defined in xref target=BABEL /, and extended protocol any extension of the Babel protocol that follows the rules set out in this document./t /section @@ -94,7 +95,7 @@ protocol, as well as by other extended implementations of the Babel protocol, as long as the TLV types do not collide./t -tAll new TLVs MUST have the format defined in RFC 6126, Section 4.3. +tAll new TLVs MUST have the format defined in xref target=BABEL /, Section 4.3. Additionally, they SHOULD be self-terminating, in the sense defined in the next section, and any data found after the main data section of the TLV SHOULD be treated as a series of sub-TLVs./t @@ -141,8 +142,8 @@ tExcept for Pad1 (see below), a Sub-TLV has exactly the same structure as a Babel TLV:/t figureartwork![CDATA[ -0 1 2 3 -0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |Length | Body... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- @@ -167,8 +168,7 @@ section title=Pad1 figureartwork![CDATA[ -0 -0 1 2 3 4 5 6 7 + 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Type = 0| +-+-+-+-+-+-+-+-+ @@ -186,8 +186,8 @@ section title=PadN figureartwork![CDATA[ -0 1 2 3 -0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type = 1 |Length | MBZ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- @@ -216,7 +216,7 @@ /section -section title=The Flags field +section title=The Flags Field of the Update TLV tThe Flags field is an eight-bit field in the Update TLV. Bits with values 80 and 40 hexadecimal are defined in the base protocol, and -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Babel for use in a dense disconnected mesh network
Are there any obvious settings that are required for babel to work in dense mesh networks? Would increasing the hello interval reduce the load on the network (though babel already appears to have a relatively low overhead). As it was noted, the issue is likely to be rooted not in babeld, but rather in lower-level wireless. One way of troubleshooting this would be replacing the Pis with an equal amount of any other PCs and confirming that the mesh builds up OK using the same USB adapters. If it goes well, the replacement may be the straightforward solution, starting from Pi-sized alternatives and going up to cheap nettops with built-in wireless, Atom CPU and no need for cross-compiling. But if it doesn't, the problem is likely in the adapters themselves or the band they are trying to use. My personal observation is that the old 802.11b is slower, yet notably more robust than the newer g/n bands. Consider borrowing a pack of different brand adapters and trying them. Eventually you may figure out specific component that fails this network. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
[Babel-users] on Babel protocol decoding in tcpdump
Hello, list. The three latest commits in my copy of tcpdump are Babel-focused. Two commits address Pad1 TLV iteration issue and one commit implements sub-TLV decoding, which so far is only used to carry channel information for the diversity routing feature. Somebody please review/test this before I offer these changes for tcpdump upstream: https://github.com/infrastation/tcpdump -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
[Babel-users] AE 3 spec versus implementation
During the work on the decoder I spotted another potential issue. RFC6126
defines address encoding 3 as follows:
o AE 3: link-local IPv6 address. The value is 8 octets long, a
prefix of fe80::/64 is implied.
The actual code in network_prefix() looks different, in that less than 8 octets
of encoding would suffice for prefixes /120 and shorter (as with AE 1 and AE 2):
case 3:
if(pb 8 len pb - 8) return -1;
prefix[0] = 0xfe;
prefix[1] = 0x80;
if(pb 8) {
memcpy(prefix + 8, p, pb - 8);
consumed = pb - 8;
}
break;
This is not tcpdump-specific, the babeld code implements it the same way.
Somebody please proofread these findings.
--
Denis Ovsienko
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] [PATCH] Ignore IPv6 routing cache on linux
+ /* Ignore cached routes, advertised by some kernels (linux 3.x). */ + if(rtm-rtm_flags RTM_F_CLONED) + return 0; + This concurs with respective code in https://github.com/Quagga-RE/quagga-RE/blob/RE-testing-0.99/zebra/rt_netlink.c -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Buggy routes exported by babeld
23.04.2013, 11:41, Baptiste Jonglez baptiste.jong...@ens-lyon.fr: On Mon, Apr 22, 2013 at 10:29:22PM +0200, Gioacchino Mazzurco wrote: I can reproduce a similar but not identical bug because my filter are defferent gioacchino@G10h4ckLab ~ $ ip -6 route show ... ... 2001:470:c8f7:ee:ee:15:6d7b:4d21 via fe80::7825:ddff:fe9d:4643 dev isole proto 42 metric 1024 2001:470:c8f7:ee:ee:15:6d7d:9e9 via fe80::7825:ddff:fe9d:4643 dev isole proto 42 metric 1024 2001:470:c8f7:ee:7058:edab:5584:25b8 via fe80::7825:ddff:fe9d:4643 dev isole proto 42 metric 1024 2001:470:c8f7:ee:f4e4:47dd:ac3a:f52d via fe80::7825:ddff:fe9d:4643 dev isole proto 42 metric 1024 ... ... those 3 /128 route shouldn't appear ( they aren't babel node but a babel node can see them ( but doesn't have a specifical 128 route for them ) ) All right, it looks similar enough. The /128 routes I was talking about are the routes that babeld reportedly exports. Other babel nodes simply grab these exported buggy routes and install them in their routing table (as in your case). My experience is as follows. A Linux (kernel 3.6.11-4.fc16.x86_64) PC with a single wireless interface runs both IPv4 and IPv6. It has a number of IPv6 neighbors visible with ip -6 ne, which don't produce any extra IPv6 routes visible with ip -6 ro. Pinging external IPv6 hosts, however, produces a few extra IPv6 routes like below: 2001:67c:2e8:22::c100:68b via fe80::215:17ff:fe6a:f1b0 dev wlan1 metric 0 cache 2a00:1450:4010:c03::64 via fe80::215:17ff:fe6a:f1b0 dev wlan1 metric 0 cache 2a00:1450:4010:c03::71 via fe80::215:17ff:fe6a:f1b0 dev wlan1 metric 0 cache 2a00:1450:4010:c04::8b via fe80::215:17ff:fe6a:f1b0 dev wlan1 metric 0 cache (Note the cache keyword that is missing from the case above, but proto 42 is present.) Running the standalone babeld (current git master) as ./babeld wlan1 on the PC does not translate these cached routes into the Babel routing domain (there's tcpdump running to examine the contents of the PDUs). The only /128 route advertised is the address of the wlan1 interface itself. Running babeld as ./babeld -C redistribute ip ::/0 metric 256 -d 2 wlan1 doesn't change anything either, except that the default route (::/0) is advertised. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
[Babel-users] Babel authentication I-D version 03
Hello list. The next (03) revision of the Babel authentication Internet-Draft is now available at: http://tools.ietf.org/html/draft-ovsienko-babel-hmac-authentication-03 The changes since revision 02 are as follows: * Numerous fixes to common use of English (thanks to proofreaders!). * Section 2.1 now mentions specific editions of hash algorithms where necessary. * Section 4.3 now contains an additional paragraph with some thinking behind padding method. * Appendix A is now called Figures and Tables and contains three new tables replacing two figures. * Appendix B is a new Test Vectors section. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Babeld Team ID ( AS number like )
This work fine if there is only a gateway that make the communication between olsrd and babeld network but if we add other gateways they will learn the subnet that babeld learned from first olsrd as HNA and this is distruptive for the olsrd network Hello. Could you help mapping this problem? 1. How much do the set of OLSR prefixes and the set and Babel prefixes intersect? 2. Do routers redistribute from OLSR to Babel or vice versa or both? 3. Do you intend blocking all prefixes originated by specific Babel speakers or rather just some specific prefixes? -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
[Babel-users] Babel authentication I-D version 02
Hello, list. There is the next (02) revision of Babel HMAC Cryptographic Authentication available at http://tools.ietf.org/html/draft-ovsienko-babel-hmac-authentication-02 It addresses the issues raised by Gabriel Kerneis and also a few issues discovered by myself. Below is the summary of changes between revisions 01 and 02: * remove some excess commas * clarify the meaning of at runtime * minor refinements in hash algorithms requirements * refine first paragraphs concerning padding constant * articulate XOR as bitwise function * fix some XML and referencing item numbers * switch from ordered lists to finite sequences for clarity * articulate CSA.LocalKeyID being of unspecified bit length * use packet body where appropriate (mind the packet trailer) * move TLV namespace table to IANA section (least surprise) * distinguish between speaker and protocol instance * clarify TS/PC update methods disclosure * improve some sentences in ESA deriving section * fix the order or populate/deduplicate steps (ibid) * clarify ordinals (ibid) * clarify deduplication (ibid) * refine Body length update sentence * refine refuse condition in Rx procedure * add references to the list of event counters * improve section 6.4 * add temporary Implementation Status section * update Acknowledgements section -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Babel authentication I-D version 01
3. Remove all duplicate keys from the copy. It is essential that you explain how duplicates are removed, since it changes the list of ESAs! Consider the following case: K1,K2,K3,K1. If you remove the first occurrence of K1, then K2 and K3 will be selected (assuming the value of MaxDigests is 2), otherwise K1 and K2. When I was refining that paragraph, I discovered another issue: steps 3 (remove all duplicate keys) and 4 (populate the output list of ESAs) should go in the opposite order, otherwise the output is messed up. The next revision will have it fixed. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
[Babel-users] Babel authentication I-D version 01
Hello, list. This is the next version of the Babel authentication spec: http://tools.ietf.org/html/draft-ovsienko-babel-hmac-authentication-01 The changes since version 00 are as follows: * change Section 2.1 to require two mandatory-to-implement hash algorithms * provide more information on CSA implementation specifics in Section 6.5 * clarify ESA being a requirement in Section 3.9 * move some FIGURE elements out of T elements * reword a few sentences to clarify meaning * refine TLV namespace table * refine some section headers * fix punctuation/spelling issues * refine two figures -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
[Babel-users] time for feedback (Babel authentication goes I-D)
Hello, list. As some of you remember, in late May I suggested a sketch of a Babel authentication mechanism, intending to develop it into a more formal specification later. A prototype implementation became available in early June, the next step was writing a proper specification. That's what I've been busy doing for last two months, and today I would like to share the result, which is the very first (00) version of the Babel authentication Internet-Draft (I-D): http://tools.ietf.org/html/draft-ovsienko-babel-hmac-authentication-00 The document is just 40 pages long. Just to remind, the draft relates to the publication series, not necessary to the document quality. This I-D hopefully incorporates all the background, technical information and justification necessary to understand, implement and use this authentication mechanism. I am basically asking to show where I am wrong in this assumption. I need your feedback and reviews to understand how much finished it is. Is there anything that is written really bad? Anything that should be added or removed? Feedback of first-time readers is even more welcome. If you understand Babel but not the authentication, that's not a problem, the I-D is self-contained. It's not? Let everyone know! Please send your comments to the mailing list. Cheers. Special notes to Juliusz. 1. Section 4.1 was written to address the encoding concerns, tell me if it does this job. May be some of the arguments didn't make it from my head to the paper, I will fix it then. 2. The current document works off the current no IANA registry situation. If you prefer creating an IANA registry for Babel TLV types, let me know and I will update the document respectively. I can post a draft registry description, if you want. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] switching cerowrt to quagga-babeld issues
I've got no required expertise to make such change safe for all, but starting
with a Cero-only patch seems possible.
Hello, all.
Let me make an update on the problem and the solution. NetworkManager does not
belong to the problem space of the current IPv6 default route issue in CeroWrt
just because it is not packaged in CeroWrt. NetworkManager sample data is
provided to explain the machinery of the kernel/zebra route delivery issue in
different environments. So far I would prefer to get this issue resolved in
CeroWrt and focus on the next show stopper.
There is a kernel patch attached, which should fix the issue with IPv6 default
route delivery in CeroWrt (it does fix it on my PC). Offering it for generic
kernels is a different story, which shouldn't start until, say, 1-2 weeks of
safe test-driving.
Cheers.
--
Denis Ovsienko
From 1d969903c6221980360f76abb5e063300e5cf3bb Mon Sep 17 00:00:00 2001
From: Denis Ovsienko infrastat...@yandex.ru
Date: Fri, 6 Jul 2012 18:08:18 +0400
Subject: [PATCH] fix RTPROT_RA markup of some RA routes in netlink
There are three types of IPv6 routes originated by kernel ND RA code:
* Default routes standing for RA packets with non-zero router lifetime.
* Connected prefix routes standing for a Prefix Information (3) RA TLV.
* Any prefix routes standing for a Route Information (24) RA TLV.
All three types are internally stored using RTPROT_KERNEL or RTPROT_BOOT
protocol code and RTF_ADDRCONF route flag (this is the only purpose for
this flag). The flag isn't directly available in netlink socket space.
Given the need to tell route origin in userspace, for routes with
nexthops in the first turn, rt6_fill_node() tries to distinguish default
router case sending the netlink route structure with RTPROT_RA (this is
respectively the only use case for this protocol code), but to no
success due to a test condition taken wrong. All three types are
delivered with RTPROT_KERNEL.
This change is modelled after the original mailing list posting by Jeff
Haran. It fixes the test condition for the default router case and
extends it for the Route Information case.
---
net/ipv6/route.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 999a982..2f070d6 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2441,9 +2441,15 @@ static int rt6_fill_node(struct net *net,
if (rt-rt6i_flags RTF_DYNAMIC)
rtm-rtm_protocol = RTPROT_REDIRECT;
else if (rt-rt6i_flags RTF_ADDRCONF)
- rtm-rtm_protocol = RTPROT_KERNEL;
- else if (rt-rt6i_flags RTF_DEFAULT)
- rtm-rtm_protocol = RTPROT_RA;
+ {
+ /* any ND RA route, most probably originated by kernel */
+ if (rt-rt6i_flags RTF_DEFAULT) /* default router */
+ rtm-rtm_protocol = RTPROT_RA;
+ else if (rt-rt6i_flags RTF_ROUTEINFO) /* any route w/nexthop
*/
+ rtm-rtm_protocol = RTPROT_RA;
+ else /* RTF_PREFIX_RT, interface connected prefix route */
+ rtm-rtm_protocol = RTPROT_KERNEL;
+ }
if (rt-rt6i_flags RTF_CACHE)
rtm-rtm_flags |= RTM_F_CLONED;
--
1.7.7.6
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] switching cerowrt to quagga-babeld issues
How goeth ipv6? IPv6 default route is lost somewhere on the way from kernel to zebra process (and not promoted by babeld respectively). I'll try looking at it tomorrow and also pulling together some thoughts on the rest of your message. This seems to be caused by a difference in kernel behaviour between current CeroWrt and, for example, my notebook (3.3.7-1.fc16.x86_64). Plugged into the same network one after another, they end up with different default routes in kernel: (cero) default via fe80::230:48ff:fed4:63e4 dev ge00 proto kernel metric 1024 expires 1797sec (notebook) default via fe80::230:48ff:fed4:63e4 dev em1 proto static metric 1 default via fe80::230:48ff:fed4:63e4 dev em1 proto kernel metric 1024 expires 1786sec Note the kernel/static route protocol. The established practice of zebra process used to be ignoring any RTPROT_KERNEL netlink messages. It is not clear if RTPROT_BOOT/RTPROT_RA should be used for a RA-originated route, but RTPROT_STATIC does the job in the latter case anyway and the default route reaches zebra. In the former case the default route is effectively isolated from zebra. Does anybody know where this difference comes from? -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] [Cerowrt-devel] switching cerowrt to quagga-babeld issues
Does anybody know where this difference comes from? The difference comes from NetworkManager. Its efforts in reproducing high-metric RTPROT_KERNEL routes with low-metric RTPROT_STATIC ones are effectively hiding the kernel issue outside of CeroWrt runtime. Would it be better to add a watchdog shell script, which does the same, or patch the kernel? -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
[Babel-users] switching cerowrt to quagga-babeld issues
03.07.2012, 17:18, Dave Taht dave.t...@gmail.com: On Tue, Jul 3, 2012 at 8:35 AM, Denis Ovsienko infrastat...@yandex.ru wrote: Does anybody know where this difference comes from? The difference comes from NetworkManager. Its efforts in reproducing high-metric RTPROT_KERNEL routes with low-metric RTPROT_STATIC ones are effectively hiding the kernel issue outside of CeroWrt runtime. Would it be better to add a watchdog shell script, which does the same, or patch the kernel? I would *much rather* patch the kernel than have a watchdog. However I don't quite understand the redistribution issue vs a vs ipv6 here. If I have a redistribute kernel on for ipv4, it does propagate the default route. The matter is, IPv4 default route comes flagged as either static or boot (both cases are displayed without proto column by /sbin/ip route). This is properly picked up. IPv6 default route comes flagged as kernel.. (I note that I dislike network manager too as it tries too hard to work around bugs in the base OS and my own view of the world is far more meshy) I'll gladly try pushing a patch up to the mainline if that's what is needed. I've got no required expertise to make such change safe for all, but starting with a Cero-only patch seems possible. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] switching cerowrt to quagga-babeld issues
2) I'd used the rxcost parameter to babel to give 5.x ghz network a tiny preference in case of tie with 2.4 ghz. Don't know how to do that in quagga-babel Hello, all. The rxcost knob doesn't currently exist in quagga-babeld, although the cost field is defined and used. The current code, function babel_set_wired_internal(), sets cost to 96 for wired links and to 256 for wireless. I could not come up with anything better than this syntax: ! interface eth0 ! all reset to default setting, invisible in running-config babel rxcost auto no babel rxcost no babel rxcost 100 ! custom value, visible in running-config babel rxcost 100 ! implicitly change rxcost in auto mode babel wired babel wireless ! This can be implemented relatively quickly. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] switching cerowrt to quagga-babeld issues
01.07.2012, 00:44, Juliusz Chroboczek j...@pps.jussieu.fr: babel rxcost auto no babel rxcost no babel rxcost 100 ! custom value, visible in running-config babel rxcost 100 ! implicitly change rxcost in auto mode babel wired babel wireless No objection, but I really think that route-maps are the right solution for what Dave is suggesting. Let's consider the options. A route-map way could look like: ! router babel redistribute connected route-map mymap-out receive route-map mymap-in ! route-map mymap-in deny 10 match ip prefix-list Alice_IPv4 route-map mymap-in deny 15 match ipv6 prefix-list Alice_IPv6 ! route-map mymap-in permit 20 match interface gw11 set metric +1 ! route-map mymap-out permit 10 match ip prefix-list mynets_IPv4 set metric +1 route-map mymap-out permit 15 match ipv6 prefix-list mynets_IPv6 set metric +1 ! It would be interesting to hear from the users of the original babeld filtering language, if any other match/set clauses are worth implementing in the first turn. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] RIP and onlink flag [was: Babel for Quagga status]
19.06.2012, 13:36, Juliusz Chroboczek j...@pps.jussieu.fr: Denis, why is this not used also by the RIP code? This would make it possible to use Linux-style unnumbered interfaces with RIP, and would make RIP behave the same as RIPng. Well, there may be multiple places where RIP nexthops are matched against connected prefixes. Perhaps, it's better to convert these checks conditional rather than drop them, because coupling an open-minded RIP router with a traditional one will likely create one-way routes. Could you please clarify? I don't think that third-party announcements are allowed in RIP. Two traditional RIP routers, one with interface 10.0.0.254/24 and another with interface 192.168.0.254/24, would either ignore each other's messages or fail installing the received routes, because the nexthop isn't on the connected network. But with only one of these routers using onlink nexthops it would succeed installing the received routes, but the other still would not, which may cause a routing problem. Onlink nexthops fall out of the RIP specification space somewhere, it seems to me. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Babel for Quagga status
Basic functionality *** For IPv6, Babel/Quagga should be just as functional as the standalone implementation. For IPv4, you need to have a prefix on your interfaces that covers all your neighbours, and the prefixes on all of your interfaces must be disjoint. This is standard practice in traditional networks, but of course not in pure meshes. You can check whether you're bitten by that by typing show ip route; if any of the Babel routes are marked as inactive, that's probably your problem. There are commits in RE-testing-0.99 addressing onlink nexthop management in zebra and babeld. The problem should be gone on Linux, could anyone confirm? -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Babel for Quagga status
19.06.2012, 00:49, Juliusz Chroboczek j...@pps.jussieu.fr: There are commits in RE-testing-0.99 addressing onlink nexthop management in zebra and babeld. The problem should be gone on Linux, could anyone confirm? Denis, why is this not used also by the RIP code? This would make it possible to use Linux-style unnumbered interfaces with RIP, and would make RIP behave the same as RIPng. Well, there may be multiple places where RIP nexthops are matched against connected prefixes. Perhaps, it's better to convert these checks conditional rather than drop them, because coupling an open-minded RIP router with a traditional one will likely create one-way routes. It would be interesting to hear from someone who researched this matter thoroughly, but I barely can help with that right now. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Babel for Quagga status
K* 0.0.0.0/0 via 134.157.168.126, eth0 Is this the only default route around? I observed a couple of glitches in default route management during the test of the new code. Deciding between multiple default routes and properly installing the winner may be an issue. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] RFC: Babel packet authentication
12.06.2012, 23:37, Juliusz Chroboczek j...@pps.jussieu.fr: We've just had a long discussion with Denis on IRC. Here's a summary. Short summary: this is very impressive work, and I'm very grateful to be able to accept that as an experimental extension to the Babel protocol (which is itself experimental). TLV types 11 and 12 are hereby assigned to this extension. Long version. I still prefer a trailer-based approach, which allows validating a packet with no knowledge of the packet's structure. However, Denis' has taken care to mitigate the flaws of a TLV-based approach (notably by having an obviously correct packet validation function run before any parsing is attempted), he is strongly in favour of a TLV-based approach, and has a lot of experience with security features in routing protocols. I yield to his superior experience. Thank you! This work would not be possible without larger works of other people, including yours. My role boils down to picking the best in one problem space and delivering into another. The design of TLV 11 (cryptographic timestamp) is excellent. I am fully confident that it can be reused by a trailer-based extension. It definitely could (technically), PC/TS is a direct development of its RFC6506 counterpart (4.1.1. Sequence Number Wrap). But for now this is left for a different solution. I am slightly less confident about TLV 12 (digest); in particular, I am not sure that it is necessary to have an explicit field for the key-id -- I'd simply make the whole body opaque. However, I don't see anything actually wrong with the current definition. This is the best current practice. An explicit Key-ID helps the receiver spend less time authenticating a packet (RFC5709 3.5. Changing OSPFv2 Security Associations, paragraph 3) and can be used to couple with a key management protocol in future. As soon as the field is always present, having it parked inside the HD TLV is convenient. I very much like the way of avoiding a pseudo-header in digest computation (by overwriting the digest with the packet's source address). This is also borrowed from RFC6506 (2.3. IPv6 Source Address Protection). The writeup needs some editing, but nothing serious. In particular, it's not clear how to deal with IPv4 source addresses (not an issue for the current implementation, which only runs over v6). Now I will work on updating the spec. There are things I need to state in plain text to make some important things implemented in the source code visible. There are points, which really matter for mesh networks. Commit f2fdcb0 (babeld: focus Rx packet structure/sizing checks) is great, I intend to pull it into standalone babeld (with Denis' permission). babel_packet_examin I'll rename -- suggestions? (I suggest babel_packet_validate.) No objections from my side. Commit 797213b (babeld: improve Rx check for fixed-size TLVs) is wrong. See RFC 6126 Section 4.3, which allows sub-TLVs to be included into any TLV. Please revert. Done. Nothing to say about commit b256107. Commit c9d6a7f is the big one. I haven't fully reviewed it yet, but here's a few things I notice. We're going to break if the interface has multiple link-local addresses. Not a big deal -- I don't think we're dealing with that edge-case in the first place. Fixing that would require a bunch of system calls for each packet, probably not worth it. There is now a comment in the code stating that this problem exists. babel_auth_got_source_address should probably fail if there's no link-local address rather than returning a non-local one. Done. Unless I'm missing something, in babel_auth_make_packet there's an obsolete comment (FIXME: write source address). Done. That's all for now. Denis, please feel free to merge your code into the trunk and document it, any further nits can be corrected there. -- Juliusz Two main commits have been pushed into RE-testing-0.99. There are minor last-time fixes incorporated, including one addressing timer thread setup. The old babelauth branch is deleted. This is the list of all relevant commits made so far: https://github.com/Quagga-RE/quagga-RE/wiki/hashes And this is an updated HTML documentation including description of new babeld commands: http://quagga-re.github.com/quagga-RE/ -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Babeld for Quagga news
3) I do get a p2p ipv6 route that works through the router, but the same does not work (or converge) on ipv4. A -R-B Where A has a /64 ipv6 address and a /27 ipv4 address gets a correct looking 'via' line for the /128 and /32 routes, but only the ipv6 makes it. 4) Now going quagga-for-babeld - quagga-for-babeld I have more luck. IPv6 routes look right, and I watched it converge a 2 hop pure ethernet route down from the 1 hop wireless route, which was the right thing... root@ida:/usr/local/etc# ip -6 route fd43:e2b3:341c::/64 dev eth1 proto kernel metric 256 expires 84045sec fd43:e2b3:341c:1::/64 via fe80::c43d:c7ff:fea3:7679 dev eth1 proto zebra metric 1024 fd43:e2b3:341c:2::/64 via fe80::c43d:c7ff:fea3:7679 dev eth1 proto zebra metric 1024 fd43:e2b3:341c:1010::2 via fe80::c43d:c7ff:fea3:7679 dev eth1 proto zebra metric 1024 The above is also on my shared wlan on another AP and initially came up on the wlan. Yea! fd43:e2b3:341c:1010::/64 via fe80::c43d:c7ff:fea3:7679 dev eth1 proto zebra metric 1024 fd43:e2b3:341c:1011::/64 via fe80::c43d:c7ff:fea3:7679 dev eth1 proto zebra metric 1024 fd43:e2b3:341c:1012::/64 via fe80::c43d:c7ff:fea3:7679 dev eth1 proto zebra metric 1024 fd43:e2b3:341c:2001::1 via fe80::c43d:c7ff:fea3:7679 dev eth1 proto zebra metric 1024 fe80::/64 dev eth1 proto kernel metric 256 fe80::/64 dev wlan0 proto kernel metric 256 default via fe80::c43d:c7ff:fea3:7679 dev eth1 proto static metric 1024 4b) Ipv4, not so much (usually a bunch more /27s than this) default via 192.168.1.1 dev wlan0 169.254.0.0/16 dev eth0 scope link metric 1000 172.30.42.0/27 dev eth1 proto kernel scope link src 172.30.42.27 metric 1 172.30.43.2 via 172.30.42.1 dev eth1 proto zebra 172.30.49.0/27 dev eth0 proto kernel scope link src 172.30.49.4 192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.111 metric 2 192.168.1.109 via 172.30.42.1 dev eth1 proto zebra CeroWrt has recent commits in QRE, which fix operation of IPv4 in quagga-babeld. Some of these issues should be gone now. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] RFC: Babel packet authentication
(Juliusz asked me to repost to babel-users. Please see the text below.) 24.05.2012, 00:10, Juliusz Chroboczek j...@pps.jussieu.fr: Hi Denis, An implementor of an authenticated Babel network is left with the following options: * Authenticate all packetes in the network (e.g. WPA). Yes. * Selectively authenticate Babel packets with IPSec policy. I don't think that can be made to work, at least not without some protocol changes. IKE doesn't work for multicast, while statically-keyed IPSec is vulnerable to replay attacks. * Implement Babel packet-level authentication using trailing data. * Implement Babel packet-level authentication using TLVs. Yes and yes. The TLV option, to my opinion, makes the most sense. I personally prefer an authentication trailer approach. Note first that the authentication trailer is variable size -- it can be anywhere between one octet and (MTU - 60) octets. So the TLV approach is no more flexible than the trailer approach. Second, note that the digest in the Hash-Digest (HD) TLV ranges over the HD TLV itself. I find that confusing, and it is difficult to implement -- you need to make an initial HD-TLV, append it to the packet, compute the digest, then walk back over the packet and fill-in all the HD TLVs. Similarly, on reception you need to walk the TLVs of a packet before you authentify it -- and then you need to walk the packet a second time in order to parse it (you don't want to be parsing an unauthenticated packet). None of these are issues with an authentication trailer (AT). You generate your packet as usual, just making sure you have enough space left for the AT. You then compute a hash of a pseudo-header and the packet, and append the AT to the packet. Similarly, on reception, you jump directly to the AT, extract the data, compute the hash, and accept or drop the packet before you ever walk the packet data itself. Third, AT code can be shared by multiple protocols, even if the have different packet structure. In particular, at first glance it would appear that RFC 6506 can be adapted to Babel with little trouble. That means that we can use a mature spec (11 IDs!) without having to develop one ourselves, or even share code between OSPFv3 and Babel. For all of these reasons, I would like to encourage you to work on adapting RFC 6506 to Babel rather than on an approach based on TLVs. No problem with having TLVs 11 and 12 for your purposes, however. -- Juliusz P.S. I might be away from the Internet from 25 May until 4 June. Hello, Juliusz. Excuse me for the delay. This work was in its most part complete by today, but my initial intention was to have an IRC briefing with you before committing it as a part of QRE. Publishing it in a separate branch took finishing a few minor stylistic issues, which I have just done. Here is the code: https://github.com/Quagga-RE/quagga-RE/commits/babelauth If you study the developments in RE-testing-0.99 of the last month, you will see a functional HMAC layer used from ripd code and a few fixes/refactorings in babeld, which make it possible to pack last two weeks of Babel authentication work into just two commits. These commits are currently based on RE-testing-0.99 branch, making it possible to merge in a fast-forward way (this is what I am looking for, TBH). These two commits implement the draft specification posted to babel-users@ with a few fine, but important corrections. I have noted these corrections to include them in the next draft of the spec, but so far the implementation should be viewed as the right source, wherever it is different from the first draft of the spec. Test-driving this implmentation should be quite simple. I have updated documentation, and the commands are very close to those you can find in ripd/ospfd. Upon enabling debug babel auth you will see a very detailed picture in the log file of what is happening. There is also a complete patch for tcpdump, which I used to see what is transmitted/received on the wire: https://github.com/infrastation/tcpdump/commits/master When you look at the TLVs, you will notice there may be multiple HD TLVs. If you want, you can try rolling over authentication key and even hash algorithm, it just works. SHA-2 family of hash functions, RIPEMD-160 and Whirlpool are ready to go. MD5 and SHA-1 are not included due to the strong current tendency of migrating off these functions. Looking forward to hear your opinion. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
[Babel-users] RFC: Babel packet authentication
from basic to UNIX TS approach is possible, but not the other way. This allows for a case, where a freshly deployed Babel router would use basic PC/TS approach until it has acquired necessary routes and completed initial network clock synchronization. Once this is done, it can be permanently reconfigured to use the UNIX approach without any interruption to Babel protocol exchange. Definitions of Security Associations An authentication key (AK) is defined as a secret data with associated ID (a 16-bit unsigned integer) and a set of lifetime attributes. Depending on the current date and time (which change), each AK may be distinguished as active or inactive according to its lifetime attributes (which do not change between configuration changes). A configured security association (CSA) is defined as an interface-specific unique combination of one particular hash algorithm (HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512) and one set of 1 or more AKs. Key IDs must be unique within the scope of one given CSA. A Babel interface may have any number of CSAs (including 0) at operator's discretion. An effective security association (ESA) is a CSA with inactive AKs excluded, as evaluated against current date and time. A valid ESA can have 0 or more AKs. Changes in packet sending = If the current outgoing interface has no CSAs, the current packet is processed without any changes to the original sending process. Otherwise, the following steps are taken. 1. A PC/TS TLV is appended to the main packet body. PC and TS values are assigned as described above. 2. For each of the interface ESAs, for each AK of the current ESA an HD TLV is appended to the main packet body. This TLV must have Length field set to L+2, Key ID field set to ID of the current AK and Digest field (L bytes long) set to source address of the current packet, zero-padded to L bytes. Generation process may be stopped, if MaxDigests is set and number of HD TLVs reaches MaxDigests value. 3. The current packet (Pout) is then copied and the copy (Pout') set aside. 4. For each of the interface ESAs, for each AK of the current ESA (in the same very order as in step 2, and respectively for each of the HD TLVs generated) a HMAC procedure is performed, using Pout' as m input and AK as Ko input, with hash digest output written to Digest field of the current HD TLV of Pout (this way, m remains constant for every HMAC round, but H and Ko may change). If HD TLVs generation process was limited due to MaxDigests threshold, this process must also be terminated at the same threshold. 5. Pout' is discarded, Pout is treated as the current packet. Since this point, no more changes are allowed to the packet, which is now ready for remaining transmission procedures. Changes in packet reception === If the current incoming interface has no CSAs, the current packet is processed without any changes to the original receiving process. Otherwise, the following steps are taken. 1. PC/TS TLV of the packet (PCr, TSr) is verified against stored PC and TS values of the Babel neighbor originating the packet (PCs, TSs). If TSr TSs, the packet is discarded and processing stops. Otherwise, if TSr TSs, processing proceeds to step 2. Otherwise, if PCr PCs, processing proceeds to step 2. Otherwise the packet is discarded and processing stops. 2. A copy (Pin') of the current packet (Pin) is made and set aside. 3. For each of the HD TLVs present in Pin' the Digest field is set to source address of the current packet and zero-padded up to length of the current HD TLV. 4. For each of the HD TLVs present in Pin all ESAs are looked up, which have hash digest length = Length field of the current TLV minus 2 and an AK with ID = Key ID field. For each of the ESA-AK pairs found a HMAC procedure is performed with m = Pin', Ko = KA and H = hash function of the current ESA. If HMAC output matches the Digest field of the current TLV, processing proceeds to step 6. 5. Apparently, none of the HD TLVs matched any of the ESAs. Pin and Pin' are discarded and processing stops. 6. PC and TS value of the current Babel neighbor are updated to the PC and TS values of the current packet PC/TS TLV (PCs := PCr; TSs := TSr). 7. Pin' is discarded, Pin is accepted for remaining receiving procedures. -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
[Babel-users] Babel on FreeBSD
Hello, list. The latest (0.99.17.8) release of Quagga-RE incorporates babeld, and FreeBSD quagga-re port seems to deliver it in a way: http://www.freebsd.org/cgi/cvsweb.cgi/ports/net/quagga-re/pkg-plist.diff?r1=1.1;r2=1.2;f=h I don't currently have the time to test it. Could someone test this port? -- Denis Ovsienko ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
