Speaking of Standards

On Sunday night I head down to Philadelphia for the IETF-71 meeting for the whole week. It will be a crazy week full of discussions and conversations about all the various standards under development. The RUCUS BOF I’ve mentioned before will be on Monday as is the SIPPING Working Group. MEDIACTRL Working Group (of key interest to us here at Voxeo) is on Wednesday as is SPEERMINT and PEPPERMINT (Hey, it’s IETF, you have to have cute names!). Thursday brings SIP, BEHAVE, AVT and ENUM and Friday morning winds it all up with the P2PSIP working group.

Being who I am, I’ll pretty much sit in all of the “Realtime Applications and Infrastructure” (RAI) working groups as sometimes activity in one group turns out to have great relevance to work in other groups (or to work here at Voxeo). I’ll be online the Jabber chat rooms probably much of the whole time as well.

If you’ve never seen the full agenda for an IETF meeting, it’s pretty incredible (at least to me!). In any given timeslot there are typically eight simultaneous meetings of various working groups, BOFs, research groups, etc. This makes sense if you remember that the IETF is developing standards for pretty much all aspects of the Internet. While I usually never leave the world of RAI, there are groups dealing with security, DNS, email, IPv6, network routing, time (seriously!), host configuration and pretty much every other subject you can imagine relating to the Internet. Take a look!

And yes, the days do begin with a breakfast at 8am and meetings that go until 7pm (often with additional ad hoc meetings afterwards). The good news is that the breaks between sessions usually have food and drink to keep you recharged.

For those attending who wish to stalkfind me, here below is the agenda I think I’ll be following (subject to the fact that it can, of course, change). Like I said earlier, it’s pretty much all of the RAI area.

---

MONDAY, March 10, 2008
0800-0900 Continental Breakfast - Franklin Hall Foyer

0900-1130 Morning Session I

RAI

mmusic

Multiparty Multimedia Session Control WG

1300-1500 Afternoon Session I

RAI

rucus

Ruducing Unwanted Communications using SIP BOF

1520-1720 Afternoon Session II

RAI

ecrit

Emergency Context Resolution with Internet Technologies WG

1740-1950 Afternoon Session III

RAI

sipping

Session Initiation Proposal Investigation WG

TUESDAY, March 11, 2008
0800-0900 Continental Breakfast - Franklin Hall Foyer

0900-1130 Morning Session I
One of these:

IRTF	rrg	Routing Research Group
OPS	v6ops	IPv6 Operations WG
RAI	geopriv	Geographic Location/Privacy WG

1300-1500 Afternoon Session I

RAI

bliss

Basic Level of Interoperability for SIP Services WG

1520-1720 Afternoon Session II

RAI

avt

Audio/Video Transport WG

1740-1840 Afternoon Session III
One of these:

IRTF	asrg	Anti-Spam Research Group
RAI	simple	SIP for Instant Messaging and Presence Leveraging Extensions WG

1850-1950 Afternoon Session IV

RAI

xcon

Centralized Conferencing WG

WEDNESDAY, March 12, 2008
0800-0900 Continental Breakfast - Franklin Hall Foyer

0900-1130 Morning Session I

RAI

mediactrl

Media Server Control WG

1300-1500 Afternoon Session I

RAI

speermint

Session PEERing for Multimedia INTerconnect WG

1510-1610 Afternoon Session II

RAI

peppermint

Provisioning Extensions in Peering Registries for Multimedia INTerconnection BOF

1610-1700 PGP Session
(Yes, I’m one of those people who does actually go to PGP key signings.)

pgp

PGP Key Signing

1700-1930 IETF Operations and Administration Plenary - Salon G/H

THURSDAY, March 13, 2008
0800-1700 IETF Registration - Franklin Hall Foyer

0800-0900 Continental Breakfast - Franklin Hall Foyer

0900-1130 Morning Session I

RAI

sip

Session Initiation Protocol WG

1300-1500 Afternoon Session I
One of these:

IRTF	hiprg	Host Identity Protocol
SEC	saag	Security Area Open Meeting
TSV	behave	Behavior Engineering for Hindrance Avoidance WG

1510-1610 Afternoon Session II
One of these:

RAI	avt	Audio/Video Transport WG
RAI	enum	Telephone Number Mapping WG

1700-1930 Technical Plenary - Salon G/H

FRIDAY, March 14, 2008

0800-0900 Continental Breakfast - Franklin Hall Foyer

0900-1130 Morning Session I

RAI

p2psip

Peer-to-Peer Session Initiation Protocol WG

---

As I mentioned previously, the “RUCUS” BOF about voice spam at IETF 71 in Philadelphia is one of great interest to us. Unfortunately BOF co-chair Hannes Tschofenig ran into a problem with his domain and had to move the page to a new URL: http://www.shingou.info/bof-rucus.html

If you saved the URL or sent it on to someone, you’ll need to update to using the new URL. If you didn’t visit the RUCUS page before, please do check it out - and feel free to join the RUCUS mailing list. Of course, if you can, please do join us in person in Philadelphia!

Technorati Tags:
spit, ietf, spam, rucus, standards, sip

In the list of recently published RFCs, I was intrigued to see RFC 5118, “Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6)“. This is really a companion document to RFC 4475 that provides IPv6-related messages you can use while testing SIP. From the overview:

This document is informational, and is *not normative* on any aspect
of SIP.

This document contains test messages based on the current version
(2.0) of the Session Initiation Protocol as defined in [RFC3261].

This document is expected to be used as a companion document to the
more general SIP torture test document [RFC4475], which does not
include specific tests for IPv6 network identifiers.

This document does not attempt to catalog every way to make an
invalid message, nor does it attempt to be comprehensive in exploring
unusual, but valid, messages. Instead, it tries to focus on areas
that may cause interoperability problems in IPv6 deployments.

As IPv6 continues to move (slowly) along, it’s great to see an example like this RFC 5118 that can aid people who are developing SIP apps for IPv6.

Technorati Tags:
ietf, ipv6, standards, sip

If you are the considering attending the 71st IETF meeting March 10-14 in Philadelphia, you may want to also visit the IETF-71 micro-site put up online by Comcast, the host of IETF-71. They’ve done a good job providing information about the hotel, restaurants, the social event and more. (And yes, they of course have a link to where to find the best cheese steaks… )

And so the real use of IPv6 on the public Internet begins. In a BBC article “Overhaul of net addresses begins“, the writer notes this:

On 4 February the master or root servers for the net will have a small number of records added that are written in IP version 6 (IPv6) added to them.

This means for the first time that computers using IPv6, typically a PC and a server, can find each other without involving any IPv4 technology.

Yes, indeed, IPv6 is now live in a useful way.

You have, of course, been able to use IPv6 for quite some time, but only really between sites that knew the address of the other end. The global DNS system for resolving names to IP addresses only supported IPv4 at the top-level root name servers. So if you tried to connect to any other site out there via DNS, you were always getting IPv4 addresses through what are called “A” records in DNS parlance. Now, as of yesterday, you can also get back IPv6 addresses through “AAAA” records.

IPv6 is still a long way from being commonly deployed, but at least with this step the people out there who want to use it, or at least experiment with using it, can now actually resolve addresses through parts of the global DNS infrastructure. Of course, DNS only returns an IPv6 address for sites that have such an address entered into DNS, so it won’t truly start being useful until more people: a) have IPv6 addresses assigned to their servers, etc.; and b) enter those addresses in their DNS tables. Still, this is definitely a step in the right direction.

FYI, those of us who subscribe to the IETF discussion list were told about this impending change back on January 4th, and if you would like to really understand how all this works on a technical level, a report is available from ICANN’s Root Server System Advisory Committee and Security and Stability Advisory Committee that goes into intricate detail about the impacts of this move. For those not familiar with how the DNS system works at a technical level, Appendix A starting on page 19 is well worth a read.

Technorati Tags:
ietf, ipv6, dns, icann

Given the services we provide, one of the IETF working groups that we (Voxeo) are most interested in is the Media Server Control (mediactrl) Working Group (more information here). The charter provides a sense of what it is about:

Real-time multi-media applications often need the services of media processing elements. It is true that modern endpoints are capable of media processing. However, the physics of some media processing applications dictate that it is much more efficient for the media
processing to occur at a centralized location. By media processing, we
mean media mixing, recording and playing media, and interacting with a
user in the audio or video domains. The commercial market calls these
media processing network elements “media servers.”

Some services achieve significant efficiencies when a central node
performs media processing. Because of these efficiencies, media
servers are widely used for conference mixing, multimedia messaging,
content rendering, and speech, voice, key press, and other audio and
video input and output user interface modalities. Given the wide
acceptance of the media server, we need a standard way to control them.

Basically, the intent of the group is to arrive at a protocol suite of “media server control protocols” that standardize communication between “application servers” and “media servers”. One of the initial documents under discussion is the “requirements” document that lists the “requirements” that any proposal for a “media server control protocol” must meet. As stated in the charter, the objective of the document is:

1. A requirements document. This document will identify and enumerate
requirements for a suite of media server control protocols. Given that
one of the common media server clients is a conference application
server, we will consider the application server - media server
requirements developed by the XCON work group. Likewise, we will
consider media server control requirements from other standards
groups, such as 3GPP SA2 and CT1.

In any event, revision 3 of the requirements is out now, draft-ietf-mediactrl-requirements-03.txt, and reflects the input provided both at IETF 70 and in subsequent discussion on the mailing list. I’m personally pleased to see the inclusion of some of the security aspects that I (and others) had suggested ought to be included:

REQ-MCP-11 - The MS control protocol shall include an authentication
component to ensure that only an authorized AS can communicate
with the MS and vice versa.

REQ-MCP-12 - The MS control protocol shall use some form of
transport protection to ensure the confidentiality and integrity
of the data between the AS and MS.

REQ-MCP-13 - The MS control protocol requires mechanisms to protect
the MS resources used by one AS from another AS since the solution
need to support multiple AS controlling one MS.

Anyway, if you have any opinions about the requirements in the document, now is the time to voice them as the document is going into the final stages of approval. We need to nail the requirements as tightly as possible at the front end of the process so that later documents can reflect these requirements. (If you want to submit comments, the authors email addresses are found at the end of the document itself.)

Technorati Tags:
ietf, sip, mediactrl

Have you ever wanted to understand why SIP doesn’t work so well across NAT devices and firewalls? Have you heard of STUN, TURN or ICE but didn’t know what they were or how they worked? Over on my Blue Box podcast site I’ve just uploaded Blue Box Special Edition #22 which explores and explains all these details. In this interview I sat down with Dr. Jonathan Rosenberg, a Cisco fellow and author of a wide range of RFCs and Internet-Drafts related to SIP to talk about SIP and NAT traversal. We explore what the problem is, how ALGs and SBCs attempt to solve the problem and how the IETF has looked to address the issue through first STUN, then TURN and now finally ICE. I think you’ll find it a very educational and informative session.

On a similar note, you may also be interested in Blue Box Special Edition #20 where I sat down with Cullen Jennings to talk about overall security issues with SIP. These two podcasts together give you a solid overview of the current security issues with SIP.

Technorati Tags:
blue box, bluebox, dan york, danyork, ietf, sip, standards, voip security, jonathan rosenberg

One of the more interesting (to me) working groups within the IETF right now is the “P2PSIP” working group which is aiming to develop ways to let SIP clients communicate on a “peer-to-peer” basis, i.e. without any servers. As stated in the working group’s charter:

