Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Mon, 16 Mar 2009 17:07:41 -0700

Hi,

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.  One approach would be to define a
"union" of some sort - or introduce a second parameter to indicate how
to interpret the RSID (if it represents a counter or a time stamp, is
persisted or not).  At this point, I would refrain from either.
However, I do think it is fair to state there is no requirement that
RSIDs be sequential - all that is required is that they increase; they
don't have to increment just by 1.  I think this leaves sufficient
flexibility for the implementation to distinguish reboot sessions even
in the absence of a persistence support, while keeping the scheme
sufficiently simple.  

--- Alex

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Thursday, February 05, 2009 1:39 AM
To: [email-masked]
Subject: [Syslog] Syslog-sign: Last minor clarifications/nits

I've now gone through all the emails and comments (I think), and this
email should contain all the stuff that wasn't covered by the earlier
emails yesterday and today:

In http://www.ietf.org/mail-archive/web/syslog/current/msg02030.html,
Martin asked whether it's OK to use time() (or similar) as RSID.
A strict reading of the current text does not seem to allow this.
However, if the originator can't reliably store a persistent RSID
counter, using a timestamp as RSID would probably provide more useful
information to the collector than always sending 0 (even though
timestamps are not always increasing, most of the time they are).
What do others think?

I think Sections 4.2.8 and 5.3.2.8 still need to be clearer about what
octets exactly are signed. Here's my suggestion:

  The signature is calculated over the completely formatted Signature
  Block message (starting from the first octet of PRI and continuing
  to the last octet of MSG, or STRUCTURED-DATA if MSG is not present),
  before the SIGN parameter (SD Parameter Name and the space before it
  [" SIGN"], "=", and the corresponding value) is added.

Section 5.3.2.8:

  The signature is calculated over the completely formatted
  Certificate Block message, before the SIGN parameter is added (see
  Section 4.2.8).

Sections 5.3.2, 5.3.2.9, and 9.1 misspell Total Payload Block Length
as TBPL (instead of TPBL).

Depending on what format (OpenPGP MPI style or ASN.1/DER) we'll use
for key blob type 'K', the example in 5.3.2.9 may or may not need
updating.

Best regards,
Pasi
_______________________________________________
Syslog mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/syslog

---

From: Martin Schütte <[email-masked]>
Date: Thu, 19 Mar 2009 21:15:25 +0100

Alexander Clemm (alex) schrieb:
> 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

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Sun, 22 Mar 2009 10:06:25 -0700

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

---

From: <[email-masked]>
Date: Sun, 22 Mar 2009 22:12:02 +0100

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Alexander 
> Clemm (alex)
> Sent: 22 March, 2009 19:06
> To: Martin Schütte; [email-masked]
> 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.
> 
>    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].
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Martin Schütte

---

From: Chris Lonvick <[email-masked]>
Date: Sun, 22 Mar 2009 15:09:56 -0700 (PDT)

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?

PROPOSED:
===
4.2.2.  Reboot Session ID

    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].

    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

---

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 23 Mar 2009 10:15:34 +0100

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Chris Lonvick
> Sent: Sunday, March 22, 2009 11:10 PM
> To: [email-masked]
> Cc: [email-masked]

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.

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 ;)

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).

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).

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).

Rainer

> an
> Reboot

---

From: Chris Lonvick <[email-masked]>
Date: Mon, 23 Mar 2009 06:44:07 -0700 (PDT)

Hi Rainer,

Comments in line.

> 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".

> 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.

> 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.

> over the SNMPEngineBoots counter from the SNMP subsystem, if syslogd has

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.

> engine (this sounds natural to do if the syslogd has access to a SNMP

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

---

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 23 Mar 2009 14:48:37 +0100

Chris,

<inline>

> From: Chris Lonvick [mailto:[email-masked]]
> Sent: Monday, March 23, 2009 2:44 PM
> To: Rainer Gerhards
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Syslog] Syslog-sign: Last minor clarifications/nits
> 
> Hi Rainer,
> 
> Comments in line.
> 

You are right - at that point I overlooked that we are not latching at
2^31-1. It does definitely not make sense to use some value right in the
middle of the interval for a special case. Please disregard my suggestion.

Rainer

---

From: Jon Callas <[email-masked]>
Date: Mon, 23 Mar 2009 11:11:43 -0700

> 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.

The original intent of RSID is an opaque unique value that could be  
used in a number of ways. It had no original semantics, beyond the  
obvious ones needed for a counter.

Later, you and I observed that a timer more-or-less works as it's  
monotonically increasing and thus not going to repeat. We added in the  
SNMP things in Jan 2002.

Here's text:

4.2.2.  Reboot Session ID

    ....  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.  Hence, an originator needs to retain the previous Reboot
    Session ID across reboots.  .....

    If the value reaches 9999999999, then manual
    intervention may be required to subsequently reset it to 1.
    Implementors MAY wish to consider using the snmpEngineBoots value as
    a source for this counter as defined in [RFC3414].

Kelsey's solo -01 draft says in its entirety:

2.3.4 Reboot Session ID

    The reboot session ID is a 48-bit quantity encoded in base 64 as
    eight bytes, which is required to never repeat or decrease in the
    lifetime of the device.

That text remains in my -04 unaltered. In -05, the reference to  
snmpEngineBoots appears, and I remember you (Chris) and I discussing  
beforehand that it could be a timer (which meets the requirements of  
the original) or an SNMP equivalent.

