<inline> ----- Original Message ----- From: "Anton Okmianski (aokmians)" <[EMAIL PROTECTED]> To: "Tom Petch" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, June 20, 2006 8:18 PM Subject: RE: [Syslog] delineated datagrams
Tom: I think these are valid concerns. They span different layers: 1. If we only care about network-layer reliability (as in byte insert/remove examples): client/server can be recommended to reset connection every so often. Decent corruption detection is already part of TCP/IP and layer 2 protocols. 2. If we care about app-layer reliability (as in encode/decode error examples): app-level ACK. As in RFC 3195, for example. This certainly expands the scope quite a bit beyond just secure transport. Anton My concern was in between, the shim between TCP and syslog that is TLS. With UDP transport, a Relay receives a datagram and sends it on its way, no processing required; probability of corruption small enough to ignore, consequences when it does, one corrupted packet. With TLS, the packet must be decrypted, unpadded, decompressed split into 'datagrams' on the basis of a string of decimal digits and then re-packaged to send on its way. If a byte is lost here, chances are the string of decimal digits will point into the middle of a valid string of decimal digits, which will give a truncated second 'datagram' and point into who knows what. Eventually, the pointer will not point to a string of decimal digits and the Relay will realise it is lost. By then, it may have forwarded several corrupted or truncated 'datagrams'. And the chance of recovering sync is, IMO, nil; tear down the connection and set it up again. By contrast, there are protocols which rely on detecting sync, use it initially, error detect and error recover with it. Of course, they have more to go on than a string of decimal digits, they have structures which are distinctive in the context of the datastream (I would for example expect to recover sync with BER.1 encoding of SNMP, although I don't know anyone who does that). So my thinking is should we have more than a string of decimal digits, like </length=137> or something else that is obviously invalid so that errors are likely to be detected immediately and the Relay has a chance of scanning the stream to recover sync. You may recall we have had discussions of length v end of record marker before (and yes, I do like end of record markers:-) Tom Petch Anton. > -----Original Message----- > From: Tom Petch [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 20, 2006 8:43 AM > To: [EMAIL PROTECTED] > Subject: Re: [Syslog] delineated datagrams > wasdraft-ietf-syslog-transport-tls-01.txt > > I wonder if others share my concern about the lack of > robustness in the way in > which datagrams are delineated in the stream protocol (a TCP > rather than a TLS > issue). > > The system works as long as > - the frame length is encoded perfectly > - the frame length is decoded perfectly > - no bytes are inserted or removed in error > which is doubtless true in some networks, but I would prefer > not to rely on it. > > So, when an error occurs, can the Collector/Relay detect it? Can the > Collector/Relay recover synch? If not, what does the > Collector/Relay do? > > There is very little redundancy in the definition of frame > length, and syslog > messages have very little structure to help the application, > so I think that > this is an issue we should address. > > Tom Petch > > ----- Original Message ----- > From: "David B Harrington" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, May 09, 2006 4:26 PM > Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt > > > Hi, > > A new revision of the syslog/TLS draft is available. > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 > .txt > > We need reviewers. > Can we get > 1) a person to check the grammar? > 2) a person to check the syslog technical parts? > 3) a person to check compatibility with the other WG documents? > 4) a person to check the TLS technical parts? > > We also need general reviews of the document by multiple people. > > Thanks, > David Harrington > co-chair, Syslog WG > [EMAIL PROTECTED] > > > _______________________________________________ > Syslog mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ > Syslog mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
