Hi Martin, To answer a few but not all of your questions:
On Wed, May 27, 2020 at 1:34 AM Martin Pieuchot <m...@openbsd.org> wrote: > First question is, is it possible to use the wg(4) interface without a > port? No, that is not how WireGuard works. For details on the actual protocol particulars, please see https://www.wireguard.com/papers/wireguard.pdf . Our rev 1 submission has links to further links as well in the cover letter. > Aren't wg_noise.c and wg_cookie.c meant to be used by if_wg.c only? Or > would other parts of the kernel benefit from them? If wg(4) is the only > user I'm questionnings whether putting them in crypto/ is the best choice. Yes, they should only be used by if_wg.c. Moving them closer to if_wg.c would make sense imo. > Is IFT_WIREGUARD needed? Isn't the interface a point-to-point interface? It is a point to point interface, but it also has some important traits that point to point interfaces do not have. In this case, that means disabling automatically generated v6 ip addresses, which wireguard explicitly does not support. (It does support manually generated and cryptographically bound link local v6 addresses, however.) > Why did you re-implemented a routing table? Did you consider storing > the information you need in existing data structures? WireGuard's cryptokey routing is a different structure with different semantics and is intended to work separately from the normal system routing table. Trying to merge the two is a recipe for disaster. Paper has details. > My overall impression is that this can be simplified and integrate > better in the kernel :) If you could explain the basic architecture or > point me where you explained it, it would help. See paper above. Also see links on cover letter of rev 1 submission. Regards, Jason
