On Jan 11, 2025, at 08:09, Loganaden Velvindron <logana...@gmail.com> wrote: > > 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 ?
I know strongswan had a lot of experimental PQ algos, including NewHope and NTRUprime. These predate the INTERMEDIATE and ADDITIONAL_KE methods later designed to carry PQ algorithms. I am not aware of what openiked has implemented. This old strongswan testing stuff or some private use code point using the new stuff. The old strongswan mechanisms are not what is being standardized with IKE now. Do you know more about what implementation openiked used ? But also, personally I am not interested in NTRUprime at this point. I am interested in a pure mlkem and 25519mlkem hybrid. Possibly frodokem as alternative for mlkem. Paul > > >> On Thu, 19 Dec 2024 at 12:08, Loganaden Velvindron <logana...@gmail.com> >> 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 -- ipsec@ietf.org > To unsubscribe send an email to ipsec-le...@ietf.org _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
