Twee vragen:

1. Waarom moet dit de kernel in, kan dit niet gewoon user-mode code zijn?

2. Wat vindt Linus hiervan?

Gaafheid. "Kijk, ik ben auteur van dit stuk software en het zit standaard in de linuxkernel!

Het wordt er een soort standaardkeuze mee dus druk je de concurrentie weg. En dat landjepik is gelijk een makke van het ontwikkelmodel van linux, al is het een secundair effect. Mischien dat er wel solide technische redenen voor te verzinnen zijn hoor, maar ik zie het toch primair als "kijk mij toch populair zijn".

Dat merken we gauw genoeg.

Op de site staat aangegeven waarom.

Linus is voor: https://lkml.org/lkml/2018/2/13/752

Linux is voor! https://lkml.org/lkml/2018/2/13/752

https://tweakers.net/nieuws/141611/voorstel-moet-wireguard-aan-linux-kernel-toevoegen-voor-beveiligde-vpn-tunnels.html

TheYOSH

Dat antwoord mist een URI; desite.com is het klaarblijkelijk niet.

Lang geleden dit:
Bron: https://lkml.org/lkml/2018/2/13/752

Sommige mensen zijn inderdaad wel erg snel met zeggen 'staat op de site' , want het staat er amper .

op https://www.wireguard.com/ staat een kleine blurb 'high performance' met daarin "A combination of extremely high-speed cryptographic primitives and the fact that WireGuard lives inside the Linux kernel means that secure networking can be very high-speed"

Je kunt dit min of meer lezen dat performance een reden is voor een in-kernel implementatie .

Dat wordt ondersteund door het whitepaper op p18

https://www.wireguard.com/papers/wireguard.pdf

"7.6 Potential Userspace Implementations
In order for WireGuard to have widespread adoption, more implementations than our current one for the Linux
kernel must be written. As a next step, the authors plan to implement a cross-platform low-speed user space
TUN-based implementation in a safe yet high-speed language like Rust, Go, or Haskell."

(zie 'low-speed user space TUN-based.. )

Ik denk overigens wel dat het een valide argument is - dwz, dat het heen en weer kopiëren van packets naar userspace heel stevig performance impact heeft .

Wat het zo lastig maakt om een algemeen bruikbare VPN oplossing te ontwikkelen is o.a. dat het zo'n breed inzetbaar
product is. "speciaal voor Linux ontwikkeld" dat parkeert het meteen al in een niche hoek waarmee het nooit zo
algemeen gebruikt zal worden als IPsec. Als het niet beschikbaar is op de bekende routers, wat moet je er dan mee
zou je zeggen. Dit is ook een probleem van OpenVPN en dat is dan tenminste nog wel voor Windows en een enkele
specifieke router beschikbaar.

Ik ben het er mee eens dat IPsec veel te ingewikkeld is maar ik kan me niet voorstellen dat het voorgestelde protocol
"sneller" is. IPsec is vaak hardware-accellerated en dan valt er weinig meer te winnen.
Waar de problemen bij praktische inzet beginnen is bijvoorbeeld het opzetten van de netwerkconfiguratie na tot stand
komen van de VPN. Daar heb je bij OpenVPN allerlei mogelijkheden (pushen van routes naar de juiste subnetten)
en dan is het iets simpeler om "door de eindgebruiker opgezette VPN" te ondersteunen, maar zelfs dat is eigenlijk
al te beperkt (geen ondersteuning voor policy routing). Ik ben benieuwd hoe men dat gaat aanpakken, "dat komt
allemaal in de volgende versie" daar win je het niet mee.

Beperken tot UDP transport kan ook een probleem zijn. Bij het gebruik van OpenVPN en IPsec over UDP ben ik
al een paar keer tegen "door anderen beheerde routers" aangelopen die er geen zin in hebben om grote hoeveelheden
UDP verkeer te verstouwen. Fallback naar TCP moet dan mogelijk zijn hoe gruwelijk dat verder ook is.
Helaas werkt dat met OpenVPN ook niet. OpenVPN support wel UDP en TCP maar een server kan altijd alleen
UDP of TCP zijn, nooit beiden.

Er is best nog wel wat te wensen op VPN gebied maar ik krijg niet direct de indruk dat dit product zo veel beter is
dan andere alternatieven als je het hele gamma bekijkt en niet alleen kijkt naar een simpele toepassing.

Misschien zou dat ook interesant kunnen zijn in de nieuwe Mac Os Mojave die in Oktober uit komt,die in de kernel te doen.
In Ios net zo,en voor Mac Tv os.

Dat op zich kan wel - vaak is de hardware acceleration alleen AES (bulk throughput) - als je snellere crypto primitieven gebruikt voor signing en sessie setup kun je daarin veel winnen. Misschien niet zichtbaar bij een heel lange download, maar een snelle sessie setup is erg prettig - en snel merkbaar .

Ik weet niet _of_ dit het geval bij Wireguard, maar alleen 'hardware accelerated' zegt nog niet meteen "niks kan meer sneller" .

[..]

TCP-over-TCP is wel extreem gruwelijk. TCP heeft de feedback van packet arrival tijden heel hard nodig , en die behoud je alleen met encapsulatie in een protocol zonder eigen buffering transmissie regulatie .

Ik denk niet dat _volumes_ UDP het probleem zijn - dan heb je al snel Chrome-met google kapot gemaakt, omdat dat default naar QUICC .

Wat wel makkelijk kapot kan gaan - UDP met fragmentatie samen met een heel klein beetje packetloss .
( Ja AVM, ik kijk naar die $@%! 7581 van jullie - met SSL VPN . SSL VPN gebruikt UDP/443 )
Met alle encryptie en encapsulatie wordt een payload van 1500 bytes gefragmenteerd - en devices die zo nodig state willen tracken houden niet van fragmentatie . Met een klein beetje packet loss kan zo'n device dan makkelijk de tel kwijtraken .

Grotendeels eens met je reactie dat het (nog) geen volwaardige vervanger is van IPSec. Ik zie echter wel de use cases, vooral voor mobiele devices. De gebruikte ChaCha20/Poly1305 encryptie/auth is ideaal voor mobiele devices zonder hardware crypto versnelling. Tevens is opzetten een breeze vergeleken met IPSec.

Ik denk dat het voor het scenario "road warrior" momenteel al goed inzetbaar is. Met IPSec zat ik lang te k*tten, maar WireGuard begrijpen en opzetten was zo gebeurd. Als alternatief voor de OpenSSH VPN functionaliteit lijkt het me ook al prima inzetbaar, het is gemakkelijker en qua concept vergelijkbaar.

Dat het voor Linux ontwikkeld is wil niet zeggen dat het protocol, dat wat over de lijn gaat, alleen vanaf Linux kan werken. Ik zie zelfs geen enkele reden waarom een dergelijk protocol ook maar iets zou bevatten dat aan een specifiek OS gebonden is, "voor Linux ontwikkeld" wil zeggen dat de nu enige implementatie maatwerk voor de Linux-kernel is, maar dat sluit andere implentaties niet uit.

Aangezien heel wat routers onder Linux draaien kan een protocol dat het goed op minder krachtige apparaten doet juist heel interessant zijn, ook als achter de router Windows-machines staan.

Wat er te winnen valt is dat je niet van die hardware afhankelijk bent om een goede performance te halen. Dat kan ook voor routerfabrikanten interessant zijn.
Als het totaal overbodig blijkt te zijn dan zal het ook wel weer uit zicht en uiteindelijk uit de Linux-kernel verdwijnen. Als het de potentie heeft een razend succes te worden dan is het goed om het te proberen. En bij een uitkomst die ergens tussen die uitersten inzit is het iets dat zijn bestaansrecht aan zijn eigen niche ontleent en is het ook goed om te proberen.

Heel erg voor zelfs:

https://lkml.org/lkml/2018/8/2/663

(quote, gericht aan David Miller, maintainer van de netwerk code )

"Btw, on an unrelated issue: I see that Jason actually made the pull
request to have wireguard included in the kernel.

Can I just once again state my love for it and hope it gets merged
soon? Maybe the code isn't perfect, but I've skimmed it, and compared
to the horrors that are OpenVPN and IPSec, it's a work of art.

Linus
"