The Peer-to-Peer (P2P) Session Initiation Protocol working group (P2PSIP WG) is chartered to develop protocols and mechanisms for the
use of the Session Initiation Protocol (SIP) in settings where the
service of establishing and managing sessions is principally handled
by a collection of intelligent endpoints, rather than centralized
servers as in SIP as currently deployed. A number of cases where such
an architecture is desirable have been documented.

Peer-to-peer is intriguing to me primarily because it does represent a different deployment paradigm than what we are primarily using today for SIP deployments. Today SIP clients register with SIP servers and all the signaling is generally handled by those servers. With P2PSIP, the idea would be that you remove the servers and have all the routing, signaling, etc. handled by the “cloud” of P2P SIP clients. Clients get added and removed to the P2P cloud as they come and go and all the “intelligence” resides in the cloud.

Outside of the world of open standards, this architecture is best seen in voice with Skype. Skype clients connect to each other and route calls and media packets across the Skype cloud. I should note that Skype is not a pure P2P cloud. As was shown by the 2-day outage earlier this year, Skype still does very much rely on servers for authentication.

Will the P2PSIP working group wind up creating something like an open standards version of Skype? Maybe… maybe not… the effort is really only in the beginning stages. (And you can stay up with what is going on at “p2psip.org“.) There are all sorts of security and privacy issues that have to be addressed but it’s intriguing to see. It’s certainly a group I’ll be monitoring and participating in to the extent that I can.

P.S. If you are curious to experiment with open P2P architectures, you can check out OpenDHT.org, an open, publicly accessbile distributed hash table (DHT). Do be warned, though, that this is really for developers…

Technorati Tags:
ietf, sip, skype, p2p, p2psip

As I mentioned previously, there is some activity related to the IETF happening within the walls of Facebook. With IETF 70 over last week, I was both surprised and pleased to see that Tony Li over at Cisco had already created a Facebook Event for IETF 71 in Philadelphia on March 10-14, 2008. If you are a Facebook user, you can add yourself to the Event if you will be attending.

Now that I know the event has been created, it will be interesting to see what usage it gets in advance of the IETF 71 meeting. I confess to being a bit skeptical about the usage of Facebook Events and Groups for coordinating or communicating in advance of meetings. In theory, they seem useful, but because you only get notified of new wall posts or discussions when you visit the Event or Group page, I don’t really see the conversations developing.

In any case, it’s an interesting experiment and I’ll be glad to join in to see what comes of it.

One of the livelier sessions at the IETF meeting in Vancouver, BC was the segment having to do with SPIT. No I am not talking about what comes out of your mouth but rather the internet telephony version of SPAM. While it’s not a big problem yet, folks in the industry are indeed concerned about it and how to prevent it before it gets to be one.

The problem (or really the good news in this case) is that for the most part SPIT does not really exist yet in the wild. This being the case however we really don’t yet know what it looks like or how to detect it.

Currently some of the work is going into figuring out what SIP header we would transmit SPIT information to clients in. The problem is that at this point I don’t think that it’s clear that we know what SPIT scores need to look like. Is a simple number from 1-100 the right way to measure this? Or do we need a more complex way of delivering multiple scores and information to explain to the user agent what the SPIT detectors have discovered.

All of this however does not yet touch on the MUCH bigger problem of how to detect SPIT. As with e-mail the problem is that much depends on the context and permissions involved in the actual message. You can not simply decide that something is SPIT based on the fact that they place a lot of calls in a short amount of time (as I have heard suggested by some people). An example of a use-case where this does not work is emergency outbound notification. For systems like this platforms NEED to be able to place very large numbers of phone calls in a short amount of time. While some might say that white listing can help with some of these cases I think e-mail has shown that for this most part this does not not work. I don’t want to miss a call telling me that something horrible when on at my child school because I forgot to enter my school’s phone number into my office PBX.

Anyway there is still much work to be done in the space and there are sure to be many more heated discussions at the IETF and elsewhere on this subject.