[Chapter-delegates] IETF 77 Rough Guide Follow-up

[Greg Wood]

-----------------------------------------------
Follow-up to the Internet Society's Rough Guide to IETF 77's Hot Topics 
-----------------------------------------------

In March, we published the Rough Guide to IETF 77's Hot Topics. Here now is the follow up to the meetings highlighted in that guide.

For IETF 77, which was held in Anaheim, California, we focused our attention on working groups, BoFs, plenaries, and other events in the following broad categories:

	* Common and Open Internet
	* Global Addressing
	* Security and Stability
	* Trust and IDentity

In addition to the main IETF content, the Internet Society (ISOC) also held another expert panel "IPv6: Are we there yet?" that gathered experts to discuss the growing momentum behind IPv6 deployment. You can listen to a recording of that event here:

http://www.isoc.org/isoc/conferences/ipv6momentum/

Looking ahead, the final preparations are underway for IETF 78, in Maastricht, Netherlands, 25-30 July 2010, so we will soon be bringing you a guide to the expected highlights of that meeting.

_____________________________________
Common and Open Internet
As P2P and VoIP technologies become more prevalent, and network usage patterns sometimes deviate from their architects' expectations, managing bandwidth to allow best use for customers becomes an increasingly important topic.
_____________________________________


alto (Application-Layer Traffic Optimization) WG

The alto WG is occupied with designing a service to provide applications with information from the network that enables them to perform better-than-random peer selection. In this context, there are various definitions of "better" (such as maximum throughput, minimum cross-domain traffic, and lowest cost to the user).

Outcomes:
	* Continued progress towards chartered milestones
	* New work on deployment scenarios - http://tools.ietf.org/html/draft-stiemerling-alto-deployments-03

Minutes: http://www.ietf.org/proceedings/10mar/minutes/alto.html

--------------

conex (Congestion Exposure) BOF

Congestion Exposure (ConEx) is a proposed new IETF activity to enable congestion to be exposed along the forwarding path of the Internet. By revealing expected congestion in the IP header of packets, congestion exposure provides a generic network capability which allows greater freedom over how capacity is shared. Such information could be used for many purposes, including congestion policing, accountability and inter-domain SLAs. It may also open new approaches to QoS and traffic engineering.

Outcomes:
	* WG has been chartered
	* Initial focus on experimental specifications for IPv6 networks

Minutes: http://www.ietf.org/proceedings/77/minutes/conex.txt

--------------

decade (Decoupled Application Data Enroute) BOF

Peer-to-Peer (P2P) applications, including both P2P streaming and P2P file-sharing applications, make up a large fraction of traffic in the Internet today. One way to reduce access network and/or cross-domain bandwidth usage by P2P applications is to introduce storage capabilities in the network between hosts running P2P applications. Allowing P2P applications to store and retrieve data from inside the network can reduce traffic on the last-mile uplink, as well as backbone and transit links.

Outcomes:
	* Working Group has been chartered

Minutes: http://www.ietf.org/proceedings/77/minutes/decade.html

--------------

ledbat (Low Extra Delay Background Transport) WG

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

Outcomes:
	* Working Group is close to completing its chartered work
	* Evaluations of LEDBAT algorithm are ongoing

Minutes: http://www.ietf.org/proceedings/77/minutes/ledbat.txt


--------------

mptcp (Multipath TCP) WG

The Multipath TCP (MPTCP) working group develops mechanisms that add the capability of simultaneously using multiple paths to a regular TCP session. The primary output of the group will be the protocol extensions needed to deploy MPTCP, and adaptations to congestion control to safely support multipath resource sharing. Initially the WG will only produce documents that are experimental or informational.

Outcomes:
	* Working Group is making solid progress.
	* There will be an implementer's workshop prior to IETF 78: http://trac.tools.ietf.org/wg/mptcp/trac/wiki/Maastricht_workshop

