mirror of
https://github.com/linuxkit/linuxkit.git
synced 2025-07-19 01:06:27 +00:00
Merge pull request #2248 from tych0/sig-security-2017-07-19
sig-security: add notes from 2017-07-19
This commit is contained in:
commit
4fb767a480
@ -20,3 +20,36 @@ Previous meeting notes: [2017-07-05](2017-07-05.md)
|
||||
- we can propose additional deep dives and discussion topics!
|
||||
|
||||
## Meeting Notes
|
||||
|
||||
- WireGuard intro;
|
||||
[slides](https://www.wireguard.com/talks/dockersig2017-slides.pdf) are
|
||||
comprehensive, below is a small discussion of questions that occurred
|
||||
- Jason Donenfeld the author and maintainer
|
||||
- Patches for traditional userspace tools (ifupdown, OpenWRT/LEDE,
|
||||
OpenRC netifrc, NixOS, systemd-networkd WIP, NetworkManager WIP) available
|
||||
to allow ease of interface configuration
|
||||
- demo
|
||||
- ip and wg tools used to configure and inspect WireGuard interfaces
|
||||
- no patches needed for iproute2, since the string "WireGuard" just gets
|
||||
passed to the kernel via netlink when doing `ip link add type wireguard`
|
||||
- WireGuard can live in one netns, physical interface can live in another
|
||||
- so you can put wg0 in a container as the only interface, and it *must*
|
||||
connect to the world via this interface
|
||||
- No additional traffic necessary when packets are successfully sent/received
|
||||
- When a unidirectional packet is sent, WireGuard sends back an empty ack
|
||||
packet
|
||||
- Kernel networking stack is the one allocating the packet buffers,
|
||||
WireGuard doesn't allocate anything on top of this
|
||||
- WireGuard overhead = UDP header + WireGuard = 60 bytes
|
||||
- performance
|
||||
- fast, no copies across \*space
|
||||
- ChaChaPoly is fast
|
||||
- upstreaming status:
|
||||
- no v1 posted
|
||||
- need to move from ioctl => netlink
|
||||
- need to improve kernel crypto API to remove allocations
|
||||
- maturity
|
||||
- officially "experimental"
|
||||
- formally verified, "pretty damn stable" :)
|
||||
- may break protocol, but hopefully not now that it's verified
|
||||
- Next meeting August 2nd, please propose topics!
|
||||
|
Loading…
Reference in New Issue
Block a user