[Sipping] Re: [VOIPSEC] VoIP Spam paper

["vijay arvind" <[e-mail]>]

Hello Hannes,
Thanks for introducing the paper to the larger community. Was away for
thanksgiving so could not respond earlier. I have a few
additions/corrections to what has been mentioned in your mail:

1) The contents of the call credential:
The call credential contains the following information, in addition, to
provide sender authentication and remove the possibility of credential
misuse:
Identity of Caller, Public Key of Caller, Identity of Call Recipient, Public
Key of Call Recipient, Call Duration, Timestamp, {all the previous info
encrypted with the callers private key}.
This ensures multiple things
a) If Alice and Bob know each other (and have each others public keys as
described in work
http://www-static.cc.gatech.edu/~vijayab/locating_SIP_users.pdf), then when
Charlie calls with a credential from Bob, Alice can actually ensure the
credential is from Bob.

2) Deployment:
Quoting Hannes: "Although not stated explicitly, I assume that information
about a users
call patters are stored with its VoIP provider."
This is not how the paper extracts information about a user. Consider user
Alice who uses say Vonage's VOIP service and thus all calls to and from
Alice pass through Vonage's proxy server. Now lets say user Dave wants to
call Alice and is using some VoIP provider X. Then Dave's reputation (if he
doesnt have an SN credential) is assigned by the Vonage proxy and built on
all the interactions (call history) that Vonages' customers have had with
him. So the reputation for an incoming call is assigned by the proxy of the
call recipient (that is Alice's Vonage proxy). So Vonage will thus have a
reputation matrix of all users of Vonage and all users that Vonage users
have interacted with and then assign reputations (based on
Eigentrust(pagerank)) to them. Daves proxy X has no say in this matter.
Therefore if a particular VoIP provider provides this reputation calculating
mechanism, users of that VoIP provider can utilize it and we expect the
deployment to work that way.

3) Privacy aspects:
The paper as it stands now has privacy issues with regards to its credential
sharing mechanism. We have come up with a way to address that and that will
be available along with an actual implementation of CallRank that we are
building on MjSip as a client and OpenSER as the proxy server.

4) Future work:
In addition to what is already mentioned we realize that for each proxy to
calculate the reputation matrix for a large number of users we need far more
intelligent, efficient ways of calcualting the reputation matrix. We find
that there are ways in which we can organize the matrix to come up with
efficient and accurate reputation calculations. All this and more are part
of the next paper that we are working on.

I hope I have clarified certain things that we could not provide in all
detail in the paper due to space constraints.

Bye,
Vijay

On Nov 25, 2007 5:32 AM, Hannes Tschofenig <[e-mail]>
wrote:

> Hi  all
>
> BACKGROUND
>
> In the IETF SIPPING WG we had discussions regarding SPIT prevention
> mechanism. Particularly with regard to the SPIT marking techniques it
> seems that there is some disagreement about the usefulness of
> statistical techniques. A number of ideas have been discussed already on
> various IETF mailing lists.
> I would like to bring another paper to your attention that has been
> posted to the VOIPSEC mailing list.
>
> THE PAPER
>
> The paper says that it exploit the fact that in regular communication
> users both make and receive calls, while spammers are interested in only
> making calls and disseminating information. This paper takes existing
> work from the email environment and applies it to VoIP (as it seems).
>
> The basic idea is to observe communication and call duration in
> particular. Thereby, the call duration is used to create, so-called call
> credentials. A call credential CC consists of A, the identity of the
> caller, B, the identity of the call recipient, t, the call duration and
> TS, the time stamp of the call along with a digital signature of the
> same information.
>
> Although not stated explicitly, I assume that information about a users
> call patters are stored with its VoIP provider. Then, when a user makes
> a call information about the call patters (i.e., in the form of call
> credentials) are made available to the receiving domain or other end
> point. Sharing information about the sender with the recipient's domain
> or the recipient itself has been described in
> http://tools.ietf.org/id/draft-schwartz-sipping-spit-saml-01.txt
> (although no reference to that document is included in the paper). This
> work on utilizing social networks, as described in
> http://tools.ietf.org/id/draft-ono-trust-path-discovery-02.txt, might
> also be applicable.
>
> To deal with the introduction problem turing tests are suggested.
>
> Working on draft-schwartz-sipping-spit-saml-01.txt we encountered
> problems, such as
>
> * Deployment challenge to get SPIT SAML to deploy. Without it being
> widely deployed the receiving domain does not have a way to know
> anything about the call statistics. Hence, the mechanism would only work
> within a single domain. Without sufficient deployment the mechanisms
> described in the paper wouldn't be so useful either. As such, this
> deployment challenge has nothing todo with SAML but is rather a generic
> problem with the solution approach outlined in the paper (although the
> authors claim it differently in Section 2.4 "Related Work").
>
> * Privacy aspects: It is not clear whether it is actually possible to
> distribute some of this information from one domain to another one
> without violating some privacy laws.
>
> * Trusting the information provided by the sending domain is likely to
> work only for larger VoIP providers. In the worst case the Spammer might
> provide this information since he is acting as a VoIP provider.
>
> The idea of using call patterns for SPIT prevention is not new. Still,
> the provided details for using the call duration (using the Eigentrust
> algorithm) in a SPIT prevention scenario are nice. Maybe this paper
> provides a different spin to our SPIT marking discussion.
>
> Ciao
> Hannes
>
> PS: http://tools.ietf.org/id/draft-schwartz-sipping-spit-saml-01.txt did
> not describe which algorithms to use to compute some of the parameters.
> I believe that this is fine for an IETF document given that there are a
> lot of implementation specific aspects that are not relevant for
> standardization.
>
>
> -----Ursprüngliche Nachricht-----
> Von: [e-mail] [mailto:[e-mail]] Im
> Auftrag von ext vijay arvind
> Gesendet: Montag, 12. November 2007 00:34
> An: [e-mail]
> Betreff: [VOIPSEC] VoIP Spam paper
>
> Hello All,
>
> Attached is a link to a VoIP spam approach that we at the Georgia Tech
> Information Security center (GTISC) are working on and was presented at
> the
> 4th conference of Email and Anti Spam:
> http://www.ceas.cc/2007/papers/paper-63.pdf
>
> The basic idea is to try and exploit the fact that in regular
> communication
> users both make and receive calls, while spammers are interested in only
> making calls and disseminating information. Users rarely call a spammer
> and
> even if they inadvertently do so, the call will last for a small duration.
> Hence we use call duration and the directionality of calling patterns to
> distinguish between a regular user and a spammer. We use basic
> cryptographic
> primitives to encapsulate call duration as call credentials. How we
> combine
> these call credentials using social networking theory and the Eigentrust
> algorithm (PageRank) to create a spammer detecting mechanism forms the
> crux
> of the paper.
>
> Bouquets and Brickbats are most welcome.
>
> Thanks,
> Vijay
> _______________________________________________
> Voipsec mailing list
> [e-mail]
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>
>

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP