Category: IETF

Nov 04

Deploy360@IETF88: Day 1 – 6Man and v6OPS

IETF LogoOur first day here at IETF88 is a quieter day for us on the Deploy360 team in terms of the number of sessions but  today’s sessions are two of the biggest in terms of content related to our work with IPv6.   The “6man” working group is focused on the “maintenance” of IPv6 and continuing the evolution of the IPv6 protocol.  The 6man agenda is FULL of talks about suggested fixes and improvements – and should generate some good discussion and actions.

Similarly, today’s “IPv6 Operations” (v6ops) sessions has what should be very interesting discussions:

Xbox One and Teredo
Balanced Security for IPv6 Residential CPE
An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices
NAT64 Operational Experiences
Recommendations of Using Unique Local Addresses
464XLAT CLAT IPv4 Address

Information about the two sessions today is here, including the links for the audio streams, the slides and the Jabber chat rooms:

For these sessions and all the others, the “tools-style agenda” for IETF 88 provides many helpful links for remote participants.

If you’d like to meet with the Deploy360 team here at IETF88, please see our post about where we’ll be at IETF88.

An audio version of this post is also available:

Nov 04

Meet The Deploy360 Team At IETF 88 In Vancouver This Week

IETF LogoThe 88th meeting of the Internet Engineering Task Force (IETF) takes place this week in Vancouver, BC, and Megan Kruse and myself (Dan York) will be there participating in Working Group sessions, recording some video interviews, helping with the live video stream of the IETF 88 Technical Plenary and the ISOC@IETF panel on IPv6 and just generally meeting with people about how we accelerate the deployment of IPv6, DNSSEC and routing technologies!

If you’d like to meet with us at IETF 88, the best bet is to probably send an email to:

deploy360@isoc.org

as that gets to both of us and the rest of the team.  As to where you can find us at IETF 88, you can expect to find Megan and I in most of the sessions related to IPv6, DNSSEC or routing resiliency/security.  Here are some of the prime ones where one or both of us will be:

You can also expect us to be in other sessions where IPv6 or DNS or routing security are mentioned.  We’re around and we’d definitely be interested in meeting with people while here.  Please do drop us an email message or find us in person.

Nov 01

4 Sessions About DNSSEC, DNS And DANE At IETF 88 Next Week

IETF LogoNext week IETF 88 in Vancouver will be a bit quieter on the DNSSEC and DANE front.  As I wrote in a post today on our “Internet Technology Matters (ITM)” blog, “Rough Guide to IETF 88: DNSSEC, DANE and DNS“, the only major working group related to DNSSEC that will be meeting will be the DNSOP WG on Tuesday, November 5th.  However, in that meeting there will be the very big topic of how we automate the transfer of updated DS / DNSKEY records from a child zone up to a parent zone within DNS.  There are  a couple of different proposals that will be discussed, including:

It should be an excellent discussion.  As I wrote in the ITM post, there are several other interesting drafts as well being discussed in DNSOP – all focused around improving the operations of DNSSEC.  It should be a great session at IETF!

The DANE Working Group is not meeting but as I mentioned in the other article I expect that DNSSEC / DANE will come up in some of the many conversations that will be going on next week related to how we harden the Internet against large-scale surveillance and pervasive monitoring.  The Technical Plenary on Wednesday, November 6, should be an excellent event well worth listening to.   The “Perpass” BOF session will dive into more details. I don’t know if DNSSEC / DANE will be discussed there… but it certainly could be.

The DNS-SD Working Group discussion could also be quite interesting because as you extend DNS service discovery beyond a simple local network into a multi-network environment, you need to have some way to securely communicate that information.  We’ll see what is begin talked about in that regard.

Anyway, here are four of the sessions where DNSSEC / DANE / DNS will be discussed – you can expect to find me in all of them:

NOTE: If you are not going to be in Vancouver next week, there are multiple ways that you can participate remotely in these working groups, including audio streams and Jabber chat rooms.

Oct 31

7 Of The Many Sessions About IPv6 Next Week At IETF 88