Minutes: http://www.ietf.org/proceedings/77/minutes/mptcp.txt

_____________________________________
Global Addressing
There is steadily increasing momentum to deploy IPv6 as the IPv4 address pool approaches depletion. While much work is ongoing to support interoperability in coexisting IPv4 and IPv6 network environments, there are also interesting developments in emerging IPv6 environments.
_____________________________________


behave (Behavior Engineering for Hindrance Avoidance) WG

While behave was chartered to create mechanisms for transiting NATs in reliable ways, most of its activity is now focused on protocol translation from IPv4 to IPv6 in a number of different scenarios. Of particular interest in these scenarios is how the proposed mechanisms deal with DNS operation across the two protocol realms (and whether it is possible to maintain any kind of reasonable operation of secure DNS in such a scenario).

Full charter: http://www.ietf.org/html.charters/behave-charter.html

The IETF and 3GPP held a joint workshop on IPv6 deployment strategies for 3GPP networks on 1 and 2 March. Dan Wing has produced a summary meeting report of that meeting, which was published in the IETF Journal v6.2 (http://www.isoc.org/tools/blogs/ietfjournal/?p=1702#more-1702). One of the important outcomes seemed to be a shared recognition that there is not community support for PNAT based proposals.

The work on the first set of new transition mechanisms for IPv6 networks to an IPv4 Internet (NAT64, DNS64, etc.) is wrapping up. Documents have gone to last call and and comments are being resolved.

Meeting minutes are available here: http://www.ietf.org/proceedings/77/minutes/behave.txt
Slides are available here: http://www.ietf.org/proceedings/77/

--------------

core (Constrained RESTful Environments) WG
(formed from 6lowapp (Application Protocols for Low-power v6 Networks) BOF

The 6lowapp BOF has indeed been chartered as a working group, called CoRE. CoRE is providing a framework for resource-oriented applications intended to run on constrained IP networks. A constrained IP network has limited packet sizes, may exhibit a high degree of packet loss, and may have a substantial number of devices that may be powered off at any point in time but periodically "wake up" for brief periods of time.

Full charter: http://www.ietf.org/dyn/wg/charter/core-charter.html

CoRE held its first working group meeting at IETF 77. The 6lowapp BOF has been considering whether different protocols, or modifications to existing protocols, are needed for very low power devices that may proliferate for sensor type networks. There is a great deal of energy on work in this area with protocol proposals being discussed on the mailing list.

There are no meeting minutes available; however, the consolidated slideset for the meeting is available here: http://www.ietf.org/proceedings/77/core-0.pdf

--------------

intarea (Internet Area) 

The Internet Area Working Group (INTAREA WG) acts primarily as a forum for discussing far-ranging topics that affect the entire area. Such topics include, for instance, address space issues, basic IP layer functionality, and architectural questions. The group also serves as a forum to distribute information about ongoing activities in the area, create a shared understanding of the challenges and goals for the area, and to enable coordination.

Outcomes:
	* Shared Addressing Issues draft has been adopted as intarea WG work item.

Minutes: http://www.ietf.org/proceedings/77/minutes/intarea.txt


--------------

v6ops (IPv6 Operations) WG

The IPv6 Operations Working Group (v6ops) develops guidelines for the operation of a shared IPv4/IPv6 Internet and provides operational guidance on how to deploy IPv6 into existing IPv4-only networks, as well as into new network installations.

Full charter: http://www.ietf.org/html.charters/v6ops-charter.html

Meeting minutes are available here: http://www.ietf.org/proceedings/77/minutes/v6ops.txt

Slides are available here:

http://www.ietf.org/proceedings/77/v6ops.html

_____________________________________
Security and Stability
Securing the DNS and greater assurance in routing is critical for the ongoing expansion and evolution of the Internet in all areas of our societies and economies.
_____________________________________



dnsop (Domain Name System Operations) WG

The dnsop WG works on various operational aspects of the Domain Name System.

Full charter: http://www.ietf.org/dyn/wg/charter/dnsop-charter.html

Yahoo! presented a proposal for improving the behavior of recursive name resolvers for IPv6. There was little time on the agenda for this but it received quite an animated discussion in the meeting and on the mailing list afterwards. One of the discussions focused on the measurement of brokenness for IPv6 connectivity. Google has shared numbers for this in previous and subsequent meetings. Both Yahoo! and Comcast reported that they are in the process of collecting measurements of their own to get an assessment of brokenness of IPv6 connectivity.

No minutes for the working group meeting were published. 
Slides are available at: http://www.ietf.org/proceedings/77/dnsop.html

--------------

karp (Keying and Authentication for Routing Protocols) WG

Many routing protocol deployments, if they use authentication at all, are using older (possibly deprecated) cryptographic algorithms and are missing some modern security mechanisms, like replay protection, algorithm agility, or key rollover. In addition, many use the same key permanently. This needs to be fixed. Additionally, key management for routing protocols needs to be added to easily address the terminated-employee problem of compromised shared secrets. Such key management needs to work over multicast media, and needs to work directly over the link layer in some cases (since routing depends upon it).

Full charter: http://tools.ietf.org/wg/karp/charters

The karp working group was recently chartered and held its first working group meeting at IETF77. Initial versions of the three base documents intended to guide the efforts of the working group were discussed. The working group is still in the process of refining the requirements and processes for moving forward with the working group. There is also a fair amount of effort focused on getting the security and routing communities to understand the perspectives of each other. The collaboration of the two communities of expertise is critical to successful outcomes in this working group. 

Meeting minutes are available at: http://www.ietf.org/proceedings/77/minutes/karp.html
--------------

RRG (Routing Research Group)

The Routing Research Group (RRG) is chartered to explore routing and addressing problems that are important to the development of the Internet but are not yet mature enough for engineering work within the IETF.

Group charter: http://www.irtf.org/charter?gtype=rg&group=rrg

The RRG has been considering a number of proposals for solving the route scaling "problem" in the routing infrastructure. At this meeting, the chairs discussed the three basic classes of proposals received, divided based on where they stop non-aggregatable addresses. The co-chairs made the following recommendations: 1) AIS as immediately deployable solution to relieve pain today; 2) ILNP as the long term solution; and, 3) further work on renumbering support. 

Meeting minutes are available at: http://www.ietf.org/proceedings/77/minutes/RRG.txt 

____________________________________
Trust and Identity
As public concerns increase about security of infrastructure, privacy, trust, and identity on the Internet, these themes recur in several working group discussions.
_____________________________________

Applications Area Open Meeting

At this session, two new SASL related drafts of interest to identity providers were discussed.

A SASL Mechanism for SAML: http://tools.ietf.org/html/draft-wierenga-ietf-sasl-saml-00

This memo specifies a SASL mechanism for SAML 2.0 that allows the integration of existing SAML Identity Providers with applications using SASL.

A SASL Mechanism for OpenID: http://tools.ietf.org/html/draft-lear-ietf-sasl-openid-00
This memo specifies a SASL mechanism for OpenID that allows the integration of existing OpenID Identity Providers with applications using SASL.

No minutes for this meeting were published.

--------------

httpstate (HTTP State Management Mechanism) WG

The HTTP State Management Mechanism (aka Cookies) was originally created by Netscape Communications in their informal Netscape cookie specification ("cookie_spec.html"), from which formal specifications RFC 2109 and RFC 2965 evolved. The formal specifications, however, were never fully implemented in practice. RFC 2109, in addition to cookie_spec.html, more closely resemble real-world implementations than RFC 2965, even though RFC 2965 officially obsoletes the former. Compounding the problem are undocumented features (such as HTTPOnly), and varying behaviors among real-world implementations.

