RE: [Syslog] byte-counting vs special character

"Anton Okmianski \(aokmians\)" <aokmians@cisco.com> Tue, 15 August 2006 18:09 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD3M3-0004qQ-B9; Tue, 15 Aug 2006 14:09:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD3M2-0004qA-2g for syslog@ietf.org; Tue, 15 Aug 2006 14:09:30 -0400
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD3M0-0003kC-Ci for syslog@ietf.org; Tue, 15 Aug 2006 14:09:30 -0400
Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 15 Aug 2006 11:08:27 -0700
X-IronPort-AV: i="4.08,128,1154934000"; d="scan'208"; a="1847238314:sNHT38969622"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7FI8RFL012323; Tue, 15 Aug 2006 11:08:27 -0700
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7FI8QcJ010227; Tue, 15 Aug 2006 11:08:26 -0700 (PDT)
Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 14:08:26 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Syslog] byte-counting vs special character
Date: Tue, 15 Aug 2006 14:04:43 -0400
Message-ID: <98AE08B66FAD1742BED6CB9522B7312201C971AC@xmb-rtp-20d.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Syslog] byte-counting vs special character
Thread-Index: Aca8ow+og+vltxWXS/6dODLfiKq6xgAt1kYAAITYp+AAD6HKgAAVuHhAAAhRtsAAGBPRkAADLZzw
From: "Anton Okmianski (aokmians)" <aokmians@cisco.com>
To: David Harrington <ietfdbh@comcast.net>, Rainer Gerhards <rgerhards@hq.adiscon.com>
X-OriginalArrivalTime: 15 Aug 2006 18:08:26.0466 (UTC) FILETIME=[CDF4A420:01C6C095]
DKIM-Signature: a=rsa-sha1; q=dns; l=9870; t=1155665307; x=1156529307; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=aokmians@cisco.com; z=From:=22Anton=20Okmianski=20\(aokmians\)=22=20<aokmians@cisco.com> |Subject:RE=3A=20[Syslog]=20byte-counting=20vs=20special=20character; X=v=3Dcisco.com=3B=20h=3DTxnSog6XPLJHf+1tx6kuXe3wy1U=3D; b=Q/AIsdyaSVWxDnh+n/7gSFVqhQ7mnvQEoPorh4uAdxQCN21HBdHtHC3PK9+NwmY1dPF0+eD7 8fNBNEbQShdhjVxvQifDggBeHvYLmOdDCY1WJzmyjzUPIbgRDahabbXY;
Authentication-Results: sj-dkim-7.cisco.com; header.From=aokmians@cisco.com; dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f
Cc: syslog@ietf.org
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

I second these concerns.  Escaping requirements result in a more
interdependent layering, which is a weaker architecture (not to mention
the overhead to a new standard). The syslog transport would need to mess
with payload instead of treating it as opaque blob with easily known
length. Not nice. Imagine TCP/IP escaping all payload to separate
datagrams and segments.

Escaping of magic characters is IMHO clearly a hack and should not be
put into a standard! If the argument was to accommodate some real
established standard and there was no way to version things - maybe.
Current syslog is not standardized (not in IETF, not in reality). The
transition to a cleaner design is trivial.  A given implementation can
support whatever legacy compatibility modes it wishes to support. Syslog
is sent to a known destination configured by administrator, not some
kind of broadcast to world-wide-web where you don't know what kind of
receiver will get it. This problem is easily administrated in mixed
legacy/standard environment if someone chooses to deploy one.     

Anton.   

