Hi,
The threads of this discussion seems to be moving into two parts. First,
there are many thoughts about the protocol and, second, there are thoughts
about dealing with the messages that are received. The two are interrelated
and I'd like to propose "goals" for each of them. I agree that the work to
be done in the IETF will revolve around the protocol/interface. I suggest
that we agree upon the basic nature of the implementation so that we can
ascertain the requirements of the protocol. -that way, we shouldn't have to
bolt-on any additions at later times- The needs/likes/wishes of the
implementation should be recorded so that we are addressing that with the
protocol.
The devices transmitting and receiving these messages may have the following
desires:
o The sending device may take some action if a message, or group of
messages, are not delivered within a time period.
o The content of the messages may be sensitive and may be encrypted when
transmitted.
o The receiver may wish to verify that the purported sender is actually
the valid & identifiable sender of a message.
o The sender may wish to verify that the purported receiver is actually
the valid & identifiable sender of a message.
o The receiver may have programs that can munge through the received
messages to deliver reports, or that may take actions upon events.
o Syslog (in its current form) has been around for a very long time and
its configuration and message format -while not standardized- are
deeply ingrained in the operational characteristics of many networks.
The addition of a new protocol should play nice with the old.
o The receiver may wish to store the messages using a tamper evident
method.
o The sending logging program may wish to timestamp each message before
transmission.
o The receiving logging program may wish to timestamp each message at
the time it is received.
The protocol may have the following characteristics to achieve the goals
of the transmission and receipt of the messages.
o The possibility of verifiable delivery of the messages.
o The possibility of time-stamping.
o The possibility of cryptographic means to ensure confidentiality,
strong authentication and/or integrity.
Please add to these lists if I have left anything out.
Are these protocol goals interdependent? I would suggest that the answer
be 'no'. The operators and administrators should be given some flexibility
in deciding which features of a new messaging protocol that they could use.
I don't like seeing death-by-options, but I would like to see us agree upon
the features of the protocol that MUST be enforced and other features that
MAY be incorporated.
There seem to be three hot topics on the list to which I'll add my opinions:
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 really just don't like (1) since you could never be certain that the
ack reached the sender -unless you used some sort of ping-pong protocol that
would continually ack the acks. I would think that to be silly. Both (2)
and (3) will have performance issues that are unlike the current udp/syslog
due to the nature of TCP and also to the maintenence of the state. In
either of these, the verification of delivery could be divined from the
state of TCP; in (2) the successful closure of the session would indicate
receipt, and in (3) an ack would. I have no great preference of either and
it may be preferable to allow both into the spec and left to the
administrator to choose.
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'm also assuming that this new messaging protocol will be a replacement for
udp/syslog in that the messages generated from each of the entities
(programs, applications, daemons, etc.) still still have their own format,
and the messaging program will encapsulate that for transmission to the
receiver. In this case, we must make no assumptions about the contents of
the original message and whether or not it contains its own timestamp. For
that, I would recommend that the protocol contain a timestamp field that
may contain a standard time format, but has the option to contain a vendor
specified value. (The coke machine may only know how long it has been
plugged-in.) I would like to say that it would be a 'best practice' if the
entity that first generated the message include its' own timestamp
(obtained from a consistent network time source) in the message, and that
the receiver timestamp the message when it writes it to a log. In that case,
the protocol may have a redundant field, but that's better than just not
knowing.
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.
Thanks,
Chris
