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

Hadriel Kaplan <> Fri, 24 July 2009 21:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E426A3A6AF6 for <>; Fri, 24 Jul 2009 14:18:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xGHJGMQnIAGj for <>; Fri, 24 Jul 2009 14:18:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 068EF3A68BB for <>; Fri, 24 Jul 2009 14:18:01 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 24 Jul 2009 17:18:00 -0400
Received: from ([]) by mail ([]) with mapi; Fri, 24 Jul 2009 17:18:00 -0400
From: Hadriel Kaplan <>
To: "Vijay K. Gurbani" <>
Date: Fri, 24 Jul 2009 17:17:59 -0400
Thread-Topic: [sip-clf] SIP-CLF slides for opsarea and possibly ipfix
Thread-Index: AcoMnce1HsJuEZtbRdeu20NMMEfCIQAA/Ixw
Message-ID: <E6C2E8958BA59A4FB960963D475F7AC31984654FE0@mail>
References: <> <E6C2E8958BA59A4FB960963D475F7AC31984654C6C@mail> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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:18:03 -0000

> -----Original Message-----
> From: Vijay K. Gurbani []
> Sent: Friday, July 24, 2009 4:32 PM
> OK; training anomaly detection systems for semantic attacks on
> SIP through the CLF may well be classified as a research topic,
> so you are right -- I have taken these two slides out.

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.

> The other point -- "to get a common view of merged/global CLFs ..."
> may require some discussion.  Are you proposing that there be a
> central CLF server where all SIP actors in a network send their
> messages for correlation?  At least my view of the SIP CLF was
> more along the lines of each SIP actor producing their own
> CLF.

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.  

For example, if B2BUA-1 generates CLF entries for SIP messages it's sending out, but does so internally before certain manipulations such as number translations - while a second B2BUA-2 receiving the message records its CLF on reception but after its number translations, the view from a common place is not consistent. (number translations just being an example)  And we may decide it doesn't matter in the end - but it's a potential "Challenge".

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, above vs. in vs. below a transaction layer, before or after Privacy anonymization, etc.