Re: [sip-clf] anomaly detectors

[Vijay Gurbani <[e-mail]>]

Hadriel Kaplan wrote:
> 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.).

Do SBCs use learning algorithms to do such anomaly detection
or do policy based triggers form the foundation of such detection?
I suspect it is the latter.

Can existing SBC-based anomaly detection system be trained on
the infamous SIP PRACK state machine to detect anomalous behavior?
I suspect not -- though I may be wrong.  I am aware of some
preliminary work on training machines to recognize the temporal
association of SIP messages in a dialog (i.e., BYE is preceded by
an INVITE); but so far this work is just starting and the more
complex cases like it is okay to send an UPDATE and CANCEL
before an INVITE finishes, but one must not send a SUBSCRIBE
in similar scenarios are not supported.  For an SBC to do such
analysis, an awful lot of dialog state would be needed; OTOH,
doing such detection at the individual SIP actor level (i.e.,
a proxy receiving such requests from UAs and producing a CLF
record for analysis) may be more manageable.

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

I suspect that what we have been discussing in the mailing list, i.e.,
having a base set of headers and an extensibility model to account
for other headers is generally a good thing.  Reverting to logging
the whole SIP message seems to be throwing our hands up in the air
and saying that we don't really know what we want so we'll save the
whole kitchen sink just in case.  HTTP CLF has worked without
saving the whole message, and with some judicious thought I think
we can make SIP CLF work as well.

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

Possibly; however, for training and subsequent use of an anomaly
system, you would need the headers which you care about (i.e., if
two colluding UAs leak information by subscribing to event package
X but sending notifications for event package Y, I'd want to log
the appropriate headers that I care about.)

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}
WWW:   http://ect.bell-labs.com/who/vkg