Hi Rainer, On Tue, 16 Sep 2003, Rainer Gerhards wrote:
> Hi WG, > > I had some off-list discussion with Anton Okmianski on the proposed > fragmentation issue in here. I think he raised some very good points and > I am now posting some of his important thoughts (with his permission): > > > I don't have any beef with reboot id... On the contrary, if it is > > defined as a per process thing, I think it is not a bad idea. But if > > it is per-host, then sequence numbers have to per-host. And this is > > bad. This means that processes have to coordinate with each other > > (through another daemon process, shared memory, peer-to-peer or other > > mechanism). This is a problem because this complexity affects > > availability and reliability of the solutions. When things are hosed > > on the system, it helps when process does not have external > > dependencies in order to report the problems. > > > > I understand that you have to deal with -sign though. And I don't > > know exactly what they spec'ed. On the other hand -sign is not even > > an RFC yet. I think they should probably add process identifier and > > make reboot id per process. It seems like a very obvious choice if we > > are saying that we support architecture of multiple processes firing > > remotely directly. > > I think this boils down to the issue of a single daemon (*nix like) > design vs. a design with multiple independant senders running on the > same system. I agree on that there is an issue if we borrow too much > from the *nix approach (or kind of silently assume it). > > Some related reading can be found here: > > http://www.mail-archive.com/syslog-sec%40employees.org/msg01217.html (be > sure to follow the thread) > > In some other mail, Anton proposed to drop the reboot session ID in > favour of using the following fields as identifier for a single message: > > - TIMESTAMP (should be at least in millisecond resolution) > - TAG (should include process id) > - HOSTNAME > > These fields should be exactly the same in each fragment and identify > the message (the whole, oversized one). Then fragementation is done > close to what was proposed in -international-0: > > fragno.fragtotal > > with fragno being the current fragment (starting at 1) and fragtotal > being the total number of fragments. fragtotal would be optional. No > byte counting is done, it is just a plain advancing number. The bottom > line of this is that we can NOT detect bytes added after the original > message with this approach (but would we really like to preserve -sign > signatures in this case...?). > > I have to say, I like Anton's approach. It's simple & efficient and > removes the need for the reboot session id, which can be challenging in > some environments. 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? 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. 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. > > 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. Thanks, Chris > So, is there any objection? ;) > > Anton: would you find this sufficent, as I do not make process id a > MUST? > > Rainer > > >
