On 2025-01-14 17:36, Michael Richardson wrote:
Hi,
"Soni \"It/Its\" L." <fakedme+i...@gmail.com> wrote:
> we've been looking at various ipsec RFCs, mailing list discussions,
> deployments, etc, and the protocol looks very neat, this "transport
> mode" stuff looks really useful, but we see no way for an app to use
> it.
RFC2367 is kinda the only document that ever got published that specified an
API. It was always intended to extend to userspace situations, and there are
socket options in some operating systems that invoke it, it has never caught
on.
Solaris probably had the best *documentation* on the APIs that they had.
*BSD, Windows, Linux and Solaris all have per-socket IPsec controls already,
but quality of implementation and quality of *documentation* varies. A few
searches tells me that Solaris documentation probably is not as good as I
recall :-(
https://docs.oracle.com/cd/E37838_01/html/E60993/ipsectask-2.html
When we did BTNS, https://datatracker.ietf.org/wg/btns/documents/ we
attempted to also do a better API, and I implemented some of it once to get
the channel bindings into the application. That code never really got released.
> we would like to propose a small experiment which we would call "ipsec
> address families". rather than using ipv4 or ipv6 address families and
> letting the os quietly use ipsec but only if configured by the admin,
> the application would open a socket explicitly for ipsec, either on
> ipv4 or ipv6, and then give it public key material (for connect) or
> private key material (for listen) and then the application can enforce
> ipsec instead.
Go ahead.
I think a new address family is a mistake because it has to go through the
entire application. And how would you *then* specify the actual intended
destination?
I guess you could have an IPv6++ socketaddr that included more info, and this
was definitely a direction I persued once.
Maybe you can use some part of IPv6 to specify secure destinations, with the
IKE daemon knowing what the real destination is. IPSECKEY RR might help (or
not).
You don't be popular for having/handling private key material in applications.
Instead, I suggest specify identities using an abstraction that gets you a
"slot"
number or other identifier that can be used with, for instance libnsa and
PKCS11.
yeah, managing private keys is hard. but also, how would you do it when
you want each application to manage its own keys?
so we mean, the use-case we have in mind is that we want to make the
internet a more shodan-resistant place. shodan scans the entire ipv4
address space multiple times a day.
it's a lot easier to add a new address family to an app that already
supports dual-stack, than to extend existing protocols to accept a token
value that shodan doesn't have access to. or indeed just switch to
ipv6-only and that also gets rid of shodan (at least, in the "ip address
space scanning" context. we think shodan also scans dns and certificate
transparency, so you wouldn't be able to protect against that. but
still, we could be doing better than we are today...)
in particular, this is a huge issue with minecraft servers. mojang could
fix it with a minimal rework of the server protocol but we think an
internet-wide solution would be a better approach in the long run.
> thoughts? would anyone be interested in this idea? we really wanna be
> able to use ipsec in end-user applications...
I don't think you need any IANA allocation or bits on the wire changes, I think
you
should just *do it* and tell us. If you need new IKEv2 Notifies, they are
easily acquired.
yeah, that's what makes ipsec so interesting to us, it should "just
work"! tho we don't believe we will be able to do this alone...
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
--
plural system (tend to say 'we'), it/she/they, it instead of you
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
