At 05:24 AM 10/26/00 -0400, John Kelsey wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>Guys,
>
>I have been thinking about the problems of adding crypto to
>UDP-based syslog, in a way that we can support even on
>devices with very few resources. I think I know how to do
---remainder deleted for brevity---
Hi John,
I think that your suggestions have merit. I know that you have proposed
similar ones to Alex and this group before and I'm hoping that Alex will
address them.
To keep this discussion going, I'd like to speculate on a "what if"
scenario to see where it leads.
Let's say that we observe these messages on the wire:
<14>message1
<14>message2
<14>message3
I can see from your proposal that these could be sequenced and 'signed'
like this:
<14>message1 +L(1)+H+MAC
<14>message2 +L(2)+H+MAC
<14>message3 +L(3)+H+MAC
(Pardon my pseudo-nomenclature. :-)
When they reach their final repository, an observer would be able to
verify their proper order and that they had maintained their integrity
from the wrapper.
However, let's take the case where this happens:
- the system generates a message that is only displayed on the console
- a user generates a message onto the wire <14>message1
- sendmail generates a message onto the wire <22> blah blah blah
- the user generates a message onto the wire <14>message2
- sendmail generates a message onto the wire <18> aieeee...
- the system generates another message that is only displayed on the console
- the user generates a message onto the wire <14>message3
We could see the following on the wire:
<14>message1 +L(2)+H+MAC
<22> blah blah blah +L(3)+H+MAC
<14>message2 +L(4)+H+MAC
<18> aieeee... +L(5)+H+MAC
<14>message3 +L(7)+H+MAC
We've lost some messages as they didn't leave the system. Let's also
take a look at what happens if the rules on the system generating the
messages are (in order):
Critical-severity messages go to ss01.example.org
Sendmail-facility messages go to sm13.example.org
User-facility messages go to he77.example.org
then their wrappers won't denote sequence unless reassembled from their
respective final destinations. This could get even messier since each of
the receivers may have additional rules for the disposition of the
messages. For example, sm3.example.org may have the following rules:
sendmail.debug messages are displayed on the console
sendmail.alert and sendmail.emergency messages are forwarded elsewhere
sendmail.* are written to a file
Honestly, I'm still OK with all of this. The records in the file should
still have an increasing sequence number as long as they still have the
same H. I could see where there may be clusters of monotonically
sequenced messages in a single file. The rest would have skips between
them but they will still show increments. Those gaps would either
represent messages with different Pri, Facility or Severity values that
went to other destinations, or messages that were not received. If needed,
I could go through all files and assemble the true picture of the sequence
of all events from a single device except for those messages that were
somehow dropped.
There may be an alternative to these disjointed files. The simplistic
answer would be to keep a unique sequence number for each pri value.
That would be 192 counters for robust systems. Going back to the prior
example, we could observe this on the wire:
<14>message1 +L(<14>.1)+H+MAC
<22> blah blah blah +L(<22>.1)+H+MAC
<14>message2 +L(<14>.2)+H+MAC
<18> aieeee... +L(<18>.1)+H+MAC
<14>message3 +L(<14>.3)+H+MAC
While that has its appeal, it could place a significant hardship on the
sending device. It may also leave us with further disjointedness in some
situations. The example of that may be a single device that is configured
to send all messages to a collector which places all of them into a
single file. The administrator would have a good idea, but wouldn't be
able to really know the actual order of all of the events from this
information. (Without looking at the timestamps, which may not be there,
did <18>.1 come before or after <14>.3?)
Following this line of though would open a plethora of additional options.
(Rat-holes! ;-) I don't think that exploring each of them would be worth
our collective time. However, I would like some comments, discussion and
agreement on this.
Would it be acceptable to have the following:
Each device MUST have a single counter (let's call it system-L) that
MUST be included in each message. They MAY have any additional counters
that they feel would be appropriate and they MAY designate them in the
message. It may be a policy decision on our example device above to have
an individual counter for sendmail but not for any of the other facilities.
That would allow something like the following:
(internal message)
<14>message1 +systemL(2)+H+MAC
<22> blah blah blah +systemL(3)+L(<sendmail>.1)+H+MAC
<14>message2 +systemL(4)+H+MAC
<18> aieeee... +systemL(5)+L(<sendmail>.2)+H+MAC
(internal message)
<14>message3 +systemL(7)+H+MAC
Along these lines, it may be possible for an implementor to assign
counters for Facilities, Severities or combinations - various PRIs. It
would still be allowable for an implementor to have a counter for each
PRI.
John: I'd like to hear your thoughts on this. Would there be any
other mechanisms that you could suggest to simplify this?
Everyone else: I'd also like to hear from people who may be
implementing this. Is it realistic to associate individual counters
with each PRI? ..or with each Facility, etc.?
Thanks,
Chris
