June 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.

IPv4 Exhaustion Gets Real – Microsoft Runs Out Of U.S. Addresses For Azure Cloud – Time To Move To IPv6!

us ipv4BOOM! IPv4 address exhaustion just hit home really hard for a good number of people.  They set up virtual machines (VMs) in a US region on Microsoft’s Azure Cloud and now suddenly find that when they use those VMs to access other websites they are treated as if they are from a country outside the US.  Why?

Because Microsoft RAN OUT OF IPv4 ADDRESSES from its “U.S.” blocks of IPv4 addresses!

As Microsoft notes in their blog post:

Some Azure customers may have noticed that for a VM deployed in a US region, when they launch a localized page on a web browser it may redirect them to an international site. 

Oops.

They go on to say precisely what we and many others have been warning about for some time:

IPv4 address space has been fully assigned in the United States, meaning there is no additional IPv4 address space available. This requires Microsoft to use the IPv4 address space available to us globally for the addressing of new services. The result is that we will have to use IPv4 address space assigned to a non-US region to address services which may be in a US region.  It is not possible to transfer registration because the IP space is allocated to the registration authorities by Internet Assigned Numbers Authority.

Keep in mind, too, that back in 2011 Microsoft bought 666,624 IPv4 addresses from Nortel for $7.5 million. So they have already been shopping for more IPv4 space in the North American region.

They’re out.  Done.  Finished.

And so all those people wanting to run VMs on Microsoft’s Azure Cloud are suddenly confronting the reality that if they wanted their server to appear as if it came from the US, they can’t!

Sure, their domain name can look like it is a regular address for a US company… but in the underlying IP addressing their server will appear to the rest of the Internet to be in Brazil or some other location based on some of the geographical IP databases.

UPDATE: It is apparently not just Azure Cloud accounts in the US.  Over on Hacker News a commenter indicated that an Azure account in the North Europe datacenter in Dublin, Ireland, is also getting an IP address from Brazil.  I would guess (but don’t know for a fact) that this means Microsoft may be out of European IP addresses, too.

The impact is that servers running in the Azure Cloud (on VMs) may be treated by applications and services running on other servers as if they are outside the U.S. and so they may be given different choices or options than would be given to US servers.  The example shown in Microsoft’s blog post is of a web browser running on a VM connecting to a site and being given a Portuguese web page because the web server thought the incoming connection was coming from Brazil.  Depending upon how strongly the web server being visited serves out pages based on geographic IP data there may or may not be an easy option to get to pages intended for visitors from the US – or it might at least require more steps.   On a more serious note, there may be some sites that might block traffic in their firewalls based on where IP addresses are thought to be coming from – and so while you thought your server was set up “in the U.S.” it could instead wind up on someone’s blocked list.

Somewhat ironically, we wrote just yesterday about the need for cloud providers to get with the IPv6 program - and today we have living proof of WHY cloud providers need to care.

And as we also noted earlier this week, Latin and South America are basically out of IPv4 addresses – so while Microsoft can use some Brazilian IPv4 addresses today, odds are pretty good they won’t be able to get any more!

Here are a couple of other posts about today’s news:

The cold hard reality is that we simply cannot continue to rely on the “experimental” version of the Internet that used IPv4 addresses.  We need to collectively take the leap to the production version of the Internet using IPv6.

There are BILLIONS of people still to come online on the Internet – and there are BILLIONS more devices that we want to put online as part of the “Internet of Things”.  IPv4 simply doesn’t have the necessary number of addresses!

To get started with IPv6, please visit our “Start Here” page to find resources that are focused for your type of organization. And if you don’t find what you need, please let us know!  We are here to help you make the transition!

As Microsoft so vividly showed us today, IPv4 exhaustion is going to increasingly make IT systems more complicated.  It’s time to make the move to IPv6 where we don’t have to worry about address exhaustion – or having to use IP addresses from a different part of the world.

The time for IPv6 is now!

Good discussions on this topic are happening at:

 

TDYR #158 – It Is So Easy NOT To Run

It is so easy to choose NOT to run or do any other kind of exercise. This morning I didn't want to go for a run... but that is a trap that is so easy to fall into. In this episode I talk about that and the need to treat one's body as sacred and important.

