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

["Anton Okmianski \(aokmians\)" <aokmians at cisco.com>]

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