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

From: [email-masked] (Didier DALMASSO)
Date: Mon, 4 Jul 2005 13:59:05 +0200

Rainer,

I agree with this. But I have some minor remarks.

I see the post of Steve Chang, I think that it's a good solution.  But
it's too bad that the size of the truncation's field  varies _during
transport_. Moreover it is necessary to pay attention to the size
during truncation.

Examples :
message 1: length is 3000 octets and truncate value is 0.
A relay truncates it to 2048 on STRUCTURED-DATA. Put 8 + 1 in TRUNCATE
field
==> length = 2048. It's OK.

message 2: length is 3000 octets and truncate value is 0.
a relay truncate it to 2048 on MSG. Put 8 + 2 in TRUNCATE field  ==>
length = 2049. Implementor must pay attention !

Perhaps it's adapted to announce it.

Thanks

On Tue, Jun 28, 2005 at 10:30:31AM +0200, Rainer Gerhards wrote:
> 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
_______________________________________________
Syslog-sec mailing list
[email-masked]
http://www.employees.org/mailman/listinfo/syslog-sec

---

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 4 Jul 2005 14:02:37 +0200

Didier,

thanks for the good point. I think I'll put a note in the informative
appendix. I plan to do this soon, so that we can proceed further.

Do you have any further feedback from implementing the draft that should
go into it? If so, I would love to hear it.

Thanks,
Rainer 

> From: Didier DALMASSO [mailto:[email-masked]] 
> Sent: Monday, July 04, 2005 1:59 PM
> To: Rainer Gerhards
> Cc: [email-masked]