Speaking of Standards

Did you know that Apple’s “Back To My Mac” service uses IPv6? Or that it sets up its encrypted tunnels using IPSEC and uses dynamic DNS?

Those are just a few of the fascinating pieces of info in an Internet-Draft that just recently (March 10) issued a new version:

http://tools.ietf.org/html/draft-zhu-mobileme-doc

As the abstract notes:

This document describes the implementation of Apple Inc.’s Back to My Mac (BTMM) service. BTMM provides network connectivity between devices so that a user can perform file sharing and screen sharing among multiple computers at home, at work, or on the road. The implementation of BTMM addresses the issues of single sign-on authentication, secure data communication, service discovery and end- to-end connectivity in face of Network Address Translators (NAT) and mobility of devices.

The introduction of the document gives an overview of what is inside:

Apple Inc.’s Back to My Mac (BTMM) service was first shipped with MAC OS X 10.5 release in October 2007, since then it has been widely used. BTMM provides an integrated solution to host mobility support, NAT traversal, and secure end-to-end data delivery through a combination of several existing protocols and software tools instead of designing new protocols. Note that we generally refer to Network Address Port Translation (NAPT) as NAT in this document. This document describes the implementation of BTMM and we hope the reader find it informative.

BTMM provides secure transport connections among a set of devices that may be located over a dynamic and heterogeneous network environment. Independent from whether a user is traveling and accessing the Internet via airport WiFi, or staying at home behind a NAT, BTMM allows the user to connect to any of Mac hosts with a click, after which the user can share files with remote computers or control the remote host through screen sharing. When a user moves around and changes locations and hence the IP address of his computer (e.g. roaming around with a laptop and receiving dynamically allocated IP address), BTMM provides a means for the roaming host to update its reachability information to keep it reachable by the user’s other Mac devices. BTMM maintains end-to-end transport connections in the face of host IP address changes through the use of unique host identifiers. It also provides a means to reach devices behind a NAT.

BTMM achieves the above functions mainly by integrating a set of existing protocols and software tools. It uses DNS-based Service Discovery [DNS-SD] to announce host reachability information, dynamic DNS update [RFC 2136] to refresh the DNS resource records (RRs) when a host detects network changes, and DNS Long-lived Queries (LLQ) [DNS-LLQ] to notify hosts immediately when the answers to their earlier DNS queries have changed. BTMM uses IPv6 Unique Local Address(ULA) [RFC 4193] as the host identifier, and employs the NAT Port Mapping Protocol (PMP) [NAT-PMP] to assist NAT traversal. It uses Kerberos [RFC 4120] for end-to-end authentication, and uses IPsec [RFC 4301] to secure data communications between two end hosts.

What I immediately found fascinating was the usage of IPv6 Unique Local Addresses (ULA – defined in RFC 4193). Think of the IPv6 ULA space as essentially like the IPv4 RFC1918 private address space (10.x, 192.168.x, etc.). A big block of IP addresses that are not publicly routable. They are designed to be used inside of a site or private network.

In effect, that’s what Apple is doing… creating a secure, encrypted IPv6 tunneled network between your devices and Apple’s servers. The document dives into great detail about how the Back To My Mac (BTMM) service works using tunneling, dynamic DNS, NAT traversal, IPSEC and more.

If you’re an Apple user or are just interested in network technologies and/or IPv6, the document is definitely worth a read!

Kudos to the team involved for all the work they put into creating this truly fascinating document.

Related to the RTCWEB BOF coming up at IETF 80 at the end of the month, Cullen Jennings at Cisco just submitted an interesting Internet-Draft:

http://tools.ietf.org/html/draft-jennings-rtcweb-api

The abstract is:

Internet browsers and other software applications are enabling support for real time interactive voice and video. This draft outlines a set of IETF protocols that can be used for this purpose and describes the overall architecture. It also identifies the requirements for an application programming interface to control these protocols.

Cullen then offers this overview:

This draft describes two models of how this would work, which are referred to as the advertisement proposal (AdProp) model and the offer answer (OffAns) model. Both of these models are useful in various situations, and they involve very similar code development efforts. This draft proposes an API and protocol set standardization that supports both models.

He provides a couple of use cases and then dives down into establishing a set of requirements:

The section defines the set of protocols and selected subset profiles of these protocols that a browser would need to implement, and forms the requirements for the API to control these protocols. At a high level we split this into connection management, transports for real time media such as audio and video, transports for non media data, codecs support, and signaling protocols.

Cullen then goes on to walk through a number of different protocol proposals, security issues and much more.

As I mentioned before, the RTCWEB initiative is a very important one in terms of ensuring that we do wind up with a standard way for browsers to connect to services using protocols such as SIP. I’d encourage you to take a look at his draft and send comment back either directly to Cullen and/or to the RTCWEB mailing list.

Given my background in security, I’ve been asked a number of times… why didn’t the IETF or someone just mandate ONE way to secure audio or video sent via RTP? After all, RTP by itself does not have any real security built-in and while Secure RTP (SRTP) is increasingly used, it’s not universal.

I’m obviously not alone in being asked this question, and Colin Perkins and Magnus Westerlund at the IETF wrote up an Internet-Draft that was recently approved to be an Informational RFC on just this topic:

Why RTP Does Not Mandate a Single Security Mechanism
http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory

From the introduction:

The Real-time Transport Protocol (RTP) [RFC3550] is widely used for voice over IP, Internet television, video conferencing, and various other real-time and streaming media applications. Despite this, the base RTP specification provides very limited options for media security, and defines no standard key exchange mechanism. Rather, a number of extensions are defined to provide confidentiality and authentication of RTP media streams and RTCP control messages, and to exchange security keys. This memo outlines why it is appropriate that multiple extension mechanisms are defined, rather than mandating a single security and keying mechanism.

The document goes on to list where RTP is use and issues with various security mechanisms (including SRTP). If you ever wondered why everyone doesn’t just use SRTP… this short document may be well worth the read.

Want to implement Skype’s SILK super wideband audio codec? You know, the software that makes Skype’s audio calls sound so rich and like you are “right there”?

If so, just check out Appendix A of this massive Internet-Draft:

http://tools.ietf.org/html/draft-vos-silk

Coming in at 566 pages, this I-D is what the word “ginormous” was meant for… but if you look closer, you’ll see that the first 26 pages describe the SILK codec and provide the usual IETF language. The remaining 540 pages are the C source code for a reference implementation of SILK!

This is part of the work of the IETF’s “CODEC Working Group” (see “MOVING INTO THE IETF” below) to standardize on a new wideband audio codec and essentially upgrade the audio quality of the Internet. Let me lay out some background…

LAUNCHING SILK

Last year at eComm 2009, Skype’s Jonathan Christensen announced the SILK codec and that it was being released for free licensing to third-party software and hard developers. Skype made available a developer site focused on the codec:

https://developer.skype.com/silk

Christensen trumpeted these items as the strengths of SILK:

• improving audio bandwidth going from 8 kHz to 12 kHz, meaning that a SILK conversation sounds like you are in the same room as the person you are speaking with
• providing real-time bandwidth scalability to deal with degraded network conditions
• balancing codec optimization between voice, music and background noise, each of which can have an impact on the overall user experience
• delivering a robust solution that delivers a more consistent audio experience, regardless of network conditions and an individual user’s voice signature

You can watch his eComm announcement here:

or view his slides here:

As a heavy user of Skype, I can personally attest to the fact that the SILK codec, available in all the latest versions of Skype, really does provide an outstanding audio experience.

MOVING INTO THE IETF

With the SILK codec available, folks at Skype started to look at how the codec could be made an open standard so that more folks would implement it. In May 2009, Skype’s Jason Fischl started a discussion around forming a new IETF working group to produce a standardized wideband audio codec. Much discussion and several meetings followed that did lead to the creation of the CODEC Working Group within the IETF. The group, created in January 2010 and co-chaired by Peter Saint-Andre and Michael Knappe, is open to the public – anyone can join the mailing list – and the problem statement is very clear:

According to reports from developers of Internet audio applications and operators of Internet audio services, there are no standardized, high-quality audio codecs that meet all of the following three conditions:

1. Are optimized for use in interactive Internet applications.

2. Are published by a recognized standards development organization (SDO) and therefore subject to clear change control.

3. Can be widely implemented and easily distributed among application developers, service operators, and end users.

There exist codecs that provide high quality encoding of audio information, but that are not optimized for the actual conditions of the Internet; according to reports, this mismatch between design and deployment has hindered adoption of such codecs in interactive Internet applications.

There exist codecs that can be widely implemented and easily distributed, but that are not standardized through any SDO; according to reports, this lack of standardization and clear change control has hindered adoption of such codecs in interactive Internet applications.

There exist codecs that are standardized, but that cannot be widely implemented and easily distributed; according to reports, the presence of various usage restrictions (e.g., in the form of requirements to pay royalty fees, obtain a license, enter into a business agreement, or meet other special conditions imposed by a patent holder) has hindered adoptions of such codecs in interactive Internet applications.

According to application developers and service operators, an audio codec that meets all three of these would: (1) enable protocol designers to more easily specify a mandatory-to-implement codec in their protocols and thus improve interoperability; (2) enable developers to more easily easily build innovative, interactive applications for the Internet; (3) enable service operators to more easily deploy affordable, high-quality audio services on the Internet; and (4) enable end users of Internet applications and services to enjoy an improved user experience.

Now, here is a critical point:

The CODEC Working Group is *NOT* just about Skype’s SILK codec!

The CODEC WG is working to identify and standardize a wideband audio codec that could be widely used over the Internet. Skype’s SILK codec is one of the potential codec candidates, as shown on this matrix of codecs from the CODEC WG. Another strong contender is the CELT codec from the Xiph.org team. There is a Internet-Draft out now for discussion that specifies the requirements for a standardized codec:

http://tools.ietf.org/html/draft-ietf-codec-requirements

The goal of the CODEC WG is to either identify an existing codec that meets those requirements or create a new codec. Either way, the goal is to have a standardized high quality audio codec that we can all use.

For those interested, the CODEC working group will be holding its first official face-to-face meeting at IETF 77 in Ananheim, California, on March 22nd. A draft agenda has been posted.

SKYPE’S SILK SOURCE CODE

So back on Monday, March 8, a new version of the SILK Internet-Draft was published and announced on the codec mailing list. As the draft notes:

The source code for the reference implementation of the SILK codec is provided in Appendix A. This fixed-point source code is the normative specification of the codec. The corresponding text description in this document is provided for informative purposes. For more information about SILK, the patent licensing terms, and to download the source code in a convenient format, please visit [silk-website]. For any additional questions, please send an email to SILKSupport@skype.net.

This particular phrase is interesting and amusing to me:

This fixed-point source code is the normative specification of the codec.

I translate that as “the source code is the specification”.

If you do read the source code, you see Skype’s license on the code is rather open:

Copyright (c) 2006-2010, Skype Limited. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, (subject to the limitations in the disclaimer below)
are permitted provided that the following conditions are met:
- Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
- Neither the name of Skype Limited, nor the names of specific
contributors, may be used to endorse or promote products derived from
this software without specific prior written permission.
NO EXPRESS OR IMPLIED LICENSES TO ANY PARTY'S PATENT RIGHTS ARE GRANTED
BY THIS LICENSE.THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS ''AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Essentially it is a Skype version of the permissive “Simplified BSD License“, which I would summarize as a non-lawyer as essentially “keep the copyrights intact, don’t use Skype’s name for endorsement, and Skype is in no way responsible if bad things happen from using this code”.

Still to be seen is if there are any additional licensing terms from Skype, but overall this is a great step forward for those of us who want to see better overall audio quality on the Internet. Obviously it’s in Skype’s interest to do this so that the CODEC WG might consider SILK as the codec to standardize on versus the others or creating a new one… but still… it’s great to see. What do you all think?

FYI, a new version -08 of my P-Charge-Info Internet-Draft is now available:

http://www.ietf.org/id/draft-york-sipping-p-charge-info-08.txt

For an understanding of what P-Charge-Info is all about, read why I first wrote it, P-Charge-Info and incredible disconnect between PSTN billing and the new world of SIP, and then my update last year on the -07 draft.

Version -08 really only has a minor tweak to the ABNF notation for the “npi-value” and then a new Appendix A clarifying the npi-values and their relation to ANSI T1.113.

I am hoping that I can very shortly request IESG consideration to move this document along the path to being an RFC. The only remaining issue is that my co-author, Tolga Asveren, has brought forward a proposal for simplifying the parameters a bit. I’ve forwarded that proposal to several people I know are very interested in this draft. We’ll see where it goes from there. I’d very much like to move this along soon, so we’ll see.

As someone writing Internet-Drafts for submission to the IETF, collaborating with co-authors always involves some challenges. Do you send the txt or XML around to co-authors in an email? Do you put them on a website? Do you try to use a version control system? Mostly with my co-authors we wind up shipping docs around via email… but whose is the most authoritative? Who has the master?

To try to help a bit on my own end, I’m trying out using Github to post my files in a public git repository. For those wise in the ways of git, the repo is at:

http://github.com/danyork/internet-drafts-york

Those who don’t know what I’m talking about might want to check out the two git tutorial videos I did earlier this year (and yes, I still need to post part #3).

Now I’m not sure git is the ideal tool for this task. The problem with Internet-Drafts is that the file name changes between versions. So one version is:

draft-york-sipping-p-charge-info-05.xml

and then when I want to do some edits to the doc to submit the next version, it needs to be renamed:

draft-york-sipping-p-charge-info-06.xml

In order for only the most recent file to be in the repo, yet still have the history intact, what it seems I need to do is use the git mv command to move the file from one name to another. So it’s basically:

git mv filename1 filename2
git commit -a

Write your commit message, and then naturally push to Github so that it has the most recent. Now I need to do this mv before I start editing it.

I also haven’t started using this with any co-authors yet. Mostly right now I’ve been working through how I will personally use it. However, the good news is that with having all the files in a repo, I can easily do a diff against what I have and what a co-author has. By using Github, I also have a backup of all the files out “in the cloud”. And mostly, I can point people to a development version of a file before it’s been formally submitted to the IETF.

I’m still working through this process… it’s definitely still an experiment. Stay tuned as I write more about what I find out. (And if you are an I-D author and have any great comments about how you manage your Internet-Drafts, I’d enjoy hearing them, too.)

This morning I submitted a new version -07 of P-Charge-Info. Not much changed in the draft. Primarily I updated the IPR language to use the language of the IETF Trust as of February 2009 and added a reference pointing to RFC 3968.

The P-Charge-Info draft has been rather delayed on its path to becoming an Informational RFC primarily because just as I was about to request “expert review” per the process in section 4.1 of RFC 3427, the SIP and SIPPING working groups decided to revisit RFC 3427 and restructure how changes are made to SIP in general.

The result has been “RFC 3427bis”, a.k.a. draft-peterson-rai-rfc3427bis and section 4 defines a new lighterweight process for registering SIP headers. (Well, it speaks of a “Designated Expert” process, but my criticism of the existing draft is that it doesn’t easily explain what someone has to do to register a new SIP header.) While this RFC3427bis draft has not been ratified as an RFC, the RAI area is proceeding as if it has been and has already replaced the SIP and SIPPING working groups with SIPCORE and DISPATCH.

At this point I’m done with P-Charge-Info in that I’ve incorporated all comments that people have had and all I am looking to do now is move it through the end of the process to an Informational RFC. I will be contacting the RAI Area Directors shortly to sort out exactly what the next step is to get this moving along. In my ideal world, I’d like to see this published by the end of this calendar year.

I do, though, still welcome comments, so if you have any please feel free to pass them along.

P.S. For info about why I originally wrote this draft, see “P-Charge-Info and incredible disconnect between PSTN billing and the new world of SIP

Long-time readers will know that I have a fascination with the ideas behind P2PSIP, which I explained once before in a post “P2PSIP and pushing voice down into local clouds”. While it has very little directly to do with my work here at Voxeo, I’ve continued to help a team of folks with the IETF who are working on an Internet-Draft providing an overview of the security concerns related to P2PSIP.

Given the upcoming IETF 75 meeting, I published an updated version of the Internet-Draft last week. It is available at:

http://tools.ietf.org/html/draft-matuszewski-p2psip-security-requirements

Those of you interested in SIP, P2P networks or security in general may find it of interest. Here’s the abstract:

This document provides a security overview and analysis for the Peer- to-Peer Session Initiation Protocol (P2PSIP) overlay network. It discusses security threats for the P2PSIP architecture and its components. It compares security difference between client/server (C/S) and P2P implementations of SIP, and then partitions the P2PSIP architecture into layers and analyzes the security issues in each layer and the security relationship among the layers.

My particular contribution in this revision was writing a new section on “Interconnection to other networks“. Many, if not most, P2PSIP networks will want to interconnect with the legacy PSTN or with other SIP networks. This section takes a look at what the security ramifications are and what an implementor of a P2PSIP network should consider.

Comments and feedback about this draft are of course welcome. At IETF75 in Stockholm I know that members of the author team will be asking the P2PSIP Working Group to accept this as a “working group document” (another step on the path to becoming a RFC) and there will undoubtedly be further revisions of the document.

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook or following us on Twitter.

Technorati Tags: sip, p2p, p2psip, security, ietf, standards

As I worked late last week on a new revision of the P2PSIP security overview Internet-Draft of which I am a co-author, I wound up learning of a wonderful hosted tool provided by the IETF called “Idspell”:

http://tools.ietf.org/tools/idspell/idspell.pyht

All you do is upload a text version of your I-D and… ta da… it goes through and checks the spelling in your draft. What’s great about Idspell versus the standard spell-checker in any editor, is that it has been preloaded with IETF-specific info. On the IETF Tools page it says:

Idspell uses an IETF-specific wordlist built from the last 2 years’ published RFCs, surnames of recent I-D authors and some manually added words.

It’s just one of many tools that have been made available to help authors more easily create Internet-Drafts. Very useful!

P.S. For those curious to see the latest version of the P2PSIP security overview Internet-Draft, I’m trying an experiment in using Github as a repository for my I-Ds. You can find them there at http://github.com/danyork/internet-drafts-york/tree/master

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook or following us on Twitter.

Technorati Tags: IETF, standards, Internet-Drafts

What are the components of a “peer-to-peer (P2P)” network? What are the different types currently available? When does it make sense to consider using a P2P architecture?

Given the intense amount of interest in P2P networking these days, the Internet Architecture Board recently came out with a new Internet-Draft, draft-iab-p2p-archs, on “Peer-to-peer (P2P) Architectures” that aims to help provide answers to these types of questions. Here’s the introduction:

P2P (Peer-to-peer) systems have received a great deal of attention in the last few years. A large number of scientific publications investigate different aspects of P2P systems, several scientific conferences explicitly focus on P2P networking, and there is an IRTF (Internet Research Task Force) Research Group (RG) on P2P systems (the Peer-to-Peer RG). There are also several commercial and non- commercial applications that use P2P principles running on the Internet. Some of these P2P applications are among the most widely used applications on the Internet at present.

However, despite all the above, engineers designing systems or developing protocol specifications do not have a common understanding of P2P systems. More alarming is the fact that many people in the telecom and datacom industries believe that P2P is synonymous with illegal activity, such as the illegal exchange of content over the Internet or P2P botnets.

The goal of this document is to discuss the tradeoffs involved in deciding whether a particular application can be best designed and implemented using a P2P paradigm or a different model (e.g., a client-server paradigm). The document also aims to provide architectural guidelines to assist in making such decisions. This document provides engineers with a high-level understanding of what defines a P2P system, what types of P2P systems exist, the characteristics that can be expected from such systems, and what types of applications can be implemented using P2P technologies. Such understanding is essential in order to appreciate the tradeoffs referred to above. In addition, we stress the importance of the fact that P2P systems can be used to implement perfectly legitimate applications and business models by providing several examples throughout the document.

Given my own long-standing personal interest in P2P networks (some of which I’ve written about here), I was pleased to see this document come out. Anything that helps improve the overall understanding out there of P2P systems is, in my opinion, a good thing.

The draft is still undergoing some revisions (and I know the authors would welcome further comments) and I believe a new version will be coming out soon. The latest version should always be able to be found at:

http://tools.ietf.org/html/draft-iab-p2p-archs

If you found this post interesting or helpful, please consider either subscribing via RSS or following on Twitter.