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