Monthly Archives: February 2015

Ensuring Continuity of the IANA Registries

One question that often comes up regarding the IANA Stewardship transition is how to ensure that the IANA protocol parameter registries continue to serve the worldwide Internet community. The current system has been working for more than three decades, and the IETF transition plan is actually a continuation of existing practices that evolved over the years; it does not involve any untested practices.

The audience for the IANA protocol parameter services are the developers for software that runs on the Internet. ICANN makes the actual allocations and maintain a public database of all allocations. There are thousands of requests for protocol parameters each year. The IETF sets the policies for the IANA protocol parameter registries, and the allocations are handled according to the policy for that registry– professionally and promptly. Should any problems develop, they are addressed first by the staff and volunteers working on the topic, then by the Internet Engineering Steering Group (IESG). If all else fails, the Internet Architecture Board (IAB) in its oversight role will decide what needs to be done. This structure provides defenses against many organizational failures.

But how do we deal with possible future events that might affect that stability? For the sake of argument, let’s assume that ICANN for some reason failed to operate the services properly, or that the organization would be brought under the control of some rogue actors that do not respect the multistakeholder way of working.

Note: ICANN provides excellent IANA services, and we find the above scenario very far fatched. Nevertheless, being prepared for all situations is good.

As with any problem, the IETF would attempt to resolve issues with IANA staff, including escalation of the issues to management and beyond, before selecting a different party to provide IANA protocol parameter registration services. As the IETF transition plan says:

Obviously such action would only be undertaken after serious
consideration.

We would do this first at the level of our normal operations. If that does not help, the “serious consideration” involves going through the steps of talking with the ICANN board, and the global community of Internet technology developers, researchers, and vendors.

But ultimately, given this worst-case scenario, the IETF maintains the authority to select the provider for IANA protocol parameter services. This is how the agreement from 2000 is set up. This ultimate accountability tool ensures that no matter how bad things become, the IETF can still get the IANA protocol parameter services for the global Internet community.

Bad things happening for the bookkeeping function should not be the only concern. Another question is whether the policy processes could come under pressure, and fail. In the case of the IETF, we have almost thirty years of history that shows we can deal with the problems that arise. During those thirty years we have also developed mechanisms to come to conclusions in an open and transparent manner, deal with the selection of leadership, and handle various contingencies. For instance, we have a well-defined and tested appeals process described in Section 6.5 of RFC 2026.

The IETF also has a leadership selection process that defends against any attempt of individual organizations to exert undue influence and ensures that rogue members can be recalled through community action. These processes are described in RFC 3777.

Together, these things provide a sound basis for continuity of protocol parameter services, even in the face of dangers from failed organizations, rogue actors, and other events outside the control of the multistakeholder community.

Jari Arkko, IETF Chair and Russ Housley, IAB Chair

HTTP/2 Approved

After more than two years of discussion, over 200 design issues17 drafts, and 30 implementations, the HTTP/2 and HPACK specifications have now been approved by the IETF’s steering group for publication as standards-track RFCs. The result is that HTTP/2 will help provide faster user experience for browsing, reduce the amount of bandwidth required, and make the use of secure connections easier.

The HTTP Working Group began work on HTTP/2 in 2012 by selecting Google’s SPDY protocol as the starting point, holding a series of six interim meetings to incorporate community feedback. This resulted in substantial changes to the format of the protocol, its compression scheme, and its mapping to the semantics of HTTP.

The resulting protocol is designed to allow a seamless switch between HTTP/1 and HTTP/2, with minimal changes to applications and APIs, while at the same time offering improved performance and better use of network resources. Web users largely will be able to benefit from the improvements offered by HTTP/2 without having to do anything different.

A key point in the protocol development process was the iteration the working group did between protocol updates, and implementations and testing. Certain draft protocol versions were labelled by the working group as “implementation drafts”, and the participants — many web browser and web server providers — updated their implementations and tested out the protocol changes. Most of the interim meetings included part of a day spent on hands-on interoperability testing and discussion. The result is a thoroughly validated protocol that has been shown to interoperate and that meets the needs of many major stakeholders.

The HTTP/2 work specifically embodies the key IETF tenet about the value of “rough consensus and running code.”

See the HTTP/2 home page, Frequently Asked Questions list (FAQ), and the chair’s blog article for more information. The specifications themselves are available here for HTTP/2 and HPACK.

Mark Nottingham, HTTPBIS Working Group Chair and Barry Leiba, Applications Area Director

New Proposals for IETF-92

The deadline for submitting proposals for new working groups for IETF-92 is approaching fast. As the schedule page notes, proposals are due this Friday, 23:59 UTC. Please talk to your Area Directors as soon as possible if you have a proposal. For instructions on how to make a request, see the procedures or RFC 5434.

Also, if you have not registered yet, this would be a good time to do so. All the information regarding the meeting can be found here.

Jari Arkko, IETF Chair

SEMI Workshop

I’m on the train this morning after the two-day Stack Evolution in a Middlebox Internet (SEMI) workshop at the Swiss Federal Institute of Technology (ETH) in Zürich. We had a very successful discussion sponsored by the IAB, the Internet Society, and the Communication Systems Group at ETH. Many thanks to the sponsors, organizers, and participants. Each played a vital role in making the workshop a success.

The IAB Stack Evolution Program provided the vision for the workshop, and some served on the workshop program committee. The forty attendees were selected based on position papers and expertise, allowing the program committee to bring together many viewpoints.

The problems we explored have been discussed before at the IETF, but not all at the same time. They included:

  • Application developers have tried to use UDP, but find that many middleboxes, including corporate firewalls, block or degrade the performance of their protocols. This has been particularly evident with WebRTC deployment experience.
  • There are a variety of new services that desire a more direct communication between applications and the network path. This has proven difficult in the past because each protocol that uses UDP requires special handling, often needing custom code in each middlebox on the path.
  • Network operators sometimes find UDP challenging because it is hard to determine flow context on a per-datagram basis. Information about the flow would improve their ability to reason about the flow with respect to policy and performance.
  • In November, the IAB issued a Statement on Internet Confidentiality. Increasing levels of encryption will amplify the above problems. As we noted in that statement, hard work will be needed to reach confidential operation by default.

During the workshop, we discussed what information could be exposed outside an end-to-end encryption context that would allow good policy decisions by middleboxes on the path without compromising the confidentiality or privacy of end-user data.

We concluded that there must be clear incentives for application developers, network operators, and equipment vendors to spur real-world deployment. Possible incentives might include:

  • Easier to deploy new Internet applications
  • More effective use of UDP by applications on more networks
  • Increased confidence for firewall administrators in the coherence of UDP flows
  • Ability for network operators to add value to traffic transiting their networks
  • Improved user confidentiality and privacy

We will write a workshop report to describe the discussion in detail. Several people signed up to write Internet-Drafts, which will hopefully lead to one or more BoFs in the next year.

Russ Housley, IAB Chair