Roger Marquis wrote: > > UDP packets are easily spoofed (x 4) > > This is misleading. IP packets are easily spoofed perhaps. But UDP is no > more easily spoofed than TCP aside from the sequence number. Syslog could > implement this in the application layer however it's debatable whether a > sequence number is needed. The majority of syslog packets are not > connection oriented and wouldn't normally be sequenced. Who mentioned TCP? You say yourself that IP packets (and therefore UDP packets) are easily spoofed, so you must agree with the above statement. I believe this thread is addressing "What's wrong with syslog", not how TCP can/can-not fix it. > Also, UDP is, in most cases, a better protocol than TCP over congested > networks because it requires less overhead. What does that have to do with the fact that "UDP packets are easily spoofed"? Perhaps this was meant to be part of the retort to "No congestion control with UDP". > > No congestion control with UDP (x 2) > > Does the syslog protocol really need to be concerned with network layer > congestion control? Many have argued that syslog should not become a > heavyweight, all-singing and all-dancing application. That's true. On the other hand, if you do TCP, you don't add any complexity to syslog but still get the congestion control, acknowledged transmissions, sliding windows so your throughput is still good even though you have acknowledged transmissions, etc. I'm not saying that TCP is right for all situations, but syslog needs the ability to use it when it is the right thing to do. So, it's still something that's wrong with syslog. > > Packets may be altered undetectably in transit (x 1) > > This is redundant, and is addressed by encryption. Virtually any > unencrypted packet can be undetectably altered in transit. True, but it's still something wrong with the current syslog, though I suppose you could argue that this can be fixed by IPsec tunneling. Personally, I'd generalize this to "log entries can be undetectably altered." Modified log entries are a problem whether they're modified in transit or on disk. To deal with the "on disk" issue, you either need end-to-end signatures, or OS support for "secure log storage," which might be possible, for example, if you have a B-level trusted OS and you use mandatory access controls to guarantee that the log system can create log entries, but nobody can delete them. > > Gaps in the message sequence can't be detected by receiver (x 1) > > See above. Still a problem with syslog. > > Bogus messages can be sent to the logging host (x 1) > > See above. Still a problem with syslog. > > No standard way of formatting of message text and separating various > > arguments of the log message (x 4) > > You might want to clarify the meaning of "message text" here. There are > formatted and unformatted fields in the existing syslog. I have not heard > anyone recommend changing this. Most seems to agree that the number of > formatted fields should be expanded. Ah, so you agree that this is a problem with the current syslog. > > syslog is not standardised, which makes it more difficult than it > > should be to produce interoperable implementations (x 2) > > This seems unnecessarily vague. Syslog is currently interoperable and > standardized though there are some variations. The syslog wire protocol is fairly standardized and interoperable. The syslog.conf capabilities are somewhat standardized/interoperable if you don't use any extensions like #include or '|'. The structure of messages is really a mess. > Otherwise it seems like a good start. I'd add: > > * Performance issues with log file opening/closing (reading and > writing the entire logfile) once per message. > > * No ability to define daemon's fsync() behavior. > > * Limited configuration file syntax. > > * No standardized logging directory (/var/log, /var/adm, ...) > > * No log entry when messages are not delivered to remote > loghosts. Now here I agree. Folks, I'm not saying that the XML-style complexity I've proposed is definitely the way to go. However, I haven't seen anything else that addresses all the concerns of log privacy, log no-repudiation, and a flexible structure in which to express concepts like "the source address was xxx.xxx" in a way that's both human and machine readable. Somebody please correct me if I'm wrong. Also feel free to send me input on the XML-ish stuff I've proposed. I'm sure it could be better. -- Chris Calabrese Internet Infrastructure and Security Merck-Medco Managed Care, L.L.C. [EMAIL PROTECTED] .
