IETF Technical Plenary Session Monday, 23 March 2015 Dallas, Texas, USA Minutes by Cindy Morgan, IETF Secretariat 1. Welcome Russ Housley welcomed the community to the IETF 92 Technical Plenary. 2. Reporting 2.1. IAB Chair Russ Housley delivered the IAB Chair report: On behalf of the IAB, Russ Housley thanked outgoing IAB members Joel Halpern, Eliot Lear, and Xing Li. Russ Housley reported that Andrew Sullivan was elected as the IAB Chair for 2015-2016. Russ Housley noted that since IETF 91, the IAB has: - Published an IAB statement on Internet Confidentiality - Published an IAB statement on the NETmundial Initiative - Published an IAB statement on Identifiers and Unicode 7.0.0 - Published an IAB statement on Liaison Compensation - Provided comments on the CSTD Report Mapping International Internet Public Policy Issues - Agreed to continue the Liaison Relationship with the ICANN Root Server System Advisory Committee (RSSAC) - Published RFC 7397: Report on Smart Object Security Workshop - Published RFC 7452: Architectural Considerations in Smart Object Networking Russ Housley noted that the IAB is currently in the process of appointing two members to the ISOC Board of Trustees, and plans to have the candidates to the IESG for confirmation by the end of March. Since IETF 91, the IAB has also appointed Benson Schliesser to IAOC and appointed Paul Wouters to ICANN Technical Liaison Group. The IAB and ISOC are planning a joint workshop on Coordinating Attack Response at Internet Scale (CARIS) in June; more information is available at . 2.2. RSE and RSOC Chair Heather Flanagan delivered the RFC Series Editor (RSE) report: Heather Flanagan noted that the RFC Production Center (RPC) contract is required to go out to bid in 2015; a vendor selection committee has been chosen, and the revised statement of work should go out for community comment soon. The RFC Editor held an experimental writing lab during IETF 91. The feedback from the participants was very positive; however, it was a significant work load for the RPC. Going forward, the RSE is considering creating a new mailing list for English language usage questions, and the RPC will continue to update the document that highlights common issues the RPC encounters when editing documents. Heather Flanagan reported that most of the drafts for the RFC format update are now stable, although they will continue to be updated as more is learned through implementation. The community comment period on the Statements of Work (SOWs) is now closed, and the RFP should go out soon. Heather Flanagan reported that work on Digital Object Identifier assignments, the RFC Editor website redesign, and the indexing of RFCs in Google Scholar are all proceeding. 3. Technical Topic: Architectural Considerations in Smart Object Networking Dave Thaler noted that RFC 7452, "Architectural Considerations in Smart Object Networking," is the result of IAB observations that: - Many non-IP-based smart object devices are being made and used - Various forums exist that define profiles for non-IP-based devices - Some of them believe that IP is too heavyweight In April 2012, RFC 6574, "Smart Object Workshop Report," recommended that the IAB develop architectural guidelines about how to use existing protocols. RFC 7452 is the result of that work. Dave Thaler and Hannes Tschofenig presented an overview of the Architectural Considerations in Smart Object Networking. The slides presented are available at: At the end of the presentation, Mary Barnes moderated a question-and- answer session with the audience. * Mike Jones asked where the IETF's points of leverage are in this conversation. Once a product has made it to the marketplace, putting an expiration date on that product is not commercially viable. Hannes Tschofenig replied that the people who are working in that space are not only writing code, but also developing open source software, and that he hopes that companies will focus on providing competitive technologies rather than redesigning security protocols. By reusing existing specifications and code, they can avoid many of the pitfalls. Dave Thaler added that the leverage is that companies make decisions based on what is the cheapest for them, and if the IETF can provide them with a larger ecosystem of viable tools, that will benefit the companies working in this space. * An unidentified member of the audience noted that the presentations talked about a shelf-life for devices, and asked what the impact on the sustainability of the code and resources would be. Hannes Tschofenig replied that the idea of putting an expiration date on IoT devices is not new; it also showed up in a recent FTC report on the Internet of Things, and was inspired by Microsoft discontinuing Windows XP. He added that open-source software may not be for everyone, but that it is difficult to make recommendations if a company goes bankrupt. * Christian Huitema noted that if data is being collected, there must be privacy controls; if a smart watch is sending out radio signals, then the person wearing that watch can be physically tracked. Hannes Tschofenig agreed that this is a problem that does not yet have a satisfactory solution. Dave Thaler added that this is one of the problems being worked on in the IAB's Privacy and Security Program. * Rene Struik observed that one of the main impacts is on the life cycle. Questions about how, when, and where to do initial keying, whether to put an identifier on a device, and how to do binding are not traditionally well-addressed by the IETF. He added that there is sometimes a tendency to water down a technology in order to meet a specific cost figure. With an IoT device, as soon as you have to have a human in the loop, you have already spent more than the device itself costs. He expressed a wish that some of these considerations be tackled by the IETF. * Bernard Aboba asked how Moore's Law will be a benefit here, given the energy constraints. Hannes Tschofenig replied that there are interesting economics at play. The large volume of devices will create new possibilities; high- volume chips originally taken from mobile phones are now available at cheap prices and can be applied to devices in completely different sectors. Dave Thaler warned, however, that Moore's Law will help the attackers as well. * Phillip Hallam-Baker noted that many vendors have a model where the customer owns a device but ends up renting the service; if the service provider gets bought, then the device becomes useless. How can the user look at their device and see what protocol is being used, or control the protocol being used? Dave Thaler replied that even if the user can see the protocol being used on the device, there still may be a proprietary schema in play. * Kerry Lynn agreed with the need to do secure updates. He asserted that randomness needs to be built into the hardware, and encouraged people to work on that. * Michael Richardson said that he was aghast at the idea that IoT devices need to be upgradeable or else have an end-of-life on them; he argued that there needs to be a common, secure update protocol that is small enough that devices can run it without a buffer. He noted that it is the software that should have the end-of-life; if a device is not field upgradeable, then maybe it can be upgraded by taking it back to the store. Dave Thaler noted that many people have expressed similar sentiments. * Eliot Lear observed that the requirement for good random number generators is hindered by economics; coupled with the point about the end-to-end model, that brings a big challenge to the IETF to bring those things to IoT devices in an economically sensible way. * Matt Mathis noted that there is also a mechanism to force retirement. There have been recent stories of attacks delivered from home routers, and there is no way to remove those devices from the field. However, these devices are remotely brickable, and once a device's bad behavior reaches a certain threshold, it should just be bricked. 4. Highlight Two IAB Activities 4.1. Stack Evolution in a Middlebox Internet (SEMI) Workshop Brian Trammell reported on the Stack Evolution in a Middlebox Internet (SEMI) Workshop that was held in January 2015: The workshop was convened to discuss ossification of the transport layer and how to fix it for emerging applications like RTCWEB. During the workshop, the participants identified several goals: - Future work on middlebox cooperation (protocol/functionality/etc.), including: o mechanisms for detection of path characteristics o measurement for path impairment detection and troubleshooting - Better understanding of how transport should/must evolve, including applicability of present transports to specific use cases. - Interface improvement: expose more to applications about transport - Identify trust issues and deployment incentives in cooperation and evolution approaches The workshop participants concluded that there is a need to make data- driven engineering decisions about transport protocol extension. Service providers and platform developers have access to a great deal of data which, in aggregate, could better inform these decisions. Next steps include: - Writing the initial workshop report - Cooperation with ETSI NFV Forum on middlebox issues - Discussions on transport extensibility in area meetings - UDP encapsulation guidelines - Statement on architectural assumptions in transport evolution Further discussion will take place on the "How Ossified is the Protocol Stack" mailing list , as well as in the Session Protocol for User Datagrams (SPUD) BOF, the Transport Services (TAPS) WG, and the IP Stack Evolution Program. The transcripts, slides, and position papers from the workshop can be found at . 4.2. Statement on Identifiers and Unicode 7.0.0 Andrew Sullivan reported on the recent IAB Statement on Identifiers and Unicode 7.0.0: An issue was noticed during the expert review of Unicode 7.0.0, when a script contains both a precomposed form of a character and decomposed form of a character and those two forms are not canonically equivalent. Humans cannot tell the characters apart, but machines treat them as different. The problem turns out to be not uncommon; there are issues in both Arabic-script and non-Arabic-script characters. The IAB has called for further work on the topic. The Locale-free UniCode Identifiers (LUCID) BOF scheduled for later in the week is intended to get a better understanding of the issues. The IAB Statement on Identifiers and Unicode 7.0.0 can be found at: 5. IAB Open Mic The IAB took the stage for the open microphone session: - Jari Arkko, IETF Chair - Mary Barnes - Marc Blanchet - Ralph Droms (incoming IAB) - Joel Halpern (outgoing IAB) - Ted Hardie - Joe Hildebrand - Russ Housley (outgoing IAB Chair, continuing IAB) - Eliot Lear (outgoing IAB) - Xing Li - Erik Nordmark - Robert Sparks (incoming IAB) - Andrew Sullivan (incoming IAB Chair, continuing IAB) - Dave Thaler - Brian Trammell - Suzanne Woolf (incoming IAB) Heather Flanagan (RFC Series Editor) joined the IAB on stage. * David Black asked if the IAB wanted to say anything about Unicode normalization forms and how they have saved us in the past, or if that was a question for the Locale-free UniCode Identifiers (LUCID) BOF. Andrew Sullivan replied that in this particular case, there were two totally different characters that did not normalize to be the same. He encouraged people to come to the LUCID BOF to discuss this further. * Kerry Lynn asked how many cases there are where there are issues with certain kinds of characters in identifiers. Andrew Sullivan replied that the total number is not known; it is at least in the 10s but probably not in the 100s. Unfortunately, there are a lot of Unicode characters and we do not want to go through them all one-by-one. * Mike Jones observed that there are a lot of characters that are indistinguishable to humans. Was this not a problem before because normalization rules fooled them? Andrew Sullivan replied that it was already a problem; there was no property by which one could make a determination. Dave Thaler added that what distinguishes them all is the language, which is not really a property. * Warren Kumari admitted that he did not follow IDNA very closely, but that he thought that the Unicode Consortium said this was not going to be an issue. Andrew Sullivan replied that Unicode is really hard; the case that was stumbled upon was not the only one. There are several pages of text in the Unicode standard about how complicated this is. The problem can be recreated in other scripts because humans are involved, and humans have a history of making things messy. Marc Blanchet added that the scoping of the problem is the challenge for the IETF, as well as making sure that the IETF is fixing the same problem as the Unicode people. He encouraged people to attend the LUCID BOF to discuss the issues further. * Phillip Hallam-Baker said that he would like to see more on why middleboxes are being deployed. Man-in-the-middle attacks are worse than people know, and soon there will be more MITM certificates than real certificates. Some of those certificates are issued by those who want to break TLS for malicious reasons, but even more are issued inside corporations to solve internal network management problems that can only be solved by middleboxes. People need to be given the tools to manage their networks without breaking TLS. Ted Hardie replied that as things move to virtualized network functions, things can appear in the path in ways that they did not before. The IETF has a unique way of looking at the path, and presumes that the path is determined by the source and destination points. In the modern Internet, that is not necessarily true; middleboxes are necessary for certain network functions. He added that the SEMI workshop tried to be very clear that middleboxes in and of themselves are not evil. Given the desire for an unbroken, encrypted, confidential channel between the two end points, what is the minimum we need to expose in order to allow middleboxes to be able to function without creating privacy concerns. The basic thing being looked at is session semantics that tell the start and stop of the session so that you don't have to do heartbeats through the NAT to maintain that NAT binding. Ted encouraged people to come to the Session Protocol for User Datagrams (SPUD) BOF to work on this further. Ted Hardie assured the audience that the IAB Privacy and Security Program is very concerned with the TLS intercept issue. The IETF needs to match efforts to increase encryption and look at ways to add second sources of truth. The work is happening in many places (SPUD, UTA, etc.). * END