Re: sequenceId and relaying

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