Category: Deploy360

Oct 27

ION Santiago Streaming Live From Chile Tomorrow

ION SANTIAGOWant to learn the latest news about IPv6, DANE, BGP security, Anti-spoofing, TLS, Best Current Operational Practice (BCOP) efforts, and standards within the IETF?

For all of this information, please join us tomorrow, Tuesday, October 28, 2014, at 2:00pm CLST (15:00 UTC), when our ION Santiago event will be streaming live out of Chile.

You can watch the event using the LACNIC 22 webcasting page. The ION Santiago agenda is packed with great sessions:

  • What’s Happening at the IETF? Internet Standards and How To Get Involved
  • Operators & the IETF
  • Beyond the Tipping Point: Global Connectivity Two Years After World IPv6 Launch
  • Best Current Operational Practices Update
  • Panel: Routing Around Catastrophe: Securing BGP, Anti-spoofing and More
  • Lock It Up: TLS for Network Operators
  • DANE: The Future of Transport Layer Security (TLS)

Join us tomorrow for what should be an excellent set of sessions!

And if you want to get started now with deploying these technologies, please visit our “Start Here” page to find resources targeted at your type of organization or role.

The post ION Santiago Streaming Live From Chile Tomorrow appeared first on Internet Society.

Aug 25

MPAA: Need To Move To IPv6 For Improved Video Viewing Experience

MPAA logoWant an improved video streaming experience?  Want faster delivery of higher resolution HD and 4K videos? Move to using IPv6!  That’s essentially the message from Alex Deacon of the Motion Picture Association of America (MPAA) in a recent blog post, “Delivering An Enhanced Video Experience With IPv6“.  He begins:

As the popularity of video streaming services continues to grow across the globe so do the requirements for efficient and high-speed network infrastructure used to deliver them. While much work is happening in this regard, one area of focus is the global deployment of IPv6 (Internet Protocol v6).

He then explores a number of the critical aspects of network infrastructure that are solved by the move to IPv6 including potentially removing the added latency that will come with deployment of Large-Scale NAT(LSN) / Carrier-Grade NAT (CGN).  He also mentions the potential for faster routing and improved multicasting, both of which can make the delivery of video faster.  His key quote to me is this (my emphasis added to the latter part):

The continued deployment and use of IPv6, and the many network efficiencies it brings, is key to the continued ability for our industry to deliver high quality, high speed and high definition content to users. This will minimize video start-up wait times, reduce video buffering and enable the delivery of HD and 4K content.

As someone who consumes video content primarily through video streaming services, I very much want to have faster start-up times and reduced video buffering.  It is great to see an organization such as the MPAA promoting this as a benefit of the move to IPv6.

The article is definitely worth a read … and if you are a provider of video streaming services, we would encourage you to visit our “IPv6 for Content Providers” page to learn more about how you can get started!

P.S. And if you are not a provider of video streaming services, you may want to visit our “Start Here” page to find resources to help you get started with IPv6.

The post MPAA: Need To Move To IPv6 For Improved Video Viewing Experience appeared first on Internet Society.

Aug 06

WebRTC “Just Works” Over IPv6…

I love opening up my computer in the morning and seeing tweets like this one:

The text is:

I’ve tested #WebRTC with Chrome talking to a ICE-Lite WebRTC server on IPv6. It just works. Nice.

And THAT is the way it should be.  For all the work we do as a community and industry to advance the deployment of IPv6, in the end the user experience should be exactly that… it should “just work”.  Users shouldn’t notice – or care – that their traffic goes over IPv4 or IPv6.

Kudos to the Chrome team for making it so that WebRTC “just worked” over IPv6.  And kudos to Iñaki Baz Castillo for noticing!

Now, let’s get out there and make everything else “just work” over IPv6! 🙂

If you’d like to get started with making your applications or network work with IPv6, please check out our “Start Here” page to find resources tailored to your type of role and organization – and please let us know if you need more information.

UPDATE: A bit more information about what made the WebRTC application “just work” in Chrome. Per Iñaki Baz Castillo, he had this bit of JavaScript code in the WebRTC app that the browser downloaded:

var pc_constraints = {
mandatory: { googIPv6: true }
};

That bit of code made his app work over IPv6.

The post WebRTC “Just Works” Over IPv6… appeared first on Internet Society.

Jul 17

A Huge Amount Of DNSSEC Activity Next Week At IETF 90 In Toronto

DNSSEC badgeIf you are interested in DNSSEC and/or “DNS security” in general, there is going to be a great amount of activity happening in a number of different working group sessions at IETF 90 next week in Toronto.

I wrote about all of this in a post on the ITM blog, “Rough Guide to IETF 90: DNSSEC, DANE and DNS Security“, a part of the Rough Guide to IETF 90 series of posts.

You can read the full details (and find links to all the drafts), but here’s a quick summary:

  • The DNSOP (DNS Operations) Working Group will be talking about DNSSEC key and signing policies and requirements for DNSSEC validation in DNS resolvers.  The group will also talk about the “DNSSEC roadblock avoidance” draft before getting into what should be a lively discussion about how we better optimize the distribution of data in the root zone of DNS.
  • The DANE Working Group will discuss a number of ways the DANE protocol can be used with applications such as OpenPGP, SMIME, SMTP and more.  There will also be a discussion of turning the “DANE Operational Guidance” draft into an actual update/replacement for RFC 6698 that defines DANE. It should be very interesting session!
  • The SIPCORE Working Group will discuss a draft about using DANE and DNSSEC for SIP-based Voice-over-IP (VoIP).
  • The TRANS Working Group will explore whether or not there is a role for Certificate Transparency (CT) to play with DNSSEC and/or DANE.
  • The HOMENET Working Group will discuss two different drafts relating to DNSSEC and customer-premise equipment (CPE) such as home wifi routers.

And a couple of other working groups may have DNSSEC-related discussions as well.  All in all it will be a very busy week at IETF 90!

Again, more details and links to all of the associated drafts can be found in the Rough Guide to IETF 90 article about DNSSEC.

If you aren’t able to actually be in Toronto, you still can participate remotely – see the IETF 90 Remote Participation page for more information about how you can join in to the discussions.

If you are in Toronto, please do feel free to say hello and introduce yourself.  You can pretty much expect to find me in all of these various DNSSEC-related sessions (and many of the IPv6-related sessions, too).

The post A Huge Amount Of DNSSEC Activity Next Week At IETF 90 In Toronto appeared first on Internet Society.

Feb 05

Comcast’s Speedtest Now Breaks Out IPv6 Speed Vs IPv4 Speed

A tip from John Jason Brzowski let us know that Comcast’s Internet speed test at speedtest.comcast.net now performs speed tests over both IPv6 and IPv4 and shows you the results separately.  This is a public test that anyone can use, regardless of whether you are a Comcast customer or not.  Perhaps obviously, for the IPv6 test to work you need to either have native IPv6 connectivity from your ISP or you need to have an IPv6 tunnel for your network.  Without that you’ll just get a regular old IPv4 test.

Naturally I had to try this out and was quite pleased with the results. I am NOT a Comcast customer so the results are for another ISP. I do have native IPv6 connectivity so this was not tunneled traffic. Here was my test yesterday with the closest geographic server (which may or may not relate to network proximity – I didn’t do much checking on that):

Comcast XFinity Speed Test

Of course I was pleased that IPv6 was faster!  I assume this probably had to do with more congestion on the IPv4 network at the precise time I did the test.  As you’ll see below, IPv6 was not always faster.

For those familiar with these type of speed tests, the test performed two separate upload and download cycles for IPv4 and IPv6.  As you can see from the center of the image a cool feature is that you can get a link to an image that you can then share out to social networks or use in other places.  For example, here is the link to my image:

Now, of course I had to try this multiple times during yesterday to see how the results varied – and as is true with pretty much all of these speedtest sites the results DID vary widely.  Some of the results included:

 

I tried other servers in other parts of the US and had similar types of variation.

