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

["Rainer Gerhards" <[e-mail]>]

Anton, 

> -----Original Message-----
> From: Anton Okmianski (aokmians) [mailto:[e-mail]] 
> Sent: Friday, June 16, 2006 5:25 PM
> To: Tom Petch; [e-mail]
> 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:[e-mail]] 
> > Sent: Friday, June 16, 2006 4:13 AM
> > To: [e-mail]
> > 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" <[e-mail]>
> > To: <[e-mail]>
> > 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
> > [e-mail]
> > _______________________________________________
> > Syslog mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/syslog
> > 
> > 
> > _______________________________________________
> > Syslog mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/syslog
> > 
> 
> _______________________________________________
> Syslog mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/syslog
> 

_______________________________________________
Syslog mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/syslog