I will also note that it doesn't take a lot of lawyering to note that  
there are other implementations that meet the original requirements  
including a hash or hmac with frosting and sprinkles to manage  
collisions, (or even just ignoring the collision issue, in some  
cases), a 48-bit finite field, and many other things that are more  
complex than and technologically inferior to the naive reboot counter.

I'll also note that if we went back to John's original of a 48-bit  
number in base64, then a 48-bit timestamp (truncate 64-bit time_t) is  
good enough, too.

	Jon

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Mon, 23 Mar 2009 17:51:01 -0700

OK, to summarize, here goes:

4.2.2.  Reboot Session ID

   A Reboot Session ID is expected to strictly monotonically increase
   (i.e., to never repeat or decrease) 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) may be used.  Implementers of this method need to
   beware of the possibility of multiple reboots occurring within a
   single second.  Implementers need to also beware of the year 2038
   problem, which will cause the unix time to wrap in the year 2038.  In
   yet another way, implementers wish to consider using the
   snmpEngineBoots value as a source for this counter as defined in
   [RFC3414].

--- Alex
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Rainer Gerhards
Sent: Monday, March 23, 2009 6:49 AM
To: Chris Lonvick (clonvick)
Cc: [email-masked]
Subject: Re: [Syslog] Syslog-sign: Last minor clarifications/nits

Chris,

<inline>

> > be emitted later in time than a lower one. This would also permit
any
> other
> > issue of two or more restarts within a single second, which means
the
> RSID
> > 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.
> > except that we permit any increment as long as the resulting
sequence
> will be
> > strictly monotonically increasing (this is necessary to permit
simply
> copying
> > Also,  RFC 3414 uses 2147483647 as a special value, while we use 0.
I
> suggest

You are right - at that point I overlooked that we are not latching at
2^31-1. It does definitely not make sense to use some value right in the
middle of the interval for a special case. Please disregard my
suggestion.

Rainer

---

From: "Rainer Gerhards" <[email-masked]>
Date: Tue, 24 Mar 2009 08:45:00 +0100

This is fine with me.

Rainer

> From: Alexander Clemm (alex) [mailto:[email-masked]]
> Sent: Tuesday, March 24, 2009 1:51 AM
> To: Rainer Gerhards; Chris Lonvick (clonvick)
> Cc: [email-masked]
> Behalf
> > > increasing"? I think this is the essence of what we need and
> permits
> > any
> > > If we refer to the POSIX timestamp, I am not sure if we refer to
> the
> > 32  or
> > > well-known 2038 problem is carried over to this draft. While 28
> more
> > years to
> > > over the SNMPEngineBoots counter from the SNMP subsystem, if
> syslogd
> > has
> > > access to it).
> >
> > I'm guessing that's the reason it was chosen for 3414.  If devices
> use
> > a

---

From: "David Harrington" <[email-masked]>
Date: Tue, 24 Mar 2009 14:13:08 -0700

Hi,

why are we allowing multiple ways to set this? 
Since our mission is to define standards, why not standardize one way?

I think there are problems with rollover when using unix time or
snmpBoots.
If we simplify this to use a simple increasing value, then we avoid
that complexity.

dbh 

> [mailto:[email-masked]] On Behalf Of Alexander Clemm (alex)
> Sent: Monday, March 23, 2009 5:51 PM
> between 1
> [mailto:[email-masked]] On Behalf
> Of Rainer Gerhards
> > >> There does seem to be some conflicts in the section; if it
SHOULD
> > start
> > > 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
> > > If we refer to the POSIX timestamp, I am not sure if we 
> refer to the
> > 32  or
> > > 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,
> > have some verbiage in the document talking about using a
time-based
> > value
> > > With any time-based counter based on seconds, there is always
the
> > subtle
> > > 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
> > Agreed.  Again, an implementer would have to beware of that issue
if
> > they
> > > I think this is a good compromise and would suggest the we
mandate
> > this, too,
> > > over the SNMPEngineBoots counter from the SNMP subsystem, 
> if syslogd
> > has
> > > access to it).
> > 
> > > that we use 2147483647, too. Otherwise, a naive implementation
may
> > forget to
> > > convert 2147483647 to 0 when copying over the SNMPEngineBoots
from
> > the SNMP
> > 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

---

From: Martin Schütte <[email-masked]>
Date: Tue, 24 Mar 2009 22:35:27 +0100

> OK, to summarize, here goes:

I'm fine with that, because the start and increment values are no longer 
a MUST.

IMHO the unix time does not even have to be mentioned explicitly because 
that only adds unnecessary semantic meaning to the value.

-- 
Martin

---

From: Jon Callas <[email-masked]>
Date: Tue, 24 Mar 2009 14:45:38 -0700

> If we simplify this to use a simple increasing value, then we avoid

You are correct, but there will be the people who will fold in the  
other ways as well. If that's okay, that's okay.

There's a problem that simplicity is in the eye of the beholder.

A mere counter is perhaps the simplest, but could lead to operational  
issues, especially if you want to tie it together.

A timestamp is simple in the sense that it's easy to get, but has  
rollover issues. Those are easy to deal with (including by making it  
be a 48-bit base64 value as Kelsey first had it), but you have to deal  
with them.

SNMP values are simple if you have an SNMP framework, but not simple  
if you don't.

What you said, "simple increasing value" simplifies definition, but  
pushes issues off to implementation and operations folks, who will  
pick one of the other obvious things -- they're each simple increasing  
values. Timestamp is merely sparse.

Arguably even simpler is Kelsey's definition which said it was non- 
repeating, as opposed to increasing.

But are they really any different, at the end of the day? The major  
debate I can see is whether it should stay a ten-digit decimal number  
or go back to a base64 48-bit binary number.

	Jon