> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 22, 2006 9:09 AM
> To: Miao Fuyou
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Syslog] Updated Syslog-tls Document
>
> On Wed, Nov 22, 2006 at 09:12:38AM +0800, Miao Fuyou wrote:
>
> > There are two major changes since last update.
> > 1, Section 3 is removed. It is an introductory text on TLS,
> and is neccesary
> > because TLS is already a normative reference.
> > 2, Updated the section 4.3.2 (original 5.3.2), removed the
> text about TLS
> > layer alert to signal a syslog-transport event
>
> I questioned the need for a version number for the TLS transport in
> private conversation and now I bring this up again here.
Was that private? I thought it was on-list. Anyhow... I concur with your
initial recommendation of removing the version number from the transport
header. The point at that time was that a version in transport specs is
unusual. If there is need to revise a transport header, a new port is
assigend. Sure, ports are a scarce ressource, but how likely is an
incompatible change to the transport header?
> I believe we
> should agree on a single solution scheme and not introduce any options
> here since signalling of a version mismatch is difficult in a fire and
> forget situation. The current text says:
>
> > If a receiver does not support the version in the messages it
> > received, it MAY just save the APPLICATION-DATA in local
> storage or
> > send a close_notify to signal the closure of the
> connection. If a
> > sender/relay finds connections are closed just after
> successful TLS
> > handshake for three times with same transport mapping version, it
> > SHOULD not connect the receiver again with the same
> transport mapping
> > version.
>
> This does not at all sound very convincing to me (and I assume what
> the author wanted to say is not well said because I believe the
> trigger for not trying again would be a close after sending the first
> syslog message and not after the successful TLS handshake).
I, too, assume this was meant...
> Is there
> not a potential attack possible here by successfully "killing" a TCP
> connection three times in a row?
... and I am not happy with it either. There may be different reasons
for tearing down the session, especially in a troubleshooting scenario.
We should keep in mind that one important application for syslog is
troubleshooting failing networks, which increases the likelyhood of
unexpected session terminations.
I object the ultimate "non-delivery" SHOULD. If we use this clause, we
should at least recommend a retry after a specified period.
But my suggestion is to remove the version as well as this text.
Rainer
>
> /js
>
> --
> Juergen Schoenwaelder {International|Jacobs}
> University Bremen
> <http://www.eecs.iu-bremen.de/> P.O. Box 750 561,
> 28725 Bremen, Germany
>
> _______________________________________________
> 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
