> 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. > 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. > > 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. _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