IETF LogoThe great news for IPv6 advocates about IETF 88 in Vancouver next week is that IPv6 is everywhere! All throughout the IETF 88 agenda you can find IPv6 in various different groups.  IPv6 is definitely “the new normal” and that shows!

Our colleague Phil Roberts posted today “Rough Guide to IETF 88: All About IPv6” where  he highlights the major working groups that are tackling IPv6 topics.  There is a great amount of activity going on and Phil’s post gives a good sense of the range of work.  You can expect to find our Deploy360 team in pretty much all of these working groups monitoring what’s going on and contributing where appropriate.

To Phil’s excellent list of Working Group sessions related to IPv6 I’d add only one more that is important from a deployment/operationalization point of view.  The OPSEC Working Group has two drafts on its agenda that are both focused on IPv6 security.  With that, here is a list of some of the major groups doing IPv6 work next week… as I mentioned, you wind up finding IPv6 across all the many different groups, but here are some of the major ones.

NOTE: If you are not going to be in Vancouver next week, there are multiple ways that you can participate remotely in these working groups, including audio streams and Jabber chat rooms.

Oct 30

4 Sessions About Routing Resiliency/Security At IETF 88 Next Week

IETF LogoNext week at IETF 88 in Vancouver the topic of routing resiliency/security will be covered in a variety of different working groups.  Our colleague Andrei Robachevsky outlined what will be covered in a post on the “Internet Technology Matters (ITM)” blog: Rough Guide to IETF 88: Routing Resilience.   We’re looking forward to those sessions and you can expect to find me in most of them.  My particular interest is in what is happening within SIDR right now, but in truth all of them should be interesting.

I’d strongly suggest reading Andrei’s post to understand what’s going to be going on with routing.  Here are the relevant working groups and times.

NOTE: If you are not going to be in Vancouver next week, there are multiple ways that you can participate remotely in these working groups, including audio streams and Jabber chat rooms.

Jul 29

Can We Create A "Secure Caller ID" For VoIP? (Join Tomorrow’s STIR BOF To Learn More)

Can we create a "secure Caller ID" for IP-based communications, a.k.a. voice-over-IP (VoIP)? And specifically for VoIP based on the Session Initiation Protocol (SIP)? Can we create a way to securely identify the origin of a call that can be used to combat robocalling, phishing and telephony denial-of-service (TDOS) attacks?

That is the challenge to be undertaken by the "Secure Telephone Identity Revisited (STIR)" group meeting tomorrow morning, July 30, 2013, at 9:00 am in Berlin, Germany, as part of the 87th meeting of the Internet Engineering Task Force (IETF). The meeting tomorrow is a "Birds Of a Feather (BOF)", which in IETF language is a meeting to determine whether there is sufficient interest to create a formal "working group" to take on a new body of work within the IETF. The proposed "charter" for this new work begins:

Over the last decade, a growing set of problems have resulted from the lack of security mechanisms for attesting the origins of real-time communications. As with email, the claimed source identity of a SIP request is not verified, and this permits unauthorized use of source identities as part of deceptive and coercive activities, such as robocalling (bulk unsolicited commercial communications), vishing (voicemail hacking, and impersonating banks) and swatting (impersonating callers to emergency services to stimulate unwarranted large scale law enforcement deployments). This working group will define a deployable mechanism that verifies the authorization of the calling party to use a particular telephone number.

The agenda for tomorrow's STIR meeting begins with a presentation by Henning Schulzrinne, now CTO of the US Federal Communications Commission (FCC) but also a long-time IETF participant and one of the co-authors of the original RFC 3261 specification for SIP. Henning will be laying out the problem statement and there will be a discussion of the proposed scope of the IETF work. He'll be followed by presentations of potential solutions by Jon Peterson, Eric Rescorla and Hadriel Kaplan and then a discussion of the proposed charter and the work to be done. Given the intense debate that has occurred on the STIR mailing list over the past weeks I expect tomorrow's session to be one where some points will receive a great amount of passionate debate and discussion. (If you are interested in listening in or participating remotely in tomorrow's STIR meeting, see the information later in this article.)

