On Sun, Apr 5, 2015 at 6:56 AM, Juliusz Chroboczek <[email protected]> wrote: > Sorry for the delay, I needed to think this over. > >>> In the light of the above figures -- can I trust an IETF working group >>> to understand that a huge amount of effort has been put into removing >>> mechanisms from this protocol, and to respect that work? > >> Yes, I think that the requirement for minimal mechanisms and a simple >> easy to implement and troubleshoot protocol can be clearly expressed. > > Here's some initial and incomplete input. I'm just thinking aloud, and > perhaps taking my God-given right to say something stupid.
My vote is for juliusz as benevolent dictator for life. Can that go in an RFC? > I'd like the charter to clearly state that no mechanism will be added > unless there is experimental data to show that it is necessary in > realistic situations. For example, should people believe that an > additional congestion control mechanism is needed, they will need to show > experimental data that prove their point. I think in larger lans ECN would be nice as a means of distinguishing between connectivity loss and congestive loss... but am totally willing to produce experimental data in favor for or against, and to wait til I get around to it as part of the upcoming short-RTT work. > I'd like the charter to clearly state that security considerations are > outside the scope of the base spec. The base spec says "This is > a completely insecure protocol" and I much prefer this frank admission of > failure to a half-baked solution, which would then prevent better security > mechanisms from being developed. (I am not a security specialist, and > while I'm really glad about RFC 7298 (HMAC auth for Babel), I am not > competent to judge whether it is the only solution.) Agree. Security has two meanings here, one of which is not useful, one that may be. The "lets encrypt and authenticate everything" part is not terribly useful (particularly in a world that still has arp and ra). I see no reason for e2e encryption here, do see so a small one for authentication, but am not sure it needs to be e2e. A part that *usefully* allowed a network to allow a mixture of authenticated nodes (injecting default routes), while retaining un-authenticated routing for other nodes would be nice. I only briefly deployed the HMAC auth, but as the quagga version fell too far behind the mainline, did not gain enough operational experience with it to have a feel for it. I look forward to seeing it in babeld-1.7. ... somewhat related ... I have a smallish bcp38-ish like document for some best current practices (like filtering out local announcements of non-rfc1918 addresses, filtering out route announcements for the hip 1.0.0.0/24, 2001:10::/28, and advice to not announce local-only vpn routes) which I could maybe finish by Prague. (On the other hand I think it is easier read if on a wiki.) ... But it is the prospect of someone with a laptop announcing the lowest metric possible default route is through them and out via 3G that is the biggest hole in the "security" of not just babel, but all non-authenticated routing protocols (targeted at the home. at least. So far as I know there are a lot of insecured routing protocol *deployments* in general. Someone feel free to correct me). > I'd like the suggested metrics to remain informative appendices, contrary > to Ted's opinion. Babel's main claim to fame is that it's an extremely > flexible protocol, and putting the suggested metrics in the body of the > document is contrary with the main goal. All routing metrics to date have had various degrees of suckage. Agree. > I'd also like the other metrics > (as well as source-specific routing) to remain separate documents, since > they require extensions to the packet format. I am not sure if I share the word "metric" here for source specific routing. I would support a rollup rfc6126.bis after several more years of deployment experience. > There is only one mechanism in the base spec that is not currently used by > implementations -- it's the reliable transport building block defined in > Section 3.3. It has very low cost (20 lines of code or so in the > C version), so it's a MUST, since it is only useful if implemented by all > nodes. I have no strong feelings about whether it should stay. > > It is not clear to me whether the extension mechanism should be merged > into the base spec. I think the answer is yes, but in the meantime this > should not delay the publication of > draft-chroboczek-babel-extension-mechanism-04 as an Experimental RFC. > Sorry for the underfull hbox. Can live. > The packet format is a little messy, but extremely compact, which is > useful in meshy places. I believe that Joel Halpern dislikes it, I'm not > so sure I like it myself. I hold no opinion whether it should be replaced > by a cleaner but more costly format -- it's a difficult choice. I have no desire to further mess with the wire format at the moment. I like very much that it carries both ipv4 and ipv6 in the same packet. > -- Juliusz -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
