RE: [logs] SDSC Secure Syslog

From: Rainer Gerhards (rgerhardsat_private)
Date: Fri Dec 13 2002 - 07:58:51 PST

  • Next message: Darren Reed: "Re: [logs] SDSC Secure Syslog"

    Darren,
    
    > Yes, the (optional) dump part is what I was referring to as 
    > being absent in syslog and how do we add that sort of 
    > functionality if we want it ?
    
    Good point. Before addressing this, please let me say that experience
    from the vast majority of our customer says that the dump part is not
    needed. So formatting Windows Event Log "PIX-Like" already solves a lot
    of problems and brings much value to log analysis.
    
    On the other hand, there are people who obviously have a valid need for
    the dump part.
    
    I see at least two solutions for this, but none with the current RFCs.
    So let's assume that we might be able to either change one of them or
    take the liberty to just ignore the RFCs if a group of implementors
    agrees to solve the issues...
    
    1. The syslog client system can actually send the binary part togehter
    with the textual one. For easy parsing, it should do this in a
    structured way (that is the discussion on message format & content). For
    example, we could use XML and include the dump (in hex or base64) within
    <bdata> tags. The syslog server can then decide to either
    accept/store/process the binary part or dump it after receiving.
    
    Pro: extremely easy to implement
    Con: uses up bandwidth for nothing if server decides to drop
    
    
    2. Much like #1, but client and server negotiate if binary data is to be
    sent on session startup.
    
    Pro: potentially less bandwidth-intense (but session overhead to be kept
    in mind)
    Con: more complicated, specifically a session-based transport needs to
    be specified as does the protocol to drive it
    
    In both cases, TCP is a requirement.
    
    Please keep in mind that we already do those kind of things with our
    non-open protocols and it performs well. So this is defenitely not a
    no-go. I think more complex protocol issues have been solved in the
    past. It is just an issue if people agree on actually doing it...
    
    Rainer
    _______________________________________________
    LogAnalysis mailing list
    LogAnalysisat_private
    http://lists.shmoo.com/mailman/listinfo/loganalysis
    



    This archive was generated by hypermail 2b30 : Fri Dec 13 2002 - 11:02:30 PST