Subject: [Sipping] spam score

From: "David Schwartz" <[email-masked]>
Date: Tue, 20 Nov 2007 15:56:35 +0200

Hi Dan

I like this draft I think however that the Via is not the correct header for this.

I recently submitted a draft titled "Domain Marking" (http://www.ietf.org/internet-drafts/draft-schwartz-sipping-domain-marking-requirements-00.txt) which discusses the need for a header that can keep track of the various administrative domains travered by a message. The purpose of the header I proposed is to pass an ONE identifier per domain giving the downstream element enough information to run its own traffic analysis among others for SPIT detection.

The reason the Via is wrong for what you are proposing is both due to the fact that no SBC will let it through as well as the fact that SPIT is a domain characteristic and NOT a Proxy one. I may have multiple elements in my network and clearly there is no need to address SPIT issues at each of these. One per domain (as I propose in my draft) should suffice. My draft addresses the SBC issue as well since the information I propose passing downstream is NOT IP based and from speaking to various SBC vendors I have gotten the impression that as long as the upstream real identity is preserved they have no problems passing this information through.

Cheers,

David

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

---

From: "Saverio Niccolini" <[email-masked]>
Date: Tue, 20 Nov 2007 19:07:11 +0100

Dear David,

I can understand your concerns, it is questionable if the VIA
header is the best place to put such info about SPIT, anyway
we have chosen VIA since they need to be looked up in detail
anyway and then the infos are already there associated with
the elemet that scored them. I do believe that SPIT scoring is
not a domain issue but a proxy/server issue.

Anyway you may agree with me that there is not so much difference:
in the end they are just additional info and they need to go somewhere...
If it is VIA or another header we will discuss and we do not need
two different drafts for this discussion, everything can be captured
by one document 

Coming back to what I do not agree:
it is not true that you need only one marking per domain, SPIT
is indeed not only a domain characteristic. There may be different
entities that are checking the message and each of them may have
different methods:
-- the entry proxy can check for call rates or verify the origin
-- an application server can challenge the caller with a CAPTCHA
-- other elements in the domain can check for more advanced signatures

thus I do not agree that one marking per domain will do the job.

Hope we will have more discussion in Vancouver about this, we got
agenda time for presenting the draft :-)

Cheers,
Saverio

============================================================
Dr. Saverio Niccolini
Senior Researcher
NEC Laboratories Europe, Network Research Division	
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.     +49 (0)6221 4342-118
Fax:     +49 (0)6221 4342-155
e-mail:  [email-masked] <-- !!! NEW ADDRESS !!!
============================================================
NEC Europe Limited Registered Office: NEC House, 1 Victoria
Road, London W3 6BL Registered in England 2832014

> -----Original Message-----
> From: David Schwartz [mailto:[email-masked]] 
> Sent: Tuesday, November 20, 2007 2:57 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [Sipping] spam score
> 
> 
> Hi Dan
> 
> I recently submitted a draft titled "Domain Marking" 
> (http://www.ietf.org/internet-drafts/draft-schwartz-sipping-do
main-marking-requirements-00.txt) which discusses the need for a > header that can keep track of the various administrative 
> domains travered by a message. The purpose of the header I 
> proposed is to pass an ONE identifier per domain giving the 
> downstream element enough information to run its own traffic 
> analysis among others for SPIT detection.
> 
> The reason the Via is wrong for what you are proposing is 
> both due to the fact that no SBC will let it through as well 
> as the fact that SPIT is a domain characteristic and NOT a 
> Proxy one. I may have multiple elements in my network and 
> clearly there is no need to address SPIT issues at each of 
> these. One per domain (as I propose in my draft) should 
> suffice. My draft addresses the SBC issue as well since the 
> information I propose passing downstream is NOT IP based and 
> from speaking to various SBC vendors I have gotten the 
> impression that as long as the upstream real identity is 
> preserved they have no problems passing this information through.
> 
> Cheers,
> 
> David
> 
> 
> 
> 
> 
> 
> 
> 
>

---

From: "David Schwartz" <[email-masked]>
Date: Tue, 20 Nov 2007 20:31:29 +0200

Hi Saverio

First a clarification.

The draft I wrote has nothing to do with SPIT scoring so it is not redundant. The draft I submitted deals with the fact that downstream elements need a way to characterize the upstream traffic and today (a) the vias do not arrive due to SBCs and (b) are not appropriate as the IP information they convey cannot be directly correlated to domain administration.

Now for where we disagree.

My comment was that I believe that vis-a-vis downstream elements the SPAM markings coming from upstream elements have context only as far as which domain they belong to and not which proxy they traversed. How you "mine" this data on a call (entry proxy, app server, etc.) within an administrative domain is completely irrelevant to me downstream and hence my comment that the most approproate place for these tags for inter-domain traversal is the header I am suggesting.

Looking forward to seeing you in Vancouver.

D. 

-----Original Message-----
From: Saverio Niccolini [mailto:[email-masked]]
Sent: Tue 11/20/2007 8:07 PM
To: David Schwartz; [email-masked]
Cc: [email-masked]; [email-masked]; Martin Stiemerling
Subject: RE: [Sipping] spam score
 
Dear David,

Cheers,
Saverio

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 20 Nov 2007 10:43:10 -0800

> Sent: Tuesday, November 20, 2007 10:07 AM

Good point.  

> agenda time for presenting the draft :-)

:-)

-d

> main-marking-requirements-00.txt) which discusses the need 
> for a > header that can keep track of the various administrative

---

From: "Saverio Niccolini" <[email-masked]>
Date: Tue, 20 Nov 2007 20:24:59 +0100

Hi David,

> First a clarification.
> 
> The draft I wrote has nothing to do with SPIT scoring so it 
> is not redundant. The draft I submitted deals with the fact 
> that downstream elements need a way to characterize the 
> upstream traffic and today (a) the vias do not arrive due to 
> SBCs and (b) are not appropriate as the IP information they 
> convey cannot be directly correlated to domain administration.

OK, actually reading your draft I saw you are citing SPIT as one
example why this marking would be important. This is why I thought
this was one of your main application scenario. Bu t if you talk about
characterization in general then I understand the two drafts are not
redundant.

> My comment was that I believe that vis-a-vis downstream 
> elements the SPAM markings coming from upstream elements have 
> context only as far as which domain they belong to and not 
> which proxy they traversed. How you "mine" this data on a 
> call (entry proxy, app server, etc.) within an administrative 
> domain is completely irrelevant to me downstream and hence my 
> comment that the most approproate place for these tags for 
> inter-domain traversal is the header I am suggesting.

I understand, you say for inter-domain one header is enough...

Still, if you need different headers (maybe added to a VIA) within
a single domain because you have multiple boxes from different vendors
and want to allow distributed decisions in the single domain, then
maybe it does not make sense to condense everything in a separate 
header when the message exits the domain since it is just additional
work (unless you really think that this info gets stripped by border elements
and that you need to put them in another header, but then why condensing?
just moving them would be enough keeping the level of detail that the single
domain wrote in the header? and what makes you think that if border elements
strip VIA header they will not strip also the additional marking header you 
suggest?)

> Looking forward to seeing you in Vancouver.

Yes, would be nice to discuss this face to face to get to a common point
since I really think there are important requirements behind the marking
of messages...

Cheers,
Saverio

> the elemet that scored them. I do believe that SPIT scoring 
> is not a domain issue but a proxy/server issue.
> 
> If it is VIA or another header we will discuss and we do not 
> need two different drafts for this discussion, everything can 
> be captured by one document
> 
> it is not true that you need only one marking per domain, 
> SPIT is indeed not only a domain characteristic. There may be 
> different entities that are checking the message and each of 
> them may have different methods:
> Hope we will have more discussion in Vancouver about this, we 
> got agenda time for presenting the draft :-)
> 
> Cheers,
> Saverio
> 
> proposed is 
> > to pass an ONE identifier per domain giving the downstream element 
> > enough information to run its own traffic analysis among others for 
> > SPIT detection.
> >
> both due to 
> > the fact that no SBC will let it through as well as the 
> fact that SPIT 
> > is a domain characteristic and NOT a Proxy one. I may have multiple 
> > elements in my network and clearly there is no need to address SPIT 
> > issues at each of these. One per domain (as I propose in my draft) 
> > should suffice. My draft addresses the SBC issue as well since the 
> > information I propose passing downstream is NOT IP based and from 
> > speaking to various SBC vendors I have gotten the 
> impression that as 
> > long as the upstream real identity is preserved they have 
> no problems 
> > passing this information through.
> >
> > Cheers,
> >
> > David
> >
> >
> >
> >
> >
> >
> >
> >
> >
> 
> 
> 
>

---

