Subject: RE: [Syslog] delineated datagrams

From: "Anton Okmianski \(aokmians\)" <[email-masked]>
Date: Tue, 20 Jun 2006 14:18:34 -0400

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. 

> -----Original Message-----
> From: Tom Petch [mailto:[email-masked]] 
> Sent: Tuesday, June 20, 2006 8:43 AM
> To: [email-masked]
> 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-masked]>
> To: <[email-masked]>
> 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-masked]
> 
> 
> _______________________________________________
> Syslog mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/syslog
> 
> 
> _______________________________________________
> Syslog mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/syslog
> 

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 22 Jun 2006 11:47:12 +0200

<inline>
----- Original Message -----
From: "Anton Okmianski (aokmians)" <[email-masked]>
To: "Tom Petch" <[email-masked]>; <[email-masked]>
Sent: Tuesday, June 20, 2006 8:18 PM
Subject: RE: [Syslog] delineated datagrams

Tom:

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.

---

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 22 Jun 2006 14:32:50 +0200

Tom: 

[big snip]

> (and yes, I do like end of record markers:-)

I see your concerns and think they are valid. I have argued for using a
length in the header instead of an end of record marker. But this is
different from what you are discussing now. We discussed it in the
context that there were no header and we would exlusively rely on the
end of record marker. As any valid character sequence is allowed in the
MSG part, this is not a valid option (how do you know it is an EOR and
not just a usual sequence in the middle of the message?).

However, we can add a trailer, which is much like a cookie. For the same
reason as the EOR, it is not fault-prooven by itself, but the likelyhood
that is is mistakenly interpreted if you use it togehter with a byte
counting header is small.

Again, the only other alternative would be to disallow an EOR sequence
inside MSG or require it to be escaped their. That sounds like a crappy
little rule to me...

Rainer