On 2025-01-14 18:01, Paul Wouters wrote:
> On Jan 14, 2025, at 15:43, Soni "It/Its" L. <fakedme+i...@gmail.com> wrote:
>
>
>
>> 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.
Not in our PoC with unbound DNS resolver.
Its IPsec module specifically triggers IPSECKEY lookups for QNAMEs and sends
these to the IKE daemon before it returns the resulting A/AAAA to the
application.
this matters for DNS caches too. you can end up desyncing IPSECKEY and
AAAA. and let's not forget when you have multiple AAAAs and they don't
all point to the same machine.
> 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.
You’d better use SVCB records then instead of creating a new RRtype ?
>> 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.
If you have a tunnel to 8.8.8.8 you can’t also have plaintext to 8.8.8.8. I
mean you can segment the network space and have apps run it in but limiting
your tunnel to an app requires careful orchestration of all network connections
on a host. Some OSes can place apps in a “require vpn” but even that is much
simpler than what you propose.
what do you mean? TCP/IPsec and TCP/IP are separate protocols, the OS
should be able to handle that quite naturally, should be no different
from dual-stack really.
>
> 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).
>
Sadly NAT will exist with IPv6 too.
at least address translation is a lot easier to deal with than port
translation, what with port numbers not existing in IPsec.
--
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
