Subject: [Syslog] sequenceId and relaying

From: Balazs Scheidler <[email-masked]>
Date: Tue, 15 Jul 2008 17:41:52 +0200

Dear syslog working group,

I'd have a question regarding the syslog-protocol RFCs, more
specifically about the "sequenceId" portion of the "meta" structured
data element.

The definition of sequenceId states:

"7.3.1.  sequenceId

   The "sequenceId" parameter tracks the sequence in which the syslog
   application submits messages to the syslog transport for sending.  It
   is an integer that MUST be set to 1 when the syslog function is
   started and MUST be increased with every message up to a maximum
   value of 2147483647.  If that value is reached, the next message MUST
   be sent with a sequenceId of 1."

I see a couple of problems:
  1) It is not stated clearly in the RFC, what relays may or may not do 
    with structured data.
  2) By reading the definition above, I understand that each relay must 
    generate a new sequenceId for every message, e.g. the collector sees
    the sequence id generated by the last hop, and not the sequenceId
    sent by the originator of the message.
  3) if the relay is permitted to change the structured-data portion 
     (and the current sequenceId definition mandates this IMHO), how 
     will this work with things like signed messages?

My questions:
  - Was this the original intent with "sequenceId"?
  - I think some clarification about the role of relays regarding 
    structured-data handling would be needed in the RFC.

-- 
Bazsi

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

---

From: Chris Lonvick <[email-masked]>
Date: Tue, 15 Jul 2008 11:52:33 -0700 (PDT)

Hi,

Section 5 says:
    Any syslog transport protocol MUST NOT deliberately alter the syslog
    message.  If the transport protocol needs to perform temporary
    transformations at the transport sender, these transformations MUST
    be reversed by the transport protocol at the transport receiver, so
    that relay or collector will see an exact copy of the message
    generated by the originator or relay.  Otherwise end-to-end
    cryptographic verifiers (such as signatures) will be broken.  Of
    course, message alteration might occur due to transmission errors or
    other problems.  Guarding against such alterations is not within the
    scope of this document.

I think that clearly states that the relay MUST NOT make any changes to 
the sequenceID nor to any other SD-ID of messages passing through them.

Thanks,
Chris

---

From: Balazs Scheidler <[email-masked]>
Date: Wed, 16 Jul 2008 10:38:42 +0200

> the sequenceID nor to any other SD-ID of messages passing through them.

I disagree, a relay is not merely a transport. If it was it couldn't
drop messages based on filtering, which it is allowed to do.

In the same paragraph above: "so that _RELAY_ or collector will see an
exact copy of the message generated by the originator or
relay." (emphasis is mine).

For me, this boils down to: the relay _OR_ collector receive messages
from the transport, and the transport layer may not modify messages.
This I completely agree with, but transport is the layer that adds
framing and pushes a syslog message to the wire.

If relays are completely disallowed to modify messages then there's no
migration path for the new syslog protocol, we're going to have legacy
syslog messages from existing devices for at least a decade, if relays
are not allowed to change the format to the new protocol style, we'll
never really migrate to syslog-protocol. And there's merit in adding new
information to the syslog packet as it goes through the relay network.
(for instance another timestamp that can be trusted whereas the
originating timestamp cannot be)

Also, if the sequenceId is an end-to-end identifier (which it is if 
relays are not allowed to change the SD data), then the sequenceId is 
not really useful in the collector if one of the relays on the path drop 
messages by intent.

I think two identifiers are needed:
 1) one for identifying the message hop-by-hop, this is always increasing 
    (to determine whether we lost messages because of the transport)
 2) one for identifying the message end-to-end, which is not a sequence 
    number, but a unique identifier

Of course I can also live with the idea of using the sequenceId 
end-to-end, but I don't see this stated in the RFC.

-- 
Bazsi

---

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 16 Jul 2008 11:07:29 +0200

Hi all,

the intent is end-to-end. It got mangled during the "name wars" of syslog application/sender/receiver/originator etc. To restore the original meaning, we could do (during auth48 if there is consensus):

###
The "sequenceId" parameter tracks the sequence in which the ***originator*** submits
###

Anything beyond this is for the next version. I violently object any change that brings us out of the RFC editor publishing queue after we have finally reached this state after years and years... I say this even though I tend to agree to Bazsi on many points.

Rainer

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Balazs Scheidler
> Sent: Wednesday, July 16, 2008 10:39 AM
> To: Chris Lonvick
> Cc: [email-masked]
> Subject: Re: [Syslog] sequenceId and relaying
>

---

From: Balazs Scheidler <[email-masked]>
Date: Wed, 16 Jul 2008 13:20:39 +0200

> Anything beyond this is for the next version. I violently object any change that brings us out of the RFC editor publishing queue after we have finally reached this state after years and years... I…

This is ok for me at this point of time, I'll act accordingly.

However I see some ambiguities with relays and how relays are permitted
to change messages, especially with syslog-sign in mind.

-- 
Bazsi

---

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 16 Jul 2008 14:24:37 +0200

> From: Balazs Scheidler [mailto:[email-masked]]
> Sent: Wednesday, July 16, 2008 1:21 PM
> To: Rainer Gerhards
> Cc: Chris Lonvick; [email-masked]
> Subject: RE: [Syslog] sequenceId and relaying
> 
> > the intent is end-to-end. It got mangled during the "name wars" of
> syslog application/sender/receiver/originator etc. To restore the
> original meaning, we could do (during auth48 if there is consensus):
> >
> > ###
> > Anything beyond this is for the next version. I violently object any
> change that brings us out of the RFC editor publishing queue after we
> have finally reached this state after years and years... I say this
> even though I tend to agree to Bazsi on many points.
> 

That comes at no wonder, have a look at A.1:

####
RFC 3164 describes relay behavior.  This document does not specify
relay behavior.  This might be done in a separate document.
####

So details of relay operations are not covered by intension. After the
"name war", this has become a bit hard to grasp because the word relay
is all over the document. But a more prominent statement of
non-applicability was prevented by the "precise vs. imprecise spec war"
roughly two years before that. All of this is reasoning for not touching
anything right now. If we touch once again, we'll most probably blow the
whole effort. I, at least, am not prepared to invest any time more into
that same thing without seeing any progress. (I am open to discussion,
though, on something that may later become the text defining relay
operations).

Rainer

---

From: "David Harrington" <[email-masked]>
Date: Wed, 16 Jul 2008 08:46:17 -0400

Hi,

Chris and I believe the following change accurately represents
consensus of the WG intent.
Rainer, can you make that change during auth48?

> The "sequenceId" parameter tracks the sequence in which the 

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 16 Jul 2008 14:52:37 +0200

Sure, noted.

Rainer

> From: David Harrington [mailto:[email-masked]]
> Sent: Wednesday, July 16, 2008 2:46 PM
> To: Rainer Gerhards; 'Balazs Scheidler'; 'Chris Lonvick'
> Cc: [email-masked]