[Babel-users] althea presentation on isp in a box at nanog 76

[Justin Kilpatrick]

> 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
  justin at altheamesh.com

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
>