Just a guy in Vermont trying to connect all the dots...
Author's posts
Sep 25
BlackBerry’s New Blend Application Requires IPv6 Networking
Yesterday BlackBerry held a series of events announcing their new “Passport” smartphone as well as an application called “BlackBerry Blend” that lets you use your computer or tablet (including iOS and Android tablets) in conjunction with the Passport phone. There was a good bit of media coverage, almost all focusing on the Passport phone itself.
One interesting fact to emerge, though, is that the BlackBerry Blend application requires IPv6 networking in order to function.
NOTE – it does not seem to require IPv6 connectivity, i.e. your network doesn’t have to have actual IPv6 addressing and connectivity to the IPv6 Internet, but your network needs to allow IPv6 networking.
This is stated very clearly under “Step 1″ on Getting Started with BlackBerry Blend and even more clearly in a knowledge base article titled “Unable to connect to BlackBerry Blend due to ipv6 being blocked on the computer“. That support document states:
Overview
BlackBerry Blend is unable to connect to, or communicate with the BlackBerry 10 smartphone when IPv6 traffic is being blocked.Cause
An item in the network environment such as a VPN connector, firewall, network adapter setting, or anti-virus software is blocking or preventing IPv6 traffic.Resolution
IPv6 is a requirement for BlackBerry Blend to connect and communicate with the BlackBerry Smartphone. In order to complete the connection, IPv6 traffic will need to be enabled or allowed in the network environment.
So you apparently don’t necessarily have to have actual IPv6 connectivity… but you can’t be blocking IPv6 packets on the WiFi network that Blend is using to communicate with the Passport smartphone.
Similarity to Apple’s Back To My Mac
I can’t yet find any further information on exactly how BlackBerry is using IPv6 to make the connection between your computer or tablet. However, on a certain level it sounds similar to what Apple does with their Back To My Mac (BTMM) function that is now part of their iCloud service. BTMM allows you to connect from one Mac back to another Mac to share files or to “share the screen” and remotely operate that remote Mac. Apple has more info about BTMM in its iCloud support area.
Similarly, BlackBerry Blend lets you connect from your computer or tablet to your Passport smartphone to be able to send and receive messages, view your calendars, transfer files, access internal websites using the Passport’s connection, etc. Effectively you are “remotely” managing the Passport smartphone from the tablet or computer, although unlike Apple’s BTMM you aren’t manipulating the actual desktop of the device but rather using the services and applications on the Passport.
The IPv6 connection comes in through the work of a team from Apple, UCLA and Toyota who documented how Apple’s BTMM service works in RFC 6281 and showed how it essentially creates an IPv6 “tunnel” over IPv4 between the two Macs. It’s well worth a read to understand how Apple did this.
Now, differently from what BlackBerry Blend apparently does, Apple tunnels all their IPv6 packets over IPv4 and so they don’t care about what the local network does with IPv6. Apple’s BTMM is also designed to work anywhere across the entire Internet, while the BlackBerry Blend is designed to only work across the local WiFi network. (The device running the BlackBerry Blend app and the Passport smartphone must both be on the same WiFi network to communicate.)
Still, it sounds like BlackBerry is creating some kind of IPv6 “tunnel” between the Blend app and the Passport device.
BlackBerry Assumes IPv6 Will Be Allowed
However, it seems BlackBerry assumed that IPv6 packets would not be blocked on the local WiFi network or would not be blocked on the computer running the Blend app. That probably is a safe assumption for many or even most networks, but I’ve heard of some enterprise networks who have not yet moved from IPv4 restricting IPv6 to prevent any unknown communication. It is those networks where Blend may have challenges working.
The reality is that the world is moving to IPv6 and so network operators MUST understand IPv6 security so that they can create appropriate IPv6 security policies that securely allow IPv6 traffic, rather than just blindly blocking IPv6.
BlackBerry’s Blend is just one of the first apps we’ll see assuming IPv6 is allowed. I’m sure there will be many more in the years ahead. Network operators who don’t at least allow IPv6 will find themselves with people or customers who are unhappy that they can’t use these new applications and services. Time to make IPv6 happen! (Or at least not block it!)
P.S. If you want to get started with IPv6, please visit our “Start Here” page to find resources targeted at your role or type of organization. And please let us know if you need more information!
Sep 23
Talko Looks Very Cool, But Needed A Firewall Change To Work
I think Talko has great potential to do so, particularly after using it.
But...
... I had to change my firewall rules in order to make Talko work. :-(
And I don't know how long it will continue to work.
Perhaps worse than that... it wasn't clear initially that I had a firewall problem. Frequent testing partner Jim Courtney sent me a message and after installing the Talko app on my iPhone I tried to talk to him, but all I seemed to be able to do was send him a voice message or a text message.
Subsequently I tried connecting to Tim Panton and again could only send voice messages. It made for a very asynchronous "walkie-talkie" style of communication that clearly seemed to not be what was described in the article.
At that point my many years in VoIP kicked in and I realized the firewall at the edge of my network was probably blocking something. Sure enough, when I pulled up the live firewall log and filtered on my iPhone's IP address I could see blocked connections from my iPhone that were intended for an IP address in Amazon's EC2 cloud. These blocked connections happened when I tried to initiate a voice conversation within Talko.
I first tried to create a firewall rule that would allow specific ports through, just by guessing from the firewall logs what ports Talko might be using. However, they jumped around and what I ultimately had to do was create a rule allowing any connection from inside my network to the specific IPv4 address of what I assume is one of Talko's servers on Amazon EC2.
Once I did this, I was able to have a voice conversation with Tim perfectly fine. It was actually rather cool how it would record the conversation and let me easily go back, listen again, advance through it, etc.
But...
... poking a hole in my firewall to a specific IP address is very definitely NOT the way to have a telecom application work.
And... Talko will only work on my network as long as that destination IP address doesn't change. If they add more servers or change their architecture, it's dead to me. At least... dead on my home WiFi network. Presumably it could still work on my mobile data network (at a cost to me).
Now, to be fair, I'm a bit more security-paranoid than the average home user and so I run a Linux-based firewall/server/gateway on the edge of my home network with a fairly restrictive set of firewall rules. The default policy is to deny outbound connections unless they fit into various rules. I've had to add rules allowing VoIP and IM protocols... and it's not uncommon for me to have to add new rules for applications like this. For instance, I had to do so for Tox when I was playing with it a few months back.
Odds are Talko will probably work fine for the vast majority of connections from WiFi networks with less paranoid firewall rules.
But... for an app like this to really challenge the existing telecom infrastructure, it needs to work from almost anywhere. This is why Skype usage is so ubiquitous - Skype "just works" and has its ways to work around firewalls. Within the SIP and WebRTC communities there are all the STUN / TURN / ICE servers and technologies that enable this kind of transit of a firewall. The technology is out there. And there will certainly be some enterprises and other businesses that set up firewalls at least as restrictive as mine is.
I realize today's news is the initial public launch and that this is early days for the app. I hope the Talko team can figure out a way to make the voice conversation work through firewalls. I really like what I see inside the app.
Meanwhile... I'm just hoping they don't change the IP address of the server with which my app is communicating!
If you found this post interesting or useful, please consider either:
- following me on Twitter;
- adding me to a circle on Google+;
- following me on App.net
- subscribing to my email newsletter; or
- subscribing to the RSS feed
Sep 22
FIR #774 – 9/22/14 – For Immediate Release
Sep 19
Three Years At The Internet Society
Today marks three truly amazing years at the Internet Society. It was September 19, 2011, when I visited the main office in Reston, Virginia, and began this wonderful journey. I wrote back then about why I was taking this job to fight for the open Internet - and in truth the reasons haven't changed.
If anything, the situation has only gotten worse.
There are now far more threats to what I've taken to calling the "Internet of Opportunity" ... the kind of Internet we have today where anyone can start any kind of service or publish any kind of information.
Within the Internet Society (or "ISOC" as we are often called) we call this "permissionless innovation", not needing to ask permission of anyone to innovate. If you have a new idea or a new service or product... you can just do it. You don't have to plead with a "gatekeeper" or pay someone in order to launch your service out onto the Internet.
But that could change.
Some of the legacy telecommunications companies who have lost out on revenue as everyone has moved away from phone calls would really like their revenue back. Some of the entertainment and traditional media companies would like their revenue and control back, too. And many governments would like to regain some of their control - and tax revenue.
Money and control.
As I wrote in that article three years ago, there is a great quote from the 1992 movie Sneakers:
“There’s a war out there, old friend. A world war. And it’s not about who’s got the most bullets. It’s about who controls the information. What we see and hear, how we work, what we think… it’s all about the information!”
That is definitely the case. And that war is only gotten stronger... and it's going to get even more fierce in the years ahead.
I'm personally glad that there are a group of organization including the Internet Society that are dedicated to shining the light on the changes that are happening... and arguing for why we need to keep the current "open" nature of the Internet so that we and our children, and their children, can all benefit from the kinds of opportunities we've had to date with the Internet.
Last year I wrote a good bit about how pleased I was to be part of the Internet Society. That hasn't changed! My passion for the work that ISOC does around the world has only grown stronger in this past year as I have learned more of the amazing things happening around the world. I continue to love my own work with the Internet Society Deploy360 Programme - I wake up each morning excited to write more and do more to help people learn how they can deploy new technologies to make the Internet work better, faster and be more secure. I absolutely love what I do!
But I was reminded this week of how many other things are done by my colleagues all over the world. I just game back from a 4-day all-staff retreat at a hotel in Virginia. This was the first time an event like this had been held in over 3 years and we've added so many new staff that many of us had never met each other. We spent the time talking about what our priorities should be... where did we see the organization going... how could we best help the Internet... what could we do......
It was an amazing time. VERY intense... although certainly with some time for fun mixed in. We came out with some great ideas and plans that I'm looking forward to making happen in the weeks and months ahead.
What struck me most is that the people are amazing. It's truly an honor and privilege for me to serve with them and to do what we do.
The mission of the Internet Society is quite simple:
To promote the open development, evolution, and use of the Internet for the benefit of all people throughout the world.
It's that mission that brought me here... and that's the reason I continue to be as excited as I am about what I do. As I celebrate three years with the Internet Society, I'm very much looking forward to the next three years... and the next beyond that!
P.S. One great way you can help is to join the Internet Society to stay up-to-date on current issues affecting the Internet - membership is free for individuals. You can also subscribe to my infrequent email newsletter where I hit many of these topics.
If you found this post interesting or useful, please consider either:
- following me on Twitter;
- adding me to a circle on Google+;
- following me on App.net
- subscribing to my email newsletter; or
- subscribing to the RSS feed
Sep 19
Watch Live TODAY (Sept 19) – CITI State of Telecom 2014
Today, September 19, 2014, there is an interesting set of presentations happening at the Columbia Club in New York City, organized by the Columbia (University) Institute for Tele-Information (CITI) called the "CITI State of Telecom 2014". Subtitled, "From the Internet of Science to The Internet of Next Generation Entertainment Implications for Content, Technology and Industry Consolidation", the session description states:
The goal of the early Internet was to connect research institutions. Yet today 71% of all Internet traffic consists of video, games, and music, and that number is growing. This transition raises issues for media content, technology, industry consolidation, business strategy, and regulatory policy. Media companies, academics, policy makers, and technologists must think ahead.
You can watch it all live at:
http://new.livestream.com/internetsociety/citisot14
The sessions are being recorded, too, and are available at that address.
The session agenda and list of all the speakers is available on the CITI event page. The quick summary is:
- 9:00am Welcome and Introduction of Topic
- 9:15am Session 1- Technology and business drivers of the transformation of the Internet
- 10:25am Session 2- Emerging business, marketing, and transaction models for Next Generation Video (NGV)
- 11:35am Coffee Break
- 11:50am Session 3- Public Interest Dimensions in Next-Generation Video and Networks
- 12:50pm Lunch
- 1:50pm Session 4 - Consolidation in the network platform industry: drivers and impacts
- 3:00pm Coffee Break
- 3:10pm Session 5 - New TV and (video) OTT issues for telecom and media policy
- 4:20pm Session 6 - Defining the future: initiatives to lead the next generation of internet video
- 5:30 Closing remarks and reception
The sessions began 3.5 hours ago at 9:00am US Eastern and will continue for another 5 hours. I've learned a good bit from a number of the sessions - and am listening right now to the discussion around the challenges of getting Internet infrastructure deployed in rural areas of the USA.
Great sessions to listen to!
If you found this post interesting or useful, please consider either:
- following me on Twitter;
- adding me to a circle on Google+;
- following me on App.net
- subscribing to my email newsletter; or
- subscribing to the RSS feed
Sep 19
Video: Geoff Huston – what if everyone did DNSSEC? (APNIC 38)
What if everyone enabled DNSSEC? What would happen to your network? Should you be scared?
The good folks at APNIC are out with a video from Geoff Huston answering these questions:
If you want to get started with DNSSEC so that your domain name can be secure from being impersonated, please visit our Start Here page to find resources targeted for your type of organization.
Help us make the Internet more secure – deploy DNSSEC validation and start signing your domains NOW!
P.S. For a good example of HOW DNSSEC can help protect you, please read our recent article about email hijacking attacks that are going on now – but could be prevented by the use of DNSSEC.
Sep 18
BGPmon: Using BGP Data To Fight Spam
Can we use BGP data to find email spammers? And could securing BGP provide a mechanism to help reduce spam?
In a fascinating article on BGPmon’s site, Andree Toonk explores how they found that “IP squatting” is used by spammers. Essentially the attack seems to work like this:
- The spammers identify a block of IP addresses (IPv4) that are not currently being used on the actual Internet.
- The spammers send out BGP announcements routing that block of IP addresses to their servers.
- The spammers send out their spam email messages.
- When done (or when the IP address block is blocked by anti-spam tools), the spammers stop announcing the BGP routes for those IP address blocks.
They then can move on to announcing other IP address blocks to send more spam.
The article provides a very compelling and very readable description of two case studies where they found this to happen. In one case the spammers also used an Internet Route Registry (IRR) to attempt to give their BGP route announcement more legitimacy.
The BGPmon article doesn’t get into solutions… but preventing these kind of attacks is precisely why we set up the Securing BGP topic area of this site.
A general area of “source address validation” is critical here – the idea being to have some way to know that the router announcing the BGP routes has the actual authority to do so. New tools such as RPKI are emerging that let us securely validate the origin of route announcements to prevent spammers from performing the attacks like this. With such tools a router would reject BGP announcements that came from the spammers’ systems because the spammers would not be able to securely assert that they had the right to announce those IP address blocks. The challenge, of course, is to get more routers start signing route announcements – and more routers start validating route announcements. (Read about how Jan set up RPKI for his lab.) There are other tools and methods being explored, too. The point is to not allow “spoofed” IP address blocks to get into the global routing tables.
This idea of securing BGP route announcements is also part of the “Routing Resilience Manifesto” that continues to be developed as (voluntary) guidelines for network operators.
If we are collectively able to implement some of these mechanisms for securing BGP we can potentially make a significant reduction in the ability of spammers to send their email – and make the Internet more secure and working better in the process. Please do check out our Securing BPG section and consider what you can do in your network today!
Sep 15
FIR #773 – 9/15/14 – For Immediate Release
Sep 12
Email Hijacking – New Research Shows Why We Need DNSSEC Now!
Want a great example of why we need DNSSEC now? Consider this new research from the CERT/CC team at Carnegie Mellon University that finds that someone is hijacking email messages to relay them through another email server. The messages are being delivered, but it’s unknown whether they are being modified before delivery or simply logged and monitored. As they say:
The disconcerting aspect of this work is not how many domains we see being poisoned, as there are relatively few, but which domains they are. We observe changes in A records so that a domain resolves to a different IP address. But the domains being targeted are often listed as name servers or mail exchanges for other domains. The biggest free webmail providers have been repeatedly victimized on some unknown (but likely smaller) subsection of the Internet sometime during the last year.
Someone… or multiple entities… appear to be poisoning DNS caches so that they can interject their own mail server into the delivery path of the email messages. The CERT/CC team goes on to explain the attack and provides a very useful diagram:
Figure 2 diagrams how this usual process can be thwarted if the DNS answer for the IP address of the destination MX is changed. The mail message makes an unintended pit stop at the poisonous IP address. That server can then forward the message to its intended destination. Since mail is transmitted asynchronously, the sender and recipient are not likely to notice anything out of the ordinary. The sending IP address in the message header would likely reflect the diversion, but since mail handling often has a few exchanges before the final destination, it is not immediately obvious to anyone along the path that the diversion was out of the ordinary.
They go on to outline the potential outcome of the attack:
Unless the whole message is cryptographically protected, the intermediate server can read and modify the message, or append malicious content. This attack would defeat opportunistic TLS encryption between MXs that is meant to ensure the confidentiality of messages in transit. And there are some small changes the intermediary could make to the mail that would make the attack worthwhile, such as changing a bank account number for a home purchase deposit.
Essentially, the attacker could do anything they want with the email message as it is now in their possession, including:
- Modify the message to either add, change or remove content
- Log the message (and all of its content) in some large database
- Simply drop the message (i.e. don’t deliver it) so that the recipient never gets the message
The researchers don’t yet know who is behind this redirection. It could be:
- Criminals
- Nation states (ex. intelligence agencies)
- Other security researchers
All they know is someone is hijacking delivery of email messages for some reason – and they are seeking help from the larger Internet community! (Please see the bottom of their post.)
How To Protect Your Email Delivery
As the researchers note, DNSSEC is designed to prevent this type of hijacking of DNS information. This type of hijacking would be prevented if:
1. The recipient’s domain name was signed with DNSSEC which means that the MX records (and all other DNS records) would have a cryptographic signature added.
2. The sender’s local DNS resolver was performing DNSSEC validation in which it checked the DNSSEC signatures.
Had this been in place, then the sending mail server would not have received the false MX record and would not have delivered the email to the attacker’s server. You can read more in our document about the two sides of DNSSEC.
This hijacking of email messages is going on right now on an ongoing basis according to the researchers, and so you can take two steps to ensure that your email messages are not being hijacked:
1. Sign Your Domain With DNSSEC
The first step is to sign your domain with DNSSEC so that your MX records are protected. If you do not operate your own DNS servers, this may involve you contacting your DNS hosting provider or DNS registrar to ask them to perform DNSSEC-signing on your domain. We have some information about how to do this here:
and ICANN has a list of some of the registrars that provide some degree of DNSSEC support.
If you do operate your own authoritative name servers for your domain, then you can determine what you need to do to sign the domain with DNSSEC. Many of the common authoritative name servers such as BIND, NSD, Knot and Microsoft Windows Server 2012 all include support now for DNSSEC signing. There are also additional tools such as OpenDNSSEC that can help make this work smoothly. Some of the resources that may help:
- Our list of DNSSEC tools
- The DNSSEC Tools Project
- NIST’s guide to secure DNS deployment (a great tutorial)
- Microsoft’s guide to deploying DNSSEC in Windows Server 2012
- NLNet Labs’ DNSSEC HOWTO
Once you have signed your domain, you will then need to communicate your “DS record” to your parent zone (often the top-level domain) by way of your registrar. See our page about working with registrars for more information.
2. Turn On DNSSEC Validation On Your Network
With signing, inbound email messages to you will not be hijacked (assuming the sender is performing DNSSEC validation), but the possibility will still exist for outbound messages you send to be hijacked if your mail server doesn’t learn the correct address for the recipient’s mail server.
To enable this layer of protection, all you need to do is turn on DNSSEC validation on your local DNS server – or whatever DNS resolver your email server uses. That is the important part because in this instance we are trying to protect email delivery. You want your email server to be getting the correct DNS information.
We wrote about how to do this and recommend an excellent whitepaper from SURFnet that explains how to easily do this with three of the common DNS resolvers: BIND, Unbound and Microsoft Windows Server.
Now… if you don’t control the local DNS server – for instance, if you use the DNS resolver at your local Internet service provider (ISP) – then you need to contact that organization to find out if they can enable DNSSEC validation.
If your ISP is unwilling/unable to turn on DNSSEC validation, you could set your mail server to use external DNS servers that perform DNSSEC validation such as Google’s Public DNS, but we don’t recommend this unless it is your last resort because using such a distant DNS server provides a lot of room for an attacker to still inject fake packets. As we wrote about in our “plan for DNSSEC validation“, the ideal is to have the DNSSEC validation happening as close as possible to the mail server (in this case). It would be much safer, and perhaps quite easy, to install a local DNSSEC-validating resolver on or near your mail server itself.
With those two steps, you will protect the delivery of email to your domains – and protect your mailserver from delivering email to whomever is out there right now hijacking all these messages.
Let’s do that today, okay? If we all do it now we can make the Internet that much safer and more secure!
If you’d like more information about DNSSEC, please see our “Start Here” page to find resources tailored to your type of organization and role – and please let us know if you need even more information!
Sep 12