Revisiting Previous SIP Identity Work

As some background, the Internet Architecture Board (IAB) laid out some of the challenges to "secure origin identification" in IP-based communication last November and took a very high-level look at the overall issue. Next, in preparation for what became this STIR effort, Jon Peterson, Henning Schulzrinne and Hannes Tschofenig authored a draft problem statement and requirements document.

The "Revisited" part of the group name is a nod to the fact that this whole issue of asserting "identity" has been explored within the SIP community in the past. Way back in 2006, RFC 4474 defined what has been called "SIP Identity" and provided a method for cryptographically signing certain SIP headers to identify the origin of a call. Unfortunately, RFC 4474 turned out not to work well with the way SIP was actually deployed and so usage has been virtually non-existent. An effort to update that document, what is called "RFC4474bis", has also been proposed and some of those ideas may be incorporated into the new proposed work for the STIR group.

There have also been other efforts such as the "P-Asserted-Identity (P-A-I)" defined in RFC 3325. The challenge here, though is that theoretically P-A-I is supposed to be limited to usage within a trusted network, although in practice it may be seen by other networks. There have also been several efforts to define or document identifiers for billing purposes (including my own P-Charge-Info) although these efforts are trying to solve a slightly different problem.

The point here really is that the STIR effort is drawing upon a rich body of "SIP identity" work that dates all the way back to some early drafts in 2002. Much thought has been given to this issue and many of the people involved with STIR have also been involved with earlier efforts and understand well some of the challenges faced by that past work.

An Important Difference

One important difference between STIR and earlier "SIP identity" efforts is that initially the STIR effort is only focused on telephone numbers. The draft charter explicitly states this:

As its first work item, the working group will specify a SIP header-based authorization mechanism to verify the originator of a SIP session is authorized to use the claimed source telephone number, where the session is established with SIP end to end. This is called an in-band mechanism. The mechanism will use a canonical telephone number representation specified by the working group, including any mappings that might be needed between the SIP header fields and the canonical telephone number representation.

and later:

Expansion of the authorization mechanism to identities using the user@domain form deferred since the main focus of the working group is to develop a solution for telephone numbers.

Previous "identity" work was also undertaken to include a "SIP URI" or "SIP address" and while the ultimate STIR mechanism (or a variant thereof) might also work for SIP URIs, the focus in this initial work is all around securing the origin identification of telephone numbers.

This initial focus makes a great amount of sense given that so much of the SIP traffic today is a result of telecom service providers moving their regular calls to telephone numbers off of the legacy PSTN networks and over to IP networks where they use SIP. Additionally, a great amount of the "problem" traffic seen in VoIP today can be created by attackers who use simple VoIP software to generate their calls to regular telephone numbers.

Remotely Participating In Tomorrow's STIR BOF

If you are interested in participating in the meeting (or at least listening in) on Tuesday, July 30, the meeting will go from 9:00 - 11:30 local time in Berlin, Germany. Berlin is in Central European Summer Time (CEST) which is UTC+2 (and 3:00 am US EDT / midnight US PDT for my friends back in the USA).

You can hear the audio stream at:

You can also join the Jabber chat room at:

The slides and other meeting materials can be found at (and note that materials may not be uploaded until shortly before the session and so you may need to refresh your browser):

Alternatively you can use the "MeetEcho" conferencing system that integrates the audio, the slides and the Jabber chat room at:

More information about participately remotely can be found on the IETF 87 Remote Participation page.

To get the most out of the meeting, you'll also want to read these three Internet Drafts that will be part of the solutions being discussed:

.... and be prepared for what should be a LIVELY discussion!

If you are unable to participate remotely, the session will be recorded and you will be able to listen to the archived audio stream, view the Jabber chat logs and also playback the MeetEcho recording.

Getting More Involved

Beyond listening to tomorrow's BOF session, the best way to get involved - either to actively participate or to at least monitor the effort - is to join the STIR mailing list at:

https://www.ietf.org/mailman/listinfo/stir

