Re: [sip-clf] anomaly detectors (was: SIP-CLF slides for opsarea and possibly ipfix)

Hadriel Kaplan <> Fri, 24 July 2009 22:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9FF893A6BA3 for <>; Fri, 24 Jul 2009 15:58:10 -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 q9hP29VVZQ2P for <>; Fri, 24 Jul 2009 15:58:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 65AD03A6812 for <>; Fri, 24 Jul 2009 15:58:09 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 24 Jul 2009 18:58:09 -0400
Received: from ([]) by mail ([]) with mapi; Fri, 24 Jul 2009 18:58:09 -0400
From: Hadriel Kaplan <>
To: "Vijay K. Gurbani" <>
Date: Fri, 24 Jul 2009 18:58:08 -0400
Thread-Topic: anomaly detectors (was: SIP-CLF slides for opsarea and possibly ipfix)
Thread-Index: AcoMpjcfbWmOM+YRRau96GylkZkNRQAADbuQ
Message-ID: <E6C2E8958BA59A4FB960963D475F7AC31984655059@mail>
References: <> <E6C2E8958BA59A4FB960963D475F7AC31984654C6C@mail> <> <E6C2E8958BA59A4FB960963D475F7AC31984654FE0@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] anomaly detectors (was: 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 22:58:10 -0000

> -----Original Message-----
> From: Vijay K. Gurbani []
> Sent: Friday, July 24, 2009 5:32 PM
> 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?

Yes, of course.  You do know I work for an SBC vendor, right? :)
SBC's do anomaly detection both at the parser layer _and_ at higher layers, and have been for years.  Some of us just don't call the higher layer things "anomaly detection" - because we market it more on the actions we take once we detect an anomaly (like reject or log or blacklist), or the benefit to the customer (like "Fraud Prevention", "Hijack prevention", "DDoS protection", "SPIT Protection", etc.).  

But anyway, there are centralized "anomaly detectors" that purport to analyze "anomalies" too - I don't know what all they mean by that, but they've asked us to provide them SIP message feeds (which right now is basically everything).  If I was them and looked at a CLF, I'd want to get quite a bit more than what we define: Via's, Route's, Record-Route's, Refer-To's, P-Asserted/P-Preferred/Remote-Party-ID, Path's, Max-Forwards, Content-Type's, History-Info, and Diversion... just off the top of my head.  

And really, as an "anomaly detector" I would want to filter which headers I *don't* care-about, not which I do.