> 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.)
HMAC would resolve the need for the bottom layer. There are advantages to being able to share keys between the layers though. Not sure I would want to give up on Wireguard especially since we're so dependent on it for performance. All this encryption on little passively cooled processors is a real challenge. > 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. Link local is fine. The big kicker for Wireguard is uniqueness. -- Justin Kilpatrick [email protected] On Thu, Jun 20, 2019, at 1:59 PM, Juliusz Chroboczek wrote: > > 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 [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
