search

cloudflare / boringtun

Userspace WireGuard® Implementation in Rust
BSD 3-Clause "New" or "Revised" License
5.92k stars 397 forks source link

feat: registry trait #310

Closed thrykol closed 1 year ago

thrykol commented 1 year ago

Encapsulates peer management logic within a trait to facilitate managing peers using external resources. InMemoryRegistry and () implementations are provided to make the change nearly invisible to existing projects. Due to adding a generic to the Device trait, projects will need to instantiate a DeviceHandle with a generic type via DeviceHandle::<()>::new().

I know there's some work in the pipeline on refactoring the API to be more extensible but didn't see any branches to base things on. In order to minimize the scope of the PR, I've opted to keep everything synchronous but would like to see the methods in the Registry trait be async/await at some point. Hoping this PR starts some dialog around that refactor.

Noah-Kennedy commented 1 year ago

@thrykol this should be done by just using noise and implementing a peermap and cryptokey routing system around it, which is what we are looking to do to device. The issue with device is that the whole API surface needs broken up. We don't need to drop more hooks into it.

thrykol commented 1 year ago

@Noah-Kennedy understood on the issue with an additional hook. Just trying to get things working with pre-existing requirements on my end. :) I'm not very familiar with the project in general aside. Are there any examples I can take advantage of or any pointers on what I can look at specifically?

Noah-Kennedy commented 1 year ago

@thrykol noise has a Tunn API that represents a single tunnel with a single peer. You would need to implement Cryptokey routing on top of that so that you can associate incoming packets, both on the tun interface side and on the wireguard side, with Peer and Tunn objects representing those remotes, which encode all the session and timer info.