Just to clarify... I don't think that host/process/time is the best unique identifier for messages. The example that I gave also included per-process sequence number (count which resets to 1 on restarts). But even this format is not as good as one with reboot id because time can be moved backwards, counts can be reset, it is harder to interpret, etc. It is the next best thing if reboot id is missing.
I think reboot id is a good thing. My only real beef was with reboot id and count being *per-host* things instead of *per-process*. OS re-installs are a different issue -- could potentially be mitigated by persisting data on a separate disk form OS. I see many examples of multiple processes that could fire syslog messages directly to a remote host. I can easily have Cisco TFTP, DNS and DHCP servers installed on a single Solaris/Windows/Linux host (all of which are supported) and I am not sure what benefit is there in making them go through a separate daemon in order to log messages remotely via UDP. This does not help performance, reliability or robustness IMO. The problem is with maintaining per-host message count across multiple processes or centralizing the generation of log messages somewhere. Note, that previous syslog RFCs did not have anything in them that made it harder for individual processes to fire messages remotely directly. If I am to use to use reboot id and counts for just fragmentation, a newly required component on my servers is high price to pay it seems. Thanks, Anton. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Rainer Gerhards > Sent: Tuesday, September 16, 2003 4:45 PM > To: Chris Lonvick > Cc: [EMAIL PROTECTED] > Subject: RE: fragmentation in -international > > > Hi Chris, > > > The purpose of the reboot counter is to prevent replay. I > > can see the inclusion of the process id and/or name with the > > certificate block messages to identify the sender. (I'm > > still a little doubtful about the concept of multiple syslog > > processes from a single device but I'll go along for the > > discussion. :) Can you explain how this will prevent a replay? > > Let me ask a return question... If the reboot counter is > implemented as > e.g. Albert suggested, it is more or less a timestamp > (remember, it was > suggested to take the seconds since some date and use this is reboot > counter...). How can this provide more replay protection > than an actual > timestamp...? > > Oops... Maybe I wasn't clear enough. I think that > TIMESTAMP/TAG/HOSTNAME > together should make up the message identifier. This would > - in my point > of few - create the same reply protection that a time-based reboot > session ID does. > > > > > In which environments is this challenging? To utilize a > > timestamp, devices will require a TOY (Time of Year chipset). > > To utilize a reboot counter, a device just needs some memory > > that will persist over a reboot. > > Maybe Anton can help me out with some of the devices. But > at least for > Windows, it is not uncommon that the OS is freshly > installed. This will > also remove any previously stored reboot session id. If the machine > retains the same ip, there will be an issue... > > > I believe that the latter is > > more common and that this was discussed in the SNMP mailing > > list prior to coming up with SNMPv3, which came to the > > conclusion that a reboot couter was preferred. > > Looks like I need to review the SNMPv3 mailing list and see > what drove > the decision. I assume there is lot to learn... > > > > If there is no objection, I will move this approach > into the next > > > revision of -international. > > > > > > > I'm not objecting - just trying to make sure we've got our > > bases covered. > > Please bear with the non-English natives ;) Eventually > "object" is too > hard - I meant if somebody disagrees and/or has a better > answer/comment > - as you did ;-) > > Rainer > >
