Anton, the ACK should only be from hop to hop - much as in SMTP. It is a method to know if the data has arrived at the next receiver. I think it probably is worth it. I can live without the ACK, but I think a defined closure is needed. An initiation exchange I consider useful, but again not mandotory.
Rainer > -----Original Message----- > From: Anton Okmianski (aokmians) [mailto:[EMAIL PROTECTED] > Sent: Friday, June 16, 2006 5:50 PM > To: Rainer Gerhards; Tom Petch; [EMAIL PROTECTED] > Subject: RE: [Syslog] stream > transportwasdraft-ietf-syslog-transport-tls-01.txt > > App-layer ACK is an interesting idea, but I think it opens up > a big discussion. Does the relay ACK? Overlap with RFC 3195 > (syslog-beep). Overlap with SNMP Informs. Etc. > > Anton. > > > -----Original Message----- > > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > > Sent: Friday, June 16, 2006 11:36 AM > > To: Anton Okmianski (aokmians); Tom Petch; [EMAIL PROTECTED] > > Subject: RE: [Syslog] stream > > transportwasdraft-ietf-syslog-transport-tls-01.txt > > > > Anton, > > > > > -----Original Message----- > > > From: Anton Okmianski (aokmians) [mailto:[EMAIL PROTECTED] > > > Sent: Friday, June 16, 2006 5:25 PM > > > To: Tom Petch; [EMAIL PROTECTED] > > > Subject: RE: [Syslog] stream > > > transportwasdraft-ietf-syslog-transport-tls-01.txt > > > > > > I was just talking to Rainer about similar concern. > > > > You were, but I misunderstood it. I was so focussed on the > (objected) > > plain tcp transport, that I did not realize that you were actually > > talking of a layer between -protocol and -transport-whatever-secure. > > > > > I think first of all we need a basic mapping to TCP or more > > > generally define syslog payload (framing) format for > > > connection-oriented protocols. This should cover sending > > > multiple messages over the same connection, obviously. The > > > same payload structure can be used over various TCP protocols > > > (TLScTCP, SSHoTCP, etc) or even over straight TCP with IPSec. > > > > > > Connection establishment and tear-down issues should be left > > > to the actual transport. > > > > I think it shouldn't. I actually think we need an app-layer ACK, > > otherwise we might loose messages without knowing it. This > is from the > > SELP spec I posted earlier: > > > > ======= > > As such, SELP is only reliable as far as the TCP stream is not > > broken. If the TCP stream breaks, the sender does not > exactly know > > which data has actually been transmitted to the receiver > and which > > not. This is due to the fact that TCP uses a sliding window of > > variable size. In short, this allows that the sender > sends packets, > > receives an acknowledgement from the OS, but the data is > > still on the > > wire. The OS acknowledgment does NOT mean the data is actually > > received. While the sender continues to send data, the already OS > > acknowledge data is eventually delivered to the sender. If that > > succeeds, everthing is fine. If now, however, the TCP stack will > > detect the problem over time and notify the sender. However, the > > sender does not know exactly where the problem occured > and so does > > not know what to re-send. Anyhow, it knows at least > something went > > wrong and SHOULD log an event to a local system event repository. > > ====== > > > > I think we should address this need in a tcp (or better: stream) > > framing. It's not a big deal to add an app-level opening and > > closing to > > the protocol - and eventually even an app-level ack/nak > (per message), > > which would relive us of many problems. > > > > It can be as simple as > > > > Sender: > > XFERSTART <sender-name> (could be checked against cert!) > > MSG <header><protocol-message><trailer> (trailer for error-checking, > > questionable) > > CLOSE <optional-param> > > > > Receiver: > > SMTP-like status codes (or simply ACK / NAK "reason") > > > > No a big deal but a big advantage... > > > > > If we don't introduce anything new > > > in TLS or SSH, I am not sure why anything extra is needed to > > > be specified. Maybe just to create a baseline of requirement > > > (minim cipher suite, auth mode, etc), but even that is > > questionable. > > > > I think the parameters should be outlined. > > > > > > BTW, can IPSec be considered a viable security transport for > > > syslog using UDP transport? I already mentioned how IPSec > > > can address security issues in syslog-transport-udp-07. So, > > > do we simply need to provide an overview of how it does it in > > > that ID to pass the IESG criteria of secure syslog transport? > > > > This is a very good question, I think one for Sam. Maybe Chris could > > check it out? > > > > Rainer > > > > > > Thanks, > > > Anton. > > > > > > > -----Original Message----- > > > > From: Tom Petch [mailto:[EMAIL PROTECTED] > > > > Sent: Friday, June 16, 2006 4:13 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: [Syslog] stream transport > > > > wasdraft-ietf-syslog-transport-tls-01.txt > > > > > > > > I think that this document has some way to go. It has > > > > introduced, and woven > > > > together, both TLS and TCP transport, which I think wrong. > > > > Ideally, I think > > > > that we should have two separate documents, one dealing with > > > > TLS, the other with > > > > TCP issues; given that both would be short, it is probably > > > > sensible to have only > > > > the one, but I still see the need for separation within the > > > > document. After > > > > all, DTLS exists: an outsider could, should, think that > > > > syslog is UDP-based, > > > > DTLS provides UDP security so DTLS is the obvious choice, > > > > what on earth is this > > > > document talking about? We need a section on DTLS (if only > > > > justifying why it is > > > > not for further consideration). And, for me, that alone > > > > justifies teasing out > > > > the TLS issues from the TCP issues; is FRAME-LEN needed > > over DTLS?. > > > > > > > > That said, I do not think that this document adequately > > > > covers the TCP issues, > > > > ones that have surfaced on the list before. > > > > > > > > TLSoTCP can deliver one syslog message, many syslog messages, > > > > part of a syslog > > > > message or a combination thereof - it is in the nature of a > > > > stream protocol. > > > > This needs spelling out. > > > > > > > > A TCP connection takes time to set up, TLSoTCP longer. This > > > > needs spelling out; > > > > if timely delivery is a concern, then the connection should > > > > be established in > > > > advance. > > > > > > > > The section on TCP termination is too weak. If we are > > > > recommending a timeout, > > > > then we should recommend a value, even specifying that it > > > > should be configurable > > > > over a range. And if we cannot agree on such values, I do > > > > not think we should > > > > be specifying a timeout. > > > > > > > > TCP perforce introduces flow control. This will slow down > > > > and rate limit > > > > messages; what is the impact of this on the application? > > > > > > > > TCP failures can terminate the connection! Again, this has > > > > an impact on the > > > > application with the time taken to become aware that the > > > > connection has failed. > > > > > > > > Tom Petch > > > > > > > > ----- Original Message ----- > > > > From: "David B Harrington" <[EMAIL PROTECTED]> > > > > To: <[EMAIL PROTECTED]> > > > > Sent: Tuesday, May 09, 2006 4:26 PM > > > > Subject: [Syslog] draft-ietf-syslog-transport-tls-01.txt > > > > > > > > > > > > Hi, > > > > > > > > A new revision of the syslog/TLS draft is available. > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-01 > > > > .txt > > > > > > > > We need reviewers. > > > > Can we get > > > > 1) a person to check the grammar? > > > > 2) a person to check the syslog technical parts? > > > > 3) a person to check compatibility with the other WG documents? > > > > 4) a person to check the TLS technical parts? > > > > > > > > We also need general reviews of the document by multiple people. > > > > > > > > Thanks, > > > > David Harrington > > > > co-chair, Syslog WG > > > > [EMAIL PROTECTED] > > > > _______________________________________________ > > > > 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 > > > > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
