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 > -----Original Message----- > From: Didier DALMASSO [mailto:[EMAIL PROTECTED] > Sent: Monday, July 04, 2005 1:59 PM > To: Rainer Gerhards > Cc: [email protected] > Subject: Re: [Syslog-sec] I-D ACTION:draft-ietf-syslog-protocol-12.txt > > 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 PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of > > > Didier DALMASSO > > > Sent: Friday, June 03, 2005 11:51 AM > > > To: [email protected] > > > 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 protected] > > > http://www.employees.org/mailman/listinfo/syslog-sec > > > > > _______________________________________________ > > Syslog-sec mailing list > > [email protected] > > http://www.employees.org/mailman/listinfo/syslog-sec > _______________________________________________ Syslog-sec mailing list [email protected] http://www.employees.org/mailman/listinfo/syslog-sec