From: "Saverio Niccolini" <[email-masked]>
Date: Wed, 21 Nov 2007 20:49:28 +0100

Dear all,

there has been quite a number of messages sent off list on this topic,
we agreed to bring them to the list for making people aware of what the 
discussion was about. 

The biggest summary and agreement seems to be that, in the end, people
(I am among those) is ok if the spam-score is in the VIA or somewhere
else, but it must be somewhere to have product specifications (since people
is starting bulding these products...).
Still David is arguing his domain-level solution is better than the node-level
one that we have in the draft, there is still space for discussing this I would
say :-)

Here it is the summary (sorry for the very long email...), I am sorry
if I am reporting something misleading by extracting the conversation
from multiple emails:

-- Thread 1:
Text written by Saverio Niccolini:
"Still, if you need different headers (maybe added to a VIA) within
a single domain because you have multiple boxes from different vendors
and want to allow distributed decisions in the single domain, then
maybe it does not make sense to condense everything in a separate
header when the message exits the domain since it is just additional
work"

Comment of Hadriel Kaplan:
"One thing I don't understand is what good does the extra info do you? 
I mean if I'm a spam filtering system, which values would I believe,
and what would I do with two or more values from two proxies I believed?
Isn't it always the case you'd take the worst-case of the ones you believed,
and you believe them starting from the closest proxy? (as the spam score draft
suggests)  In which case why not just have one value set, and each hop that
performs scoring sets the value based on the received value as input to its
local algorithm, where the local algorithm may even be "ignore the received
value" or "copy the received value"."

Answer of Dan Wing:
"You believe the values from the entities that you trust"
"With two or more values from two proxies you trust you could use the last one
(the one closest to you), use the average, or whatever."
"[[ Possibly-useless information about how I do some email spam controls, but
here it is anyway:
For myself, with email spam, Cisco IT has a corporate spam filter (from IronPort,
which we bought about a year ago).  They score messages, and some of it that is
borderline spam they allow through.  I also run SpamAssassin myself (on my own laptop).
I consider IronPort's scoring when I build my SpamAssassin score (that is, if IronPort
marked it as "might be spam", I adjust my scoring to add a few spam points to the
message just because IronPort scored it.  I also apply my own whitelists, blacklists,
Bayesian filtering, and other magic.  That eventually results in a final score which
is used to route my message (inbox or spam). 
I could imagine doing something similar with SIP.
]]"
"My upstream proxy might not honor the spam-score from whoever sent the message in.
However, _I_ might want to honor it.
For example, I have a relationship with Acme, Nortel, and with Siemens (for the same reason). 
However, Cisco IT has no relationship with those companies, and has no reason to trust
spam scores attesting "this is a real subscriber in my network and not a spammer". 
I do have reason to trust that assertion from Acme/Nortel/Siemens, though.
You could imagine that Cisco's payroll department might trust spamminess assertions from
ADT (the company that we, and most of America, outsources paychecks to).  However, Cisco
engineering doesn't care at all that ADT thinks their messages are, or are not, spam. 
Cisco IT might not be in a position to care about arbitrating those two different user
communities within the company ---- just like, today, with email, Cisco IT doesn't know/care
about Dan Wing's interactions with Acme/Nortel/Siemens.
If that isn't sufficiently motivating (and perhaps it is
not sufficiently motivating), let me finish this by saying
I'm not too tied into scoring in Via: -- it was my idea,
and I still think it's the best place to put scoring, but
if we create a single "Spam-Score:" header which gets
over-written by each domain, or if we allow multiple
"Spam-Score:" headers to exist, I'm fine.
I just want to standardize something that works for
everyone so we can get this spec'd into some product."

Comment of David Schwartz:
"DS: My point is not whether there should be more than one source - only that if there
is it should be a associated with domains not proxies. Why on earth would I trust the
border proxy at a particular domain but not the app server that comes right after it.
My contention all along was that the info is valuable but it should be in a domain based
header (like the one I am proposing) and not in a hop by hop (possibly many within a domain)
one like Via."
"DS; Multiple is fine - I agree with your reasoning above. Why just limit to SPIT and
not just combine with a header whose sole purpose is to define an upstream AD where one of
the markings is SPIT? (Am I sounding like a broken record?)"
"DS: Could not agree more so lets pick a non controversial and non overloaded header :)"
--> DS was referring to the fact that everybody wants to have this standardized in some way :-)

