Hi Rainer,
Comments in line.
On Mon, 23 Mar 2009, Rainer Gerhards wrote:
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Chris Lonvick
Sent: Sunday, March 22, 2009 11:10 PM
To: [email protected]
Cc: [email protected]
Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits
Hi,
There does seem to be some conflicts in the section; if it SHOULD start
with 1 and increment by 1 then how do we get to SnmpEngineReboots?
What if we just say "must start at 1 and be strictly monotonically
increasing"? I think this is the essence of what we need and permits any
value to be used as seed as long as it can be assured that a higher RSID will
be emitted later in time than a lower one. This would also permit any other
second-counting time base reference to be used, e.g. creation/compilation
date of the software in question.
I'm OK with most of that. I wouldn't require it to start at "1" however.
I'd assume that some sort of timestamp value may be used, or that if
snmpEngineBoots is used then it is already past "1".
If we refer to the POSIX timestamp, I am not sure if we refer to the 32 or
64 Bit version of it (I even think I remember the bitness is not preciesley
defined?). In any case, we have subtle issues: if we talk about 32 bit, the
well-known 2038 problem is carried over to this draft. While 28 more years to
go sound reasonable, I'd still think it is worth pointing out. With 64 Bit,
the RSID will latch ~ 2110 when 64 bit Unix time goes beyond 9,999,999,999 -
that is probably not a real concern ;)
I see your point but that's outside of our scope to solve. :-) If we
have some verbiage in the document talking about using a time-based value
for RSID, then at most we should have a line in the security
considerations section telling the implementer to be aware.
With any time-based counter based on seconds, there is always the subtle
issue of two or more restarts within a single second, which means the RSID
will not necessarily be strictly monotonically increasing. While the
probability is (very) low for this case, it is not 0. So we cannot outrule
it. I have not yet checked if that can lead to permanent problems (counters
related to RSID which may occur twice).
Agreed. Again, an implementer would have to beware of that issue if they
chose a time-based value.
SNMP, as I understand RFC3414, seems to have solved this by requiring the
device to actually increment the counter and store it in non-volatile memory.
I think this is a good compromise and would suggest the we mandate this, too,
except that we permit any increment as long as the resulting sequence will be
strictly monotonically increasing (this is necessary to permit simply copying
over the SNMPEngineBoots counter from the SNMP subsystem, if syslogd has
access to it).
This sounds good. ..I'm trying to remember if this is what was first
discussed for RSID when John Kelsey first proposed a counter for this.
Also, RFC 3414 uses 2147483647 as a special value, while we use 0. I suggest
that we use 2147483647, too. Otherwise, a naive implementation may forget to
convert 2147483647 to 0 when copying over the SNMPEngineBoots from the SNMP
engine (this sounds natural to do if the syslogd has access to a SNMP
subsystem).
I disagree on that. 2147483647 is the largest 32bit unsigned integer -
I'm guessing that's the reason it was chosen for 3414. If devices use a
64bit field (or larger) to store their RSID value then they will have to
proactively avoid using 2147483647.
Thanks,
Chris
Rainer
PROPOSED:
===
4.2.2. Reboot Session ID
The Reboot Session ID is a decimal value that has a length between
1
and 10 octets. The acceptable values for this are between 0 and
9999999999. Leading zeroes MUST be omitted.
A Reboot Session ID is expected to increase whenever an originator
reboots in order to allow collectors to distinguish messages and
message signatures across reboots. There are several ways in which
this may be accomplished. In one way, the Reboot Session ID may
increase by 1, starting with a value of 1. Note that in this case,
an
originator is required to retain the previous Reboot Session ID
across
reboots. In another way, a value of the unix time (number of
seconds
since 1 January 1970 [reference?] may be used. In yet another way,
implementors wish to consider using the snmpEngineBoots value as a
source for this counter as defined in [RFC3414].
In cases where an originator is not able to guarantee that the
Reboot
Session ID is always increased after a reboot, the Reboot Session
ID
MUST always be set to a value of 0. If the value can no longer be
increased (e.g., because it reaches 9999999999), then manual
intervention may be required to subsequently reset it.
If a reboot of an originator takes place, Signature Block messages
MAY use a new PROCID. However, Signature Block messages of the
same
originator MUST continue to use the same APP-NAME and MSGID.
===
Does this work for everyone?
Thanks,
Chris
On Sun, 22 Mar 2009, [email protected] wrote:
Hi Alex,
By "timestamp", at least I've meant "POSIX timestamp (seconds since
1/1/1970) when the syslog daemon started". But even with the new
text, I'm still having trouble determining whether this would be
an acceptable value for RSID...
Best regards,
Pasi
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of ext Alexander
Clemm (alex)
Sent: 22 March, 2009 19:06
To: Martin Sch?tte; [email protected]
Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits
Hello Martin,
I have clarified in the text that what I think it is you are
suggesting will be allowed. But it is not a time stamp. A time
stamp would be something like 2008-10-16T20:23:03+02:00.
While it still suggests that the RSID should increase by 1, it is
not required. It is merely required to simply increase (no problem
with an RSID reflecting a "time stamp"), unless it is set to 0.
Here is what the section in question reads now:
The Reboot Session ID is a decimal value that has a length
between 1 and 10 octets. The acceptable values for this are
between 0 and 9999999999. Leading zeroes MUST be omitted.
A Reboot Session ID is expected to increase whenever an
originator
reboots in order to allow collectors to distinguish messages and
message signatures across reboots. The Reboot Session ID SHOULD
increase by 1, starting with a value of 1. Note that in this
case,
an originator is required to retain the previous Reboot Session
ID
across reboots.
In cases where an originator is not able to guarantee that the
Reboot Session ID is always increased after a reboot, the Reboot
Session ID MUST always be set to a value of 0. If the value can
no longer be increased (e.g., because it reaches 9999999999),
then manual intervention may be required to subsequently reset
it. Implementors MAY wish to consider using the snmpEngineBoots
value as a source for this counter as defined in [RFC3414].
Does this accommodate your concern?
--- Alex
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Martin Sch?tte
Sent: Thursday, March 19, 2009 1:15 PM
To: [email protected]
Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits
Alexander Clemm (alex) schrieb:
On the first item, yes, the first item (RSID) is clearly a
counter; a
time stamp cannot be used, nor can a value that is arbitrarily
generated.
To use a time stamp would require a parameter that is differently
defined than the current RSID.
Excuse my persistance here, but: why?
Especially if they do not have to be sequential.
Is there any reason to define RSID as a counter instead of an
increasing
ID? When is a counter like 1-2-5-6 better than IDs like
1234400000-1234500000-1234600000-12374700000?
--
Martin
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog
