. Should read. Comcast's "Evil Bot" Scanning Project (Lauren Weinstein)

[Dave Farber <dave () farber net>]

Begin forwarded message:

> From: Steven Bellovin <smb () cs columbia edu>
> Date: October 12, 2009 17:20:56 EDT
> To: Dave Farber <dave () farber net>
> Subject: Re: [IP] Fwd: [ NNSq Re: Comcast's "Evil Bot" Scanning  
> Project (Lauren Weinstein)

> I don't regard malware detection as inherently improper; however, I  
> do think there are several principles that Comcast (or whomever)  
> should follow.  I'm less concerned about how the notification is  
> done (which is the focus of draft-livingood-web-notification-*.txt),  
> and more interested in classification of malware and in the overall  
> process.
>
> 1)    The ISP should be forthright about what it is doing, and why.   
> Comcast seems to have fulfilled this point.
>
> 2)    The classification criteria used should not assume that  
> everyone runs Windows.  A Mac, a Linux box, a BSD box, an appliance,  
> etc., will probably have different network behavior patterns; this  
> difference should not be seen as indication of evil.
>
> 3)    The remediation process should not assume Windows, either.   
> Some sites, if they conclude your machine is infected, reconfigure  
> their DHCP server to put you on a net that has access only to  
> Microsoft patches and Windows anti-malware sites.  That won't do me  
> any good if they conclude -- rightly or wrongly -- that my machine  
> is infected, since I generally have no Windows machines in the  
> house.  (It's a mix of NetBSD, Linux, and Mac OS.)
>
> 4)    The classification should not be biased towards today's  
> applications.  We do not want the next <voip,twitter,facebook,*WEB*>  
> labeled as "evil" because today's ISPs have never seen a traffic  
> flow like that.
>
> 5)    The classification should be honest, and not favor the ISP's  
> own revenue-generating applications. Assume, for example, that the  
> ISP has its own VoIP offering, and that for some reason it looks  
> different to their classifier than, say, Vonage's or Skype's or  
> Ooma's.  Rejecting these while permitting the captive VoIP offering  
> is dubious, to say the least.  (Yes, I know I'm treading on network  
> neutrality turf here...)
>
> 6)    The notification process should not assume that it's always a  
> human on the client end of a port 80 connection.  (The draft was at  
> least somewhat cognizant of the fact that it's not always a web  
> browser.)
>
> 7)    There needs to easy -- for the customer, and for the ISP --  
> recourse in event of misclassification. This is hard -- customer  
> care is expensive for ISPs, and both their Tier 1 support and much  
> of their clientele are often of less than expert knowledge, shall we  
> say, when it comes to the fine details of network and OS behavior.   
> (I recall one memorable interaction where I told a Tier 1 person  
> that I was seeing 15% packet loss and 5-90% packet duplication, and  
> was told in return that (a) 15% packet loss is pretty good, and I  
> could repair my performance problems by clearing my Internet  
> Explorer browser cache.  This was less than helpful advice, based on  
> a completely inaccurate diagnosis.  I fear I wasn't particularly  
> gentle with the rep after that answer.)
>
> 8)    There should be serious consideration by the ISP of regular  
> reviews by an outside advisory board.  Generally, we are dealing  
> with monopoly environments here; assurance that these principles are  
> being followed, and that this isn't a scam by an entrenched  
> incumbent, are valuable for all concerned.  Indeed, the ISP itself  
> may find that it benefits from such oversight.
>
>        --Steve Bellovin, http://www.cs.columbia.edu/~smb



-------------------------------------------
Archives: https://www.listbox.com/member/archive/247/=now
RSS Feed: https://www.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com