The list is open to anyone to join. There are no membership or corporate requirements or fees - anyone with an email address may participate.

WARNING! - As can be seen in the list archive, there is currently a large volume of discussion and it will probably continue for some time. If you do join the mailing list you may want to consider setting up rules to sort the STIR email into a folder - or just prepare for the volume to be added to your inbox.

The other way to be involved is to monitor and read the documents that are created for the STIR effort. Newer documents are being created with "stir" in the document name and so they can be easily found at:

http://datatracker.ietf.org/doc/search/?name=stir&activedrafts=on

Other documents that are useful to understand this effort are linked to earlier in this article and can also be found in the text of the proposed STIR charter. After tomorrow's STIR BOF session there will be more information about how the effort will proceed within the IETF. The meeting tomorrow should result, I expect, in the recommendation to go ahead with formally creating a working group and undertaking this work, but we'll see what outcome occurs.

Can a method of secure origin identification for SIP-based VoIP calls be created? Given that basically all telecom traffic is in the process of moving to be based on IP, the need for a secure origin identifier is very clearly here - and many of us do believe we can develop a system that will work in today's environment.

What do you think? Are you ready to join in and help?

Update: Added the additional charter text about "Expansion of the authorization mechanism to identities..."

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

Jul 29

Reminder – Opus Codec Presentation Streaming LIVE From IETF 87 in 2 Hours

Opus codec logoWant to learn more about the Opus codec and why it is so important? As I mentioned at the end of my last post about why Opus matters, there will be a special presentation about Opus as part of the IETF 87 Technical Plenary happening in about 2 hours starting at around 17:45-18:00 in Berlin, Germany (Central European Summer Time, UTC+2, 6 hours off of US Eastern time).

There are three options for watching and participating live:

The technical plenary begins at 17:40 but there are some other reports before the Opus section. The agenda can be found online and includes:

1. IAB Chair Report
2. IRTF Chair Report
3. RSE and RSOC Chair Report
4. Technical Topic: Opus Codec
a. Introduction
b. Overview of Opus
c. Testing
d. History of Opus in the IETF
e. Opus Deployment Panel
f. Future Work
5. Open Mic

I suspect that the Opus session will begin closer to 18:00 local time, but you can tune in around 17:40 to see the start of the session.

It should be quite an interesting session!

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

Jul 26

Why The Opus Codec Matters – Even If You Don’t Care About Audio

Opus codec logoWhat makes the Opus codec so interesting? Why is there such a buzz about Opus right now? If you are not in telecom or doing anything with audio, why should you even remotely care about Opus?

In a word...

Innovation!

And because Opus has the potential to let us communicate with each other across the Internet with a richer and more natural sound. You will be able to hear people or music or presenters with much more clarity and more like you are right there with them.

Opus can help build a better user experience across the Internet.

You see, the reality is that today "real-time communication" using voice and video is increasingly being based on top of the Internet Protocol (IP), whether that communication is happening across the actual Internet or whether it is happening within private networks. If you've used Skype, Google+ Hangouts, any voice-over-IP (VoIP) softphones, any of the new WebRTC apps or any of the mobile smartphone apps that do voice or video, you've already been using IP-based real-time communication.

Dropping The Shackles Of The Legacy PSTN

Part of the beauty of the move to IP is that we no longer have to worry about the constraints imposed upon telecom by the legacy Public Switched Telephone Network (PSTN). Chief among those constraints is the requirement to use only part of the sound frequencies we can hear. You all know the "sound" of the telephone - and you hear it in any movie or TV show when someone is using the phone. It's that certain "sound" that we are all used to... that's what the "phone" sounds like.

In technical terms, we call this "narrowband" audio and it has a frequency range of only 300-3400 Hz.

There are historical reasons for this limitation in telecom, but moving to IP-based communications removes those limits. With VoIP we can use what is called "wideband" audio to have a full rich sound to our voice or video call.

Have you had a really good Skype connection with someone where it sounded like they were almost right there in the room with you?

That is wideband audio.

The Codec Problem

