----- Original Message ----- From: "David Harrington" <[EMAIL PROTECTED]> To: "'tom.petch'" <[EMAIL PROTECTED]>; "'Miao Fuyou'" <[EMAIL PROTECTED]>; "'Balazs Scheidler'" <[EMAIL PROTECTED]>; "'Chris Lonvick'" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, September 18, 2006 8:56 PM Subject: RE: version field in syslog-tls - was: RE: [Syslog] WorkingGroupLastCall: syslog-tls document
> > I agree that section 5.3.2 should describe the behavior of the > receiver if a message with a protocol version that is not supported is > received, and it should recognize that future version #s are possible > in this position. Could you suggest text for this? > Not yet; I do not yet see one obvious right action to text. Rather I see choices:- a) receiver terminates session unilaterally; currently this is only allowed after an 'idle timeout' and closure alert. 'protocol_version' alert would seem appropriate; do the TLS stacks allow syslog to generate this?. b) receiver returns syslog text message 'not ok' which rather implies a message 'ok' when it is, all of which is alien to this simplex application. c) receiver terminates session. simple, but likely to cause the sender to keep retrying for a while. Thoughts? Tom Petch > Can you identify which applications find it useful to have a string at > the front, and what was found useful about it? Would the string be > required, and the text be standard? I would be interested in seeing > others' comments on this suggestion. > > Personally, I think using an assigned port serves the purpose of > differentiating syslog from syslog/tls for receiving applications and > for applications such as firewalls; use of a reserved port number > alleviates the need for the string and is consistent with other > Internet standards. Other protocols retrofitted to run over secure > protocols have been assigned separate ports to differentiate the > secure and non-secure versions of the protocol. Presumably there have > been good justifications for the IESG to approve such port > assignments. BCP 72, RFC 3552 section 4.5.2 supports the practice. > > I will note that so many applications are retrofitting to TLS that > maybe IANA should consider port assignment ranges for udp, tcp, and > tls/ssl ;-) > > David Harrington > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > > > > -----Original Message----- > > From: tom.petch [mailto:[EMAIL PROTECTED] > > Sent: Monday, September 18, 2006 3:23 AM > > To: Miao Fuyou; 'Balazs Scheidler'; 'Chris Lonvick' > > Cc: [EMAIL PROTECTED] > > Subject: Re: version field in syslog-tls - was: RE: [Syslog] > > WorkingGroupLastCall: syslog-tls document > > > > 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 > > > _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
