Re: potentially disallowing IP fragmentation on wg packets, and handling routing loops better
On Sun, Jun 06, 2021 at 01:14:16PM +0200, Peter Linder wrote: > This would break things for me. We're doing a lot of L2 over L3 site to > site stuff and we are using wireguard as the outer layer. Inner layer is > vxlan or l2tpv3. > > In particular, people connect lots of stuff with no regard for MTU. For > some things it's also very hard to change so we just assume people > don't. Since the L3 network typically has the same MTU as the inner L2 > network, we need fragmentation. There is no practical way to be able to > tell hosts on the L2 network about the limited mtu, for all we know they > don't even run IP I've not looked in to vxlan much, but for L2TP you always have recourse to RFC 4623, where the MRU & MRRU can be exchanged. DF
Re: Interest in adding multicast support to Wireguard?
Various routers have support for running PIM (and IGMP/MLD) in NBMA mode, whereby individual hosts and joins/leave for such are tracked, rather than depend upon a shared broadcast medium. This is used for mcast over Frame Relay, ATM, etc which are inherently NBMA. ISTM that wg should also be modelled as NBMA, and as such the same sorts of approaches should be taken. DF
Re: Fragmentation on UDP layer possible?
UDP may (eventually) get a native segmentation capability, but the work is still under discussion, and possibly subject to change. See the FRAG option within draft-ietf-tsvwg-udp-options (https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-05) DF ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: PMTU Discovery Security Concerns
On Mon, Apr 16, 2018 at 07:23:29AM +0200, Jason A. Donenfeld wrote: > > See RFC4821, RFC8085 and > > https://tools.ietf.org/html/draft-ietf-tsvwg-datagram-plpmtud-01 > > for more info about PLMTUD. > > > > https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-packetization-layer-path-mtu-discovery-01 > > has a quick overview of where IPsec stands with implementing it. > > Thanks for these. I followed the rabbit hole, and found [1], which > seems to be the current latest and greatest from the IPsec people. > It's probes inside the control plane. Using something based upon that UDP version of PLMTUD would seem to be the correct approach, sending probe packets protected by the encryption layer. Rather than have it totally based upon the control layer, one could use a data layer notification of decrypted packets arriving to indicate that certain sizes have been received, then reflect those back to the sender in a minimal encrypted ack packet. i.e. something similar to how solicited probe responses operate for IPv6 NDP. Keep in mind that the PMTU may be different in the two directions. DF ___ 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