And then to my amusement I tried the test today shortly before writing this post and found that my speed has degraded significantly. Two results from Boston and one from the New Jersey server:

  

Just to check I tried a couple of other speed test sites and they provided similar results today.  Now the explanation for this drop in my own bandwidth is probably pretty simple.

Snow.

Today we’re experiencing a major snowstorm here in New Hampshire (and all of the northeast USA) and so all the schools are closed and many kids are at home along with parents who need to be home with them.  So people are undoubtedly streaming more movies, playing more online games and just consuming much more online bandwidth than they usually do during the day.  My Internet connection is through my local cable provider… so it’s shared through my neighborhood, and so there we are.  Tomorrow when everyone goes back to school my daytime speed should increase! 🙂

All comments about snow aside, this is very cool for Comcast to break out the speeds by protocol this way.  They are of course NOT the only speed test out there that does this.  Other IPv6 vs IPv4 speed tests include sites such as  http://ipv6-test.com/speedtest/  and http://www.speedtest6.com/

Congrats to the team at Comcast for making this available!

P.S. I’d note that Comcast has to be collecting some fascinating measurements out of this effort because they are gathering test results from not only their own customers but also from all of their competitor’s customers who use this test site.  They can then come up with statistics and metrics about the performance of those competitor networks.  A rather brilliant move by someone within Comcast! Now… what would be great for the larger Internet community would be if they could also find some way to perhaps expose some aggregated level of information about what they are are seeing in terms of IPv6 performance across the range of ISPs from people using the site… maybe a topic for a presentation by someone at Comcast at a future event?  (Hint, hint…)

The post Comcast’s Speedtest Now Breaks Out IPv6 Speed Vs IPv4 Speed appeared first on Internet Society.

Jan 29

Introducing A New Deploy360 Topic: Securing BGP

BGPHow can we help network operators ensure that their usage of the Border Gateway Protocol (BGP) is as secure as possible?  How can we help enterprises who operate their own routing infrastructure make sure that they are keeping their own networks secure?  How can we help network operators at all levels make sure they are doing their part to keep the Internet’s routing infrastructure as secure and resilient as possible?

A year ago we launched the “Routing” topic on Deploy360 to explore these kind of questions.  We’ve written many articles about routing resiliency and featured panels about improving routing resiliency/security at our ION conferences, such as a recent session at ION Toronto.

However, as we went around speaking with people about the need to make the Internet’s routing infrastructure more resilient and secure,  one extremely important bit of feedback we received from people was that our topic here on Deploy360 of “Routing” was far too broad.  It wasn’t as specific as our areas on IPv6 and DNSSEC, and that provided multiple challenges both in terms of creating a logical flow of providing deployment information and also in finding resources and/or people to create new materials.

We’ve listened to all that feedback and are changing how we address the overall routing resiliency topic.  Instead of one massive topic, we’re going to be breaking the area down into several smaller topics that we will be rolling out over the course of 2014.

Today we’re pleased to announce the first new topic area, Securing BGP, where we will be focusing on the tools, services and technologies that can help make BGP routing more secure.  We’ll be talking about not only basic “good hygiene” for routing but also specific tools that can help secure BGP such as prefix filtering, ACLs, RPKI, BGPSEC and much more.  We have created a set of initial pages related to the topic which will be populating with more content over the weeks and months ahead:

Perhaps more importantly we have outlined a content roadmap for the resources related to securing BGP that we want to add to the site and are now actively looking for resources that are out there now that we can point to – or identifying authors who can write some of the resources that don’t yet exist. Naturally we’ll be adding blog posts related to securing BGP to our Deploy360 blog – and you can expect sessions related to securing BGP to appear at our future ION conferences.

How You Can Help

We need your help!  In order to provide the best possible resources to help network operators secure their use of BGP, we need to hear from you!  We need your feedback to help us know that we are helping you make your network more secure.  A few specific requests:

1. Read through our pages and content roadmap – Please take a look through our “Securing BPG” set of pages, and also please take a look at our content roadmap for BGP.  Are the current resources listed helpful?  Is the way we have structured the information helpful?  Will the resources we list on our roadmap help you make your routers more secure?

