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

"Vijay K. Gurbani" <vkg@alcatel-lucent.com> Fri, 24 July 2009 21:32 UTC

Return-Path: <vkg@alcatel-lucent.com>
X-Original-To: sip-clf@core3.amsl.com
Delivered-To: sip-clf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C75828C18A for <sip-clf@core3.amsl.com>; Fri, 24 Jul 2009 14:32:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.556
X-Spam-Level:
X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8f6VYvJJSufv for <sip-clf@core3.amsl.com>; Fri, 24 Jul 2009 14:32:16 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 2C61A28C0EE for <sip-clf@ietf.org>; Fri, 24 Jul 2009 14:32:15 -0700 (PDT)
Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail4.lucent.com (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 [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n6OLWCLv015762; Fri, 24 Jul 2009 16:32:13 -0500 (CDT)
Message-ID: <4A6A285C.6050007@alcatel-lucent.com>
Date: Fri, 24 Jul 2009 16:32:12 -0500
From: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Hadriel Kaplan <HKaplan@acmepacket.com>
References: <4A69DFBB.3010307@alcatel-lucent.com> <E6C2E8958BA59A4FB960963D475F7AC31984654C6C@mail> <4A6A1A29.9010504@alcatel-lucent.com> <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 135.245.2.39
Cc: "sip-clf@ietf.org" <sip-clf@ietf.org>
Subject: Re: [sip-clf] SIP-CLF slides for opsarea and possibly ipfix
X-BeenThere: sip-clf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Common Log File format discussion list <sip-clf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip-clf>, <mailto:sip-clf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-clf>
List-Post: <mailto:sip-clf@ietf.org>
List-Help: <mailto:sip-clf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-clf>, <mailto:sip-clf-request@ietf.org?subject=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
requests.

> 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.

Sure.

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/