June 16, 2014 archive

Critical Need To Update Tweetdeck (If You Haven’t Already)

Tweetdeck logoIf you are a user of Tweetdeck, as I am, and you somehow missed the security warnings from last week, you need to update Tweetdeck!

There is a critical security vulnerability that allows an attacker to remotely execute code on your system. Granted, "all" it can go is send out tweets from your account, follow users or do other tasks that your Twitter account can do, i.e. it can't access your local hard drive or system. Still, though, having tweets go out from your account(s) via Tweetdeck could be harmful in any number of ways.

More information is available in these articles:

It seems to be the stereotypical case where a programmer didn't check to see if the text that is about to be displayed contains only allowed HTML code. This is the kind of error that has been found in any number of web applications over the years.

The net is that you need to update Tweetdeck to the latest version through whatever means you use to update your computer.

If you are a regular user of Tweetdeck you should have seen an update notice come up last week - and hopefully you did so! If you only occasionally use Tweetdeck, you may want to go in now and make sure you update to the latest version.


If you found this post interesting or useful, please consider either:


What Shall We Call Our New Topic Area On “Anti-Spoofing” Of IP Addresses?

question markWe need your help.  We are struggling with what to name the new topic area we are planning to launch related to preventing the “spoofing” of IP addresses.

In routing security circles this topic is generally referred to as “anti-spoofing” and we’ve talked about it ourselves that way such as in our report on an anti-spoofing panel at RIPE66 and the associated videos and whitepapers.  But that name has a couple of problems I’ll talk about below.

First, for some context, back in January 2014 we announced that we were changing how we covered the general topic of “routing resiliency and security”.  Rather than one broad – and vague – topic on “Routing”, our plan was to launch smaller focused topic ares – and with that announcement we  launched our “Securing BGP” topic.

The second focused topic area we want to launch is about steps that network operators and others can do to prevent the spoofing of IP addresses on their networks – and how this can help with prevention of distributed denial-of-service (DDoS) attacks.  Essentially we want to promote the validation of source IP addresses through using tools such as network ingress filtering.  Those who are aware of IETF RFCs/BCPs will know this as BCP 38 and BCP 84.  (And yes, there are the cynics out there who say that getting people to implement BCP 38 is right up there with seeing unicorns and with getting people to deploy IPv6, but hey, we are collectively making some progress with IPv6!  Unicorns are still not walking around, though.)

The simple answer (and where we might end up) would be to call this new topic area: “anti-spoofing“.  But if you look at our other topic areas, they are all technologies that can be deployed:

Okay… so “Securing BGP” is a bit squishy and not as specific as the others, but still, it is about a technology.  All of the topic area names are also short and easy to add to menus.  They all yield nice easy URLs of the form “/deploy360/<topic>/”.

The problems we have with “anti-spoofing” include:

  • “anti-spoofing” … of WHAT?   A web search will show that outside of the routing community the same term is used for efforts against the spoofing of Caller ID, email messages, face recognition, GPS signals, and more.  Many of the results seem to be about spoofing of IP addresses, but not all.
  • It does not reference a technology.

What we are really talking about is preventing the spoofing of source IP addresses inside of a network and the prevention of those spoofed addresses from leaving a network.  We are seeking validation of the original IP address.  However, calling it “IP Spoofing” speaks to the thing we want to prevent, rather than the technology or standards that we want to see deployed.  We want the topic name to reflect what we want people to deploy.

We tried a number of different names:

  • Anti-spoofing
  • Source Address Validation
  • IP Address Source Validation
  • IP Anti-spoofing
  • Ingress Filtering
  • Preventing IP Spoofing
  • Preventing IP Address Spoofing
  • Preventing IP Address Fraud
  • IP Address Validation
  • Stop Spoofing
  • Stop IP Address Spoofing
  • Illegitimate Traffic
  • BCP 38  (or BCP 84)
  • DDoS Prevention

We didn’t find any of those particularly appealing.  Keep in mind that the topic name needs to appear in a number of places on the Deploy360 website including the home page graphic slide, the navigation menus, sidebars, categories, etc.  It also needs to fit in with the other topic areas mentioned earlier.

We thought about “Ingress Filtering”, because that is the technology we ultimately want deployed – but that name is probably even less familiar to people than “anti-spoofing” and just seemed too long.

We toyed with “DDoS Prevention”, as that is really the end goal, and quite frankly would have some SEO/publicity value given the increased reports of DDoS attacks in the news.  But as our summer intern so aptly put it, that “sounds like we are on a crusade” and is also too broad.  We realized that if we open up a topic area on “DDoS Prevention” it is much more than source address validation – we could wind up getting into global load balancers, CDNs and so many other approaches.  And maybe that’s a good thing – but our goal right now is to get out deployment information related to why network operators should deploy source address validation to help the overall resiliency of the Internet.

And so here we are… we want to start promoting some of the tools and methods network operators can use to prevent IP address spoofing.  We want to do this because it is a way to make the Internet more secure and more resilient – and also in part to support some of the other Internet Society efforts underway such as the Routing Resiliency Survey.  We want to be able to talk here on the Deploy360 blog about why is is important to do this.

But we’re struggling with the name because “anti-spoofing” doesn’t seem to fit well with our other names. We’re looking for something specific, short and ideally focused on the technology we want to see deployed.

What do you think?  What should we call this new topic area?  Should we just go with “anti-spoofing”?  Or “ingress filtering”? Or “DDoS Prevention”?  Or one of the other names here? Do any of you have some idea for another name that we’ve missed here?

Any suggestions, ideas and feedback would be greatly appreciated as we’re kind of sitting here spinning our wheels while we try to sort out what name would work best.

Please leave a comment here on the blog or on Twitter, Facebook, Google+ or any of the other social networks where we post this.  Or just send us an email at deploy360@isoc.org if you share your thoughts privately with us.  We’d greatly appreciate any comments BY THIS FRIDAY, JUNE 20, 2014, as we’re trying to move ahead with this topic area soon.

Many thanks!


UPDATE: We’ve had a couple of suggestions coming in already:

Please do keep them coming!

FIR #760 – 6/16/14 – For Immediate Release

Upcoming speaking engagements; Mobile Mind Shift book review forthcoming; Quick News: Kit Kat gives rail passengers in Japan a break, Global PR agencies endorse Wikipedia policies, Jaguar XF owner's novel protest, Robert Peston vs. PR; Ragan promo; News That Fits: New York Times debuts the Snowfall of native ads, advice for adaptive storytelling from the Washington Post, Media Monitoring Minute from CustomScoop, listener comments, Dan York's Tech Report, FleishmanHillard releases 2014 Authenticity Report, Igloo Software promo, the past week on the FIR Podcast Network, Salesforce and others bet the business world is ready for wearables; music from Tab Spencer; and more.