2. Send us suggestions – If you know of a report, whitepaper, tutorial, video, case study, site or other resource we should consider adding to the site, please let us know. We have a list of many resources that we are considering, but we are always looking for more.

3. Volunteer – If you are very interested in this topic and would like to actively help us on an ongoing basis, please fill out our volunteer form and we’ll get you connected to what we are doing.

4. Help us spread the word – As we publish resources and blog posts relating to securing BGP, please help us spread those links through social networks so that more people can learn about the topic.

The post Introducing A New Deploy360 Topic: Securing BGP appeared first on Internet Society.

Dec 06

Want To Quickly Create A TLSA Record For DANE / DNSSEC?

Generate-TLSA-Record-3Would you like to use the DANE protocol to secure your SSL/TLS certificate via DNSSEC?  If so, the first step is to generate and publish a “TLSA record” in DNS – and that record generation can be a stumbling block for some people.  While there are command-line tools such as just the basic “openssl” or Paul Wouter’s “hash-slinger“, Shumon Huque recently released a web interface that lets you easily create a TLSA record.  As Shumon writes about on his blog, the tool is at:

https://www.huque.com/bin/gen_tlsa

All you need to do is to set the type of TLSA record you want to create, paste in the X.509 certificate, and enter the appropriate port number, protocol and domain name.  Shumon’s script then generates the appropriate TLSA record that you can paste into your DNS zone file.

Last year, Shumon wrote a post on “DNSSEC and Certificates” where he walked through how to do this using openssl on the command line – this latest post now builds on that to make it even easier.

It’s excellent that Shumon has made this tool available and we look forward to seeing many more TLSA records out there!  (If you have a SSL/TLS cert for your website, how about adding a TLSA record today?)

The post Want To Quickly Create A TLSA Record For DANE / DNSSEC? appeared first on Internet Society.

May 01

Confirmed – Google’s Public DNS Now Performs DNSSEC Validation For ALL Queries By Default

Google logoIt’s official… Google’s Public DNS service is now performing DNSSEC validation for all DNS queries by default!

When news broke back on March 19 that Google had enabled DNSSEC validation on its Public DNS service, there was some initial concern after people noticed that Google was only performing the DNSSEC validation when requested. This led to a clarification a few days later from Google that their initial rollout required a client to request DNSSEC validation so that they could test out the service – and that full validation was coming soon.

The Official Word

Yesterday, Google’s Warren Kumari posted in the dnssec-deployment mailing list that full validation IS now happening:

We have recently enabled validation by default globally, and you should now get SERVFAIL for validation failures.  Apologies again for the original, unclear announcement.

The blog / documentation has not been updated yet (that will probably happen in the next few days) but we wanted to give you the good news as soon as possible.

And indeed a quick test to see if I could get the DNS records for a test domain known to have a bad DNSSEC signature did produce the expected “SERVFAIL” message and correctly did not return any DNS records:

$ dig @8.8.8.8 www.dnssec-failed.org

; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 www.dnssec-failed.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60286
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.dnssec-failed.org.        IN    A

This is great news for those of us who are advocates of DNSSEC and means that anyone using Google’s Public DNS servers for DNS name resolution are now automatically receiving the greater security of DNSSEC. Anyone using those servers will know that (for signed domains) the information they are getting out of DNS is the same information that the domain operator put into DNS – and not that of an attacker seeking to have you go to some other site.

If you, too, want to gain access to the increased security of DNSSEC, all you have to do is configure your computer or home router to have as its DNS servers the Google Public DNS servers:

8.8.8.8
8.8.4.4

2001:4860:4860::8888
2001:4860:4860::8844

That’s it!

Moving DNSSEC Validation Even Closer

As awesome as this move by Google is (and it is awesome), you could still increase the security provided by DNSSEC a bit more.  Because Google’s Public DNS servers are not on your local network and are rather somewhere out across the Internet, there is still a chance that an attacker could insert himself or herself between you and Google’s DNS servers.  The attacker could then pretend to be sending you back the correct information and masquerading as Google’s Public DNS servers.

