I should add that the lack of IPsec-specific APIs has been a large
reason why we don't see large-scale deployment of end-to-end IPsec.
A lot of folks seem to agree, and we're working on abstract IPsec APIs
at the IETF, and I know that Dan wants to see our IPsec APIs improved.
It'd be very odd to do all that for IPsec but not for TCP MD5! Why
perpetuate mistakes made in the IPsec world? Just because it fits into
ipsecconf(1M)? I reject that rationale.
Also, IPsec APIs are particularly difficult to design and implement
because without a notion of IPsec channel (think connection latching[*])
the only reasonable APIs are ones that look a lot like our admin 1M and
4 interfaces, which is just too difficult to program to.
But TCP *is* a "channel" in this sense, and so APIs are much simpler to
design and implement in this case (per-socket options/function calls vs.
editing configuration files or running admin commands that edit system
configuration).
[*] Dan invented connection latching precisely as a way to make simple
IPsec APIs feasible, IIUC (in any case, it does do that).
Nico
--
_______________________________________________
networking-discuss mailing list
[email protected]
