Re: [sip-clf] SIP-CLF slides for opsarea and possibly ipfix

"Vijay K. Gurbani" <> Fri, 24 July 2009 21:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C75828C18A for <>; Fri, 24 Jul 2009 14:32:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.556
X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8f6VYvJJSufv for <>; Fri, 24 Jul 2009 14:32:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2C61A28C0EE for <>; Fri, 24 Jul 2009 14:32:15 -0700 (PDT)
Received: from ( []) by (8.13.8/IER-o) with ESMTP id n6OLWDRl014335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jul 2009 16:32:13 -0500 (CDT)
Received: from [] ( []) by (8.13.8/TPES) with ESMTP id n6OLWCLv015762; Fri, 24 Jul 2009 16:32:13 -0500 (CDT)
Message-ID: <>
Date: Fri, 24 Jul 2009 16:32:12 -0500
From: "Vijay K. Gurbani" <>
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: Hadriel Kaplan <>
References: <> <E6C2E8958BA59A4FB960963D475F7AC31984654C6C@mail> <> <E6C2E8958BA59A4FB960963D475F7AC31984654FE0@mail>
In-Reply-To: <E6C2E8958BA59A4FB960963D475F7AC31984654FE0@mail>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on
Cc: "" <>
Subject: Re: [sip-clf] SIP-CLF slides for opsarea and possibly ipfix
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Common Log File format discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Jul 2009 21:32:17 -0000

Hadriel Kaplan wrote:
> It's not so much that it's a research topic, but rather that some of
> the needs of anomaly detection literally require getting the entire
> SIP message (or at least a lot more than what we're proposing as the
> baseline header info).  Even the currently *deployed* anomaly
> detectors check more than what the current drafts are proposing to
> include in a CLF.

Currently deployed anomaly detection systems that I am aware
of perform mostly at the parsing layer to determine whether or
not a SIP message is well-formed -- hence they need the whole
SIP message.  Are you aware of any anomaly detection systems that
do semantic anomaly detection for SIP above and beyond the
parsing layer?

> Nope, I'm talking about if all SIP actors generate their own CLF's,
> and one or more central systems read and merge the CLF's generated by
> the actors.  In that case, then it's potentially important that we
> specify how/when the data in the CLF was created, so that all actors
> provide a consistent view.

OK, but this merge is an orthogonal step.  Each actor still
produces CLF from the SIP messages that it is processing, yes?

> Even for some sanity/consistency we'll probably need to define
> whether a CLF entry is generated at both receiving and sending of SIP
> messages, 

Would not that depend on the specific role being played by the
SIP actor?  A proxy will, out of necessity, generate incoming
requests, responses sent upstream, requests sent downstream,
and responses received from downstream servers -- and do all
this so that the entire SIP search tree corresponding to the
incoming request can be rapidly recreated for analysis later.
A UAC, OTOH, can simply generate a CLF that has a list of requests
that it sent out and the responses it received for those

> above vs. in vs. below a transaction layer, 

Below the transaction layer is the parser -- probably need to
generate CLF at or above the transaction layer.

> before or after Privacy anonymization, etc.



- vijay
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{,,}