On Wed, 20 Oct 1999 10:54:24 -0500, Chris M. Lonvick wrote:
[snip]
>The underlying protocol:
>Verifiable delivery would require that some sort of 'state' be maintained
>between each sender and receiver. This could be accomplished through any
>of the following:
>(1) UDP with a positive acknowledgement scheme,
>(2) TCP for each message, or
>(3) persistent TCP connection between sender and receiver.
I'm not sure that this merits much attention. I suspect it will end up
as a configuration option much like the port number and interfaces
to listen on.
>The use of Timestamps:
>A lot of different parts to this could add their own timestamp: the entity
>that first generated the message, the sending syslogger program, our
>proposed protocol, the receiving entity, intermediate entities, etc. While
>I agree that having consistent clocks across a network is very good, I've
>seen many large networks that don't implement it. Mandating ntp in [yet
>another] RFC will still not change the minds of many people and it will not
>automagically implement a consistent clock in their networks.
I agree. NTP does not belong in this layer of abstraction.
[snip]
>The use of Cryptography:
>IPSec is available and can offer strong authentication, integrity and
>confidentiality. For establishing a syslogging architecture, I could see
>that an administrator would want integrity and confidentiality of messages
>and in most cases would also want strong authentication. I would suspect
>that some administrators would like to set up a new machine in the network
>and just point it at the syslog server with as little work as possible. In
>that case, it would require a lot more work to implement IPSec - possibly
>more than an administrator is willing to deal with at that time.
>
>I would like to recommend that a low-effort, commonly available encryption
>method be built-into the protocol for administrators requiring integrity
>and/or confidentiality. They should have the ability to disable that if
>they do not require (or cannot legally implement) it. If they require all
>of the available characteristics of IPSec, then they should be able to turn
>off the built-in method and simply run IPSec between the sender and the
>receiver for this protocol. SSL/TLS comes to mind that can provide
>unauthenticated encryption between two devices for integrity and
>confidentiality. I'm certain there are others.
I disagree. Cryptography does not belong in this layer of abstraction.
Although in this case, its use does. I would much rather see an interface to
external encryption and authentication. That would include the choice not
to use encryption (which may consume memory, and cpu cycles).
IPSEC is great but if someone can't set it up let them pay for link level
encryption. SSL should be in a library and that library should be optional.
[EMAIL PROTECTED]