CIRA Makes DNSSEC Available For .CA Through Registrars

CIRA logoGreat news today for our friends up north in Canada – they can now sign their .CA domains with DNSSEC! As the Canadian Internet Registration Authority (CIRA) said in a news release yesterday, they are making the Internet safer for all Canadians and noted:

DNSSEC builds a “chain of trust” between users and the websites they wish to visit. It helps counter malicious online activities such as DNS spoofing and man-in-the-middle (MITM) attacks. These fraudulent activities are usually intended to capture personal information, such as bank account logins.

Perhaps even more importantly, DNSSEC will now let people with .CA domains use innovative new protocols like DANE to add a layer of trust to TLS/SSL certificates used for ecommerce and secure access to websites.

CIRA also rolled out an updated FAQ page on DNSSEC (thanks, CIRA, for the link to our work here!) and already has three registrars/DNS hosting providers who will offer DNSSEC-secured .CA domain names.

You may recall that CIRA first made DNSSEC available for .CA domains back in early 2013. However, it was still a manual process to get your signed .CA domain linked in to the global “chain of trust” for DNSSEC.  With this announcement yesterday CIRA has now removed that manual process and made it easy for registrars to upload the necessary DS records. Now they just need more of the .CA registrars to support DNSSEC. (See our page about DNSSEC and registrars for an overview of the process.)

Congrats to the team at CIRA for making this happen!

P.S. If you want to get started with making our domain more secure, visit our “Start Here” pages to learn more about DNSSEC.

GigaOm: Cloud Providers Need To Get IPv6!

GigaOm article about IPv6Over on GigaOm today we were delighted to see the article “With billions of devices coming online, cloud providers better get with IPv6 program“.  In that article, author Barb Darrow writes:

As we enter the internet of things era, with millions; check that, billions of devices coming online, we’re going to need a lot more unique IP addresses. That means the big cloud providers need to get on the stick to support IPv6, the internet protocol that opens up billions of new addresses for just that purpose.

EXACTLY!

This is a key point we’ve been making in our events and presentations – with all these many devices coming online, and also with 3-4 billion more people to come online, we need to move to using IPv6!

In the article, she goes on to note that IPv6 is NOT supported by Microsoft Azure, Google Computer Engine and most of Amazon Web Services.  She does point out that IBM Softlayer does support IPv6 as will a new “Verizon Cloud” service apparently coming out later this year.  (All of which has made me note that we need a page on this Deploy360 site about “cloud services that support IPv6″.)

A few weeks back I asked a friend of mine who has an Internet of Things (IoT) startup whether his new service supported IPv6.  He runs his system, not surprisingly, on a cloud platform – in his case Amazon’s Elastic Compute Cloud (EC2) – and because EC2 doesn’t have IPv6, he can’t run his apps over IPv6.

We need to get there.  We need all the cloud providers to be enabled for IPv6, because they will then enable all the companies, large and small and everything in between, to make the move to the “production” version of the Internet.

Barb Darrow mentions in the GigaOm article that “the device population explosion pose to cloud providers and the very architecture of data centers will be a hot topic next week at Structure“, where Structure is GigaOm’s conference on the whole “cloud” topic.  That sounds great… although in looking at the agenda I don’t see anything specifically mentioning IPv6.  Hopefully that is a topic that gets covered and maybe we’ll be able to write about some of the IPv6-related news next week.

UPDATE: In a comment to this post, Barb Darrow indicates that IPv6 will be a topic in the Structure panel “What has to happen to enable the infrastructure to support IOT?”  And indeed, to support the Internet of Things (IoT) we very definitely need to move to IPv6!

Meanwhile, if you are a cloud provider – or anyone else – do check out our “Start Here” page or just browse through some of our IPv6 resources to get started with the move to IPv6!

TDYR #157 – Talking TLS For VoIP At SIPNOC 2014

How can we use TLS to make SIP-based voice-over-IP more secure? I was at the SIPNOC 2014 conference in Virginia talking on that specific topic. You can find more info at: http://www.internetsociety.org/deploy360/tls/

SIPNOC 2014 Begins Today In Virginia – I am speaking about TLS and SIP (and DANE)