Now, for voice or video over IP to work, you need to use something called a "codec" to translate the sound of your voice to digital bits and carry them across the network (and to do the opposite for whomever you are speaking with). There are MANY audio codecs out there and they come in all sorts of flavors and with all different kinds of capabilities. The problem has been that there hasn't been a codec that:

  1. is optimized for interactive Internet applications;
  2. is published by a recognized standards organization; and
  3. can be widely implemented and easily distributed at little or no cost.

In particular that last point about the cost of licensing, especially for wideband codecs, often caused developers to shy away from giving us the rich voice quality that we can now have with IP. Or, in the case of companies like Skype or Google, they went out and bought companies who created wideband codecs so that they could use those codecs in their products. (See my story from 2010 about Google buying GIPS.)

Now there are free codecs out there that developers can use. For narrowband, there has been the ubiquitous G.711 which provides an IP version of "PSTN audio". There have been many others, including notably Speex.

But the struggle has been that there hasn't been a widely accepted "G.711 for wideband" equivalent that developers can just bake into their products and start using. Instead there have been a number of different, incompatible codecs used in different products.

Enter Opus...

So to address these points, back in 2010, engineers within the IETF got together and formed the CODEC Working Group to come up with a codec that could meet these requirements and become the ubiquitous wideband codec used across the Internet. Skype was involved early on through contributing their SILK codec. The folks at Xiph.org contributed their CELT codec. People from many other companies got involved and there were huge technical discussions on the mailing lists and at IETF meetings.

And it worked... the Opus codec was standardized in RFC 6716 in September 2012.

You can read all about the codec at:

http://www.opus-codec.org/

The key points are at the beginning:

Opus is a totally open, royalty-free, highly versatile audio codec. Opus is unmatched for interactive speech and music transmission over the Internet, but is also intended for storage and streaming applications.

Open, highly-versatile... and royalty-free.

At that site there is some great information, including:

There is also a FAQ and many other great pieces of information.

So Why Does Opus Matter?

Opus matters because it lets developers focus on creating a high quality user experience and not having to worry about codec incompatibilities and licensing issues.

Opus matters because it lets developers easily create applications with high quality audio. They can just start using available libraries and communicating with other applications and devices using a common wideband codec.

Opus matters because it can work in very low-bandwidth environments enabling real-time communications across Internet connections that might not previously have supported such communications. As we start to get more Internet connectivity out to the 5 billion people not yet on the Internet, the ability to work over different kinds of connections is critical.

Opus matters because it can help foster innovation in applications and the user experience. Opus is the default audio codec for WebRTC, and so all the zillion new WebRTC-based apps and startups are already beginning with a far superior audio experience than we've had before.

Opus matters because it will enable even more ways that we can connect with family members or friends and have the experience of being "right there". It can help musicians collaborate better across the Internet. It can help podcasters and journalists deliver higher quality interviews across the Internet. It can, in the best conditions, give us that rich audio experience we get when we are right with someone - even though we may be thousands of miles away.

Opus can help us deliver on the potential of the Internet to create more powerful user experiences and to help us better communicate.

THAT is why Opus matters.

Learn More At Monday's IETF 87 Technical Plenary

To understand more about the current status of Opus, who is using it and where it is going, the IETF 87 Technical Plenary on this coming Monday evening in Berlin, Germany, will have a special segment focused on Opus that will include a number of people involved with the Opus work. The agenda for the session can be found at:

http://trac.tools.ietf.org/group/iab/trac/wiki/IETF-87

It is happening from 17:40-19:40 Berlin time, which is Central European Summer Time, which is currently UTC+2 and 6 hours ahead of where I live in US Eastern time. If you can't be there in person, there are several remote options:

If you are unable to watch the meeting in real time it will be archived for later viewing.

The first option above to listen to the session using the Opus codec (and WebRTC!) is a very cool one. The panel also includes people who have actually implemented Opus including people from Google and also Emil Ivov from the Jitsi softphone. Their insight into what they did will be great to hear.

What's Next?

