Date: Thu, 16 Jan 2025 17:31:01 -0300 From: "Soni \"It/Its\" L." <fakedme+freebsd@gmail.com> To: Vadim Goncharov <vadimnuclight@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: ipsec as an address family Message-ID: <d609729a-2455-4b8d-9cf7-fab049c4ec3a@gmail.com> In-Reply-To: <20250116225743.3bffd39f@nuclight.lan> References: <aac3846a-ccfa-41bd-a7e1-4ee940f3c095@gmail.com> <20250116225743.3bffd39f@nuclight.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
On 2025-01-16 16:57, Vadim Goncharov wrote:
> Could you provide technical overview, both from API and packet format side, at
> least briefly?
>
packet format is just regular ipsec, there are no protocol changes required!
API... we're currently thinking the sockaddr_ipsec struct would take a
key (appropriate for the task, e.g. public key for connect, private key
for bind). we're however not so certain about the private key part, but
at least for connecting, it makes sense to just take the public key of
the target. ideally we would also be able to request just
authentication, just encryption, or both, tho we're not entirely sure
how the API should look (authentication-only is the most useful to us,
as we're just trying to prevent port scanning and most modern protocols
(TLS, SSH, minecraft server protocol, etc) provide their own encryption
anyway).
it's not unusual to have an asymmetry between connect and bind, as an
example, port 0 is reserved for connect but lets the OS pick a port for
bind.
[-- Attachment #2 --]
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 2025-01-16 16:57, Vadim Goncharov
wrote:<span style="white-space: pre-wrap">
</span></div>
<blockquote type="cite"
cite="mid:20250116225743.3bffd39f@nuclight.lan">
<pre class="moz-quote-pre" wrap="">
Could you provide technical overview, both from API and packet format side, at
least briefly?
</pre>
</blockquote>
<br>
packet format is just regular ipsec, there are no protocol changes
required!<br>
<br>
API... we're currently thinking the sockaddr_ipsec struct would take
a key (appropriate for the task, e.g. public key for connect,
private key for bind). we're however not so certain about the
private key part, but at least for connecting, it makes sense to
just take the public key of the target. ideally we would also be
able to request just authentication, just encryption, or both, tho
we're not entirely sure how the API should look (authentication-only
is the most useful to us, as we're just trying to prevent port
scanning and most modern protocols (TLS, SSH, minecraft server
protocol, etc) provide their own encryption anyway).<br>
<br>
it's not unusual to have an asymmetry between connect and bind, as
an example, port 0 is reserved for connect but lets the OS pick a
port for bind.<br>
</body>
</html>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d609729a-2455-4b8d-9cf7-fab049c4ec3a>