Re: [Sipping] Alternate CLF syntax proposal

[Hadriel Kaplan <[e-mail]>]

BTW, the below would be parsed as a RADIUS Accounting message.
So essentially what this could mean is the "log file" entry format is a pcap packet format, one "capture packet" per log entry.  You could encode the whole SIP message in such as usual, including real IP/UDP headers, or you could encode what effectively looks like a RADIUS message in such to encode specific TLV's (Radius Attributes) - or you can do *both* in the same log stream.  

Or if we think 255 attributes of up to 255 octets each is not enough, one could encode it as DIAMATER messages - again you're not running DIAMETER, it's just an encoding format that supports TLV's which happens to look like DIAMETER for tools receiving it, without actually running RADIUS/DIAMETER and thus without the responses and application of those - just streamed log entries.

Just a whacky idea, probably.  But there sure is a lot of available, running code for this.

-hadriel

> -----Original Message-----
> From: Hadriel Kaplan
> Sent: Thursday, March 26, 2009 5:06 PM
> To: Hadriel Kaplan; Vijay K. Gurbani; Adam Roach
> Cc: sipping WG; [e-mail]
> Subject: RE: [Sipping] Alternate CLF syntax proposal
> 
> 
> Actually, ya know we can combine this with something like Adam's draft.
> If you take the pcap entry format, and encode a "log" entry with the
> following header:
> 
> 
> |   0    |   1    |   2    |   3    |   4    |   5    |   6    |   7    |
> -------------------------------------------------------------------------
> |                           seconds                                     |
> -------------------------------------------------------------------------
> |                         microseconds                                  |
> -------------------------------------------------------------------------
> |                           saved_len                                   |
> -------------------------------------------------------------------------
> |                           orig_len                                    |
> -------------------------------------------------------------------------
> |                           all 0x00                                    |
> -------------------------------------------------------------------------
> |             0x00                  |     0x0800      |    0x4500       |
> -------------------------------------------------------------------------
> | log_entry_len   |    seq_no       |        0x000001         | 0x11    |
> -------------------------------------------------------------------------
> |                              all 0x00                                 |
> -------------------------------------------------------------------------
> |      0x00       |    0x0715       |    0x0715       |  entry_len      |
> -------------------------------------------------------------------------
> |      0x00       |  0x04  | 0x00   |      tot_len    |     0x0000      |
> -------------------------------------------------------------------------
> |            all 0x00                                 |   BEGIN         |
> -------------------------------------------------------------------------
> 
> Then starting with the BEGIN bytes, you can record each Tag-Length-Value
> triple using the following:
> 1-Byte Type
> 1-byte Length (including type and length bytes)
> 1-255 bytes of chars
> 
> And once again there would be plenty of tools/running-code which can
> already parse that today.  :)
> 
> Or we could do a slightly different variant of the "header", if you want
> TLV's which can be bigger/longer.
> 
> -hadriel
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> Behalf
> > Of Hadriel Kaplan
> > Sent: Thursday, March 26, 2009 3:57 PM
> > To: Vijay K. Gurbani; Adam Roach
> > Cc: sipping WG; [e-mail]
> > Subject: Re: [Sipping] Alternate CLF syntax proposal
> >
> >
> > If the purpose of it is troubleshooting, or threat analysis type stuff,
> I
> > think the following format satisfies the needs as well:
> > http://wiki.wireshark.org/Development/LibpcapFileFormat
> >
> > The advantages:
> > 1) There's running code
> > 2) There's open source, on all operating systems, and also for
> commercial
> > use
> > 3) It's used by many people
> > 4) There are many tools which accept/process it
> > 5) It's fast to write/save
> > 6) It supports a sub-second timestamp
> > 7) It supports length encoding of packets, so you can skip past them
> > 8) It supports truncated saving of packets, so you don't have to save
> all
> > of very big ones
> > 9) It records the method name or response code very early in the saved
> log
> > entry for each packet
> >
> > Disadvantages:
> > 1) Nothing much new to specify, except to document it?
> > 2) It's a little tricky for SIP/TLS, where you basically have to create
> > fake segments/packets for the low layers, and same may be true for
> SIP/TCP
> > depending on when you record the log
> > 3) It doesn't provide a way to report internal system
> events/actions/info
> > (although we could fix that)
> > 4) Afaik, there is no specific remote push/streaming mechanism for it
> > defined (there was an attempt at it, but not final)
> >
> > -hadriel
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] On
> > Behalf
> > > Of Vijay K. Gurbani
> > > Sent: Wednesday, March 25, 2009 10:58 PM
> > >
> > > Adam Roach wrote:
> > > > In the spirit of "send text," I've put together a straw-man proposal
> > for
> > > > an easy-to-generate and fast-to-process extensible format for saving
> > SIP
> > > > log messages:
> > > >
> > > > http://www.ietf.org/internet-drafts/draft-roach-sipping-clf-syntax-
> > > 00.txt
> > > [...]
> > >
> > > Adam: Essentially you are advocating for a table-of-content
> > > type of approach where you read the ToC and index straight
> > > to where you want to go.  I have worked on SIP parsers
> > > designed this way.
> > >
> > > The parsing is optimized, yes, when compared to the ASCII
> > > version -- though perl can do wonders, but not to outperform
> > > binary parsing.  The disadvantage is that you loose readability
> > > and would need specialized tools to, say, grep through such
> > > a file.
> > >
> > > It will be interesting to see what others think...
> > >
> > > Thanks,
> > >
> > > - vijay
> > > --
> > > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> > > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> > > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
> > > Web:   http://ect.bell-labs.com/who/vkg/
> > > _______________________________________________
> > > Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP
> > > Use [e-mail] for questions on current sip
> > > Use [e-mail] for new developments of core SIP
> > _______________________________________________
> > Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use [e-mail] for questions on current sip
> > Use [e-mail] for new developments of core SIP