To get the highest level of DNSSEC security, you ideally want to be performing the DNSSEC validation on at least your local network and potentially even your local computer. There’s a great whitepaper out from the folks at SURFnet called “Deploying DNSSEC: Validation on recursive caching name servers” that explains how you can simply enable DNSSEC validation for three of the common DNS servers used by enterprises and networks today.

Hey, if Google can enable DNSSEC validation, why can’t you?

If you can’t do DNSSEC validation locally (for example, if you only have a home WiFi router that doesn’t perform validation) then getting the validation performed at your ISP may be the next step… and if your ISP won’t do DNSSEC validation then you really have no other choice but to use a service like Google’s Public DNS services. Their DNSSEC validation is definitely far better protection than none at all!

Again, kudos to Google’s Public DNS team for taking this step and we look forward to the day when all DNS resolvers just perform DNSSEC validation automatically.

The post Confirmed – Google’s Public DNS Now Performs DNSSEC Validation For ALL Queries By Default appeared first on Internet Society.

Jul 20

Have You Checked Out This Online IPv6 Training?

Are you looking to learn what IPv6 is all about?  Would you like to understand the basics of how IPv6 addresses work?  If so, the 6Deploy project has put some great video tutorials online at:

http://www.6deploy.eu/e-learning/english/

As we mention on our resource page about the training, the seven sections of the course cover the basics of IPv6, the construction of IPv6 addresses and headers, security issues, mobility/routing issues and suggestions for co-existence with IPv4.  If you have a few minutes to watch these videos, you may find them a quick way to start your learning about IPv6:

6DEPLOY training

P.S. The 6Deploy project also has a great set of IPv6 tutorials that you may find helpful.

The post Have You Checked Out This Online IPv6 Training? appeared first on Internet Society.

Apr 18

Where Are The IPv6-Only Wi-Fi Routers And Access Points?

Question ?In trying to set up an IPv6-only Wi-Fi network for a test environment in my home office, I ran across an interesting stumbling block:

You can’t turn IPv4 OFF on typical Wi-Fi access points or routers!

Now, this does make a certain degree of sense for consumer-grade equipment.  Providing such a setting is simply one more thing for someone to mess up – and generate support calls into the router manufacturer about how they can’t get on the network, can’t access email, etc., etc.  So I get it… the consumer equipment manufacturers are operating on commodity margins and need to minimize support inquiries.

It may also be quite honestly that… no one has asked for it!  We’ve been living in a world where IPv4 was the only option for so long that equipment product managers may not even be thinking about the desire for an IPv6-only Wi-Fi network.  “Why would you ever want to do that?”

But I do want to do that – and I imagine I’m not alone among those of us working on deploying IPv6. I want a Wi-Fi test network that is IPv6-only. No IPv4 at all.  Just IPv6… which then lets me connect to an IPv6 server and experiment with various different transition technologies.  Plus I get to see which apps work in an IPv6-only environment and which don’t.  I want a Wi-Fi network to experiment and play in the land of pure IPv6.

However, in searching online and looking through documentation of various Wi-Fi routers and access points, I’ve yet to find any off-the-shelf routers/APs that allow IPv4 to be disabled on an interface.

Yes, multiple people have suggested that I could hack the OpenWRT or DD-WRT code to roll my own AP without IPv4… and yes, I certainly could, and maybe that winds up being my only choice, but I’d personally rather hack on other projects than my Wi-Fi infrastructure.  However, that may be what I do.

Have any of you seen Wi-Fi routers or access points where you could disable IPv4 on the Wi-Fi network and only use IPv6?  Even better, an AP that lets me create multiple networks and have one of them be IPv6-only?

Or have any of you already hacked OpenWRT or similar code to be IPv6-only?

I’d love to hear what options folks have found (and would love to publicize them here).

Image credit: a_ninjamonkey on Flickr

The post Where Are The IPv6-Only Wi-Fi Routers And Access Points? appeared first on Internet Society.