I have checked some of the archived messages on this topic, but not all.
I have a few points of view that I would be grateful for some feedback on
regarding using IPSEC to protect syslog.
IPSEC/IKE/PKI is regarded as 'the best available' key management,
authentication and encryption suite. Although IPSEC has been architected as
a 'system-wide' or 'interface-wide' security screen, this is just one of the
implementation options. It can be used/implemented in a similar way to other
system services. For example, a protocol stream, say SNMP, could use an
IPSEC API to express an interest in an SNMP stream (or more than one) to a
particular host/protocol/port using specific connection authentication
information (pre-shared secret, certificate, other 'legacy' authentication).
IPSEC has been implemented on Solaris, Windows, Apple, Lynix, Firewalls,
Routers/Switches.
Even with other changes that may be needed to syslog (reliable transport?),
it seems useful to re-use the best, and most widely deployed IP protection
protocols.
This would also allow protection of 'legacy' syslog, or protection of any
unicast IP flow for that matter.
Separating security and syslog allows the two 'technologies' to evolve
separately with the generic security developments being available to other
protocols as other security risks are addressed.
I have read in the archive about the requirement for syslog 'finger-printed'
messages, so that the authenticity of messages can be checked latter. If
IPSEC is protecting the syslog messages arriving, then this option could be
disabled. If the authenticity needs to be 'historical' or 'mobile', then per
message finger printing could be used as well - perhaps using digital
signatures (another service from the 'security API' perhaps).
Thanks, Steve.
