Starting from TCP and then upgrading to tls is quite different to current
tls transport mapping document. If we decide to do UPGRADING, we may first
need a TCP transport mapping for Syslog, and then define a specific string
to indicate the other side to upgrade to TLS. We currently assume Syslog has
a IANA allocated port for tls transport mapping, we may not need such
complexity on upgrading.
FYI, HTTP has two tls mechansims: RFC2818(standards track) is similiar to
this draft, RFC2817(Informational) is on upgrading.
-Original Message-
From: tom.petch [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 06, 2006 2:51 AM
To: Balazs Scheidler; Chris Lonvick
Cc: [EMAIL PROTECTED]
Subject: Re: version field in syslog-tls - was: RE: [Syslog]
Working GroupLastCall: syslog-tls document
- Original Message -
From: Balazs Scheidler [EMAIL PROTECTED]
To: Chris Lonvick [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, September 05, 2006 9:18 AM
Subject: Re: version field in syslog-tls - was: RE: [Syslog]
Working GroupLast
Call: syslog-tls document
On Mon, 2006-09-04 at 15:49 -0700, Chris Lonvick wrote:
Hi All,
Please do consider the version field. If we don't have one, we
would have to live forever with the decisions we are making now.
Having a version number in there would allow a future group to
re-decide things (like byte-count v. special character)
and to just
change the version number rather than go asking for a new
port number - or have a flag day.
Please review the document and send in your thoughts on this.
Sending the version field is a good idea in general, however I feel
that adding it to _every single_ message in a conversation is too
redundant, apart from the extra bandwidth used, it causes
ambiguities
what to do when different messages use a different version number.
The version should be associated with the channel, and not
individual
messages.
Having a simple negotiation at the start would IMHO be way better.
Something like:
HELLO capabilities
OK capabilities
START
OK
message stream
I too like starting with a simple negotiation. I notice that
other applications that started with TCP and then added
security have used character strings such as AUTH TLS which
has the advantage of readily adding in SSH (or anything else)
in the future.
I also like being able to add later a choice as to which end
is client and which server since I foresee problems here with
security credentials (most other applications have the server
on a well-connected device well able to verify secuirty
credentials, something a remote network box is less well able to do).
Tom Petch
--
Bazsi
___
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
