Re: [sip-clf] draft CLF charter

["David Harrington" <[e-mail]>]

Hi,

My concern is that I am not quite sure what we are trying to log, or
why.

If we are trying to log events that occur, then syslog might be a
reasonable choice for a logging protocol.
If we are trying to log the series of IP flows that make up a SIP
transaction, then ipfix might be a reasonable choice for a logging
protocol.
Somebody suggested using libpcap format, which would indicate that we
are trying to capture the packets that make up a transaction, for
later off-line analysis. If so, then libpcap might be a reasonable
logging protocol.
If we want to use an IETF standard protocol for packet captures, or if
we do not need to capture every packet, but just sample the flows
enough to be able to track the transaction, then PSAMP might be a
reasonable logging protocol.

If there are multiple purposes we are trying to meet, then it might be
best to address each purpose separately. There may be existing
standards that would meet the separate requirements very well, but no
standard that can meet the combination of purposes because the
requirements are so varied and potentially in conflict.

I am not promoting any particular solution. I would like to make sure
we discuss the targeted purposes and the subsequent requirements, so
we can best assess whether any of the existing IETF standards or
industry defacto standards meet those requirments.

I am a bit concerned that the charter seems to have a goal of defining
a data model, without knowing what the corresponding transport
protocol will be (if transporting the data is not a requirement, why
should the IETF standardize it?). The format that the data can take is
often inter-dependent with the protocol to be used to transport it.
For example, we have existing pairings - SMIv2 MIBs and SNMP, IEs and
IPFIX, XML and Netconf, SDEs and syslog. I am not sure it makes sense
to define a common log format without knowing which protocols will be
used when it is being transported.

It is possible we could define an information model rather than a data
model, but the plan to define a specific vendor-neutral format says we
are working on a data model. See RFC 3444 for a discussion of the
difference between information model and data model.

Part of my concern about the data and the transport protocol is driven
by my OPS-DIR role; part of it is driven by my SEC-DIR role. How
sensitive will this information be? Will this potentially be used as
evidence in legal proceedings? How much information will there be?

If it used for intrusion detection purposes or as evidence, does the
data-in-flight need to have integrity protection? Will this data be
used as a legal audit log? i.e., does the data-at-rest need to have
integrity protection?  SIP transactions might include information that
should be subject to privacy protection - protection against revealing
personal information, and that means confidentiality and integrity
must be preserved for data-in-flight as well as data-at-rest. 

The charter talks about meeting efficiency requirements for client and
server. What about resource requirements? How much information do we
expect might be generated? What happens if the buffer fills? Do we
discard old data? That could enable an attacker to force a buffer
overflow to hide their tracks. Large buffers of information could
cause problems in storage-or-CPU-constrained enviornments; IPFIX is
designed to off-load information quickly to reduce local resource
requirements. 

Without understanding how this data is expected to be used, we do not
know the requirements that must be met for operations, management, and
security while at rest and while in transit to support the use cases.

I think the applicability of the data to be collected really needs to
be nailed down much better than this charter proposal does. I think
the operations, management, and security requirements need to be
nailed down better. Then we can realistically talk about what the
field formats should be.

David Harrington
[e-mail]
[e-mail]
[e-mail]


> -----Original Message-----
> From: Spencer Dawkins [mailto:[e-mail]] 
> Sent: Wednesday, July 22, 2009 11:05 AM
> To: SIP-CLF Mailing List
> Cc: David Harrington
> Subject: Re: [sip-clf] draft CLF charter
> 
> Just to stay on the same page :D
> 
> I had a short chat with Dave Harrington Monday, and he asked "why
not 
> IPFIX?" - has anyone looked at IPFIX yet?
> 
> I know Glen Zorn's question in February was "why not SYSLOG?" 
> - the answer 
> then, from Eric Burger, was (paraphrasing) "SYSLOG's the 
> envelope, CLF might 
> use SYSLOG but needs to define what goes in the envelope".
> 
> The answer may be the same for IPFIX, and we'll probably need 
> to figure this 
> out, but if anyone has already looked at this, that would be 
> great to know.
> 
> Thanks,
> 
> Spencer
> 
> 
> > Just to make sure we are all on the same page:
> >
> > On Jul 21, 2009, at 5:25 PM, Vijay K. Gurbani wrote:
> >
> >> Romascanu, Dan (Dan) wrote:
> >>> A few comments after the first reading of the charter.
> >>
> >> Dan: Thanks for your feedback; more inline.
> >>
> >>> - Is it Common Log File as it appears at the first 
> instance, or  Common
> >>> Log Format?
> >>
> >> CLF expands to Common Log File, though colloquially you will
> >> see references to "the CLF format", which simply means the
> >> specific fields and their representation.
> >
> > This is something we need to state more clearly.
> >
> > Are we defining a file are we defining a format that might 
> go in a file?
> >
> > I think the proposals I've read so far are trying to do the
second.
> > Does anyone disagree?
> >
> > I was planning to  change the word File Dan is pointing  to in the
> > proposed charter to Format.
> >
> > RjS
> > _______________________________________________
> > sip-clf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sip-clf 
> 
>