Answer from Dan wing:
"Here is a case:  imagine you are the IT manager at a company, example.com.  You want to test
some fancy new SPIT-protection system from some startup.  You install it.  You also have your
old SPIT-protection system that came built into your IP PBX, and a SPIT-protection system
that came built into your VoIP-aware firewall.
It seems useful to be able to see how each system scores each incoming call, in order to decide
the false-positive and false-negative rate associated with each of those three products.
Can we do that if there is only one header allowed for "example.com" ?  Would we be able to
do it by (essentially) mis-configuring each box to have a different domain name
(spit-1.example.com, spit-2.example.com, spit-3.example.com)?"
"I am quite willing to give up on Via: being the best place for this.  However, I'm not quite
convinced -- at the time I am writing this -- that a domain-level 'spam result'
is necessarily the right place, either."

-- Thread 2:
Text written by Saverio Niccolini:
"and what makes you think that if border elements
strip VIA header they will not strip also the additional marking header
you suggest?)"

Comment of Hadriel Kaplan:
"Because he's writing the requirements such that the information being passed is
not domain sensitive, to avoid any need to hide them.  The truth is Via's don't
make it across a lot of devices in the "core", not just SBCs at the border. 
B2BUA's are rampant.
Also, I think Via is not appropriate because it's so far been a fairly low-level
header in SIP, in terms ofwhat it's used for.  Whereas this spam thing is a fairly
high-logic-level decision. (right?)."

Answer of Dan Wing:
"I doubt any other new header, like Spam-Score, would have
a better survival rate through B2BUAs or SBCs.

But I'm equally happy with:

  Spam-Score:  23.0; danwing.cisco.com

or:

  Spam-Score:  23.0; danwing.cisco.com
  Spam-Score:  5.3; outgoing-proxy.cisco.com
  Spam-Score:  17.3; att.net"

Comment of David Schwartz:
"DS: I completely disagree and hence my stubborn insistence on my  
Domain header. One of my prime motivators for the header was SPAM and  
therefore I purposely omitted (over the protesting of my co-author)  
any reference to identifying information such as IP. This is the  
achilles heal of the Via. This is not a debate whether or not SBCs  
should exist but how do we make something work in a world where they  
do and will continue to exist. Does it really matter to me WHO is  
spamming me or is it enough for me to know that the message IS SPAM?  
I contend that while it would be nice to have tags like "originating- 
ip=212.23.34.5" if having this info means the message gets stripped  
than what have I gained. I therefore kept it obscure enough to pass  
through SBCs yet informative enough to be able to distinguish one  
originating path from another for many things INCLUDING SPIT."

-- Thread 3
Two more comments from David Schwartz:
"DS: Two more comments.

a. Regardless of what header is chosen, can i suggest since there is  
always going to be additional info that we should have a spam report  
which is a (multiline) text field containing additional info. This  
quite common in SPAM blocker information in the email header.

b. Regarding your draft I would already add a few (3-10) reserved  
fields such as "spam1, spam2, spam3.. spam10" so that parsers already  
parse them allowing for some limited future proofing."

Answer from Dan Wing:
"point a. is clear and agreed, point b. is unclear"

Hope you enjoyed :-)

Saverio

