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