Re: [Gen-art] Genart last call review of draft-ietf-babel-applicability-06
Dear Joel, Thank you very much for your review. > Nits/editorial comments: >In section 2.2, in talking about "metric M", if I have understood properly, >I think it would be clearer if you referred to "metric value M". Thanks, noted. If that's okay with you, I'll wait for the RTGDIR review before submitting a new revision. -- Juliusz ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [babel] Genart last call review of draft-ietf-babel-rfc6126bis-10
Dear Russ, Thank you very much for your review. I agree with all of your comments save one, I'll publish a new revision taking your comments into account as soon as possible. >... A node SHOULD NOT send triggered updates >for other reasons, such as when there is a minor fluctuation in a >route's metric, when the selected next hop changes, or to propagate a >new sequence number (except to satisfy a request, as specified in >Section 3.8). > This seem backwards to me. Perhaps: >... The node MUST send triggered updates to satisfy a request, as >specified in Section 3.8; however, a node SHOULD NOT send >triggered updates for other reasons, including a minor fluctuation >in a metric for a route, the selected next hop changes, or to >propagate a new sequence number. I disagree. The requirement to send triggered updates is already present in 3.8.1.1, we should not repeat it. This section is concerned with avoiding excessive noise. > Section 4 says: >A Babel packet is sent as the body of a UDP datagram, with network- >layer hop count set to 1, destined to a well-known multicast address >or to a unicast address, over IPv4 or IPv6; in the case of IPv6, >these addresses are link-local. > It seems to me that this should be reworded as MUST statements. Agreed. > Section 4.1.2 says: >A router-id is an arbitrary 8-octet value. A router-id MUST NOT >consist of either all zeroes or all ones. > I do not think you are referring to octets with a value of one. I > think you mean that the router-id cannot be 0x or > 0x. Please reword. Agreed. Thanks again, -- Juliusz ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Babel-users] althea presentation on isp in a box at nanog 76
> I actually have mostly written RFC's for both. Please submit them as I-Ds: https://datatracker.ietf.org/submit Please make sure you agree with this: https://tools.ietf.org/html/bcp78 > The price updates are hacked onto the update tlv as we aren't running > the price extension I specified. which is why I advertise a different > protocol number for now. I do hope to upgrade to the full spec version > of the price advertisement at some point. I see. > I've been conflicted over making full path packet loss it's own TLV or > not. You can derive it from the metric field if all nodes are configured > 'the althea way' but that's very much not spec behavior. So I should > probably bite the bullet. I agree, it's better to be explicit -- it doesn't eat up a lot of bytes on the wire, and makes troubleshooting easier. > If the general protocol registry form on the IANA site is appropriate > than this shouldn't take but a few minutes. I think 45, 46, and 47 are > all available right? You need to write a specification and go through expert review (I believe that Donald Eastlake and myself are the experts right now). RFC is not required, an Internet-Draft should be enough. >> You're running Wireguard over Babel or the other way around? Any issues >> with that? > We're running Babel over WireGuard and WireGuard over Babel. The bottom > layer for authenticating packets between peers and the top for securing > user traffic as it traverses the network. Hmm... does HMAC alleviate the need for the bottom layer? https://tools.ietf.org/html/draft-ietf-babel-hmac (It's implemented, but not merged yet -- I've got two students working on making it mergeable.) > I think now we could condense this by configuring unicast peer discovery > which from what I understand is in master. No, it's not implemented yet. More exactly, the protocol bits are in there, but the configuration bits are not. It's also only designed to work with link-local addresses, I'm not sure how much work it would be to get it work over global addresses. > Oh yeah the default number of management connections is puny, I bumped > it to 128, might want to make it configurable. Ok, I'll see how much memory that would waste. > The final thing on my wishlist is just a Rust Babel implementation. It's > such a pleasure to write in, very easy to get your code to the point > where if it compiles it works. Chances are we'll make one ourselves > eventually. It should be easy enough. (I'm a Go fan myself, we'll hopefully have a debate on the subject at some point.) -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Cake] [Babel-users] althea presentation on isp in a box at nanog 76
> Interesting stuff - wireguard, fq_codel/sch_cake, babel with new > metric that allows for cryptocurrency traffic billing. Justin, could you please document the private TLVs that you're using and register them with IANA? (I'm currently under pressure to make the TLV allocation more onerous, and yours is a good example of why requiring an RFC for every Babel extension is a bad idea.) You're running Wireguard over Babel or the other way around? Any issues with that? -- Juliusz ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
Re: [homenet] [Babel-users] althea presentation on isp in a box at nanog 76
> Interesting stuff - wireguard, fq_codel/sch_cake, babel with new > metric that allows for cryptocurrency traffic billing. Justin, could you please document the private TLVs that you're using and register them with IANA? (I'm currently under pressure to make the TLV allocation more onerous, and yours is a good example of why requiring an RFC for every Babel extension is a bad idea.) You're running Wireguard over Babel or the other way around? Any issues with that? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [Babel-users] althea presentation on isp in a box at nanog 76
> Interesting stuff - wireguard, fq_codel/sch_cake, babel with new > metric that allows for cryptocurrency traffic billing. Justin, could you please document the private TLVs that you're using and register them with IANA? (I'm currently under pressure to make the TLV allocation more onerous, and yours is a good example of why requiring an RFC for every Babel extension is a bad idea.) You're running Wireguard over Babel or the other way around? Any issues with that? -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] VPN Bridging with Babel
Is there an IPv6 link-local address on the tun0 interface? Please show us the output of ip addr show dev tun0 If there's no link-local address (Linux kernel bug), then you should add one manually: ip addr add fe80::1/64 dev tun0 You should use different link-locals on the two sides of the tunnel (e.g. fe80::1 on one side and fe80::2 on the other). -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [homenet] securing zone transfer
> No, we are assuming that there are one or more homenet routers that either > come with a delegated domain from the manufacturer (probably a very ugly > one), or which that CPE's ISP will delegate via DHCPv6. (or both) I see. (I still disagree with the technical choices, especially that of binding the domain with either the manufacturer or the ISP, but now I see a little better where you're coming from.) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] securing zone transfer
>> Your turn now. Could you please describe the UI that you envision? > The list of names (from the internal mDNS/DNS-SD, as well as DHCP hostnames) > is presented to the house owner, they click on the ones that the want to > be publically visible. Are you assuming here there's a central Homenet controller that presents a web interface where the "house owner" can choose which names get published? Daniel's original draft used the term "CPE" for the hidden primary. At the time, I pointed out two things: - there's no single CPE in Homenet, there's zero, one or more edge routers which might or might not be ISP-controlled devices; - no Homenet service should be bound to an ISP-controlled device. I believe that these requirements still reflect WG consensus. Assuming that I'm right, I can only see two ways to provide global naming without giving up on the properties above: - we avoid relying on a central controller (hidden primary with web interface); - we define a way to elect the central controller (hidden primary) in a way that doesn't bind the election to an ISP-controlled device. (Am I missing a third option?) The protocol that I have outlined is certainly not perfect, but it has the virtue of avoiding the need for a central controller in the Homenet by outsourcing naming using an end-to-end protocol between the host being named and an external DNS primary. I'm probably missing something, Michael, so please explain if you agree with the analysis above, whether you're assuming a central controller, and, if so, where is the central controller located in a network that has multiple edge routers. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] securing zone transfer
> It would seem your objection can be summarized as "we don't need this". > Correct me if I'm wrong. No, my objection is that I cannot see how that can work in a decentralised manner -- with no central Homenet controller. > To me is like saying we don't need a new routing protocol like BABEL, because > we have loads of routing protocols already. > [for the record I strongly supported incorporating BABEL into Homenet, > because to me it was the best choice] When we argued between Babel and IS-IS, we were deciding between two decentralised protocols. In some sense, we were having an argument among friends -- had someone suggested we use a central SDN controller instead of a distributed routing protocol, we'd probably have ganged on the culprit. If that's okay, I'll give a more detailed description of my objection as a followup to MCR's comment, since the two of you are saying very roughly the same thing. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] securing zone transfer
> Actually, it's fatal, because you can't get a certificate for "boombox.local" > so you can't secure it that way. So you always have to use the FQDN. That sucks, of course, but the problem is completely unrelated to being published in the global DNS -- the very same problem applies to names that only appear in local MDNS. >> I think that's our main disagreement. >> For some reason, you guys seem to be assuming that the average user will >> want to publish hundreds of names in the global DNS. > Hundreds? How about two. > My son wants to publish his desktop's name so that his friend can reach his > system directly for minecraft. I want the same. Your son clicks "publish name" in the Minecraft server's UI, at which point he faces the following dialog box: Domain: dyndns.minecraft.example.com Hostname: minecraft-7ac8 Password: The young man considers that default values are for noobz, and edits as follows: Domain: richardson-family.vanity-dyndns.example.com Hostname: better-server-than-dads Password: After the name is published (which takes half a second), the Minecraft UI displays a "share" icon, so that your son can publish the server's name over UUCP, or whatever it is that them youngsters use nowadays for chatting. Your turn now. Could you please describe the UI that you envision? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] securing zone transfer
> The front end naming architecture uses a primary and a secondary dns server to > synchronize a zone. People will recall that the need for a hidden primary hasn't been established yet. Please see my unanswered e-mail of 21 November 2018. https://mailarchive.ietf.org/arch/msg/homenet/vz1kdCJISN6UPNZpj9ZD4e8EdwQ -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [Babel-users] HMAC documentation
>> I'm sending you this email to inform you that there isn't any >> documentation about HMAC in the babel manual. > Isn’t the code self-documenting? Well, sure, it's beautifully written :-) Still: - the HMAC branch hasn't been merged into mainline yet; - even in the HMAC branch, there ain't no documentation of the config file format. I'm busy right now, I'll take care of any pull requests on Monday. -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [homenet] wifi broadcast domain - Mikael Abrahamsson's comments
>> If there is a more complex HNCP network, then we could probably simulate >> the L2 scenario with VXLAN, configured by HNCP. > If memory serves, VXLAN requires support for multicast, which HNCP+Babel > doesn't provide. There's a set of IBM (?) extensions to VXLAN that avoid > the use of multicast, I'm not a fan. Another issue is that since VXLAN emulates a layer 2 network, it doesn't have any means to regulate MTU; hence, it requires either network-layer fragmentation or the use of jumbograms. Not a fan, sorry. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] wifi broadcast domain - Mikael Abrahamsson's comments
> If there is a more complex HNCP network, then we could probably simulate > the L2 scenario with VXLAN, configured by HNCP. If memory serves, VXLAN requires support for multicast, which HNCP+Babel doesn't provide. There's a set of IBM (?) extensions to VXLAN that avoid the use of multicast, I'm not a fan. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] wifi broadcast domain - Mikael Abrahamsson's comments
> prplMesh solves the wifi broadcast domain issue. >https://prplfoundation.org/working-groups/prplmesh/ >From their website: « prplMesh is an open-source, carrier-grade and certifiable implementation of the WiFi Alliance’s Multi-AP specification. » That's a purely layer 2 solution that relies on a central controller. It depends on IEEE 1905: https://en.wikipedia.org/wiki/IEEE_1905 -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [Babel-users] Study about Babel
>> Is there a command to check if babeld is working and which >> nodes are in the topology? > There is the `-d level` (level 1 is good enough) of babeld that > shows neighbours and installed routes. Uh-huh. You can also: - send a SIGUSR1 to babeld to get a dump; - run babeld with '-g 33123', and then do nc ::0 33123 dump quit Don't try to setup BabelWeb until you've got the above to work. -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
[Babel-users] Babel meeting at IETF-104
Dear all, The Babel meeting at IETF 104 will be this Thursday 28 March in room Athens/Barcelona. https://datatracker.ietf.org/meeting/agenda/ If you're in Prague, please come. If you're not in Prague, please attend through the Internet : https://www.ietf.org/how/meetings/104/remote/ The preliminary agenda is here : https://datatracker.ietf.org/meeting/104/materials/agenda-104-babel-02 Among other things, I'll be giving a talk about Babel-RTT, an extension to Babel developed a few years ago by Baptiste Jonglez and which I'm pushing for adoption by the IETF. This should be interesting even if you haven't been following the Babel standardisation work. See you all on Thursday, -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [homenet] homenet: what now? ... next?
> PIE [...] lends itself better for implementation in existing hardware, > or hardware with small modification. Could one of you please explain why? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [Babel-users] [babel] Reworked implementation of HMAC authentication
>> - we compute HMAC for each TLV, rather than just once for the whole >> packet, which, again, makes us vulnerable to DoS; > ugh. Don't worry, it's an easy fix. >> - we don't support key rotation. > Sigh. The data structures are designed so it'll be easy, the problem is designing an understandable user interface. Given the following interface declaration: interface eth0 hmac key1 what does the following mean? interface eth0 hmac key2 Does it add key2 to the set of keys associated with eth0, or does it override the current value? I'm afraid that either will cause confusion. I'm considering keeping the set of keys associated with an interface static, and allowing key rotation by redefining existing keys. So you'd say interface eth0 hmac key1 hmac key2 key id key1 type sha256 value ... key id key2 type none and do key rotation by saying key id key2 type sha256 value ... key id key1 type none I'll look at Barbara's information model, the must be some insights there. -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
[Babel-users] Reworked implementation of HMAC authentication
Hi, I've finally gotten my act together, and reworked Clara's and Weronika's implementation of Babel-HMAC. You can get the code by doing git clone -b hmac --recurse-submodules https://github.com/jech/babeld While this code is almost completely untested, it is meant to eventually implement the protocol described in https://tools.ietf.org/html/draft-ietf-babel-hmac Known issues: - no interop testing has been done yet; - we create a neighbour entry too early, which makes us vulnerable to DoS; - we compute HMAC for each TLV, rather than just once for the whole packet, which, again, makes us vulnerable to DoS; - we don't timeout neighbours properly, which makes us vulnerable to delayed packets; - we only support sending one HMAC (receiving multiple HMACs should work, but for obvious reasons it's untested); - we don't support key rotation. You can test this code by saying something like: babeld -C 'key id test type sha256 value ebf49e6fbc6414aa567e30891846e96963cdda73289b9cd245d67ff9d281abc0' -C 'interface eth0 hmac test' The "key" stanza defines a key of type sha256, with the value given as a 32 byte-long hex key. The "interface" stanza enables the key on the interface eth0. In addition to "type sha256", we support "type blake2s", which requires a 16 byte-long key. -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [homenet] homenet: what now? ... next?
>> I think that this work should be stalled until we have an implementation >> to play with and make some in vivo experiments. > I'm not sure if by "stalled" you mean sticking with the plan above, or > something else I'm concerned about two things: - if you're not implementing yourself, everything seems easy, and you end up with an overly complex design; - once you've spent a lot of time on a paper protocol, you're unwilling to change things even when the implementation work indicates they're broken, so you end up with a design that is not only overly complex, but doesn't work very well. I think this protocol has reached the point where any further paper work will be counter-productive until somebody tries their hand at implementing it. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] homenet: what now? ... next?
Hi Stephen, Sorry if I'm repeating myself -- I've already expressed the opinions below, both at the mike and on the list. > (a) work on simple naming I think that this work should be stalled until we have an implementation to play with and make some in vivo experiments. (Experience shows that the best way to break a protocol is to give an implementation to Dave.) > (b) the drafts on handling names with help from your ISP. I fear that these drafts are a bad case of complexity for the sake of complexity (or perhaps a case of involving the ISP for the sake of involving the ISP). I still haven't seen a compelling argument that they do solve a problem that a trivial end-to-end protocol wouldn't solve. Back in July 2018, I wrote the following: This is a question that I've been asking since July 2014, and I still haven't received an answer I could understand. Please see the thread starting on 18 July 2018: https://www.mail-archive.com/homenet@ietf.org/msg07012.html > (We also have a chartered work item [4] on security that has seen no > progress but you can comment on that as item (c) if you like;-) Some pointers for the rare people who don't spend most of their leisure time reading Internet-Drafts: - HNCP is based on DNCP, which includes a security mechanism designed to provide authenticity, integrity and confidentiality of the HNCP data: RFC 7525 Section 8 I believe that this is implemented in hnetd. (Yeah, Markus and Stephen did some remarkable work.) - Babel has two security mechanisms: https://tools.ietf.org/html/draft-ietf-babel-hmac https://tools.ietf.org/html/draft-ietf-babel-dtls There appear to be no standards-track key distribution and rotation protocols for either of OSPF, IS-IS, BGP or BFD (static keying seems to be the norm), so a natural question is whether HNCP could serve this purpose, or whether it would be better to use a dedicated key distribution and rotation mechanism. - RFC 3971 Section 6 says the following: To protect Router Discovery, SEND requires that routers be authorized to act as routers. This authorization is provisioned in both routers and hosts. Since hosts don't participate in HNCP, it is not clear if HNCP can be used as a SEND trust anchor. I believe there's the same issue with securing access the DNS stub resolver (DNSCrypt, DNS over TLS, etc.). -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [Babel-users] Open-Mesh migration, 802.11s, babeld, speed degradation
> Yes, in this situation all neighbor stations enumerate. Everyone can ping > everyone via 802.11s mesh. You're running Babel over an 802.11s mesh? Why? Both Babel and 802.11s are routing protocols (more exactly, 802.11s contains a routing protocol). Running both in the same mesh is redundant. > However, now that it is running on the wlan0 that is a bridge of wlan0-1 > and wlan0, it just seems boring; I don't see those fancy routing tables, > and I am not seeing that it is establishing the shortest route based on > prevailing network conditions, I am see only metrics passed of 0, 128, > and 65535. This is expected. The 802.11s mesh is doing its thing, and Babel sees the mesh as a single hop. If 802.11s works for you, then please use that. If it doesn't, then please tear down the 802.11s and use Babel. It is pointless to run both 802.11s and Babel on the same network. -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [homenet] homenet: what now? ... next?
> Both HNCP and Babel carry their control traffic over link-local IPv6, but > they support both IPv4 and IPv6 with almost equal functionality. > (The only significant difference is the treatment of border routers, which > are assumed to be doing NAT in IPv4 and stateless routing in IPv6.) > Does that equality mean that I can route from a device in one home to a device > in another over v4. You'll need something like ICE (RFC 8445), or at least STUN (of which ICE is a superset). PCP (or NAT-PMP) should in principle work too, but I haven't actually tried getting it to work over multiple hops. You'll need ICE STUN or PCP even for IPv6, since people appear to be intent on putting stateful IPv6 firewalls on their edge routers. > Won’t they both have rfc 1918 addresses (possibly the same ones). ICE is fine with that. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] homenet: what now? ... next?
> I do remember that talk. CS grad students are not our target market. First year undergrad, Ted. Eighteen year-old lass with no previous networking experience. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [Babel-users] Open-Mesh migration, 802.11s, babeld, speed degradation
Hi Stuart, > I would much rather use babeld, and I had set it up with the default > settings from OpenWRT, but the radios fell off the net (not a logfile > issue). What do you mean they "fell off the net"? Is the link layer associating? Please run "iw dev wlan0 station dump" on each of the nodes, and check whether the link layer sees the neighbours. If it does not, then you've got a lower layer problem, and babeld can't help. > Then I ran it on each node with- babeld -d1 -C 'redistribute metric 128' > br-lan (with firewall hole), Don't do that, since it prevents babeld from selecting the right interface. You should un-bridge the LAN interfaces, and run babeld directly over the physical interfaces. In /etc/config/wireless, say something like: config wifi-iface 'wlan0' option device 'radio0' option mode 'adhoc' option network 'wlan0' ... The important bit is that you create a new network "wlan0" rather then inserting the wlan0 interface into the "lan" network. In /etc/config/network, you need to define the wlan0 network: config interface 'wlan0' option ifname 'wlan0' option proto 'static' option ipaddr '192.168.2.1' option netmask '255.255.255.0' option force_link '1' Finally, add your "wlan0" network to the "lan" zone in /etc/config/firewall: config zone option name lan list network 'lan' list network'wlan0' list network'wlan1' list network'wlan2' option inputACCEPT option output ACCEPT option forward ACCEPT > But the nodes lose their connection every few minutes and reset, What do you mean exactly? Try doing killall -USR1 babeld and send us the relevant part of the log. -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [homenet] homenet: what now? ... next?
>> It should be an easy fix, feel free to go ahead. > The point of soliciting participation at hackathon is for us to gain > collective experience on the easy or difficulty of deploying homenet in > practice. Oh, that's different, and not at all the motivation you give in your previous mail. Experience shows that the best way to make something happen is to organise it oneself, and therefore you should feel free to organise a Homenet tutorial yourself, just like you should feel free to fix yourself the issues you're having with hnetd. I'm not sure that you'll find much of an audience, though -- as you rightly point out, there doesn't appear to be much excitement left around Homenet, and the main contributors appear to have moved on with their lives. It's been six years, after all. (For my part, my IETF funding runs out in September.) On that subject, you might remember the talk I gave about HNCP deployment back in 2016. The conclusions were that a first year student who had never done any networking before was able to deploy an HNCP+Babel mesh network in two weeks, and most of that time was spent learning to reflash off-the-shelf routers from scratch. https://datatracker.ietf.org/meeting/96/materials/slides-96-homenet-1 -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] homenet: what now? ... next?
>> Both HNCP and Babel carry their control traffic over link-local IPv6, but >> they support both IPv4 and IPv6 with almost equal functionality. >> >> (The only significant difference is the treatment of border routers, which >> are assumed to be doing NAT in IPv4 and stateless routing in IPv6.) > Oh, I thought the charter was for v6 only. Did that change, or am > I misremembering? Yeah, I never understood that. The charter is pretty much v6-only, but I don't recall anyone ever suggesting that we should omit IPv4 support (but then, I only got involved around the summer of 2014). RFC 7788 says: While RFC 7368 sets no requirements for IPv4 support, HNCP aims to support the dual-stack mode of operation, and therefore the functionality is designed with that in mind. while the Babel profile for Homenet says: REQ3: a Homenet implementation of Babel SHOULD implement the IPv4 subset of the protocol The implementation status is pretty solid: - both implementations of HNCP (hnetd and shncpd) have good support for IPv4 and DHCPv4; - of the six implementations of Babel known to me, four support IPv4 (babeld, BIRD, FRR and David's Top Secret Implementation). -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] homenet: what now? ... next?
> Both HNCP and Babel carry their control traffic over link-local IPv6, but > they support both IPv4 and IPv6 with almost equal functionality. > in fact while what you are saying is technically true, in practice IPv4 > _is_ treated like a second-class citizen in the sense that if your > ISP-provided public IP address ever goes away, all of your RFC1918 > addresses on the homenet also go away. That's an property of the hnetd implementation, not a feature of the protocol (and it doesn't apply to shncpd). See RFC 7788 Section 6.5. > This is one of the reasons that I would like us to get together and hack on > this at the hackathon: It should be an easy fix, feel free to go ahead. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] homenet: what now? ... next?
> What I meant is that homenet router protocols are v6 only. No, they're not. Both HNCP and Babel carry their control traffic over link-local IPv6, but they support both IPv4 and IPv6 with almost equal functionality. (The only significant difference is the treatment of border routers, which are assumed to be doing NAT in IPv4 and stateless routing in IPv6.) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [Babel-users] Study about Babel
> For BATMAN, I’m using LibreMesh.org and for BABEL, I’m trying to find a > solution using OpenWRT and babeld but it is not a success… Does anybody know > where I can find a simple solution using Babel protocol to implement on my > routers with OpenWRT (or something similar)? It is my opinion that third-party firmwares are a bad idea -- if something is worth sharing with the community, it should be included in OpenWRT itself. Babeld works just fine with stock OpenWRT. On your OpenWRT box, create a statically configured interface in ad-hoc mode. In /etc/config/wireless: config wifi-iface 'wlan0' option device 'radio0' option mode 'adhoc' option ssid 'babel' option channel 11 option encryption 'none' In /etc/config/network: remove the interface from the 'lan' bridge (in case it's included), then do: config interface 'wlan0' option ifname 'wlan0' option proto 'static' option ipaddr '192.168.2.1' option netmask '255.255.255.255' You may add an IPv6 address if you wish. In /etc/config/firewall, add the new interface to the 'lan' zone (since you're no longer bridging it with the lan interface). Then do opkg update opkg install babeld and add the following to your /etc/config/babeld: config interface option ifname wlan0 config filter option type redistribute option ip '0.0.0.0/0' option eq 0 option action 'metric 128' Feel free to write to the list again if you need any further help. -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Bug#916705: Please patch DHT
> point it, it's already been applied - should i remove it or not? It doesn't hurt, so if you'd rather not bother with a new upload, feel free to leave it as it is. Sorry again for the confusion, -- Juliusz
Bug#916705: Please patch DHT
> Debian (i think) ships dht > https://salsa.debian.org/debian/transmission/blob/master/third-party/dht/CHANGES > - what should we do here? Debian's 2.94-1+b2 appears to be shipping 0.22, which is a rather old version. There's no need to apply this patch to that version. -- Juliusz
Bug#916705: Please patch DHT
> in light of > https://github.com/transmission/transmission/issues/782#issuecomment-450852432 > should > https://salsa.debian.org/debian/transmission/blob/master/debian/patches/patch-vendored-libdht.patch > be reverted? dht-0.25 doesn't have the bug. The patch is harmless, but it doesn't achieve anything useful. Sorry again for the confusion. -- Juliusz
[go-nuts] Re: why in source of go compiler, initialize a *gc.Node with the help of a temp struct x? can't we initialize it directly?
> See https://golang.org/cl/36022. There's a terrifying sort of beauty to it, like a tarantula or a snake. (And it most certainly deserves a comment in the source.) -- Juliusz -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Babel-users] [babel] BASE64 and hex encoding HMAC keys for user presentation
>> I think that the HMAC key should be generated automatically. I'd hope >> that any actual production deployment of HMAC would generate HMAC keys >> either randomly or by using a suitable KDF (or whatever the right acronym >> is) and distribute it automatically. > Should we pick a KDF? Not necessarily for the RFC, but at least try to > get compatibility between bird and babeld, so users can just input a > password and expect things to work? I think we might need more deployment experience before we can answer that. At this early stage, however, I wouldn't expect the master key to be distributed -- the KDF would be applied to the master key on a central node, and the derived secret is what gets distributed to the babeld and BIRD instances. So having a common syntax for the HMAC secret should be good enough. -- Juliusz ___ 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] Relax martians check
> 'Cause I'd sent you a patch earlier for just e (240/4) and you didn't > apply it? :) I'm a bad man. Please double-check commit 19a442ba. -- Juliusz ___ 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] interface: clarify error message when adding existing interface
Thanks, applied. ___ 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] Relax martians check
> This patch enables both class-e and multicast IP addresses to be > carried within the babel protocol. No objection to class E, but why multicast? ___ 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: interface.c: flush_interface() call local_notify_interface() once
Thanks, applied. ___ 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 2/3] Introduce taskqueue for easier tasks and timeout handling
> I happen to really like timerfds but they are a linuxism. How would they be used here? ___ 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] v2: Allow to independently monitor events for neighbour, interface, route, xroute
Great, I've been planning that for a long time.
> +.B neighbour-monitor
> +and
> +.BR neighbour-unmonitor ;
Please use the syntax "monitor neighbours" and "unmonitor neighbours".
Two keywords.
> +#define CONFIG_ACTION_NEIGHBOUR_MONITOR 6
> +#define CONFIG_ACTION_NEIGHBOUR_UNMONITOR 7
> +#define CONFIG_ACTION_ROUTE_MONITOR 8
> +#define CONFIG_ACTION_ROUTE_UNMONITOR 9
> +#define CONFIG_ACTION_XROUTE_MONITOR 10
> +#define CONFIG_ACTION_XROUTE_UNMONITOR 11
> +#define CONFIG_ACTION_INTERFACE_MONITOR 12
> +#define CONFIG_ACTION_INTERFACE_UNMONITOR 13
Please use a single action with a parameter.
> +static void
> +local_notify_all_1(struct local_socket *s)
> +{
> +local_notify_all_interface_1(s);
> +local_notify_all_neighbour_1(s);
> +local_notify_all_xroute_1(s);
> +local_notify_all_route_1(s);
>}
Why is that refactoring necessary?
> +inline void set_flag(uint8_t *d, uint8_t flag) {
> +*d |= 0x01 << flag;
> +}
Please don't -- just but the bit manipulation inline, I find that easier
to read.
-- Juliusz
___
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 3/3] utilize taskqueue for check_interfaces()
> this illustrates how the taskqueue can be used and removes a little bit of > code from the main loop It would be more interesting to see how you can replace the mess that is resend.c. That will require an interface for task cancellation. -- Juliusz ___ 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 2/3] Introduce taskqueue for easier tasks and timeout handling
Thanks for the code. > The task queue allows to schedule tasks that happen in the future. This implements a binary heap as a linked tree, which has very poor locality. In order to improve locality and avoid memory allocations, we should be implementing the heap as an array. An alternative would be to use the opportunity to make babeld multithreaded by using work-stealing scheduler, but that might be overkill. I'd also like somebody to explain to me what are the tradeoffs between a binary heap and the timer wheel. I've used binary heaps (implemented as arrays) since I was but a bairn, but I don't fully understand the timer wheel. -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
[Babel-users] Marginal IHU [was: more eyeballs on some scaling bugs]
> I find it difficult to read the babeld code It was difficcult to write. I don't see why it should be easy to read ;-) > I guess that reach is a bitmap of some kind, storing on which of the > last 16 hellos the neighbour was reachable. That's right. The logic is in update_neighbour, and described in human terms in Appendix A of RFC 6126bis. > If a marginal ihu really is just a ihu that is sent on specific > conditions, we could name this function send_ihu_on_$CONDITION() and avoid > many questions with this small change. > The only thing left to do is: understand the condition. The idea is that: - we send at least one IHU every three Hellos; - if the link is lossy, we send one IHU with every Hello. The condition reads as follows: if(neigh->txcost >= 384 || (neigh->hello.reach & 0xF000) != 0xF000) If the direct cost of the link is above 384, or we've missed at least one of the last four hellos, then the link is marginal, and we send the IHU unconditionally. -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] [babel] BASE64 and hex encoding HMAC keys for user presentation
> I would like the bird and babel implementations to allow for and use > BASE64 and hex encodings. > This allows for a shorter, more human friendly representation of both > cryptographically generated keys and the keys humans are more likely > to remember and type without error. In the latter case, guidelines as > to length, mixed case and punctuation would be useful. I think that the HMAC key should be generated automatically. I'd hope that any actual production deployment of HMAC would generate HMAC keys either randomly or by using a suitable KDF (or whatever the right acronym is) and distribute it automatically. (At the current time, I'm not advocating designing a key distribution protocol to go with HMAC -- I'm in favour of using a centralised script that uses ssh to distribute keys. Please see https://cr.yp.to/djbdns/tcp.html) So no, I'd rather not encourage people to generate HMAC keys manually. -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Bug#916705: Please patch DHT
Package: transmission-gtk
Version: 2.94-1
Severity: wishlist
Hi,
I've just released libdht version 0.26, which fixes a rather unpleasant
bug. I've filed a bug upstream:
https://github.com/transmission/transmission/issues/782
Since upstream hasn't done a release in a long time, I'm attaching the bug
fix, in case you wish to patch the Debian package.
diff --git a/dht.c b/dht.c
index c752d13..b3709f9 100644
--- a/dht.c
+++ b/dht.c
@@ -2713,7 +2713,7 @@ send_closest_nodes(const struct sockaddr *sa, int salen,
int numnodes = 0, numnodes6 = 0;
struct bucket *b;
-if(want < 0)
+if(want <= 0)
want = sa->sa_family == AF_INET ? WANT4 : WANT6;
if((want & WANT4)) {
Re: [Babel-users] key rotation take #2
> This is the present babel conf file format: > key id key1 type sha1 value deadbeefdeadbeefdeadbeefdeadbeefdeadbeef > key id key2 type sha1 value dea2f0d01a57b0071057a11da7adeadbeeff > interface enp7s0 unicast false hmac key1 > interface wg1 hmac key2 Right. It currently cannot be updated dynamically, but the plan is that it will at some point before HMAC get merged into mainline. > so we invent a new keyword "serial". > a key rollover is initiated by adding a new key with the same name and a > larger serial number than the old one. I don't understand what problem you're trying to solve. You're happily HMACing your packets: key id key1 type sha1 value ... interface wlan0 hmac key1 At some point, you decide to start using a new key: key id key2 type sha1 value ... interface wlan0 hmac key1 hmac key2 You deploy the new key on all routers, then you delete the old key: interface wlan0 hmac key2 Why do you need a serial number? -- Juliusz ___ 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
> 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, In musl too: https://git.musl-libc.org/cgit/musl/tree/src/time/clock_gettime.c Also, babeld doesn't make that many calls to clock_gettime -- the current time is cached in the global variable "now", which is only updated once per call to select. -- Juliusz ___ 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 1/3] add error helper functions
Thanks, Christof. I'm still dealing with exams and student defenses, I'll review all of your proposals during the holidays. Genuinely sorry for the delay, -- Juliusz ___ 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)
> 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. Have you looked at RFC 7210? -- Juliusz ___ 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 Key rotation key format (was ripemd)
> FWIW, for homenet the thought was to use HNCP to distribute keys amongst > routers. HNCP is not a good choice for symmetric key distribution, since it floods all information across the HNCP domain. It's impossible to use HNCP to distribute a key to some routers only while keeping it secret from others. -- Juliusz ___ 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 routerid->key mappings?
> The "one interface per key" rule adds complexity but I think it also > brings benefits by requiring such. It's conceptually elegant and easy to explain. These are good features to have. > About the only issue I see for an interchange like this is that you'd > also need one ipv4 address per veth, which are kind of scarce. > unless there was a way to do the obscure extended nexthop idea in > https://tools.ietf.org/rfc/rfc5549.txt in babel and linux? Babel (at least babeld, don't know about BIRD) should deal fine with Linux-style unnumbered links (which are different from Cisco-style unnumbered links). In the Linux style, you put the same IPv4 address on multiple links: ip addr add 192.0.2.1/32 dev eth0 ip addr add 192.0.2.1/32 dev eth1 ip addr add 192.0.2.1/32 dev wlan0 Now you run babeld on all interfaces, and everything should just work -- look, Ma, just one IPv4 address per host. (In Cisco style, you put your IPv4 address on the loopback interface, and the other interfaces magically borrow the loopback's IPv4 address. I find the Linux style easier to comprehend, but perhaps that's just me.) -- Juliusz ___ 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 routerid->key mappings?
> as keys (currently) protect each interface, not each router association... Correct. Babel uses both unicast and multicast, and Babel-HMAC is designed so that it can protect multicast traffic while remaining immune to replay, even in the absence of persistent state or hardware clocks. > consider, instead a case where you are dropping a bunch of networks > into an information interchange (call it "BIX"[1]), where a bunch of > networks have agreed to interconnect, over a single "wire", much like > how BGP network interchanges work today. Key exchange here, in the BGP > world, is on a per-router, not per-interface, basis. BGP is a unicast-only protocol, hence it can easily use per-peer keys. > It is unwise to share one key with all interchangers. Co-ordinating a > key rollover with that many different entities on that wire is hard. > Using specific keys instead for each of the A-F, A-G, A-B, etc, > associations limits the geometric growth and security vulnerabilities. The clean solution would be to use a bunch of point-to-point interfaces, either by replacing your switch with direct router-to-router links, or by putting up a bunch of VLANs or GRE tunnels. Then you can use Babel-HMAC unmodified. > A) while we can append quite a few HMACs in a hello, at some point, > when an interchange's hmacs grows past the size of a packet, we run > out of space. What happens? Can we resend that hello with even more > HMAC's attached, and win? Sort of. However, if there are any plaintext routers on the same link, they will parse both packets. I think that Babel should deal fairly well with packet duplication, but I'm not sure. But at that point, you might as well use DTLS. > So if the code (in addition to protecting interfaces) could also (or > instead of interfaces) associate keys to routerids, we scale to this > scenario. I'm not going to do that, unless there are any good reasons why you don't want to use DTLS in that case. > 1) Use BGP instead at large interchanges Yep. If your routing tables are relatively stable, BGP is the right choice. > 2) Use DTLS Yep. It supports per-peer keying out of the box. > 3) Use a minimal number for all associations on an interface scaled to > the max size of hello + ihu + hmacs Not so keen on that -- while the protocol does in principle support multiple HMACs, both the amount of overhead and the amount of computation go up linearly with the number of HMACs. It's really not designed for that. Of course, you could envision using the unicast variant of the protocol (the one that rejects all multicast packets except Hellos) and protect unicast packets with HMAC instead of DTLS. But at that point, you might just as well use DTLS. Quite frankly -- just use DTLS, or run HMAC over point-to-point links. -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Blake2S, blake2B or neither? [was: rather than ripemd160...]
>> Where is Blake2S-based HMAC defined? RFC 7693 merely says > Section 3.3 simply says: >If a secret key is used (kk > 0), it is padded with zero bytes and >set as d[0]. Otherwise, d[0] is the first data block. The final >data block d[dd-1] is also padded with zero to "bb" bytes (16 words). Thanks, that was the bit I'm missing. With that info, I have no objection to making Blake2S RECOMMENDED in Babel-HMAC. I'm still waiting for more opinions before I make up my mind. -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Blake2S, blake2B or neither? [was: rather than ripemd160...]
>> (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-based HMAC defined? RFC 7693 merely says: BLAKE2 does not require a special "HMAC" (Hashed Message Authentication Code) construction for keyed message authentication as it has a built-in keying mechanism. but it does not appear to clearly define the HMAC construction. ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
[Babel-users] Blake2S, blake2B or neither? [was: rather than ripemd160...]
>> With these numbers, I withdraw my support of including anything else >> than SHA256 as MTI. I think specifying Blake2B or 2S as well makes >> sense (mostly for crypto robustness reasons for having alternative >> that is specified) but making it MAY-SHOULD seems sensible to me. > I can probably live with that :) Excellent, it looks like we're converging. Thanks to both of you for the informative and kind discussion. At this stage, I see four possibilities: (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 am in favour of (1), since I am convinced that SHA256 is fast enough for all reasonable devices. (2) makes sense to me, and I won't oppose it. I'll need some convincing in order to do (3) or (4), since Blake2B does not appear bring any significant speed advantage over SHA256. In either case, I'm planning to implement SHA256, Blake2B and Blake2S in the reference implementation. -- Juliusz ___ 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...
> 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 control traffic? I don't have an ARM device handy right now, but a 450MHz MIPS 24Kc is able to SHA256 on the order of 16MB/s. That's 1 full-size frames per second, or on the order of 60 Babel updates per second. My suggestion is to implement whatever the list recommends (Blake2B or 2S) in both BIRD and babeld, but to keep the status quo (SHA256 is MTI) in the spec. -- Juliusz ___ 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 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...
> 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
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation
Thanks for your reply, Daniel. > If I understand correctly the question is why do we have a Homenet Naming > Authority responsible to outsource the Homenet Zone to the Public > Authoritative > Servers ( Front End architecture) instead of having each device updating their > data directly to the Public Authoritative Servers (End to end architecture) ? Yes, that's a good summary. > * The End to end architecture does not seem to be scalable in term of > management I don't think that this argument is relevant to Homenet. I'd expect most devices in a home network to have no externally visible name. The number of externally named devices is 0 for the typical user, and just 3 for a rather extreme geek (NAS, boom box, and game server). I'm sure we can agree that the end-to-end architecture scales well beyond 3 devices. > The architecture where all devices directly update their data to the Public > Authoritative Servers requires these devices being configured appropriately > with authentication credentials, This is also the case with the proxying architecture: devices are by default not announced to the global DNS, and per-device configuration is needed for devices that want to be named globally. > With the architecture proposed, all this information is centralized to the HNA > and easier to secure. The devices that need to have globally visible names are the secure ones (the NAS, the music collection, the game server). The insecure devices are exactly the ones that should not have a global name. Or are you assuming that I'll want to publish each lightbulb in the global DNS? > * End-to-end Architecture does not provide internal and external views. I don't see how. The end-to-end protocol only publishes names of devices that have been explicitly configured to do so, just like the proxying algorithm. > In addition its design imply that everything is published to the > Internet, and the naming within the homenet hardly work without > connectivity. I don't see how. Homenet-local naming is not impacted by how we publish externelly-visible names. > * End-to-end architecture is hard to get adopted. > DNS update seems the only standard way to update DNS data. There's no reason why DNS updates couldn't happen end-to-end. I am not discussing the exact encoding here, what I'm discussing is the need for a proxy. > Currently most homenet architectures have a CPE that assigns ip addresses to > devices. This statement is in clear contradiction with the Homenet architecture. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation
Dear Daniel, > I am planning to update the front end naming delegation draft [1] in the next > weeks. Before revisiting the draft, I am collecting comments that need to be > addressed. After your talk at IETF-102, I asked what is the purpose of this rather complex protocol, and why it is preferable to a trivial end-to-end protocol. As instructed during the meeting, I carried my question to the list, in a message dated 18 July 2018. A number of people participated in the ensuing discussion, however, none provided a definitive answer to my question. I may have missed something, but as far as I know you did not participate in this discussion. Daniel, please explain why proxying through a hidden master is needed, and what problem this protocol solves that could not be solved with a trivial end-to-end protocol. Thanks for your understanding, -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [TLS] Babel-HMAC [was: are we holding TLS wrong?]
>> Unless I've missed something -- they are not, assuming you have >> a sufficiently strong random number generator. The challenge mechanism >> rebuilds the shared state in a secure manner, and the index mechanism >> ensures that an (index, seqno) pair is never reused. > I had a really hard time understanding this, even with this help. > Right now, I don't know what key is used for HMAC. I think that the > expectation is that each peer has a fixed HMAC key, but the contents > of the packet always change, thereby ensuring that the resulting MAC > is different for every packet. That's the general idea, yes. I'm not a cryptographer myself, and I don't know how original this is. > I would suggest that a formal analysis would be a good idea. Yes, we're hoping to do that. If you could point us to examples of papers that contain a proof of correctness of a cryptographic protocol that you believe is well done, that'd be helpful. -- Juliusz ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Are we holding TLS wrong?
> - s2.5 Not sure what the ceremonies around flushing a neighbor are, > but I'd make explicit signalling EOD at least a SHOULD? It seems more > polite :-) > I agree, I upgraded politeness to a SHOULD. Note however that a neighbour is usually discarded when we loose too many Hellos from it. At that point, we've lost contact with the neighbour, it's too late to be polite. -- Juliusz ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Are we holding TLS wrong?
> Yep, all of which speaks to some serious shortcomings of the > HMAC-based protocol. The scope of Babel-HMAC is deliberately limited. Babel-HMAC aims to implement the strict minimum of features that make it useful. Any deployment that needs features beyond what Babel-HMAC provides should use Babel-DTLS instead. > If N^2 is feasible, it would be good to hear how those keys are managed. Not in Babel-HMAC, no. We've tried to be very clear about that in Section 1.1 of draft-ietf-babel-hmac-00 : The protocol defined in this document assumes that all interfaces on a given link are equally trusted and share a small set of symmetric keys (usually just one, two during key rotation). The protocol is inapplicable in situations where asymmetric keying is required, where the trust relationship is partial, or where large numbers of trusted keys are provisioned on a single link at the same time. This protocol supports incremental deployment (where an insecure Babel network is made secure with no service interruption), and it supports graceful key rotation (where the set of keys is changed with no service interruption). This protocol does not require synchronised clocks, it does not require persistently monotonic clocks, and it does not require any form of persistent storage. If you believe this deserves further clarification, we'll be grateful for your guidance. -- Juliusz ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [Babel-users] hmac merge
>> 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 course, we'll make it easy for distributors to replace our bundled implementation of SHA-256 with whatever it is they find convenient. (I expect Dave to replace it with his hand-written implementation that interleaves MMX with AVX2 while simultaneously performing modular multiplication in the U pipe to hash 27.7 bytes per cycle per core.) (If you know what the U pipe is, you're old.) -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Loop-freedom [was: emacs...]
>> 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. Since the union of multiple acyclic graphs is not in general acyclic, Babel does not guarantee that the forwarding graph for a prefix p is acyclic in the case where p is originated at different routers, although it does guarantee that any loops disappear in linear time (with a constant that depends on the amount of packet loss). And of course Babel does not guarantee loop-freedom in the presence of redistribution between protocols (as in your case with DHCP). -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] how to set the pacing rate
> +rc = setsockopt(s, SOL_SOCKET, SO_MAX_PACING_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.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] hmac merge
> 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 working prototype, we focused on getting the protocol specification in time for IETF-102 and before the girls' internship ended. In particular, we need to do some restructuring to current master (passing an interface pointer to a number of functions that lost access to the interface structure in the unicast refactoring) before we can merge HMAC. The following features are supported by the protocol but not by the implementation : - graceful key rotation (ability to add/remove keys at runtime); - graceful deployment (ability to send signed packets but accept unsigned ones). > I do have one objection to the codebase, in that it pulls in > libgcrypt, ssl, and pthreads... about 5MB? of libs... for two hash > functions. Yeah, we should just include an implementation of SHA-256 in the code. -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: Installer: 32 vs. 64 bit
> Or an user error. In either case, I don't get what a 32-bit _x86_ virtual > machine would be good for. Are you teaching some code archeology? Not at all. We're trying to make it compulsory for first year students to have a Unix installation on their personal machine. In practice, this means any of native Linux, native Mac OS, or virtualised Linux. (We've found Cygwin to be confusing, and we haven't looked at WSL.) Since we're trying to get this to scale across a few hundred eighteen-year olds (smart ones, thankfully), we're seeing all sorts of user errors. -- Juliusz
Re: Installer: 32 vs. 64 bit
> Filing a bug on src:virtualbox with severity 'wishlist' or 'normal' for this > issue to discuss it with the maintainer of the virtualbox package(s) seems a > logical thing to do. Unfortunately, we're speaking about running Debian under VirtualBox under Windows, so it would need to be something that happens in VirtualBox upstream.
Re: [Babel-users] bird version interop issues
> 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, that'd be very helpful. -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
[Babel-users] Branches obsolete -- please track master
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/meeting/103/materials/slides-103-babel-recent-changes-to-rfc-6126bis-00.pdf RFC 6126bis is almost compatible with RFC 6126. Versions of babeld since 1.8.2 and versions of BIRD since 2.0 understand both revisions of the protocol. In order to avoid a flag day: * upgrade all of your routers to babeld 1.8.3 or later (1.8.2 is buggy) or to BIRD 2.0 or later; * only then start deploying current master. If you are not sure whether all of your routers have been upgraded, you may add the following stanza to your babeld.conf: default rfc6126-compatible true The above is true for ordinary next-hop routing. It is not true for source-specific routing, which has changed in an incompatible way. The transition model here is "ships in the night" -- version 1.8.4 speaks the old source-specific protocol and ignores the new one, while current master speaks the new source-specific protocol and ignores the old one. Please get in touch with me if you're using source-specific routing and cannot afford a flag day. Happy upgrading, -- Juliusz pgpYLLmaAvRhT.pgp Description: OpenPGP Digital Signature ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
[Babel-users] ANNOUNCE: babeld-1.8.4
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. -- Juliusz 9 November 2018: babeld-1.8.4 * Fixed a bug that discarded pipelined commands received on the local configuration interface. * Added the per-interface option rfc6126-compatible. pgptyLL6ba9p9.pgp Description: OpenPGP Digital Signature ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [TLS] Are we holding TLS wrong?
> I'm somewhat dismayed by the firm recommendation to use the HMAC > mechanism, Yeah, this could probably be loosened somewhat. > which doesn't seem particularly robust. It's designed to be fairly robust. Of course, we may have done things wrong. > Offhand, it seems like replays are possible if you allow the possibility > of the node crashing and dumping state. Unless I've missed something -- they are not, assuming you have a sufficiently strong random number generator. The challenge mechanism rebuilds the shared state in a secure manner, and the index mechanism ensures that an (index, seqno) pair is never reused. > The same applies during a rollover of the 32-bit counter. You generate a new index when the counter overflows, and send a new challenge. First point of Section 4.2 of the HMAC draft. -- Juliusz ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [homenet] writeup of my 2018 homenet experience on openwrt
> Markus, I tried to be really clear about what I was communicating on the > slide about implementations, but probably failed. Indeed. A number of your comments about Markus' code were entirely unnecessary. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] writeup of my 2018 homenet experience on openwrt
> Anyway, getting back to topic of Ted's passionate speech about bad HNCP > implementations, I'd love to see him (or someone else) provide better one :-) Ted is busy working on his implementation of Simple Naming. Please leave him in peace, it's important that he convince us that Simple Naming is as simple as he claims. (Not that we don't trust him, but obviously nobody in this WG would ever seriously listen to a person without an implementation.) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: Installer: 32 vs. 64 bit
>> I've been encouraging my students to install Debian on their personal >> machines, and we've found out that a lot of them get the wrong Debian >> installer: >> >> - some of them attempt to install an AMD64 version of Debian in >> a 32-bit-only virtual machine; > Why are they creating 32-bit virtual machines? Perhaps this is a bad > default in the VM manaager? Yes, it was a bad default in the laptop's BIOS (VT-something was disabled). HP's bug, obviously, but it would have made for a better experience if the Debian installer had complained in a comprehensible manner straight away. >> - others attempt to install an i386 version on 64-bit hardware. > This should work, in general. It won't work on a 64-bit system that > only supports EFI boot - and the installer won't be able to report > that, unless it includes a dummy 64-bit EFI program just to do that. It was a recent laptop, and the user had manually enabled BIOS boot. The installer hung with a black screen just after the initial menu. > We should not do in this in the second case, since it is supposed to > work. (But a warning might be reasonable.) Please. -- Juliusz
Re: [Babel-users] 64k routes, bird, babel rfc, rtod, etc
>> 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/listinfo/babel-users
Re: [Babel-users] 64k routes, bird, babel rfc, rtod, etc
> 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 ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: Installer: 32 vs. 64 bit
> When discussing virtual machines it would be helpful to mention which virtual > machine hypervisor is being used, because the resulting behavior can differ > depending on hypervisor. It was VirtualBox under Windows. The underlying issue was that VT-x was disabled in the BIOS, and hence VirtualBox didn't offer any 64-bit machines. The student tried her best to make it work, I don't think she can be blamed for failing. -- Juliusz
Re: Installer: 32 vs. 64 bit
>> I've been encouraging my students to install Debian on their personal >> machines, and we've found out that a lot of them get the wrong Debian >> installer: >> >> - some of them attempt to install an AMD64 version of Debian in >> a 32-bit-only virtual machine; > Why are they creating 32-bit virtual machines? Perhaps this is a bad > default in the VM manaager? Yes, it was a bad default in the laptop's BIOS (VT-something was disabled). HP's bug, obviously, but it would have made for a better experience if the Debian installer had complained in a comprehensible manner straight away. >> - others attempt to install an i386 version on 64-bit hardware. > This should work, in general. It won't work on a 64-bit system that > only supports EFI boot - and the installer won't be able to report > that, unless it includes a dummy 64-bit EFI program just to do that. It was a recent laptop, and the user had manually enabled BIOS boot. The installer hung with a black screen just after the initial menu. > We should not do in this in the second case, since it is supposed to > work. (But a warning might be reasonable.) Please. -- Juliusz
Re: Installer: 32 vs. 64 bit
> This is not what I get. > - 32bit debian on 64bit machine: this should be working fine > - 64bit debian on 32bit machine: I get the attached message > If it's not what they get, there is some bug and more investigation is > needed. I no longer have access to their machines, so I'm unfortunately unable to check. -- Juliusz
Re: [Babel-users] 64k routes, bird, babel rfc, rtod, etc
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/mailman/listinfo/babel-users
Re: [homenet] writeup of my 2018 homenet experience on openwrt
>> From a user perspective, there are a few problems: > When an interface goes down and then up again, it's renumbered. This > includes reboots. That shouldn't happen as long as there remains at least one Homenet router to maintain the prefix (see Section 4.1 point 3 of RFC 7695). I believe that hnetd (but not shncpd) additionally supports some mechanism to handle the case where there are no routers left to maintain the prefix, but I'm less sure. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[Babel-users] IETF Babel meeting tomorrow Wednesday 7 November
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/ and choose « Boromphimarn 3 ». See you all tomorrow, -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Fwd: Babeld redistribution problem
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 rule is: - if proto is specified, then only routes with the given proto are redistributed; - if proto is not specified, then all routes *except* the ones with proto 3 (boot) are redistributed. All of this is documented in the babeld manual page. In your case, it should be enough to remove the line that specifies "proto", and your static routes should get redistributed. Please let us know (on list) whether it works for you. Regards, -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] more nlogn crash details
> #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=, > id=0x1cf66b0 "\002%\220\377\376\302*\242\374c\311/S\266)j", hop_count=127) > at message.c:1806 Thanks, that's helpful. Fixed in branch rfc6126bis. ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Tcpdump or wireshark
> 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-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] Tcpdump or wireshark
>> 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: [udp sum ok] babel 2 (40) Hello seqno 64302 interval 4.00s sub-timestamp 3093.772159s IHU fe80::e246:9aff:fe4e:9178 txcost 292 interval 12.00s sub-timestamp 3629.213133s|3091.035168s ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
[Babel-users] Tcpdump or wireshark
> 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'll have a look. -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] unicast branch test
> 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 left is hmac? and dtls? No decision has been taken yet. I'm rather keen on merging HMAC (since we took a lot of care with Clara and Weronika to make it easy to merge). I'm a little more hesitant as to DTLS. On the one hand, it requires some changes to the core of Babel, on the other hand, most of the work has been done already (DTLS is why we wrote the unicast code in the first place). I guess it depends on how aggressive Antonin will want to be ;-) > I added default unicast true to one of those boxes, and yea! lots of unicast! > lots of ns solicit and response. Route transfers. over unicast. I'll be listening. -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
[Babel-users] Babel security [was: 57 forks of babel on github]
> One of my issues with crypto, rather than auth, is I'd wanted a way to > have a partially untrusted network to bootstrap off of and/or to allow at > least some unauthed or uncrypted nodes to participate with filters or inflated > metrics. The important thing to understand is that both security mechanisms that we're currently developing protect Babel messages. We're not attempting to secure Babel updates end-to-end. Both security models use auth per-interface. Either you allow anyone to associate on a given interface, or you require crypto on that interface. So in order to build a partially untrusted network: - set up security for your backbone links, either at the application layer (DTLS or HMAC), or at the link layer (WPA2, 802.1X) or at the physical layer (a guy or gal with an AK47 (Chinese clones will do) in front of every Ethernet socket); - set up strict filtering rules for your guest interfaces; - set up ingress firewall rules for your guest interfaces; - allow anyone to associate on the guest interfaces. To restate -- there is no way in Babel currently to have end-to-end signatures on route announcements. Doing that properly is difficult, and as far as I'm aware nobody is working on it. -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] unicast branch test
> 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 the unicast code. As soon as I have some time, I'll release 1.8.4, then branch off a new babeld-1.8 branch for bug fixes, and then merge all of the other branches into master. In the meantime, please run rfc6126bis only, and ignore all of the other branches. > An oddity, I think, is I see one box making a mh-request unicast, and > the other box seems to respond with a mcast (?). Perfectly legal and expected. > Is there fun, happy, new config options I can enable to enable way > more unicast? :) The unicast code does nothing by default. To enable it, say default unicast true in your config file. > However, I now have enough lab boxes to basically do interop between > a lot of versions, I figure adding 1.5, 1.6, 1.7.1 to the mix would be > useful? At this stage, we're only interested in reports against: - BIRD; - rfc6126bis/xroute-nlogn, soon to be master; - master, soon to be babeld-1.8 If you're running older routers, make sure that you say default rfc6126-compatible true in the config file of the more recent branches. > and I *gotta* go climb a few trees. And put Babel routers on a few drones? (Speak to Valent, in copy of this mail.) -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] basic bird//babeld interop for ss
> * 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 if you have time to debug that, that'd be helpful. ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Installer: 32 vs. 64 bit
Hi, I've been encouraging my students to install Debian on their personal machines, and we've found out that a lot of them get the wrong Debian installer: - some of them attempt to install an AMD64 version of Debian in a 32-bit-only virtual machine; - others attempt to install an i386 version on 64-bit hardware. In both cases, the installer crashes with no useful error message (in the former case, it crashes just after installing grub, in the latter case, it crashes straight away). This is a bad user experience, since the students lose a lot of time trying to work out the issue on their own before they ask for an appointment, and end up with the impression that installing Debian "never works". Could somebody please speak with the installer people so they make sure that the installation fails with a friendly user message in both of the cases outlined above? Thanks, -- Juliusz Chroboczek
[go-nuts] Re: Failed iterator proposals?
>> for i:=c.Iterator();i.HasNext(); {
>> v := i.Next()
>> }
> I don't like the eyeball friction.
Could you please explain what you mean?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Babel-users] Optimised xroute updates
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.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
