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
> > Syslog@ietf.org
> > https://www.ietf.org/mailman/listinfo/syslog
> >
--
Bazsi
_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog
