Re: UDP checksums and inband control messages
Hello, Derek Fawcus writes: > I see from the code that currently the kernel UDP sockets > have checksums enabled. I also note the message from > November speculating upon if in band control messages > should be added. > > One thing I was pondering recently in the context of UDP tunnelling, > is that one doesn't really need to have UDP checksums on the > encapsulating packet, since they payload itself is eventually > protected by its IPv4 header checksum, and likewise its transport > payload being protected by its own TCP/UDP/etc checksum. > [OK - some exceptions, but valid to a first approximation] This is only correct for IPv4, IPv6 does not have a checksum field (coincidentally because all high level protocols implement their own checksum). > In the case of a crypto tunnel tunnel when using a > verified / authenticated crypto algorithm, any lower level > UDP checksum is even more redundent. Yes, but computing the UDP Checksum is really inexpensive in contrast to the authentication done on a packet with the correct checksum. > > The one place where UDP checksums would stil seem to be useful > is for any in band control messages, if they were themselves > not covered by the crypto layer. i.e. c.f. OpenVPN and > its payload vs control messages. > > Which then got me to thinking that one could sort of cheat, > and use the checksum field in the UDP header as an indicator > of if the payload is control or data. All zero bits for > data, none zero (including 0x) for control. > > This would also have the advantage that if one is using a system > without support for h/w checksum offload, one gets to save a > bit of CPU; however that may or may not be significant depending > upon just if/when packet memory if touched, and by which cores > in a system. i.e. I'm pondering a non Linux kernel implementation. > > So - thoughts? Is it worth doing something like this for wireguard? Greetings, Rouven Czerwinski ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
UDP checksums and inband control messages
I see from the code that currently the kernel UDP sockets have checksums enabled. I also note the message from November speculating upon if in band control messages should be added. One thing I was pondering recently in the context of UDP tunnelling, is that one doesn't really need to have UDP checksums on the encapsulating packet, since they payload itself is eventually protected by its IPv4 header checksum, and likewise its transport payload being protected by its own TCP/UDP/etc checksum. [OK - some exceptions, but valid to a first approximation] In the case of a crypto tunnel tunnel when using a verified / authenticated crypto algorithm, any lower level UDP checksum is even more redundent. The one place where UDP checksums would stil seem to be useful is for any in band control messages, if they were themselves not covered by the crypto layer. i.e. c.f. OpenVPN and its payload vs control messages. Which then got me to thinking that one could sort of cheat, and use the checksum field in the UDP header as an indicator of if the payload is control or data. All zero bits for data, none zero (including 0x) for control. This would also have the advantage that if one is using a system without support for h/w checksum offload, one gets to save a bit of CPU; however that may or may not be significant depending upon just if/when packet memory if touched, and by which cores in a system. i.e. I'm pondering a non Linux kernel implementation. So - thoughts? Is it worth doing something like this for wireguard? DF ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Question about SPDX marking on some crypto files
Hello, having just learnt of this product, I started poking through the source; when I got to some of the crypto code I noticed something curious, and did a bit more research. I'm curious about the SPDX licence marking on the crypto source files which seem to be autogenerated, specifically these: src/crypto/curve25519-fiat32.h - GPL-2.0 machine generated from https://github.com/mit-plv/fiat-crypto src/crypto/curve25519-hacl64.h - GPL-2.0 mahine generated from https://github.com/mitls/hacl-star The LICENCE file on the former site indicates that its code is MIT licence, so it seems odd that the output from its execution should be any more restrictive. Whereas for the latter site, its README.md explicitly states 'All generated C code is released under MIT', so again it seems odd to make the tag more restrictive. So was there simply an error made when the SPDX tags were applied, or has some additional significant manual addition occured to justify changing the licence? Doing any significant manual change to the output would however seem to defeat the object in using formally verified automatically generated implementations. Thanks. DF ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Alternative to UDP
Dear Eric, I strongly second Steve's opinion here: if you want this, make it option-defined, and definitely not the default option. The case study to look at is SCTP: https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol While an interesting and useful protocol, SCTP adoption and support is severely limited by the fact that it is an IP protocol on its own: SCTP gets dropped in 90% of implementations doing IP packet header operations (NAT, PCEF, Firewalls, 6to4 ...) Hope this helps, Best regards, Philippe Langlois. -- http://www.P1security.com Priority One Security This transmission is intended only for the use of the addressee and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately. On Mon, Feb 19, 2018 at 11:15 PM, Steve Gilberd wrote: > Hi, > > This feels like a bad idea to me - switching to a dedicated protocol would > remove a small amount of overhead, but comes with a lot of downsides, which > in my opinion outweighs the minor benefit of removing some of the overhead. > > I have a strong preference for the continued use of UDP, because a large > amount of consumer networking gear can't handle destination NAT for > anything that isn't UDP or TCP. And even wth gear that can, using a > separate IP protocol would limit clients relying on destination NAT to one > client machine per public IP. > > Cheers, > Steve > > > On Tue, 20 Feb 2018, 09:20 Eric Dillmann, wrote: > >> Hi, >> >> Today i discovered that OVH is limiting UDP rate to 6Mbit/s, i did a test >> by encapsulating wireguard in an ip/ip tunnel >> and got 90Mbit/S. >> >> Is there a way to make wireguard evolve to use it's own protocol number. >> >> That would prevent the overhead of wireguard over ipip/gre/vxlan ... >> >> Thanks, >> Regards, >> Eric >> ___ >> WireGuard mailing list >> WireGuard@lists.zx2c4.com >> https://lists.zx2c4.com/mailman/listinfo/wireguard >> > -- > > Cheers, > > *Steve Gilberd* > Erayd LTD *·* Consultant > *Phone: +64 4 974-4229 <+64%204-974%204229> **·** Mob: +64 27 565-3237 > <+64%2027%20565%203237>* > *PO Box 10019 The Terrace, Wellington 6143, NZ* > > ___ > WireGuard mailing list > WireGuard@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/wireguard > > ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Alternative to UDP
Hi, This feels like a bad idea to me - switching to a dedicated protocol would remove a small amount of overhead, but comes with a lot of downsides, which in my opinion outweighs the minor benefit of removing some of the overhead. I have a strong preference for the continued use of UDP, because a large amount of consumer networking gear can't handle destination NAT for anything that isn't UDP or TCP. And even wth gear that can, using a separate IP protocol would limit clients relying on destination NAT to one client machine per public IP. Cheers, Steve On Tue, 20 Feb 2018, 09:20 Eric Dillmann, wrote: > Hi, > > Today i discovered that OVH is limiting UDP rate to 6Mbit/s, i did a test > by encapsulating wireguard in an ip/ip tunnel > and got 90Mbit/S. > > Is there a way to make wireguard evolve to use it's own protocol number. > > That would prevent the overhead of wireguard over ipip/gre/vxlan ... > > Thanks, > Regards, > Eric > ___ > WireGuard mailing list > WireGuard@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/wireguard > -- Cheers, *Steve Gilberd* Erayd LTD *·* Consultant *Phone: +64 4 974-4229 **·** Mob: +64 27 565-3237* *PO Box 10019 The Terrace, Wellington 6143, NZ* ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Alternative to UDP
Hi, Today i discovered that OVH is limiting UDP rate to 6Mbit/s, i did a test by encapsulating wireguard in an ip/ip tunnel and got 90Mbit/S. Is there a way to make wireguard evolve to use it's own protocol number. That would prevent the overhead of wireguard over ipip/gre/vxlan ... Thanks, Regards, Eric ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
wireguard-go relative imports
Can someone tell me the reason why the wireguard-go package uses relative imports? This breaks go build when the working directory is inside of the /home/thesuess/workspace and thus wireguard-go cannot be installed via go get. What are the upsides to this approach? ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Compiling wireguard-go on non linux platforms
It seems wireguard-go is not exactly cross-platfrom at the moment, this is what happens at the moment when compiling os mac os: go build -o wireguard-go # _/Users/johan/projecten/testdevel/go/examples/wireguard-go ./main.go:94:11: undefined: CreateTUNFromFile ./main.go:108:11: undefined: UAPIOpen ./main.go:142:18: too many arguments in call to Daemonize have (*os.ProcAttr) want () ./main.go:165:15: undefined: UAPIListen ./tun_darwin.go:178:2: cannot use device (type *NativeTUN) as type TUNDevice in return argument: *NativeTUN does not implement TUNDevice (missing File method) make: *** [wireguard-go] Error 2 (Darwin Kernel Version 17.5.0: Mon Jan 29 02:17:30 PST 2018; root:xnu-4570.50.257~17/RELEASE_X86_64 x86_64) I noticed there was some discussion about not having a mac available to test cross-platform code. I do. If there is anything I can do to help to make the code work cross-platform, please let me know. Kind Regards, Johan Henselmans ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