The working group charter is available at: http://www.ietf.org/dyn/wg/charter/httpstate-charter

This working group will create a new RFC that:
- obsoletes RFC 2109,
- updates RFC 2965 to the extent it overlaps or voids RFC 2109, and
- specifies Cookies as they are actually used in existing implementations and deployments.

No minutes for the working group meeting were published. 
--------------

The Moonshot Bar BOF 

This Bar BOF (outside the formal agenda) discussed federated authentication beyond the web.

A description of the informal meeting is available at: 
http://www.painless-security.com/blog/2010/02/12/moonshot1

This meeting focused on a description of the problem space and possible solutions. The outcome of the discussion was to pursue an official BOF at IETF78. Subsequent discussions have resulted in the Federated Authentication BOF planned for IETF78 and a draft charter for a working group. 

Related documents provided as input to the meeting include: 

A GSS-API Mechanism for the Extensible Authentication Protocol, 
http://www.ietf.org/internet-drafts/draft-howlett-eap-gss-00.txt

"Project Moonshot: Community briefing paper for the TF-EMC2 & TF-Mobility meetings, Vienna, 16-18 February 2010", 5 February 2010, Josh Howlett, JANET(UK): http://www.terena.org/mail-archives/mobility/pdfEKnl2kkFsw.pdf

--------------

newprep (Stringprep after IDNA2008) BOF

The handling of non-ASCII strings in Internet protocols is a difficult problem that has still not been solved in a generalized way. In 2002, the IETF defined a method for preparation and comparison of internationalized strings that could be re-used by various applications. This method, stringprep (RFC 3454), has been re-used in several Internet protocols that have defined "profiles".

In completing revisions to the IDN technology, the IETF's IDNAbis WG decided to move away from the use of stringprep in domain names, instead defining sets of allowed and disallowed characters based on Unicode character properties (often called an "inclusion approach") rather than defining explicit mappings of Unicode characters as in stringprep (an "exclusion approach"). 

However, any move away from stringprep by existing profiles would introduce backward compatibility issues and migration challenges, which need to be weighed against the benefits of a new string preparation technology.

Minutes are available at: 
http://www.ietf.org/proceedings/77/minutes/newprep.txt

--------------

oauth (Open Authentication Protocol) WG

OAuth allows a user to grant a third-party Web site or application access to their resources, without necessarily revealing their credentials, or even their identity.

The full charter is available at: http://tools.ietf.org/wg/oauth/charters

Current topics include a discussion of signatures, disposition of OAuth WRAP, and use cases. The focus for signatures is on "signing requests" not on "signing tokens". Signing requests secures the direct communication between two parties (consumer and authorization server / consumer and protected resource). In contrast, signed tokens are used in stateless authorization server designs to protect token contents from modification thus establishing trust between authorization server and protected resource. http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy

Also on the agenda was the disposition of OAuth Web Resource Authorization Profiles (WRAP) (http://tools.ietf.org/html/draft-hardt-oauth-01), use cases ((http://trac.tools.ietf.org/wg/oauth/trac/wiki/OauthUseCases), and discussion of the OAuth 2 specification.

Minutes for this working group are not published at this time. 

--------------

rydeirde (Registry Data Escrow/Internet Registration Escrow) BOF

In the context of domain name registries, registration data escrow is a requirement for the current generic top-level domains and it is expected to be for new registries. Some country code top-level domain managers are also interested in implementing registration data escrow for themselves. There is also such a requirement for ICANN's generic top-level domain accredited registrars.

The desired outcome of this BOF was to have a mutually agreed specification of the contents and format of the deposits, allowing extensions for new services and objects.

The BOF outcome was that there was a majority of individuals who thought this effort should be pursued in the IETF; however, there were significant concerns to be addressed including additional clarity and limited scope in the charter. 

Meeting minutes are available at: 
http://www.ietf.org/proceedings/77/minutes/rydeirde.txt

===================================================