On 2025-01-14 16:53, Paul Wouters wrote:
On Jan 14, 2025, at 14:43, Soni "It/Its" L. <fakedme+i...@gmail.com> wrote:
>
> we really wanna be able to use ipsec in end-user applications...
If you look at my Opportunistic IPsec presentations (pdf and videos available),
you will an ondemand system triggered by DNS lookups in the resolver. Thus an
application looking up a dns name can cause ipsec tunnels to be established.
Key material is provided in DNS as well.
unfortunately, IPSECKEY is decoupled from the original A/AAAA lookup.
looking at DNS's history, we've had a few iterations of similar concepts
before (the lead-up to MX records, also A6 apparently) and they've all
negatively impacted deployment, so we don't see this as a viable
approach. and indeed, one of the implications of this experiment, if
successful, would be the introduction of IPSEC4 and IPSEC6 records,
combining an IP address and a public key.
Applications usually only have flows, not own
IP addresses, so your term “to use in an application” needs some clarification.
The above assumes a “this app wants to talk to X, if possible over IPsec” style
request.
Giving apps permissions to throw key material around can be dangerous. As the
resulting tunnels apply to all applications taking to the same remote IP
addresses.
we question the assumptions of this statement. there is nothing
preventing IP and IPsec from coexisting (or even multiple IPsec from
coexisting), just like there's nothing preventing IPv4 and IPv6 from
coexisting. (granted, IPv4 and IPv6 require separate routing, with all
the administrative overhead that comes with, while IPsec mostly should
not, aside from conntrack on the client/server node.)
Additionally, if you are behind NAT, there are other concerns such as being on
RFC1918 space and a remote server will have a hard time talking to two
applications on the same IP behind different NATs. That is why libreswan has
support for opportunistic using a NAT within the IPsec subsystem to give all
clients a unique IP from the servers’ view (who hands it out from its own
addresspool). The apps are not aware of this IP.
if we're being completely honest we don't really care about the
applicability of this experiment to IPv4. arguably IPsec should've just
have a way to turn off source address and port authentication (it's not
like they didn't know about NAT when it was being developed), but we're
a couple of decades too late for that (so none of the existing routers
would be able to use it, even if it were to exist now).
side note: the use case we have in mind only cares about authentication.
encryption is provided by TLS anyway.
Paul
--
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
