Re: [logs] SELP spec - Apologies

krhat_private

On Mon, 21 Jul 2003 13:25:25 +0200, "Rainer Gerhards" wrote:
> > Connection initiation and termination are very closely connected to
> > reliability, and there is some overlap.  I think the distinction is
> > still good, but you may want to swap 2.4 with 2.5.
> >
> > The description in 2.4 feels a little long, and there are things in
> > 2.5 that I think should be in 2.4.  I suggest replacing it with
> > something shorter.  For example:
> >
> > ---
> > SELP is a simplex protocol. It relies on TCP exclusively for
> > reliability. There is no SELP layer acknowledgment.
> >
> > SELP is only reliable as long as the TCP stream is not broken.
> > If the TCP stream breaks, the sender does not know what data
> > has been received by the receiver and what has not.  In this
> > case the sender SHOULD log an event to the local system event
> > repository.
> >
> > If the sender intends to transmit further data to the receiver,
> > or if a message was not fully transmitted before the connection
> > ended, the sender MUST attempt to reconnect to the receiver.
> > If the receiver is unavailable for long periods of time,
> > implementations MUST eventually stop attempting to reconnect.
> > Implementations MAY then log any queued messages to the local
> > repository.  Whether or not the messages are logged locally,
> > the messages MUST NOT then be retransmitted to the receiver
> > when it becomes available.
> >
> > If the sender succesfully reconnects to the receiver, the
> > sender MAY attempt to determine the last message correctly
> > transmitted, and if it does, it SHOULD attempt to retransmit
> > any messages after the last message that was known to be
> > correctly transmitted.  The sender MUST NOT use out-of-band
> > communication methods to determine the last correctly transmitted
> > message.  If the sender does not attempt to determine the last
> > correctly transmitted message, the sender SHOULD retransmit
> > the most recently sent message.
> >
> > If a connection is unexpectedly terminated and an partial SELP
> > frame has already been sent, the receiver MUST mark the message
> > as having been cut off, and the receiver MUST then log the
> > frame as if it were properly terminated.
> >
> 
> Great content - but I need to think a little bit more on this. I
> included the whole thing with the sliding window and such because so
> many people think TCP does not have any real issue. But maybe this
> should go into the security considerations... More comments? BTW: any
> objects on discussing this on the list (I talked to Tina when the thread
> initially started and she felt well with it).

Hmm.  I think you're right, this is a security consideration and should be
mentioned in there, but I also am not sure that the security considerations
section is the right place to specify this sort of protocol behavior.  There
is always the possibility that the connection will be broken when neither the
sender or the receiver is being attacked.  For example, a sysadmin might kill
the syslog process and restart it, or a router in between the sender and
receiver might crash.  I tried to phrase the text above to cover any sort
of connection termination.

I'm not sure about the third paragraph, myself.  I feel a little uncomfortable
with some of those MUSTs, but I don't know what to do about them.

I like the idea of having this discussion publically, so I'm cc'ing the
loganalysis list for this email.  (For those of you just joining us, I wrote
the innermost level of quoted text as comments on the most recent SELP draft.)

> > I hope someone adopts it, somewhere.
> 
> ... Working on this. But I honestly believe RFC3195 is the long-term
> solution.

Yes, it is.  But the reasoning behind SELP still stands: It's much easier to
implement SELP than 3195, and SELP, flawed as it is, is still much better than
plain old syslog.

> I will reformat the text soon and then post it up on the web site. Do
> you object if I post your comments to the list, so that people know what
> has changed? Of course, I can do this anonymously, if you like.

Go right ahead.  I don't keep copies of my sent email, but if you still have
it, I bet other people would be interested.

-- 
Kyle R. Hofmann <krhat_private>
_______________________________________________
LogAnalysis mailing list
LogAnalysisat_private
http://lists.shmoo.com/mailman/listinfo/loganalysis