Hannes Tschofenig

The conference recordings of the 25th Chaos Communication Congress (25c3) are available.

Take a look at the schedule and you will find a couple of interesting talks.

Mid last year Jon Peterson and others organized the P2P infrastructure workshop. Recently, a draft as a workshop summary was made available, see http://www.ietf.org/internet-drafts/draft-p2pi-cooper-workshop-report-00.txt.

I noticed that I never put my slides on my blog. Together with Marcin we worked on a position paper and Marcin presented a slide set.

Katrin Hoeper posted a NIST public call for comments that is of interest for all IETF WGs that deal with EAP. The NIST document contains security requirements for key deriving EAP methods that are used for wireless access authentication.  It covers non-tunneled as well as tunneled EAP methods.

http://csrc.nist.gov/publications/PubsDrafts.html#800-120

Here is more information about the call for comments:

NIST announces the release of draft Special Publication 800-120, Recommendation for EAP Methods Used in Wireless Network Access Authentication. This Recommendation specifies security requirements for authentication methods with key establishment supported by the Extensible Authentication Protocol (EAP) defined in IETF RFC 3748 for wireless access authentications to federal networks. Please submit comments to 800-120comments@nist.gov with “Comments on SP 800-120″ in the subject line. The comment period closes on January 30, 2009

Henning and his students have released an open source LoST server, see http://honamsun.cs.columbia.edu/lost_homepage/.

I hope that other groups are also able to publish their open source code.

Karl Heinz Wolf and Alexander Mayrhofer have worked on a book describing the IETF emergency services architecture and their contributions at NIC.AT. The book, which is written in Germany and focuses on the situation in Austria, can be bought here. Their webpage contains more information about the book and about emergency services in general, see http://www.handbuch-notruf.at/handbuch/.

Here is the cover:

In case you have not heard about it yet: http://blogs.zdnet.com/security/?p=2339

Ekr explains all this in more detail, see

http://www.educatedguesswork.org/2008/12/understanding_the_sotirov_et_a.html. A original paper can be obtained from here.

Verisign is not sleeping and tells us what they did against this problem: https://blogs.verisign.com/ssl-blog/2008/12/on_md5_vulnerabilities_and_mit.php

Karl Heinz responded to my question to the GEOPRIV mailing list that he has implemented a encoder/decoder for RFC 4776 at http://ecrit.labs.nic.at/rfc4776.php. He also claims that Wireshark 1.0 already includes his patch for decoding RFC 4776 location information in DHCPv4.

This is good news for those folks interested in implementing the GEOPRIV location based mechanisms (RFC 4776 and RFC3825).

Sébastien Vincent just posted this mail to the MMUSIC mailing list about their Open Source TURN server implementation:
”
This new version supports RFC5389 (STUN), latest turn-12 and turn-ipv6-05 drafts. We also refactor some code parts and add other things like setting DF flag on Linux and quotas / IP restriction stuff. Here is the ChangeLog:

• Add attributes from turn-12 draft;
• Add authentication on all TURN responses when possible;
• Pre-calculate account MD5 hash;
• Re-organize some code (message-integrity calculation, …);
• Alternate behavior for DF flag;
• Separate TCP and TLS sockets;
• Correctly relayed data from peer to client in TLS;
• Multiple XOR-PEER-ADDRESS support in CreatePermission;
• Update wireshark parser (packet-stun2.c);
• Additionnal configuration parameters;
• Allocation number and bandwidth quota;
• Address / port restrictions;
• Reconstruct fragmented TCP messages support;
• Prevent allocation hijacking support;
• Add logs support via syslog.

TurnServer code can be retrieved from the download page:
http://sourceforge.net/project/showfiles.php?group_id=234986
“

Dan York released a nice videopodcast about P2PSIP. You can find it here:

http://blogs.voxeo.com/ett/2008/12/11/emerging-tech-talk-011-david-bryan-about-p2psip/

For those interested in IPv6 deployment please take a look at the following upcoming conference about IPv6:

https://sites.google.com/site/ipv6implementors/conference2009/agenda

Martin Thomson wrote a really nice tool: A PIDF-LO visualizer

RFC 4119 says:

This document describes an object format for carrying geographical information on the Internet. This location object extends the Presence Information Data Format (PIDF), which was designed for communicating privacy-sensitive presence information and which has similar properties.

This tool is particularly useful for verifying geodetic location information, as described in “GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations“.

More info: http://www.emergency-services-coordination.info/esw5.html
Slides: http://www.emergency-services-coordination.info/2008Oct/slides/
Pictures: http://www.emergency-services-coordination.info/2008Oct/pics/
IETF ECRIT Tutorial Slides: http://www.emergency-services-coordination.info/2008Oct/slides/esw5-tutorial.ppt

Mission-Critical Networking (MCN) refers to networking for application domains where life or livelihood may be at risk. Typical application domains for MCN include critical infrastructure protection and operation, emergency and crisis intervention, healthcare services, and military operations. Such networking is essential for safety, security and economic vitality in our complex world characterized by uncertainty, heterogeneity, emergent behaviors, and the need for reliable and timely response. MCN should comprise networking technology, infrastructures and services that may alleviate the risk and directly enable and enhance connectivity for mission-critical information exchange among diverse, widely-dispersed, mobile users. A primary challenge to MCN is to deploy and dynamically configure and evolve communication networks that are dependable, autonomic, secure, adaptive, and rapidly deployable to support critical missions and their priorities. In order to operate effectively, the deployed networks should support services such as location determination of both authorized and unauthorized entities, quality-of-service aware audio and video communication, emergency calling and alerting, and in-situ and remote sensing and control in a secure and dependable manner. In addition, efficient operation of such networks that typically include numerous resource-constrained components may benefit from cross-layer optimization, cognition, resource engineering, on-demand federation, and service-oriented architecture. Also important is the integration of MCN with the Internet to reduce cost of deployment and maintenance and to enhance reachability and ubiquity. This special issue of the Journal on Selected Areas in Communications solicits high quality technical contributions in mission-critical networking including, but not limited to:

• Architecture and design of MCN and next-generation emergency calling  and alerting
• Rapidly and dynamically deployable services and networks
• Evolving “elastic” networking with decentralized and peer-to-peer resource management and allocation
• Federation and policy management for heterogeneous networks and protocols
• Trust, security, dependability, privacy, QoS and performance awareness and management for MCN
• Sensor and actuator networks for critical information gathering, tracking and real-time control
• MCN traffic and mobility analysis
• Formal methodology for cognitive, autonomic, and context-aware protocols and network management
• Spectrum management and access
• Testbeds, benchmarks, performance and experimental studies

** Paper Submission

Manuscripts should describe original, previously unpublished work, not currently under review. Argument justifying contribution specific to the unique features of MCN must be provided. Prospective authors should follow the IEEE JSAC manuscript format described in the Information for Authors at:
http://www.jsac.ucsd.edu/Guidelines/info.html

Authors should submit a PDF version of their complete manuscript to mcn-jsac@criticalnet.org according to the following timetable:

• Manuscript submission: April 1, 2009
• First review notification: August 1, 2009
• Revised manuscript due: October 1, 2009
• Acceptance notification: November 1, 2009
• Final manuscript due: January 2, 2010
• Publication: June, 2010

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:

• CHORIST
• ITU-T
• TSO

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