> -----Original Message-----
> From: David Harrington [mailto:ietfdbh@comcast.net] 
> Sent: Tuesday, August 15, 2006 1:25 PM
> To: 'Rainer Gerhards'
> Cc: syslog@ietf.org
> Subject: [Syslog] byte-counting vs special character
> 
> Hi Rainer,
> 
> [speaking as co-chair]
> Can we change the subject line to "byte-counting vs special character"
> for this topic so it is easier to find comments on this topic 
> as compared to other things in the timeline? That will make 
> it nuch easier for the chairs.
> 
> This WG has already gotten stuck, and had WG progress stall, 
> trying to provide backwards compatibility to a bunch of 
> incompatible implementations. I argued on this list before 
> becoming co-chair that backwarsd compatibility may not be 
> achieveable for some features and we need to stop getting 
> hung up on it. Sometimes to build a good standard, you need 
> to choose something that will break some existing implementations. 
> 
> I raised this concern with Chris when I started as co-chair. 
> I do not want to see backwards compatibility arguments stall 
> progress again. I made sure this was reflected in the 
> timeline, which says that by Friday (if you decide to use a 
> special character) you must reach consensus on which special 
> character to use.
> [/speaking as co-chair]
> 
> [speaking as contributor]
> I like the argument that the LF solution will not break 
> existing implementations, but I would like to know this is 
> actually true. Have you actually tested this against multiple 
> implementations, or is it a theoretical argument?
> 
> I know you have tested a number of other proposed ways of 
> doing things against multiple implementations to try to 
> verify backwards compatibility. Have you actually tested 
> multiple existing implementations with the LF and found that 
> they do continue to work without significant problems? Can 
> you tell the WG which ones you have tested? Are there 
> implementations that break when using this solution?
> 
> 
> In a different message you argue that syslog-sign only needs 
> to support -protocol because the implementations will need to 
> have new code added anyway, and the added complexity of 
> backwards compatibility to rfc3164 implementations is not needed.
> 
> You only mention one implementation explicitly that provides 
> syslog/tls, syslog-ng over stunnel. Would all the other 
> implementations need to be modified to support a TLS 
> substrate anyway, so it would not make a difference to them 
> which special character was chosen or if byte-counting was 
> chosen? Which syslog/tls implementations will be impacted by 
> our choice here? 
> 
> Ideally, only the implementations that support a feature need 
> to pay the price for the feature.
> 
> A syslog message delineator will only be needed in 
> implemntations that add support for syslog/tls (or other 
> streams). Whether one supports byte-counting or a special 
> character, only implementations that support multiple 
> messages in a stream, e.g. syslog/tls, should need to be 
> modified to support the choice. 
> 
> Personally I find the octet-counting cleaner because previous 
> discussions on terminators showed that available 
> implementations are highly inconsistent with their special 
> characters. 
> 
> Since byte-counting happens outside the syslog message, and 
> only for syslog in a delimited stream coming in over the 
> syslog/tls port, it would not impact existing code, only code 
> that supports syslog/tls.
> New syslog/tls code would be needed to extract each "normal" 
> syslog message from the stream and then send it on for 
> processing through the existing parser. 
> 
> If message originators start escaping special characters in 
> the message content, existing receivers may need to be 
> modified to un-escape the characters. Think about 
> applications, such as intrusion detection systems, that 
> search for special patterns in syslog content
> - those could be broken by having the content changed by 
> escaping characters in the middle of the content.
> 
> What happens at a store-then-forward relay? Does the relay 
> store the escaped characters or does it un-escape them first? 
> Does it escape them again when it forwards the message? Does 
> it escape them if it un-escaped them on input? Does it escape 
> them if it did not un-escape them on input? What if the 
> sender included some escaped characaters (like '\') for other 
> purposes? Should the relay unescape them as well?
> Will it know to re-escape them on output? What should the 
> ultimate reciever expect to receive?
> 
> Byte-counting looks way less complex to me than choosing a 
> special character and escaping/unescaping special characters 
> in the content during the sending/forwarding/recieving 
> process. (And my opinion has nothing to do with the H**** in 
> my email address.)
> 
> dbh
> 
> > -----Original Message-----
> > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]
> > Sent: Tuesday, August 15, 2006 12:41 AM
> > To: Miao Fuyou
> > Cc: syslog@ietf.org
> > Subject: RE: [Syslog] timeline
> > 
> > Miao,
> > 
> > I am actually concerned about backward compatibility with existing 
> > code
> > *without* the need to upgrade any of that code. As you know,
> deployed
> > software tends to stick.
> > 
> > If we use just LF, existing, deployed technology (e.g. syslog-ng
> with
> > stunnel) would be able to understand a message sent from a "new
> style"
> > syslogd. Having the octet count in front of the message 
> removes that 
> > ability, as the old syslogd will no longer see the <pri> at 
> the start 
> > of the message.
> > 
> > I agree that it is trivial to modify code to take care for 
> the octet 
> > counter. But this is not my concern. My concern is that I 
> would like 
> > to achive as good as possible compatibility with existing deployed 
> > (aka
> > "unmodified") technology. I should have been more specific on that.
> > Sorry for the omission...
> > 
> > I am also unaware of any implementation that mandates CR LF over
> just
> > LF. Could you let me know which ones are these?
> > 
> > Rainer
> > 
> > > -----Original Message-----
> > > From: Miao Fuyou [mailto:miaofy@huawei.com]
> > > Sent: Monday, August 14, 2006 7:07 PM
> > > To: Rainer Gerhards
> > > Cc: syslog@ietf.org
> > > Subject: RE: [Syslog] timeline
> > > 
> > >  
> > > Hi, Rainer,
> > > 
> > > A new implementation could rely on byte-counting only and then 
> > > delete LF from the frame(appplication knows exactly where the LF 
> > > is), it may not force us to use escapes. For LF, I think it is 
> > > difficult to get 100% compatibility for a legacy 
> implementation to 
> > > comply TLS-transport without any change to the code. At 
> least, some 
> > > imlementation may need to change
> > CR LF to LF
> > > because some implementations use CR LF rather than LF. 
> So, it may be 
> > > ok to add several LOC to delete FRAME-LEN SP from the frame.
> > > 
> > > I still prefer byte-counting only to byte-counting+LF even
> > if it is a
> > > feasible tradeoff.  
> > > 
> > > Miao
> > > 
> > > > -----Original Message-----
> > > > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com]
> > > > Sent: Monday, August 14, 2006 10:18 PM
> > > > To: Miao Fuyou
> > > > Subject: RE: [Syslog] timeline
> > > > 
> > > > We should not go byte-counting + LF. This is the worst choice:
> it 
> > > > 
> > > > A) breaks compatibility
> > > > B) Forces us to use escapes
> > > > 
> > > > So we get the bad of both worlds, without any benefits.
> > > > 
> > > > Rainer
> > > > 
> > > > > -----Original Message-----
> > > > > From: Miao Fuyou [mailto:miaofy@huawei.com]
> > > > > Sent: Monday, August 14, 2006 12:58 AM
> > > > > To: 'Anton Okmianski (aokmians)'; 'David Harrington';
> > > > syslog@ietf.org
> > > > > Subject: RE: [Syslog] timeline
> > > > > 
> > > > > 
> > > > > My vote: byte-counting only > byte-counting + LF > LF
> > > >  
> > > > 
> > > 
> > > 
> > > 
> > 
> > _______________________________________________
> > Syslog mailing list
> > Syslog@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/syslog
> > 
> 
> 
> _______________________________________________
> Syslog mailing list
> Syslog@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/syslog
> 

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog