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. > 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. -- Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org