Claims of encryption having a effect on network bandwidth optimisation methods have been coming thick and fast to the IETF since IETF89. To help understand the real use cases and issues the IAB organised the Managing Radio Networks in an Encrypted World (MaRNEW) Workshop working with the telecoms association, GSMA. The workshop aimed to both develop ideas for research and standards for network management in an encrypted world as well as bring together mobile operators and IETF attendees. 50 people attended the workshop from various industries such as mobile operators, OEMs, CDN providers, content providers, and browser vendors.
The workshop had seven major sessions which covered scene-setting, network or transport solutions, application layer issues, and regulation. Scene-setting and declaring items in scope was paramount; the group agreed at the beginning of the workshop that encryption is increasing and should not be broken, and network management has to work. Policy and interception were marked clearly out of scope. Other scene-setting topics covered the issues experienced when deploying encryption covered in Effect of Ubiquitous Encryption, and the importance for user privacy and difficulties with trust models. These sessions came early so later panels understood the key requirements of user privacy and existing network management solutions.
Network or transport solution sessions tackled suggestions raised in position papers including transport optimisation and cooperative frameworks (either sending data up or down for network management benefits, or both). The application session was perhaps most insightful, as CDNs and content providers explained the real monetary losses when mobile networks don’t adhere to standards. Finally a session on technical response to regulatory action made clear the regulation placed on mobile operators and how all industries could respond to this action for the benefit of everyone.
Throughout the two days a number of ideas and suggestions were made on how to tackle the issue of mobile network management for encrypted traffic. Some of these included: evolving TCP (or using a new protocol) for better congestion control, Mobile Throughput Guidance for first hop RAN information sending up to endpoints, tagging packets for latency bandwidth tradeoff (research is needed to determine if metadata is necessary for network management and if so, how much metadata is really needed), and blind caching through storing encrypted content and fetching keys / location from the original content server. Better metrics and metric standards were requested as past hand-wavy claims about network management have not been helpful to providing a better service to users. Perhaps most importantly there was a number of calls for better collaboration between network and content providers; some great stories showed how content providers have upgraded network providers equipment in effort to improve end-user experience. By working together we can achieve great user experience.
Minutes and a workshop report now have to be generated, and IETF94 attendees will get a more in-depth overview of the workshop in the SAAG meeting. From this week the Technical Programme Committee will go through the minutes and create a list of all the possible solutions, whittle these down to a feasible list and discuss these publicly on an IETF mailing list, most likely email@example.com. Some of these solutions will turn into real work items, these may be new IETF drafts, groups, supporting existing drafts, research or collaborative projects. Look out for new information soon!
As a co-chair of the workshop I want to say thank-you to the attendees and the IAB for helping us organise the event and to provide a place to discuss these issues openly. I hope all attendees had a great time and that we will all continue to work together for better user experience, user privacy, ubiquitous encryption, and fast mobile connections. Thanks again!
Natasha Rooney, MaRNEW Co-chair, GSMA
Not what you think! This blog post is not about the novel by George Orwell. Although the topic is related, as all-encompassing surveillance is a big question both in the novel and in today’s Internet communications. One of the things that can make surveillance too easy is when the technology we use has weaknesses.
The IETF recently approved RFC 1984 to the status of “Best Current Pratice”, or a document that has the strength of a recommendation for the broader Internet community. This document discusses the need for strong, cryptographic protection of communications, and makes a case that limiting access to these tools will weaken everybody’s security in the Internet. The RFC was relevant in 1996 when it was first published and still is today; the principles described in RFC 1984 have held up well in the nearly two decades.
For both symbolic reasons and to better ensure that IETF specifications reflect the spirit of RFC 1984, the IETF participants wanted to recognize the substantive content of RFC 1984 as a BCP.
The Security Area of the IETF had rough consensus to change the status of RFC 1984 to BCP in-place. The possibility of revising the text of RFC 1984 was discussed, but rejected because a) the current text is still fine, b) any changes we’d likely make now wouldn’t improve it significantly, c) affirming the continuity of the IETF’s position is valuable and even d) keeping the RFC number is worthwhile. Thus, though this update is exceptional, this in-place status change is overall considered reasonable and beneficial.
Jari Arkko, IETF Chair
Picture credits Wikimedia and Jari Arkko
The Managing Radio Networks in an Encrypted World (MaRNEW) workshop is starting today. This is a joint workshop between the IAB and the GSMA, and the focus will be on managing networks, particularly mobile ones, under the assumption that much of Internet traffic is or will be encrypted. This complicates a number of network management operations, such as traffic prioritisation. What can be done to ensure that these important operations can be done as efficiently as possible?
I am excited to wait for the discussions and new ideas coming out of this workshop. The workshop chairs Natasha Rooney and Joe Hildebrand will be writing a blog article after the workshop to report their initial impressions, and later on the IAB will be publishing official transcripts and reports.
Jari Arkko, IETF Chair
A key aspect of the IETF is running code, and we often apply our technology in our meetings, or run experiments to determine how well something works or gather information about networks.
Prior to IETF-93 we had some discussion of specific experiments and whether those experiments, while technically interesting, were allowable in the location that we were at. At the time there was too little time to determine a proper answer for that. Since then the IESG and IAOC have discussed what to do about this topic in general.
The legal frameworks in various countries can in some cases be suboptimal, but it is the environment that we must operate in. We are planning to set up a small team to look at experiment proposals and to determine if they have issues that are likely to require closer evaluation. The charter for the team is at the end of this message.
Would this team be useful from your perspective? Comments appreciated.
IETF Experiment Ethics Review Board
The purpose of the IETF Experiment Ethics Review Board (EERB) is to consider whether or not proposed experiments or studies using the IETF meeting network are acceptable. The EERB advises the IETF chair in the approval of proposed meeting experiments.
Composition of the EERB
The EERB will consist of members selected by the IETF chair. The members will include at least one member of the NOC team and at least one member of the IESG, IAOC, or IAB. The EERB members as a whole should include members familiar with research ethical review panels from different geographical regions, as legislation, custom and practice differ significantly in different places. The IETF chair may appoint additional members as desired. Members must recuse themselves from the EERB if involved in, or closely connected to, a study being considered.
When is approval from the EERB needed?
Ethical approval is required before any studies involving human participants and the IETF meeting network can commence. It is important that researchers contemplating experiments take into account the provisions of legislation relevant for the location of the experiment.
The purpose of the EERB is to determine if there are potential ethics or privacy issues. If after careful evaluation the board finds that there are no issues that would cause concern, then the EERB will indicate that they have no objection to the experiment from their perspective. If there are some potential issues, the role of the EERB (at least in its initial form) is only to ensure that an approval obtained from another research ethics body (e.g. an university IRB) exists – evidence of same can be submitted prior to the commencement of the study (see procedures below). The EERB can review this external approval and base its decision solely thereon.
In the absence of an external approval, the EERB will not be able to provide an approval by itself, but given its composition, it may potentially provide useful advice to the applicant and the research institutions involved, which may in turn lead the approval later on.
In some special cases, the EERB may also in addition determine that IETF legal counsel or other legal help may be required confirm that there is no significant risk to the IETF. The IAOC is prepared support the EERB in these situations. The board is not intended to give legal advice to researchers proposing an experiment, however. The responsibility for legal compliance rests on the researchers.
To contact the EERB send email to firstname.lastname@example.org *. When informed of a planned study, the EERB must provide an initial response within one week. The goal of the initial response is to assist the researchers in submitting an application, if one is needed. Once an application has been submitted, the EERB will consider each application and normally provide a response within two weeks but not more than one month later. It therefore makes sense to start early, in particular if targetting a specific IETF meeting.
The IETF chair will check with the EERB on all proposed experiments for an upcoming IETF meeting, and an EERB recommendation is a prerequisite for the approval of an experiment during an IETF or in the IETF network.
EERB Application Form
The EERB is responsible for deciding what information is required to be submitted in an application. The latest version of the application form and instructions will be maintained at http://www.ietf.org/experiment-ethics-review-board *.
Jari Arkko, IETF Chair
(*) Links and e-mail addresses are not yet active.
As part of the IETF standards process, our steering group (IESG) recently approved ‘The .onion Special-Use Domain Name’ (draft-ietf-dnsop-onion-tld-01.txt) as a Proposed Standard. Because this might garner attention beyond the usual standard actions, I wanted to briefly summarize some points of the process to date, and share an outcome of the IESG’s discussion that suggests possible future IETF work.
As the technical summary that accompanied the announcement to the IETF community indicated, the approved document uses the Special-Use Domain Names registry established by RFC 6761 to register ‘.onion’ as a special-use name. In effect, ‘.onion’ will be treated in the same way .local, .localhost, and .example have been dealt with previously—that is, outside the global Domain Name System (DNS). Adding .onion to the Special-Use Domain Names registry will also enable hosts on the Tor network to obtain validated SSL certificates.
The registry and the process defined in RFC 6761 for updating it are based in IETF’s responsibility for the DNS standard, and for promoting interoperability among Internet protocols. The reservation followed established IETF processes for open participation and discussion. There is no IETF specification about Tor, but the registration relates to its interaction with DNS.
The approved document is a product of the IETF DNSOP Working Group. Some contention arose during the processing of the document in the working group. There also was some discussion about needing to clarify or adjust RFC 6761 before making any additions.
During its discussions, the IESG considered the existing broad deployment and the potential security impact of not registering .onion as a special name to be important factors. For example, Certificate Authorities (CAs) might stop issuing certificates for .onion names, compromising some users’ ability to use software implementing the Tor protocols. Most importantly, the registration does meet the criteria in RFC 6761 which is our current process.
However, subsequent to this action, the IESG believes RFC 6761 needs action, and substantial community input. It needs to be open for review and modification because the current process is unscalable. Several other names had also been submitted for consideration as special names, and the RFC may not give adequate guidance about how when names should be identified as special names. Special names should also be, as the name implies – special and rare. The DNSOP working group is chartered to address this RFC 6761 review.
Jari Arkko, IETF Chair
Picture credits: Wikimedia.
The NETVC working group aims to create a video codec that can be used in open-source software, in addition to proprietary software and hardware encoders. Historically, most open-source software has been unable to make use of royalty-bearing codecs, for two key reasons: first, having to pay royalties at all on a product that yields no revenue is fiscally unsustainable. This is further complicated by the fact that the broad, uncontrolled distribution of open-source software makes accounting for per-unit costs impossible.
Beyond use in open-source software, the availability of a standardized, high-quality, royalty-free video codec is expected to remove friction from the market for applications and devices that transmit video over the Internet. This has an overall beneficial effect on Internet users.
In 2012, the IETF’s CODEC working group published the specification for what is arguably the best audio codec today, Opus, with a similar set of goals. Opus has seen fairly broad adoption on the Internet, due to its high quality and royalty-free licensing status. NETVC seeks to replicate that success for video codecs.
Last month, Cisco contributed its Thor video codec to the NETVC effort, which joins Mozilla’s Daala codec as input to our work. I’m excited that Cisco has come forth with an additional pool of techniques to draw from, and working group participants wasted no time in trying to figure out how to combine them into a best-of-breed codec. At a weekend “hackathon” before the IETF meeting in Prague, a group of NETVC participants collaborated to perform preliminary merging of some specific, easily-isolated techniques from both codecs together, with promising results.
Almost as important as its actual implementation, Thor comes to the IETF with a pool of IPR that Cisco has declared as being available on royalty-free terms. This opens up many avenues of technical progress that would have otherwise been unavailable to NETVC.
Finally, I’d like to quantify where the quality of NETVC’s eventual output stands as compared with H.264 and HEVC (also known as H.265, the successor codec to H.264). The working group has a stated goal to have “comparable or better performance” when compared with codecs in widespread use. I’ll start this quantification by emphasizing that the NETVC working group had its first meeting last month, and that the input codecs are still subjects of considerable research.
With that caveat, the results achieved by the Daala team have been objectively better (using industry-standard quality metrics) than H.264 since approximately mid-February. Early testing by NETVC participants shows that Thor is also somewhat better than H.264 already. By merging the techniques used by both codecs and applying further refinements, we expect the codec produced by NETVC to surpass the performance of HEVC.
I’ll note that this doesn’t mean that NETVC’s task is largely complete. There’s still considerable work to be done in combining the best aspects of Thor and Daala into a unified codec (along with any other techniques that are brought to the IETF by interested parties), as well as developing runtime efficiency improvements that will allow using the codec to compress media in real-time on normal consumer devices.
Adam Roach, IETF NETVC Working Group Co-chair
Photo credit (c) Stonehouse Photographic / Internet Society