Hannes Tschofenig

Weblog about IETF related topics

The recent interaction with the W3C has created some turbulence. Here is a recent press announcement (in German) entitled “IETF-Entwickler fordern Datenschutzregeln für Geodaten-API des W3C”.

More information can be obtained from the presentation of the GEOPRIV WG chairs at the IETF#73 meeting.

A number of folks have been complaining about fairness of TCP. Here is a link to a page where the presentation of Matt Mathis about this topic can be found: http://staff.psc.edu/mathis/unfriendly/

The Wireshark Development Team accepted the patch written by Karl Heinz Wolf for decoding DHCPv4 Coordinate-based Location Configuration Information. The patch re-uses the RFC 3825 decoder by Klaus Darilion (available at http://www.enum.at/rfc3825encoder.529.0.html ).
A development version of Wireshark is available at http://www.wireshark.org/download/automated/

The RFC 4776 DHCPv4 patch is already included in the stable Wireshark 1.0

I participated at the roundtable discussion on 112 in Poland and gave a presentation about the IETF ECRIT work. More info can be found here.

Just a few hours ago ext Eric Burger posted a mail about another SIP Interoperability Workshop taking place at the IETF#73 meeting. He writes
“Following on the First SIP Forum Interoperability Workshop, the SIP Forum is hosting a Second Workshop. The topics we will cover are:

What the SIP Forum is working on now:

  • UA Config
  • FoIP
  • SIPconnect
  • SIPit

What should the SIP Forum be working on in the future?

  • Security (with VoIPSA)
  • UC Interoperability
  • Other

We are meeting on Tuesday, November 18, in Symphony 1 & 2 at the Minneapolis Hilton (the IETF 73 venue). Lunch will be provided for active RAI/SIP/SIPPING/etc participants.

Description of Working Group:

The LEDBAT WG is chartered to standardize a congestion control mechanism that should saturate the bottleneck, maintain low delay, and yield to standard TCP.

Applications that transmit large amounts of data for a long time with congestion-limited TCP, but without AQM, fill the buffer at the head of the bottleneck link. With FIFO queue, this increases the delay experienced by other applications.
With buffer of one RTT, the delay doubles. In some cases, the extra delay may be much larger. This is a particularly acute and common case is when P2P applications upload over thin home uplinks: delays in these cases can sometimes be of the order of seconds.

The IETF’s standard end-to-end transport protocols have not been designed to minimize the extra delay introduced by them into the network. TCP, as a side effect of filling the buffer until it experiences drop-tail loss, effectively maximizes the delay. While this works well for applications that are not delay-sensitive, it harms interactive applications that share the same bottleneck. VoIP and games are particularly affected, but even web browsing may become problematic.

LEDBAT is a transport-area WG that will focus on broadly applicable techniques that allow large amounts of data to be consistently transmitted without substantially affecting the delays experienced by other users and applications.

The WG will work on the following:

(1) An experimental congestion control algorithm for less-than-best-effort “background” transmissions, i.e., an algorithm that attempts to scavenge otherwise idle bandwidth for its transmissions in a way that minimizes interference with regular best-effort traffic.

Desired features of such an algorithm are:

  • saturate the bottleneck
  • eliminate long standing queues and thus keep delay low when no other traffic is present
  • quickly yield to traffic sharing the same bottleneck queue that uses standard TCP congestion control
  • add little to the queueing delays induced by TCP traffic
  • operate well in networks with FIFO queueing with drop-tail discipline
  • be deployable for popular applications that currently comprise noticeable fractions of Internet traffic
  • where available, use explicit congestion notification (ECN), active queue management (AQM), and/or end-to-end differentiated services (DiffServ).

Application of this algorithm to existing transport protocols (TCP, SCTP, DCCP) is expected to occur in the working groups that maintain those protocols.

Once experience is gained with this congestion control algorithm on the Internet, the WG will consider if it is appropriate to ask the IESG to advance the document as a Proposed Standard.

(2) A document that clarifies the current practices of application design and reasons behind them and discusses the tradeoffs surrounding the use of many concurrent TCP connections to one destination and/or to different destinations.

Applications routinely open multiple TCP connections. For example, P2P applications maintain connections to a number of different peers while web browsers perform concurrent downloads from the same web server. Application designers pursue different goals when doing so: P2P apps need to maintain a well-connected mesh in the swarm while web browsers mainly use multiple connections to parallelize requests that involve application latency on the web server side. The IETF transport area community is concerned about this practice, because standard Internet congestion control results in different transport connections sharing bottleneck capacity. When an application uses several non-rate-limited transport connections to transfer through a bottleneck, it may obtain a larger fraction of the bottleneck than if it had used fewer connections. Although capacity is the most commonly considered bottleneck resource, middlebox state table entries are also an important resource for an end system communication. Other resource types may exist, and the guidelines are expected to comprehensively discuss them.

Applications use a variety of techniques to mitigate these concerns. These techniques have not always been reviewed by the IETF and their interaction with TCP dynamics is poorly understood. The WG will document the known techniques, discussing the consequences and, where appropriate, provide guidance to application designers.

To Subscribe: https://www.ietf.org/mailman/listinfo/ledbat

… and the group is meeting at IETF#73. Here is the meeting agenda: http://www.ietf.org/proceedings/08nov/agenda/alto.html

The recently mentioned ATOCA BOF that should have been taken place at IETF#73 will be postponed to IETF#74.

The reason for this decision is not quite clear but could relate to the ongoing discussions about the future of the IETF RAI area and upcoming discussions at IETF#73 on how to improve the mode of operation.

See http://identitymeme.org/archives/2008/11/04/new-rev-of-sip-saml-profile/

NIST Special Publication 800-108 Recommendation for Key Derivation Using Pseudorandom Functions is published at http://csrc.nist.gov/publications/nistpubs/800-108/sp800-108.pdf

Folks might be interested in the slides from the emergency services workshop that took place in Vienna about 2 weeks ago. The direct link to the slides can be found here:
http://www.emergency-services-coordination.info/2008Oct/slides/
but you can also find them via the workshop page at:
http://www.emergency-services-coordination.info/esw5.html

Note that I have also added three slides of presentations we skipped:

Matt Ball finally uploaded the recordings of the 2008 IEEE Key Management Summit.

Robert again provided a brief summary of the SIP interop event, see https://www.sipit.net/SIPit23_Summary.

This time he provided fewer security related statistics but there is still some interesting stuff in there. Here are a few highlights (note that 50 distinct implementations were at the interop):

  • 50% RFC3323 privacy (in endpoints)
  • 6 ICE implementations
  • Support for multipart/mime increased (38% of the UAs would do something with it on receipt). There were no implementations present testing S/MIME.
  • There were only 2 implementations claiming support for Identity. 2 for the dial-string URI (RFC4967), and none for Service URNs (RFC5031).
  • There were no implementations of the sip-config, sip-consent, or session-policy frameworks. The only people in the room who had even read the sip-config framework documents are regular IETF participants. Even fewer had read sip-consent or session-policy. There is currently a huge gap between specification and implementation for these concepts.
W3C Workshop on the Future of Social Networking
15-16 January 2009, in Barcelona, Spain
Hosted by Universitat Politècnica de Catalunya and
ReadyPeople
Call for Participation:
Deadline for submitting position papers: November 20, 2008
The goal of this workshop is to bring together industry actors to foster
discussion, to analyse risks and opportunities of the social networking
industry, and to define plans for the future of the industry, including
opportunities of creation of a W3C group to continue the discussion.

Mailing Lists:

BOF chairs:

  • Brian Rosen [brian.rosen at neustar.biz]
  • Steve Norreys [steve.norreys at bt.com]

BOF Purpose.

ECRIT is working on citizen-to-authority calls. Alerts that are sent from “authorities” (which we define broadly to any level of authority, including, for example, a school administrator) to “citizen” (which we also define broadly to include visitors and other individuals and groups) are of great interest. Many efforts are underway in other fora, but all of them are stovepipes: limited by which authorities can invoke alerts as well as which networks they can be distributed on. What is needed is a more flexible way to deliver alerts from any notifier to any interested or affected individual, via any device connected to the Internet.

This is a large problem: some alerts must be delivered to an enormous number of endpoints; a Tsunami warning may involve millions of devices eventually. A system which can deliver messages to billions of endpoints with one notification are obviously attractive attack targets. This is further complicated by the desire to accept notifications from a wide variety of notifiers, complicating authentication mechanisms that might be employed. The security implications of any solutions must be addressed as a integral part of the solution from the very start of the work.

Classic alert systems typically use layer 2 broadcast mechanisms and often use some kind of location as a criteria for who gets the alert. On the Internet, multicast mechanisms may be helpful, but the paucity of multicast deployment must be considered. Besides broadcast, which certainly is very appropriate, it is very useful to be able to subscribe to events for individuals who may not normally meet criteria for being  included in a broadcast. For example, parents may wish to receive alerts that affect their children. An alert directed to anyone in the path of a hurricane may be broadcast, but the parent may need a subscription to get the same alert when they are not in the affected area.

The content of an alert is also a significant challenge to Internet scale alerts. The alert must be rendered on a wide variety of devices with different user interface capabilities. Multiple languages have to be accommodated. Networks with limited bandwidth must be considered.

Alert work is being done in many fora, and some is directly applicable to this work. For example, OASIS work on Common Alerting Protocol is likely part of the solution. It should also be recognized that this is an area of work that will be highly regulated and as such close work with the fora where regulators operate (e.g. ATIS, ETSI and ITU-T) may help with the deployment of any solutions.

The purpose of the BOF is to determine the need and scope for authority to citizen alerts, what existing protocols and mechanisms need to be adapted to meet those needs and the appropriate representation for alerts should be.

This work could be accomplished within an expanded charter of ECRIT, or a new work group could be formed. This work will leverage GEOPRIV work on location.

Proposed Deliverables:

  1. Requirements for ATOCA .
  2. An ATOCA Framework.
  3. Various protocol and mechanism enhancements to meet the requirements identified

Input Documents:

  1. Requirements: draft-norreys-ecrit-authority2individuals-requirements-01.txt

The EU funded project PrimeLife has just made one of their first deliverable available on their webpage. PrimeLife tries to bring sustainable privacy and identity management to future networks and services.

First Report on Standardisation and Interoperability - Overview and
Analysis of Open Source Initiatives
http://www.primelife.eu/images/stories/deliverables/d3.3.1_d3.4.1-public.pdf

Scope of the deliverable:

This deliverable aims at giving an overview of standardisation and open source initiatives that are relevant for PrimeLife. It decribes the state of work there as well as possible and actual cooperations.

From the PLING Wiki:

The joint PLING & PrimeLife F2F meeting will enable an opportunity to discuss the work of the IG to date and to set directions and priorities for future work in conjunction with the PrimeLife Project members. Being part of TPAC week will also allow interactions from other W3C Groups.

Here is the main page for the PLING group:
http://www.w3.org/Policy/pling/

Here is their Wiki:
http://www.w3.org/Policy/pling/wiki/Main_Page

Here is a pointer to their workshop:
http://www.w3.org/Policy/pling/wiki/TPAC2008

We now have a web page up for this upcoming MIT Communications Futures Program workshop (http://cfp.mit.edu/events/oct08/Call-for-participation-privsec-oct-08-workshop.shtml), to take place at The Stata Center at MIT on October 21-22. The page includes an introduction to the workshop, a draft agenda, and a pointer to the registration and lodging pages.

Pictures and slides are now available for the 1st IEEE Key Management Summit. For the recordings you still have to wait…

Henning recently posted a very interesting mail to the IETF mailing list about a new mailing list:

RECIPE (Reducing Energy Consumption with Internet ProtocolsExploration). Based on some very preliminary discussions in Dublin, I’ve set up a new discussion list to talk about the intersection of Internet protocols and energy management. The goal is NOT how to make protocols, routers or servers more energy-efficient, but rather how to use Internet (application) protocols to better manage energy consumers and (local) producers. There has been a fair amount of work in this area, but mostly focused on lower layers, such as ZigBee. The initial goal of the discussion is to identify whether there is a need for work here or not. I’m also in discussion with a major local utility. The discussion will take place at recipe@ietf.org, with subscription details at https://www.ietf.org/mailman/listinfo/recipe A bit more detail is below: In the next few years, the demands on the electric grid will change substantially. New power sources, such as wind and solar, delivery varying amounts of power based on the time of day, while new consumers, such as plug-in hybrids, impose additional demands. Local generators, such as small-scale solar and wind turbines, can produce additional energy. Grid control can better match energy supply and demand, and flatten peak usage by deferring non-time-critical demands to low-usage times. For example, an office building can use low-cost off-peak energy to produce ice, which is then melted during the day to provide air conditioning. In the home, dishwashers and washing machines can defer their operation. There has even been discussion of using plug-in hybrids as energy storage devices that charge their batteries at night and release energy to the power grid during the peak usage periods. In addition, end users need to be able to determine easily what devices are consuming how much energy. For example, energy monitoring may alert a homeowner that a hot water pipe is leaking or that an AC air vent has been disconnected. All of these new usages demand a much smarter grid that interacts with power consumers and producers at the edges of the grid. With near- universal broadband and wireless data network deployments, this is becoming quite feasible. Given the diversity of consumer and industrial products that need to be controlled, we need standardized, light-weight protocols that can provide core control functions. We envision at least three core functions related to energy control: (1) A device should be able to query a grid controller to get permission to start operation. It would obtain a time-of-day when the device should start operation (or ask again). The query may indicate a “class-of-service”, such as off-peak tariff. (2) The grid controller may ask a household or company to reduce its energy consumption to a certain level for load management during peak power periods. The household or company would then shut down non- essential consumers or defer energy-consuming tasks, such as hot-water heating or vehicle charging. (3) A controller can ask a device about its power usage or total energy consumption. Particularly for the first two cases, devices need to be able to discover their energy controller, since different consumers within the same region may use different distribution or energy management companies. Particularly for the second case of grid-controlled devices, strong authentication is needed to prevent malicious or accidental shutdown of electrical systems.

A number of emergency services experts are meeting to discuss ongoing work on IP-based emergency services in Vienna, Austria on 21st to 23rd October 2008. The first workshop day is focusing on tutorials to help those interested in the classical 1-1-2 emergency call to get up-to-speed with architectures and standards developed for next generation emergency calling. During the second day various recent activities of standardization organizations around the world will be presented. The third workshop day is dedicated to early warning standardization efforts and the outlook to future emergency services activities.

Participation from those working in standardization organizations as well as persons with interest into the subject is highly appreciated.
For socializing an evening program has been organized.

More information about the workshop can be found behind the following link:
http://www.emergency-services-coordination.info/esw5.html
This page also points to previous workshops that took place in New York, Washington, Brussels and Atlanta.

The IEEE Key Management Summit brings together the top companies that develop cryptographic key management for storage devices with the standards organizations that make interoperability possible and the customers that rely on key management to secure their encrypted data.

With recent legislation, such as California’s SB 1386 or Sarbanes-Oxley, companies now have to publicly disclose when they lose unencrypted personal data.  To meet this new need for encryption, many companies have developed solutions that encrypt data on hard disks and tape cartridges.  The problem is that these data storage vendors need a solution for managing the cryptographic keys that protect the encrypted data.

This summit aims to provide clarity to the key management by showing how existing products and standards organizations address the problem of interoperability and security.

KMS 2008 is co-located with the IEEE Mass Storage and Systems Technologies conference (MSST) in Baltimore, Maryland on September 23-24, 2008.

The agenda for the two workshop days can be found here and here.

See more details at http://www.keymanagementsummit.com/2008/

I am a member fo the program committee.

Henning Schulzrinne gave an interesting presentation about the cost of bandwidth as a contribution to the ongoing discussion about P2P traffic “optimization”. This BOF was an outcome of the workshop in New York in May this year.

Jari Arkko just recently published an interesting draft on the subject of incentives. Here is the abstract:

Several papers in the May 2008 P2PI workshop have argued that there is a need to build new protocol mechanisms to accommodate peer-to-peer traffic in networks in the most efficient way and with minimal impact to other traffic.  This paper presents an analysis of such solutions from the point of view of the incentives of the different parties involved in peer-to-peer traffic.  The paper concludes that it is essential to understand the incentives in order to have a deployable solution.

More details about the next emergency services workshop that will take place in Vienna in October (21st - 23rd) are available.

We hope to see you there!

In a recent mail a CAP implementers workshop was announced. Here is the text from the mail:

The Common Alerting Protocol (CAP), an OASIS standard adopted as ITU Recommendation X.1303, is the foundation standard for all-media public warning. Designed as an all-hazards alert format, CAP is being
implemented worldwide for earthquakes, public health, and many other emergencies, in addition to weather events.

Details:

This Workshop is planned for 9-10 December 2008 at the WMO (World Meteorological Organization) in Geneva, in cooperation with OASIS and ITU. It will be primarily a forum for discussions among CAP implementers and ICT or emergency management organizations on topics requiring coordination. These topics may include, among others: having an internationally agreed list of authorities for common types of CAP alerts; disseminating, aggregating, and authenticating CAP alerts; making globally unique identifiers for CAP alerts; and, best practices for text in the CAP “description” and “instruction” elements.

You may be aware that this Workshop follows on the October 2006 “Workshop and Demonstration of Advances in ICT Standards for Public Warning” held at ITU in Geneva, see http://www.itu.int/ITU-T/worksem/ictspw and http://www.oasis-open.org/events/ITU-T-OASISWorkshop2006/proceedings.php

Since that 2006 Workshop, there have been notable developments
including:

  • The ITU-D (ITU Development sector) approved guidance for developing nations on CAP implementation
  • OASIS established its Emergency Management Member Section to accelerate implementation of CAP and allied emergency data exchange standards
  • The U.S. FCC (Federal Communications Commission) issued an order requiring use of CAP
  • The WMO SWIC (Severe Weather Information Centre) began work on CAP warnings of Tropical Cyclones
  • The U.S. National Weather Service (NWS) continued improving its CAP messages and developing its Next Generation Warning Tool
  • The Weather Channel underscored to NWS the need to institute CAP
  • The U.S. Environmental Protection Agency began developing CAP alerts for air quality warnings
  • The Earth Observations Summit highlighted CAP implementation as a major achievement
  • Canada and the U.S. coordinated on implementation of their respective CAP-based alerting systems
  • EUMETNET began exploring how to adapt METEOALARM to support CAP.