At 07:41 AM 10/21/1999 +1000, Darren Reed wrote:
>In some email I received from Roger Marquis, sie wrote:
>[...]
>> Except that syslog doesn't need sequence numbers, it doesn't need
>> sliding windows, it doesn't need slow-start or any of the other
>> connection-oriented features of TCP. These are features which
>> facilitate continuous, bidirectional data circuits. Syslog messages
>> are not, in the vast majority of cases, connection-oriented. They
>> don't need to setup, maintain, and tear-down a session/circuit. 99% of
>> syslog data requires only a single packet and a single ACK (for
>> reliability).
>>
>> The choice of protocol should be based on the traffic it's carrying.
>> For syslog that's fundamentally connectionless, stateless and by
>> extension UDP.
>
>If you showed me evidence, in court, that was based on an unreliable
>source, how could you claim that what was being presented was itself,
>reliable and accurate ?
By referring to the authentication codes included in the message. Note
that UDP does not say that the source is unreliable, just the transport,
and that TCP's "reliability" doesn't map well onto "reliable" in the sense
of evidence.
That is, TCP reliability means that if you queue something for
transmission, the system will keep trying to send it until it's
acknowledged or the TCP connection is broken. It doesn't say that only
messages from source you're connected to will be received and treated as
part of the TCP connection's data stream. In fact, it's possible to spoof
TCP w.r.t. source host.
For evidence or testimony, "reliable source" means that you can verify by
some means that what's presented as evidence has not been altered in such a
way that it "attests" to some event or circumstance that never really
happened or existed. It's not clear that losing some messages in the
normal course of operations would interfere with reliability in this sense.
>The next implicit problem with UDP is to do with size - you can only
>fit so much in a UDP message, without causing fragmentation. There
>are a number of protocols (DNS comes to mind) which have limitations
>built in because of that. With syslog today, there is an arbitrary
>limit of 1024 bytes in a syslog message. Start adding in checksums
>and you run out of room real quick.
Yeah, this is a real problem, especially under IPv6 (since routers won't
fragment for hosts). In order to handle this, a UDP-based protocol would
have to provide application-layer oversize message detection,
fragmentation, and retransmission, I think. In fact, I think old syslog
would have to provide either fragmentation or truncation to work over IPv6
(what's that minimum MTU again?).
Bob
