Re: sequenceId and relaying

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 protected] [mailto:[email protected]] On
> Behalf Of Balazs Scheidler
> Sent: Wednesday, July 16, 2008 10:39 AM
> To: Chris Lonvick
> Cc: [email protected]
> Subject: Re: [Syslog] sequenceId and relaying
> 
> On Tue, 2008-07-15 at 11:52 -0700, Chris Lonvick wrote:
> > 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.
> >
> 
> 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.
> 
> >
> > Thanks,
> > Chris
> >
> > On Tue, 15 Jul 2008, Balazs Scheidler wrote:
> >
> > > 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 protected]
> > > https://www.ietf.org/mailman/listinfo/syslog
> > >
> 
> --
> Bazsi
> 
> _______________________________________________
> Syslog mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/syslog
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog