RE: [Syslog] stream transportwasdraft-ietf-syslog-transport-tls-01.txt

["Rainer Gerhards" <rgerhards at hq.adiscon.com>]

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:aokmians at cisco.com] 
> Sent: Friday, June 16, 2006 5:50 PM
> To: Rainer Gerhards; Tom Petch; syslog at ietf.org
> 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:rgerhards at hq.adiscon.com] 
> > Sent: Friday, June 16, 2006 11:36 AM
> > To: Anton Okmianski (aokmians); Tom Petch; syslog at ietf.org
> > Subject: RE: [Syslog] stream 
> > transportwasdraft-ietf-syslog-transport-tls-01.txt
> > 
> > Anton, 
> > 
> > > -----Original Message-----
> > > From: Anton Okmianski (aokmians) [mailto:aokmians at cisco.com] 
> > > Sent: Friday, June 16, 2006 5:25 PM
> > > To: Tom Petch; syslog at ietf.org
> > > 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:nwnetworks at dial.pipex.com] 
> > > > Sent: Friday, June 16, 2006 4:13 AM
> > > > To: syslog at ietf.org
> > > > 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" <dbharrington at comcast.net>
> > > > To: <syslog at ietf.org>
> > > > 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
> > > > ietfdbh at comcast.net
> > > > _______________________________________________
> > > > Syslog mailing list
> > > > Syslog at lists.ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/syslog
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Syslog mailing list
> > > > Syslog at lists.ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/syslog
> > > > 
> > > 
> > > _______________________________________________
> > > Syslog mailing list
> > > Syslog at lists.ietf.org
> > > https://www1.ietf.org/mailman/listinfo/syslog
> > > 
> > 
> 

_______________________________________________
Syslog mailing list
Syslog at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog