This might have slipped due to holidays last year. I would like to know if there is any interest in documenting the use of x25519-sntrup761 as used in OpenIKED ?
On Thu, 19 Dec 2024 at 12:08, Loganaden Velvindron <[email protected]> wrote: > > Hi All, > > The OpenBSD project develops its own IPsec implementation known as OpenIKED. > > OpenIKED supports x25519+sntrup761 as a key exchange with the following > option: > 'ikesa group sntrup761x25519' > > OpenBSD users are already using this in production: > See this email: > " > Hi David, Hi tech@, > > I somehow managed to configure a few sec(4) interfaces and everything worked > fine yesterday. This morning as i got up I noticed my nightly recycling of > pppoe0 broke everything. I tried to bring it back but noticed that no flows > would be installed by iked. I had to revert yesterdays configuration of > changing everything to sec(4). > > I have a dynamic IP through an ISP in germany which outsourced the last mile > to telekom (DTAG). What I do is I go through everything through my cloud > provider by IPSEC'ing the traffic from the dynamic IP to the cloud VPS. It > works well except in one aspect. The IPSEC without sec(4) is doggedly slow, > so there has to be something like an MTU issue or something. To make matters > a little more complicated, I have a wireguard tunnel inside the IPSEC so it's > doubly encrypted with AES 256. This has a caveat that when the IPSEC is not > configured with iked, the wireguard will not initiate either as the telekom > or this ISP have installed certain filters preventing wireguards initiation > signature. However once it is initiated it will function nicely. > > My pppoe0 when it connects has only 1 route, to the VPS. It does not have > a default route. For sec0 it was weird configuring it with an IP of 0.0.0.0/0 > or 0.0.0.2/0 to indicate that it is of dynamic nature and I don't know before- > hand what the IP is going to be. I somehow believe that this caused problems > and sec(4) is not really meant to be on dynamic PPPoE. > > I propose this pseudo-driver change: Much like vlan(4) it should be > configured > on top of the physical or other pseudo interface, that way it knows it's > dynamic IP. The condition it will dynamically do this is when the source IP > is in the 0.0.0.0/24 netblock. For the other side it's reversed we know the > source IP but not the destination, configuring it to the 0.0.0.0/24 netblock > again should be indication enough that this is an arbitrary IP somewhere on > the Internet. The same concept could be done or IPv6 configs. > > I'd be willing to look into this but my TODO is growing and growing, I can't. > I have too many projects on my plate right now. I'll let you in on my dynamic > IPSEC/IKED config. > > ... > ikev2 passive transport esp from $self_ip to $telekom_ip1 \ > ikesa enc aes-256-gcm \ > group sntrup761x25519 \ > childsa enc aes-256-gcm \ > group sntrup761x25519 \ > srcid $self_ip lifetime 1200 tag "IPSEC" > ... > > There is similar $telekom_ip0, $telekom_ip2, and $telekom_ip3 as they are > pooled by 4 different /10's and alternate. This is a working config. With > sec(4) it breaks though (even with the added iface sec0). > > In the above config paste the $telekom_ip1 is 87.128.0.0/10 and the $self_ip > is self explanatory (it's the IP of the VPS). > > Is something like this already on a TODO somewhere? Or is there a trick or > hint that I can get how to make this work with dynamic IP's with sec(4)? > > Otherwise my proposal should be considered, and if nothings done by autumn > I can perhaps look into that. > > Best Regards, > -pjp > > Peter J. Philipp > " > Would a draft to have sntrup761 be good for documenting this choice of hybrid > ? > > Kind regards, > //Logan _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
