Subject: [Rucus] comments on draft-york-sipping-spit-similarity-scenarios-00

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 25 Feb 2008 22:02:24 -0500

Thanks for writing this up, Dan.

Couple of comments. In many of the use cases you describe there is 
probably some aspect of the system that allows these cases to be 
differentiated from SPIT. For example, for emergency traffic, the fact 
that the requests originated from the emergency notification server 
tells its downstream proxy that this is not an attack. Similarly, the 
domain that runs the emergency notification service would probably tell 
its downstream service provider that this can happen, and they can agree 
upon ways to separate this traffic out. This doesn't work in all cases 
but in some.

Also, using rfc4474 for these kinds of sources can help; since the set 
of such sources is small you can use whitelisting in downstream proxies 
to deal with it.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Rucus mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/rucus

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 26 Feb 2008 10:10:46 +0200

Hi Jonathan,

I think it is not that easy for 2 reasons:

First, we don't know yet how an IP-based early warning architecture 
would look like.

Second, your approach only works if you consider a deployment similar to 
the telephone network today. It does not work in an IP-based network 
with roaming users where every emergency services operator would have to 
establish a relationship with every other VoIP provider....

I do, however, agree that these special cases need to be dealt with even 
with mechanisms like white lists somehow. They are not only relevant for 
mechanisms that use some of these "statistical learning techniques".

Ciao
Hannes

---

From: Dan York <[email-masked]>
Date: Tue, 26 Feb 2008 14:37:24 -0500

Jonathan,

Thanks for the comments.  Yes, notification systems have some  
characteristics that *should* enable downstream providers to be able  
to differentiate the traffic to a certain degree.  However, as you  
note it *does* involve coordination with the downstream service  
provider.  In many scenarios this may be possible.   In others it may  
not.  If you had a university of, say, 10,000 students and there was  
some notification, the outbound SIP messages might go to such places as:
    1. SIP proxies and endpoints on campus under the control of  
university IT/telcom;
    2. SIP proxies and endpoints on campus under the control of  
individual labs and departments;
    3. SIP trunks to service providers providing connections to other  
SIP systems;
    4. SIP trunks to service providers providing PSTN connectivity;
    5. SIP -> PSTN gateways;
    6. SIP gateways into mobile provider networks.
And the list could go on in other environments, especially if the  
notification system uses SIP for not just phone notifications but  
also SMS or IM.

In some of those cases you could have arrangements with the service  
providers so that they would know what to do if they received traffic  
from a particular server.  In some of the other cases, it might be  
difficult.  For instance, #2.  My own experience with universities is  
that many times the labs and departments are all little fiefdoms that  
do things "their own way" and may not at all follow the lead of  
university IT.

I agree with you that SIP identity (RFC 4474 and proposed extensions)  
would go far to assist in this differentiation.

Regards,
Dan

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Bring your web applications to the phone.
Find out how at http://evolution.voxeo.com