On Tue, 25 Apr 2006, Tero Kivinen wrote:
The architecture document describes all possible ways you could use IPsec in various different places.
That's exactly the problem. "All possible ways" and "various different places" create an architecture which apparently needs to be ambigious and generic to accommodate all those.. and in turn, such architecture appears to be very difficult to use (i.e., a failure) in many contexts.
If you only implement control plane protection, i.e. host to host IPsec with transport mode, there is things you do not have to implement. If you want to combine both control plane protection (host to host IPsec) and security gateway features (i.e. VPN usage) then you need to implement more of the architecture described in the rfc4301.
In almost all the cases, I think all major implementations need to support both.
The model described below is nominal; implementations need not match details of this model as presented, but the external behavior of implementations MUST correspond to the externally observable characteristics of this model in order to be compliant.
That's nice -- unfortunately, unless the motivation of IPsec folks was to make it more difficult to create new (competing) implementations, leaving out important details on what the spec actually means and what's the best way to implement things may be an issue.
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.