SIP Forum SIPNOC 2014 OverviewToday I'm back at the Hyatt Dulles in Herndon, Virginia, for the fourth SIP Network Operators Conference (SIPNOC) event. These SIPNOC sessions are great because they bring together the people actually operating the SIP-based networks that make up our telecommunications infrastructure. SIPNOC continues to be THE best place I've found to interact with the people actually taking SIP standards and making them happen in the "real world".

I've been to all four SIPNOCs - and I continue to find them outstanding events, not only because of the excellent technical content, but also because of the people.

In many cases, these are the "phone guys" (and gals) who have found their way to IP. The "Bellheads" of the age-old "Bellhead vs Nethead" debate. The "telcos". The people who have been doing telecom for decades... and are now evolving to IP.

In other cases, the people here are the new contenders. The cable companies are here - and they are strongly challenging the legacy telcos, and they are creating entirely new IP-based infrastructures. The "Internet Telephony Service Providers (ITSPs)" and "SIP Trunking" providers are here, too... companies that are reimagining what telecom can be in an IP space. Newer vendors... newer application providers... etc.

It's a wonderful mix of people.

All here talking about telecom in the age of the Internet... sponsored by the SIP Forum.

As I mentioned in a post yesterday on the Deploy360 blog, I will be speaking today at SIPNOC 2014 about TLS for SIP. The abstract for my talk is:

With concerns about large-scale pervasive monitoring on the Internet, many groups are encouraging the increased use of Transport Layer Security (TLS, what we used to call “SSL”). While SIP has had TLS support for quite some time, it is often not used. This session will look at concerns of using TLS with SIP and discuss opportunities for providing higher security for SIP-based communication. The session will also outline some newer innovations such as the DANE protocol that when coupled with DNSSEC can provide a higher level of trust for TLS encryption.

This relates largely to the "TLS for Applications" work we are doing within Deploy360, as well as our advocacy for the use of the DANE protocol to add a layer of trust to TLS/SSL certificates.

As I note in that Deploy360 post, I'm delighted to see on the SIPNOC agenda that speaking before me will be Carl Klatsky from Comcast providing a case study of the lessons they have learned so far in moving to IPv6!

It's kind of fun to scan my list of presentations and look back at what I've spoken about at the past SIPNOC events:

SIPNOC 2011 (employed at Voxeo)
1. SIP Adoption and Network Security
2. Lessons Learned in Large-Scale SIP Interoperability
SIPNOC 2012 (employed at Voxeo)
1. SIP and IPv6 – Can They Get Along?
2. Panel Discussion: SIP Adoption and Network Security
3. BOF: SIP and IPv6
SIPNOC 2013 (employed at Internet Society)
1.IPv6 And SIP – Myth or Reality?
2. Who are You Really Calling? How DNSSEC Can Help
3. Panel Discussion: Anatomy of a VoIP DMZ (moderator)
SIPNOC 2014 (employed at Internet Society)
1. Is It Time For TLS For SIP? (also includes some DNSSEC/DANE)

It's nice to have someone else talking about IPv6 this year!

Of course, you'll also find me in the VoIP security BOF tonight... and listening to the other sessions. Unfortunately I have something else happening tomorrow evening back in New Hampshire and so I'm only here at SIPNOC today and will be flying back tomorrow. The SIPNOC event continues all day tomorrow and half a day on Thursday.

Sessions are underway now... here is photo proof:

Sipnoc2014 start

Unless you happen to be located in the DC area, it would be very hard for anyone to join into this year's SIPNOC event... but if you work with SIP or VoIP networks, I would strongly encourage you to put SIPNOC 2015 on your calendar for next year!


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


FIR #759 – 6/9/14 – For Immediate Release

Shel at the IABC conference in Toronto; Quick News: CIA joins Twitter, IABC names Carlos Fulcher new executive director, UK Podcasters meeting in London, BreatheRight does real-time marketing well; Ragan promo; News That Fits: PR reps, Wikipedians meet; Dan York's Tech Report; six myths of social sharing; the Media Monitoring Minute with CustomScoop; listener comments; social media compliance concerns in financial industry ease; what's new in the FIR Podcast Network; Michael Netzley's Asia Report; Igloo Software promo; Facebook discussion from Harry Hawk; music by Seventh Epic; and more