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

[Hadriel Kaplan <[e-mail]>]

> -----Original Message-----
> From: Vijay K. Gurbani [mailto:[e-mail]]
> 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.

-hadriel