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

Over on the Voice of VOIPSA blog today I posted about a new session has been approved for the IETF 71 meeting coming up in Philadelphia in March called “Reducing Unwanted Communications using SIP” a.k.a. “RUCUS”.Hannes Tschofenig, who submitted the proposal, has created a RUCUS web page and is looking for feedback. I’m planning to be at the RUCUS session at IETF 71 and would encourage others who want to talk about voice spam / SPIT to join in as well!

Technorati Tags: rucus, spit, spam, voice spam, voip, voip security, security, ietf, standards

As more systems get connected using VoIP and over time security systems come into use to help prevent voice spam, a.k.a. “SPam for Internet Telephony” or “SPIT”, what happens if you have an application that makes a very large number of outbound calls? For instance, a notification system? Might the traffic from that application not look like the beginning of a flood of SPIT?

Within the IETF there’s been a bit of discussion in the past months about voice spam/SPIT and just recently RFC 5039 from Jonathan Rosenberg and Cullen Jennings was published that specifically addresses the issue of SIP and Spam.

The RFC is an excellent summary of the current thinking about the SPIT problem and potential solutions to address it. If you haven’t read the document, I would *highly* recommend it.

A concern I had, though, was that it did not appear to me that existing documents address the issue of what SPIT could look like at a network level. For instance, if a network administrator monitoring network traffic suddenly saw a large flood of SIP INVITE packets coming into his/her network, it could be:

1. a telemarketer/spammer launching a flood of SIP connections to deliver SPIT;
2. an attacker launching a DoS attack through one of the various SIP attack tools out there; or
3. a legitimate notification system starting to notify a range of SIP endpoints.

I could very easily see existing network tools that look at traffic and perform anomaly detection (and potentially source suppression) being modified to suppress large flows of SIP traffic. This last case of legitimate traffic concerned me and so I put together an Internet- Draft talking about the types of legitimate systems that might generate a significant volume of traffic that could resemble SPIT (or a DoS attack).

I put the document out primarily to stimulate discussion. Are these legitimate scenarios being addressed in current thinking about SPIT? If not, my point really is that they need to be considered.

Comments about the document are very definitely welcome. Are there other scenarios I should include? Am I accurate? Am I overstating the case? or what?

Technorati Tags: ietf, security, sip, standards, voip, voip security

Over on the “Voice of VOIPSA” weblog, I posted about an excellent overview of SIP security issues that Hannes Tschofenig presented yesterday at the 3Rd ETSI Security Workshop in France. If you aren’t familiar with the current state of SIP security, I’d highly recommend you take a read through Hannes’ slides.

Technorati Tags: identity, ietf, security, sip, standards, voip, voip security

Hi, I’m Dan Burnett. I’ll be posting here occasionally about the speech-related standards in W3C and IETF.

I’m an editor of VoiceXML 2.0/2.1, SSML 1.0/1.1, and MRCPv2, an author of EMMA 1.0, PLS 1.0, SCXML 1.0, and the forthcoming VoiceXML 3, and a contributor to almost every other specification from the Voice Browser and Multi-modal Working Groups.

Out at IETF last week, there were several conversations where the people mentioned work that “another SDO” was doing. It occurred to me that outside of standards circles that acronym has little meaning, so I thought I’d just mention it for those new to the world of standards.

An “SDO” is a “standards development organization” (or sometimes “standards developing organization”), essentially an entity that exists out there to develop standards. The one we’ve been writing about here is the IETF, which sets standards for Internet-related protocols. Another one with which we in Voxeo are involved is the W3C, which has standardized HTML, XML and other web-based standards. The 3GPP is also important in the world of VoIP and mobile networks. There are, naturally, thousands of such organizations out there.

The tricky part, of course, comes when one SDO goes to use standards developed within another SDO. On the one hand, this is a great example of reusing existing work. For example, there is a draft within the MEDIACTRL Working Group of the IETF that will standardize the use of VoiceXML (a W3C standard) within the IETF’s SIP framework for media control. However, there can also be conflict when the standard being referenced evolves (or does not evolve) in the direction desired by another SDO. An example came up at the IETF meeting last week where the IETF was debating NOT including a particular element in SIP and someone who had recently attended a 3GPP meeting indicated that the 3GPP was expecting this capability to be included in SIP.

Anyway, that’s what a SDO is. If you would like to learn more about SDOs, NSBs and other TLAs (three-letter-acronyms), the Wikipedia article on Standards Organizations is a great place to start.

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.

Well so far this trip is starting off on the fun side with a bunch of flight delays from United. On the bright side they rebooked me on US Air automatically so it looks like I may actually make it to Vancouver before midnight. The real kicker however is going to be the 50 degree drop in temperature that is coming my way when I land:  On the serous side I am looking forward to a busy week of standards meetings and catching up with industry colleagues. Between sip, sipping, mediactl and all the other groups that I will be attending it will be a busy few days especially once you mix in a few customer meetings that I have scheduled with folks who are in the area.  

If you can’t get to Vancouver next week to join IETF 70, but you would like to stay up on what is going on, you actually have two options for following the sessions in real-time.

AUDIO - As they have done for several IETF meetings, the University of Oregon will offer live streaming of all IETF sessions. You may need to follow the IETF 70 agenda in order to know which session will be in which room, but this gives you a way to listen in as the sessions are in progress. They note at the bottom of the page that the raw audio sessions will be archived as well.

JABBER IM/TEXT CHAT - The IETF also runs a Jabber server with group chatrooms available for all the working groups. They provide easy steps to follow in the “IETF Text Conferencing” document available online. Basically, you connect in from your Jabber IM client to one of the groupchats hosted on “jabber.ietf.org”, where the chat room name is the abbreviation for one of the IETF Working Groups. For instance, I’ll be in the “mediactrl@jabber.ietf.org” early on Monday morning. The nice thing now is that GoogleTalk is XMPP/Jabber-based, so more people may have XMPP accounts (even if they don’t realize that they do).

Again, you’ll need to watch the IETF 70 agenda to understand which chat rooms will be active at any given time.

One caveat about IM - Whether or not the IM session is useful will largely depend upon whether someone in the room at IETF 70 will offer to act as a “scribe” and provide updates to people in the IM room. The scribe is updating people but also acting as a conduit for questions from the chatroom back to the room at the IETF meeting. At IETF 66 in Montreal this was something I did a couple of times and may well do so again here, depending upon my own schedule. Anyway, if there is a scribe for the session, the IM chat may be a useful way to stay up on what is going on. If no one will act as a scribe, well, there won’t be any meaningful communication.

That’s it! Two ways that you can join into the IETF 70 meetings even if you can’t get to Vancouver. Enjoy…

Technorati Tags: ietf, standards, jabber