Apologies for my absence last week. Comments below Tom Petch ----- Original Message ----- From: "Miao Fuyou" <[EMAIL PROTECTED]> To: "'tom.petch'" <[EMAIL PROTECTED]>; "'Balazs Scheidler'" <[EMAIL PROTECTED]>; "'Chris Lonvick'" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, September 07, 2006 11:17 AM Subject: RE: version field in syslog-tls - was: RE: [Syslog] Working GroupLastCall: syslog-tls document
> > 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. I am NOT suggesting that we have a TCP transport which can be switched dynamically to be or not be TLS; that was not my intended meaning of the words I used.. Rather I was saying that other applications, forget how they got there, found it useful to have a string at the front stating their intentions, eg to use TLS. Of course, no matter how simple, like a single digit for a version number, this is in some sense an application protocol. What does the recipient do if it agrees, what if it disagrees? Terminating the connection may cause the transmitter to try again and then what? All soluble problems. I also think that hard coding this 'information' into a well known port is wrong. Ports may or may not be in short supply but the management associated with them by anyone with firewall or gateway, ie many if not most enterprises. is a pain so I am very much of the view to keep the number of ports few in number, and reuse them by changing the initial string. 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 > > > [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