> Sent: Tuesday, November 20, 2007 8:25 PM
> Cc: Martin Stiemerling; [email-masked]; 
> [email-masked]
> > The draft I wrote has nothing to do with SPIT scoring so it is not 
> > redundant. The draft I submitted deals with the fact that 
> downstream 
> > elements need a way to characterize the upstream traffic 
> and today (a) 
> > the vias do not arrive due to SBCs and (b) are not 
> appropriate as the 
> > IP information they convey cannot be directly correlated to domain 
> > administration.
> 
> OK, actually reading your draft I saw you are citing SPIT as 
> one example why this marking would be important. This is why 
> I thought this was one of your main application scenario. Bu 
> t if you talk about characterization in general then I 
> understand the two drafts are not redundant.
> 
> elements the 
> > SPAM markings coming from upstream elements have context 
> only as far 
> > as which domain they belong to and not which proxy they 
> traversed. How 
> > you "mine" this data on a call (entry proxy, app server, 
> etc.) within 
> > an administrative domain is completely irrelevant to me 
> downstream and 
> > hence my comment that the most approproate place for these tags for 
> Still, if you need different headers (maybe added to a VIA) 
> within a single domain because you have multiple boxes from 
> different vendors and want to allow distributed decisions in 
> the single domain, then maybe it does not make sense to 
> condense everything in a separate header when the message 
> exits the domain since it is just additional work (unless you 
> really think that this info gets stripped by border elements 
> just moving them would be enough keeping the level of detail 
> that the single domain wrote in the header? and what makes 
> you think that if border elements strip VIA header they will 
> not strip also the additional marking header you
> suggest?)
> 
> Yes, would be nice to discuss this face to face to get to a 
> common point since I really think there are important 
> requirements behind the marking of messages...
> 
> Cheers,
> Saverio
> 
> > 
> > D.
> > 
> > I can understand your concerns, it is questionable if the 
> VIA header 
> > is the best place to put such info about SPIT, anyway we 
> have chosen 
> > VIA since they need to be looked up in detail anyway and then the 
> > infos are already there associated with the elemet that 
> scored them. I 
> > do believe that SPIT scoring is not a domain issue but a 
> proxy/server 
> > issue.
> > 
> > If it is VIA or another header we will discuss and we do 
> not need two 
> > different drafts for this discussion, everything can be captured by 
> > one document
> > 
> > it is not true that you need only one marking per domain, SPIT is 
> > indeed not only a domain characteristic. There may be different 
> > NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, 
> > London W3 6BL Registered in England 2832014
> > 
> >  
> > 
> > main-marking-requirements-00.txt) which discusses the need for a > 
> > header that can keep track of the various administrative
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 21 Nov 2007 13:59:33 -0600

For what it's worth, I also believe that a New "SPAM-Score" header makes more sense
then a Via.

I like the

  Spam-Score:  23.0; danwing.cisco.com
  Spam-Score:  5.3; cisco.com
  Spam-Score:  17.3; att.net

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 29 Nov 2007 10:53:00 -0800

I added 'sign the spam score' to the slides so we will be sure to talk about
it next week.  

However, a simple signature like that isn't too effective if a spammer can
capture a low spam score (which is signed) and insert that signed header into
their Invite.

(A minor point:  this is one of the reasons I like Via -- it is interfered
with on purpose to your immediate business relationship (you will only see the
Via: inserted by your ITSP's SBC) and you wouldn't trust or believe spam
scores that are farther away than your immediate business relationships,
anyway, even if they were present.

I say this is minor because I am not passionate about which header we use, or
if we create a new header.  Rather, I want something that spam-detection
systems can start labeling so that anti-SPIT techniques and solutions can
begin to blossom.)

-d

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Bernie Hoeneisen
> Sent: Thursday, November 22, 2007 12:35 PM
> To: Signaling TO Prevent SPIT
> Cc: [email-masked]
> Subject: Re: [spitstop] SPAM Score: Header or Vias
> 
> Hi Saverio, Francois et al.
> 
> I also believe, that Via is the wrong choice for such 
> information. The 
> Via header field is simply not robust enough; too many systems are 
> tampering with Via.
> 
> Furthermore I believe it makes sense to add two more 
> (optional) parameters 
> besides the (mandatory) score and the domain/realm: a cryptographical 
> signature over the score and some salt. This way the issuer 
> of the score 
> can offer authenticity of the score provided.
> 
> The header could look like this:
> 
> Spam-Score: 73.3; realm=example.org; salt="lu987ehrj67634hd";
>     signature="34879hfdsdf543tt345fg54gf435b44n3n2ggb2c"
> 
> I suggest to add such a feature to the requirements (if not 
> yet there).
> 
> cheers,
>   Bernie
> 
> 
> On Wed, 21 Nov 2007, Francois Audet wrote:
> 
> spitstop mailing list
> [email-masked]
> https://listserv.netlab.nec.de/mailman/listinfo/spitstop
>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 29 Nov 2007 19:36:54 -0800

I may have missed it but I have not seen an argument why you would  
want to stuff the Spam stuff in the via header. Unless there is a  
good reason, it probably better not to mix up the semantics of Via  
with very different semantics.

Cullen <with my individual contributor hat on>

On Nov 22, 2007, at 12:35 PM, Bernie Hoeneisen wrote:

> I also believe, that Via is the wrong choice for such information. The
> Furthermore I believe it makes sense to add two more (optional)  
> parameters
> signature over the score and some salt. This way the issuer of the  
> score
> I suggest to add such a feature to the requirements (if not yet  
> there).
>
> cheers,
>   Bernie
>
>