So if Opus is so great, how do you get it?

Well, if you are using any of the WebRTC apps popping up all across the Internet, you are already using Opus. As I noted above, the Jitsi softphone supports Opus. In an interesting bit of synchronicity, I noticed that Michael Graves wrote today about the Blink softphone now supporting Opus. More and more communications apps are starting to implement Opus.

If you are a developer of communications apps or services (or a product manager), you can look at how to incorporate Opus into your application or service. There is documentation and software available to help with the process, and many people are out there who can help.

If you are a user of IP-based communications apps or services, ask the company or vendor behind those services when they will support Opus. See if you can get it on their radar as something to implement.

And regardless of what you do with audio, let people know that this new way of communicating exists - help spread the word about Opus - let people know that audio across the Internet can be even better than it has been to date.

As you can tell, I'm excited about the potential - and very much looking forward to seeing what happens as Opus gets more widely deployed.

What do you think? If you are a telecom developer, or a vendor of such services, have you implemented Opus already? Are you thinking about it? (and if not, why not?)

An audio commentary on this post is available at:

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

Jul 25

IETF Journal – WebRTC: Moving Real-Time Communication into the Web Browser

Webrtc 2Seeking to understand the basics of WebRTC and why there is so much interest in it? There is a new July 2013 issue of the IETF Journal out this week that includes an article I wrote titled "WebRTC: Moving Real-Time Communication into the Web Browser" that looks at WebRTC from a high-level user perspective.

My aim with this IETF Journal article links was to summarize some of the links on my my WebRTC/RTCWEB page and is admittedly similar in style to my 2012 post, "How WebRTC Will Fundamentally Disrupt Telecom (And Change The Internet)", although this newer article focuses on the work happening within the IETF and provides links to get more involved.

On that note, the RTCWEB working group within the IETF will be meeting next week in Berlin (twice, actually) and has an agenda for IETF87 focused primarily on security questions and looking at the "data channel" aspect of WebRTC/RTCWEB. It should, as always, be an interesting session to listen in to.

If you can't get to Berlin, there are audio streams you can listen to remotely and a Jabber chat room where you can raise questions. Links to both can be found on the top of the agenda page. Do keep in mind that the times listed are local to Berlin, Germany.

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

Jul 25

“Rough Guide To IETF 87″ Now Available – IPv6, DNSSEC, Routing and much, much more…

IETF LogoNext week is the 87th meeting of the Internet Engineering Task Force (IETF), taking place this time in Berlin, Germany, and it will be an incredibly busy week as something like 1,200-1,500 engineers gather in a hotel meeting space to debate and discuss various topics and create the open standards that power the Internet.  There are many different working groups meeting during the week and the IETF 87 agenda can seem a bit overwhelming.  To help with that, as we’ve done in the past, the Internet Society has published our “Rough Guide to IETF 87″ available at:

http://www.internetsociety.org/rough-guide-ietf87

This document reflects our (Internet Society) interests and what we see as the important topics related to the technology priorities we have an an organization.  The working groups and events listed are ones where we have Internet Society staff participating or where the topic being covered is one of our priorities.

For instance, within our team here at Deploy360, we’ll be there in Berlin at the working groups related to:

  • IPv6
  • DNSSEC
  • Routing resiliency and security

Most of which, but not all, are captured in the Rough Guide.  As we noted in an earlier post about DNSSEC activities, there are two groups focused on DNSSEC and DANE that are of great interest to us.  There are a wide number of IPv6-related groups in which we’ll be participating and several groups related to routing resiliency and security.

If you are reading this page here on our Deploy360 site, hopefully the Rough Guide will help you understand where we will be spending our time.

There are, of course, a great many other working groups meeting next week at IETF 87 that are doing outstanding work in Internet infrastructure, applications, routing, security, real-time communications, network operations and so much more.  The full agenda for IETF 87 is an amazing list of all the great open standards work happening across the IETF!

NOTE: If you unable to attend IETF 87 in Berlin in person, there are numerous methods of remote participation that you will allow you to listen to what is going on and to provide comments.