Subject: RE: [Syslog-sec] I-D ACTION:draft-ietf-syslog-protocol-12.txt

From: "Rainer Gerhards" <[email-masked]>
Date: Tue, 28 Jun 2005 10:30:31 +0200

Didier,

I have included most of the changes. Please see comments below.

Rainer

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Didier DALMASSO
> Sent: Friday, June 03, 2005 11:51 AM
> To: [email-masked]
> Subject: Re: [Syslog-sec] I-D ACTION:draft-ietf-syslog-protocol-12.txt
> 
> Hi,
> 
> I've noticed some inaccuracies for the truncation at the initial
> sender. I suggest several modifications :
> 
> in section 6
> ---------
> <
>       TRUNCATE        = "0" / "1" / "2" / "3"
> >
>       TRUNCATE        = "0" / "1" / "2" / "3" / "5" / "6" / "7"
> ---------

changed to 1*2DIGIT
> 
> 
> in section 6.1 Message Lentgh
> ---------
> <
>    Receivers SHOULD follow this order of preferrence when it comes to
>    truncation:
> >
>    If a sender have a message with a length larger than 2,048 
> octets, the
>    sender MAY send it complete or truncate the payload before send it.

I have NOT included that change, because it implies that a sender can
only truncate if the length is larger than 2,048. In fact, a sender
might decide to truncate if the size if larger than 480 octets. However,
I think we need not point out the size restrictions at this point again.

If there is a very strong argument to do so, I would like to hear it.

> 
>    This order of preferrence SHOULD be follow when it comes to
>    truncation:
> ---------
> <
> When a receiver truncates a message, the TRUNCATE field
> (Section 6.2.4) MUST be updated.  Please note that this will break
> eventually existing digital signatures.
> >
> When a receiver or initial sender truncates a message, the TRUNCATE
> field (Section 6.2.4) MUST be updated.  In the case of a receiver,
> please note that this will break eventually existing digital
> signatures.
> ---------

changed

> 
> 
> in section 6.2.4  TRUNCATE
> ---------
> <
>    The TRUNCATE field is used to indicate if the message has been
>    truncated since it was sent.  Such a truncation might happen on any
>    receiver, including receivers on interim systems (relays). 
>  Values in
>    the TRUNCATE field are made up of bits.  Each of this bits has been
>    assigned a specific value so that there is no doubt about bit
>    ordering.  The following values MUST be used:
> 
>             VALUE     Meaning
>               1       all or some SD-ELEMENTs were truncated
>               2       all or part of MSG was truncated
>               4       truncation occured at the initial sender
> 
>    If the initial sender truncates a message, this MUST be 
> inidicated by
>    setting the "truncation occured at the initial sender" bit 
> (value 4).
> >
>    The TRUNCATE field is used to indicate if the message has been
>    truncated since it was sent or generated by an application.
>    Such a truncation might happen on the initial sender and any
>    receiver, including receivers on interim systems (relays). 
>  Values in
>    the TRUNCATE field are made up of bits.  Each of this bits has been
>    assigned a specific value so that there is no doubt about bit
>    ordering.  The following values MUST be used:
> 
>             VALUE     Meaning
>               1       all or some SD-ELEMENTs were truncated
>               2       all or part of MSG was truncated
>               4       truncation occurred at the initial sender
> 
>    The value in the TRUNCATE field is the ASCII 
> representation of these
>    ORed bits. If the initial sender truncates a message, this MUST be
>    indicated by setting the "truncation occured at the initial sender"
>    bit (value 4). In the case of the truncation occured at the initial
>    sender and at a receiver (relay or collector), he MUST 
> unset the third
>    bit (value 4). This allows to detect the signature is invalid.
> ---------

I've changed this partly. I have not included the "unset bit 4" rule,
because I do not think this really makes sense. When the initial sender
truncates the message AND the receiver also truncates the message, we
have two truncations, but the later does not undo the initial one. I
think you main concern is about signature. I got another suggestion to
include value for truncation at interim systems (8) and the receiver
(16). These are now included. So in your secenario (both sender and
receiver truncate), the value would be 20 - and thus the receiver can
detect that the signature is invalid. I think this addresses you
concern.

> 
> and for the next paragraph:
> 
> ---------
> Some examples: If no truncation occured, TRUNCATE MUST have a value
> of 0.  If SD-ELEMENTs were truncated on the receiver, TRUNCATE MUST
> have a value of 1.  If they were truncated on the initial sender,
> TRUNCATE must have the value of 5.  If structured data and MSG were
> truncated on an interim system, TRUNCATE MUST have the value 3.  If
> only MSG was truncated on the initial sender, TRUNCATE MUST have the
> value 6.
> ---------
> 
> s/must have the value of 5/MUST have the value of 5/
> 
> Thanks,
> 
> -- 
>           Didier Dalmasso
> _______________________________________________
> Syslog-sec mailing list
> [email-masked]
> http://www.employees.org/mailman/listinfo/syslog-sec
> 
_______________________________________________
Syslog-sec mailing list
[email-masked]
http://www.employees.org/mailman/listinfo/syslog-sec