Hi Tom,
Welcome back.
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?
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
