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
