Birds of a Feather at IETF 105
Six sessions devoted to new work proposals will be scheduled on the IETF 105 agenda.
This week the IETF again turns its attention to Internet of Things (IoT) security with the release of RFC 8520 on Manufacturer Usage Descriptions (MUD).
Things are generally lightweight single-purpose network devices. There are a great many number of Things connected to enterprise, consumer, and industrial networks. Many can be found on the Internet through search engines such as shodan.io. Already, deployment of connected things such as printers, thermostats, heaters, dryers, coffee makers, toasters, light bulbs, curtains, door bells, and sprinkler systems are outpacing deployment of laptops and cell phones on our networks. And there are a lot of types of Things, so many that we do not even know how to properly count them, or even how to group them into common categories. Put in other terms, we probably already do not have enough network administrators on the planet to understand what these Things are doing on our networks. In enterprise terms, that means that these devices are likely either not receiving the access they need, or they have too much access. The problem is made even worse by The Department Gap, where the IT department isn't even told what Things are being connected to the network by other teams in order to meet a critical business need.
MUD attempts to address this problem by capitalizing on the assumptions that, unlike the general-purpose computers we use to surf the Web, IoT devices have a single or small number of uses, and that these uses may be tied to a predictable set of communications patterns. For example, it is unlikely that your Internet-enabled toothbrush–a real world device that uses a built-in camera to capture and report on dental hygiene–is going to need access to Netflix. If that toothbrush attempts to access Netflix, something fishy is happening. Since manufacturers are the ones that designed these Things, they are in a very good position to document what sort of access they need.
Put in terms that network administrators might find useful, device manufacturers are in a very good position to provide us most of what we need in IP-based access lists for their devices. MUD provides the basic framework to enable manufacturers to provide policy that can be used to generate IP-based access lists. The astute will notice that manufacturers cannot know what IP addresses should be listed in an access list. To address that issue, MUD establishes some abstractions, such as “my-controller”, “controller {URI}”, “same-manufacturer”, “manufacturer”, and the use of domain names, with the idea being that each will map to one or more devices that the device should be allowed to access, or not. These abstractions build upon and augment the IETF’s brand new access control list (ACL) model (RFC 8519). A simple example of how to construct a “MUD file” can be found at MUD File Maker.
The MUD file itself is served up via HTTPS, just like any other file. It thus has a URL associated with it. What is left is for devices to output that URL such that deployments can retrieve it. This can be done in any number of ways, including via DHCP (RFC 2131 and RFC 8415), Link Layer Discovery Protocol (LLDP), or, my favorite, via a device certificate in an EAP-TLS or Tunnel Extensible Authentication Protocol (TEAP) transaction (RFC 7170) .
So what’s the result of all of this? At the very least, it’s knowledge the network administrator can use to establish security policies that are appropriate for each device. And that means a smaller threat surface. Even better, that process can be automated for the administrator. A number of implementations have taken that step:
A key point to observe is that each of these MUD managers consumes a MUD file and then produces policy in a slightly different way. One has the MUD manager reside directly on the consumer router, one is more service provide focused and delivers policy down to the consumer router, and one makes use of a FreeRadius infrastructure to deliver updated per-session ACLs. There will be other approaches over time as the technology continues to mature.
First, check out RFC 8520. It’s a page turner.
Produce a MUD file for your device and maybe even test it against an implementation or two. To create a MUD file, go to MUD File Maker. If nothing else you will have documented what access your devices need. That’s a huge win, even for deployments that don’t automate access: at least you can point administrators to what access your devices need. And then have your device output a MUD URL. Guidance for this can be found at the Cisco DevNet site.
Ask for products that implement MUD. Ask manufacturers for their MUD files, so that you know what sort of access devices need. Consider implementing one of the MUD manager implementations mentioned above.
We think MUD is pretty cool stuff, but it’s not a panacea. It’s part of a healthy breakfast, not the whole breakfast. For that, manufacturers need to do what they can to keep their devices secure, including providing security updates to customers, as well as using secure coding practices and taking advantage of hardware trust anchors available in some of the newest IoT platforms.
Hao Zhou, Nancy Cam-Winget
Six sessions devoted to new work proposals will be scheduled on the IETF 105 agenda.
One of the IETF Administration LLC Board of Directors' key work items has been to develop policies for the IETF LLC. We are now beginning our first formal IETF community consultation during which we invite community comment.
Presentations by recent winners of the Applied Networking Research Prize (ANRP) were a highlight the Internet Research Task Force (IRTF) Open session at IETF 104.
Since 1993 the Tao of the IETF has functioned as the guide for new attendees to the IETF. Over time both the IETF and the Tao have changed. The last revision of the Tao was in 2012, which led us to believe it might be time for a new version.
At IETF 104, there was a great deal of activity related to various aspects of the IoT ecosystem across numerous working groups, Birds-of-a-Feather gatherings, the Thing-to-Thing Research Group (T2TRG), as well as side conversations. The IETF Hackathon preceding IETF 104, as well as spontaneous conversations in hallways and over meals around IETF 104, were also fruitful.
The IETF LLC Board met for a two-day face-to-face meeting last week in Washington, D.C.
IETF 104 in Prague featured what was by far the biggest and most successful IETF Hackathon ever.
Web Packaging is being considered for standardization. Would doing so create better Internet experiences? Consolidate more power into the hands of a few Internet giants? Make online content accessible to new audiences and monetizable in new ways? All or none of the above?
The new JMAP email protocol provides a modern, efficient, easy-to-use API, built on many years of experience and field testing.
The Internet Engineering Steering Group (IESG) spent two days of quality time exploring ways to improve the IETF at its annual retreat last week.
Prague proved once again to be a productive and fun venue to advance the work of the IETF.
For our 104th meeting we return to one of the IETF’s favorite cities: Prague, Czech Republic.
The publication of RFC 8250 Manufacturer Usage Descriptions (MUD) adds another building block for Internet of Things (IoT) security.
The Automated Certificate Management Environment (ACME) protocol, recently published as RFC 8555, you can set up a secure website in just a few seconds.
The YANG Catalog, a platform for publishing and accessing information about and tooling for developing and using YANG models, is entering a new phase as it transitions to a platform supported by the IETF Administration LLC.
Six sessions focused on potential new work to be added to the IETF 104 agenda.
An RFC updating DNS terminology was recently published, continuing a decades-long IETF practice of publishing documents to help introduce interested readers to protocol topics by going through the most important terms.
Comcast NBCUniversal, a long-time supporter of the Internet Engineering Task Force (IETF), has made a significant contribution to the IETF Administration LLC (IETF LLC), which was established at the end of August this year to provide an updated administrative and legal framework for the work of the IETF.
Just when you thought it could not get any better, the IETF Hackathon reached new heights, not just in number of participants or projects, but in meaningful contributions to the IETF community and the standardization process.
The IETF Administration LLC (IETF LLC) Interim Board has approved the 2019 budget as recommended by the IETF Administrative Oversight Committee (IAOC).
The DoH specification in RFC 8484 defines a standardized format and protocol for sending Domain Name System (DNS) queries through HTTP rather than the traditional DNS protocol.
The Internet is not merely about technology and business. The Internet affects many aspects of our lives and societies. And of course, our societies affect the Internet. One way that this happens is via regulation, which was a hot topic in the most recent Internet Governance Forum (IGF) meeting.
Bert Hubert, the founder of PowerDNS and author of RFC 5452, shares his views on forces influencing DNS protocol development.
From November 3 to 9, the IETF community gathered for its 103rd meeting in the bustling city of Bangkok. This was our first meeting in Thailand. The incredible hospitality, sleek venue, and delicious food provided a setting well-suited to a productive and enjoyable meeting.
From November 3 to 9, the IETF will gather for its first visit to Bangkok, Thailand. Here's snapshot of some of the sessions and topics on tap for the week.
Two years ago, the IETF chartered the QUIC Working Group to "provide a standards-track specification for a UDP-based, stream-multiplexing, encrypted transport protocol, based on pre-standardization implementation and deployment experience."
RFC8200 (STD86) was published in 2017, elevating the IPv6 protocol to Internet Standard. This had been the long-awaited end result of the decades-long experience of deploying and collecting feedback about the previous version of the IPv6 protocol specification (RFC2460) published in 1998.
Two Birds of a Feather sessions were approved for the IETF 103 meeting, one of which focuses on Remote ATtestation ProcedureS (RATS).
Requests for Comments (RFCs) are how we specify many protocols on the Internet. These documents are alternatively treated as holy texts by developers who parse them for hidden meanings, then shunned as irrelevant because they can’t be understood. This often leads to frustration and – more significantly – interoperability and security issues. However, with some insight into how they’re constructed and published, it’s a bit easier to understand what you’re looking at.
Two Ph.D. students describe their first participation at an IETF meeting during an Internet Research Task Force Measurement and Analysis for Protocol Research Group (MAPRG) session at IETF 101 in March 2018.
After more than 10 years, the IETF is making a major update to the administrative framework for supporting its work.
William Zhang, a high school student from Alexandria, Virginia, USA presented his work on Automatic Multicast Tunneling at IETF 101 in March 2018.
TLS 1.3 updates the most important security protocol on the Internet, delivering superior privacy, security, and performance.
What a week we had in Montreal for IETF 102! With a newly renovated venue ideally suited to the needs of the IETF community and the convergence of research, operational, and development communities all in one spot, attendees were able to make tremendous progress in a short amount of time.
IETF 102, taking place July 14-20 in Montréal, Québec, Canada, is shaping up as a unique gathering for people from across a wide array of Internet engineering backgrounds and disciplines.
Three community discussion sessions on wide-ranging topics have been approved for IETF 102 in Montreal.
Today, is the 6th anniversary of World IPv6 Launch. We have come a long way since June 6, 2012.
At the end of April the Internet Engineering Steering Group (IESG) gathered in Paris for its 2018 retreat.
The IETF has chartered a new working group to document changes to its administrative arrangements.
I am writing to share the sad news that Bob Braden has passed away. Bob's contributions to the development of the Internet were extensive.
IETF Hackathons began just over three years ago as a way of connecting Internet protocol development more closely with running code, and they have been growing ever since.
Just after IETF 101 in London, let’s analyze the current state of affairs in the YANG Data Models world.
The IETF community took full advantage of the opportunity to collaborate at the 101st IETF meeting last week in London, UK.
IETF participants are gearing up for an intense week of collaboration and discussion at IETF 101, with numerous sessions focused on new work proposals and our largest Hackathon yet.
One of the tasks of the IAB is to look at trends affecting the Internet. Recently, we've been discussing traffic flows and popular applications on the Internet, and the role of smaller vs. larger players in the Internet ecosystem.
A slate of new work proposals have been approved for scheduling at the upcoming IETF 101 meeting.
Bufferbloat is responsible for much of the poor performance seen in the Internet today and causes latency (called “lag” by gamers) even by your own routine web browsing and video playing.
Internet routers must be able to buffer packets: buffering acts like a shock absorber for transient overloads that arise when the input link is faster than the output link or packets arrive simultaneously on different links bound for the same destination.
The deadline to submit Birds of a Feather (BoF) proposals for IETF 101 is rapidly approaching: Friday, February 2 at 23:59 UTC.
The Internet Governance Forum’s meetings bring together Internet user communities, businesses, technical folk, and a set of UN and government bodies.
Thanks to everyone who provided further input about the revamped www.ietf.org website around IETF 100.
For years, the IETF has been driving the industry transition from an overloaded Software Defined Networking (SDN) buzzword to data modeling-driven management.
Hackers.mu is a developer group based in Mauritius made up of a wide range of people from different backgrounds: high school students, university students, professional engineers, and advisors to the minister of ICT.
IETF 100 wrapped up just over a week ago in steamy Singapore. In addition to our usual productive working group sessions, hallway conversations, and ad hoc collaboration, we took the opportunity to mark the milestone of the 100th meeting with looks backward and forward in the IETF’s trajectory (plus some bubbles and sweets) at the plenary session.
The YANG team delivered again at the IETF 100 hackathon. With our goal to help YANG model users and designers, we developed new automation tools.
IETF 100 is just around the corner. It will offer all the usual opportunities for high-bandwidth exchange among IETF participants and collaboration around specs, coding and interop work.
RFC 8188 builds on existing protocols to provide a new option for delivering trustworthy messages containing confidential information over the Internet.
A highly interactive workshop organized by the Internet Architecture Board raises important issues and generates ideas for significant follow-on work.
Birds of a Feather sessions (BoFs) are initial, informal, in-person discussions about a particular the topic of interest to the IETF community. BoFs may or may not lead to establishing an IETF Working Group.
With the intention to encourage the development of a solution to an issue currently under discussion within an IETF working group, I wanted to offer a personal view of a possible ways forward.
IETF Internet Area Director Suresh Krishnan provides a brief wrap up from IETF 99.
IETF 99 is about to kick off in Prague, Czech Republic. There is lots of exciting work going on across more than 100 working groups, plus Birds-of-a-Feather (BoF) sessions, plenary talks, and other meetings.
There has been a lot of progress on the project to revamp of the www.ietf.org website.
Working on technical standards in the computing, communications and networking industries often involves dealing with patents. Like most standards-development organizations (SDOs), the IETF has policies that deal with patents covering IETF protocols, specifications and standards.
5G is the latest generation of cellular network standards. There’s a tremendous amount of activity around it in the industry. But how does 5G relate to Internet technology? Are there 5G-related work items that the IETF should be working on, for instance?
On the joint day of the the recent IESG and IAB retreats, the group discussed a number of topics related to network operator activities for encrypted flows.
Last week I had the opportunity to participate at the 3GPP plenary meeting in West Palm Beach, Florida, USA, at the invitation of the 3GPP liaison to the IETF, Georg Mayer.
Before each IETF meeting, the Internet Engineering Steering Group (IESG) collects proposals for new working groups. We decide which ones are ready for community discussion on the IETF meeting agenda, with input from the Internet Architecture Board (IAB).
Recently published IETF RFCs aim to expand the capabilities of such services, and to make them more broadly implementable.
Mirja Kühlewind, a Transport Area Director, is featured in one of the periodic IETF Blog posts which highlight individuals who serve in IETF leadership roles, people who have recently begun working in the IETF, and organizations that make the work of the IETF possible.
The IESG held its annual retreat last week, meeting one day jointly with the IAB and two days on our own in Montreal, Canada.
Periodic posts on the IETF Blog highlight individuals who serve in IETF leadership roles, people who have recently begun working in the IETF, and organizations that make the work of the IETF possible.
The Chicago IETF begins in a couple of days, and I wanted to point people to a few highlights from my perspective.
IETF Hackathons embody the IETF’s tradition of running code—testing theories against the realties of implementation, with a goal of accelerating the definition and adoption of protocols and technologies that make the Internet work better.
Recent news stories, and some IETF list discussion, have related to the release of (claimed) CIA materials relating to surveillance, hacking and information warfare.
Every year, the IETF selects its leadership through the nominations committee or NomCom process. Today, the committee has announced our new steering group (IESG) members.
The Internet Engineering Task Force (IETF) is a global community of network designers, operators, vendors, and researchers that develops Internet protocols.
RFCs are documents designed to serve a variety of purposes. They offer information to developers engineers on how to make the Internet interoperate.
We will be hosting another IETF Hackathon at IETF-98 which will take place in Chicago at the end of March. The Chicago Hackathon will run from Saturday March 25 to Sunday March 26, but will surely have follow-ups during the rest of the week.
First, there will be a CodeSprint on Saturday March 25th just before IETF-98 in Chicago.
Do you have an idea that you believe would be worthwhile standardising? Now would be a great time to start talking about it, in time for our meeting in Chicago in March!
The Internet Governance Forum or IGF is a discussion forum on matters relating to the administrative and policy questions surrounding the Internet. A handful of IETFers attended the yearly IGF meeting, this time happening in Guadalajara, Mexico, in December. We wanted to report what we saw and talk about why the discussions at the forum are important.
I wanted to send a post summarising my thoughts of the discussions at IETF-97. We had 1042 people from 52 countries on site in Seoul, very active development on a number of fronts, and I thought a successful meeting! (Apologies for sending this post out late, other tasks, holidays, etc intervened.)
Looking Back on IETF 97
This report is sent out before IETF-97 begins, in an effort to reduce reporting at the plenary and to provide an ability to discuss topics on list beforehand and afterwards.
Let me start with some good news. Not only we recently approved RESTCONF (right now in the RFC editor queue), but we published the IPv4 and IPv6 base routing models in RFC 8022.
The arrangements relating to administrative support for the IETF (IASA, RFC 4071) were created more than ten years ago, when the IETF initially took charge of its own administration.
The scale, complexity, and potential harm of Denial-of-Service attacks involving the use of compromised or misconfigured nodes or “things” is increasing. Across multiple services and activities, the network seems to be unable to defend itself effectively against large-scale bad behavior. Why is this? Can something be done about it? Who should act?
Today marks the execution of the contracts and arrangements relating to the IANA stewardship transition. The US government has ended their role in this matter. I am happy about the transition, and happy that it is happening as specified by the IETF and other communities. For me, the key issue is that the communities are in charge.
Standards organisations have their areas of work, but for many topics efforts affect multiple organisations, or even span across multiple organisations. Take the IETF and the IEEE for instance, as our efforts often interact.
I wanted to remind you that we are soliciting proposals for new work at the IETF. If you have an idea, this would be a good time to bring it up!
The essence of the IETF is not that we write specs for some other people to implement. It is that we are a place for people who write code to write specs as well. With that in mind, a big part of our work is allowing for that code writing to happen.
Kicking off IETF 96 in Berlin, Germany was the weekend’s IETF Hackathon. There is growing engagement between the Open Source communities and the IETF. The IETF Hackathon had more participants than ever and we experimented with having a place for it in the IETF Lounge all week.
We had a great meeting in Berlin, the IETF crowd clearly likes to meet there! As our meeting ended, we had 1424 people participating on site and 337 people remotely. Out of the registered remote participants, 79 were from USA, 73 from India, 52 from Brazil, and 13 from Japan.
“There’s a huge problem with the Internet of Things and we need to do something about it.” That was the invitation that brought participants to the Internet of Things Software Update Workshop (IoTSU) held at Trinity College, Dublin on June 13 and 14.
When the idea of participating in this hackathon came about, the goal was mostly to leverage FD.io’s Vector Packet Processor (VPP) as a platform and show its performance, capabilities, modularity and development simplicity. So we looked across existing IETF technologies and drafts which were not yet implemented in VPP and found out this new ILA technology (draft-herbert-nvo3-ila), which seemed to be a perfectly valid use-case for VPP used as a physical or virtual router.
I arrived in Berlin today, but there are many volunteers and support vendors who arrived days earlier to prepare for the meeting. It takes a lot of effort to setup the network, for instance. The team reports that the network is up and running, and that they have taken over the hotel network as well.
Today is the deadline for registering at the IETF with the early bird price. Do register!
During nearly every IETF meeting since 1993, an informal gathering of women participants, the Systers, has taken place. We chose the name Systers as an answer to the late Anita Borg’s call for women in computer systems to support and celebrate each other.
In my experience it is important that we talk to each other, all of us, the techies, the operators, the economists, and the policy people. We live in a connected world that is developing very rapidly, and none of us have a full picture of everything. It benefits us to share our views and increase our understanding.
I wanted to provide a brief update on the the progress of the www.ietf.org website revamp project, which began in earnest last year and is scheduled to move into production by the end of this year.
I wanted to report what new ideas are going to be discussed at the meeting in Berlin in July.
In the midst of a day’s discussion about particular issue that troubles us with technology or something else, it can be difficult to focus on topics that have a longer timescale. As you probably remember, I had asked a design team to write a draft about various trends around us that affect the IETF.
Today the US Department of Commerce National Telecommunications & Information Administration (NTIA) announced that the Internet community’s proposal to transition the stewardship of the Internet Assigned Numbers Authority (IANA) functions meets the criteria it set out for the process.
If you have followed the IETF discussion list recently, you’ve probably seen a thread about a planned meeting in Singapore next year. Traditionally, the IETF announces meeting sites as they have been contracted. After announcing Singapore during IETF-95, we heard from our LGBTQ participants that laws in Singapore make their participation (particularly when they travel with their families) a concern.
The IETF meetings are a busy time for many of the active participants, including members of our steering group or the IESG. Most of the time is spent in actual working group meetings, and there’s little time to reflect on broader issues. Every year the IESG finds some time for a “retreat” meeting to discuss topics with sufficient amount of time, to get to know the new ADs, do some team building, and so on.
The IESG has just had a two and half days of meetings in Cambridge, Massachusetts. These events are an important opportunity for our group to meet and discuss broader topics and IETF work in more depth than is possible during the regular IETF meetings.
We had a great IETF 95 meeting in Buenos Aires a few weeks ago, with a lot of topics and many participants.
Over the last few years, the IETF community has been focused on improving and expanding the use of the technical foundations for Internet security.
I am pleased to announce that Ericsson has just signed a MoU with the ISOC (Internet Society) in which Ericsson commits to support the IETF in a ongoing fashion.
In 2013, the IESG set the IETF anti-harassment policy. The IETF strives to create and maintain an environment in which people of many different backgrounds are treated with dignity, decency, and respect.
A recent Internet Draft noted the growing Free and Open Source Software movement as a trend that the IETF, as a community, can participate in by helping open source and open standards work together.
This morning I arrived in Buenos Aires, where volunteers and staff have been busy preparing for our 95th IETF meeting. It looks like everything is ready, the network is up and the hotel facilities look great.
The IETF is about interoperation. Yes, IETF participants like cleaner architecture, and more elegant solutions, and so on. But at bottom, both “rough consensus” and “running code” are all about making diverse things work together as much as possible.
It’s almost time to pack our bags and head south to Argentina. This is the IETF’s first ever meeting in Latin America!
Just before the IETF 95 in Buenos Aires, let’s analyze the current state of affairs in the YANG Data Models world.
Many of us have been working over the last two years on a small change to the way the IANA functions are managed.
My previous blog post was about the IETF BoFs, but there are also new meetings in the research arm of the IETF, the IRTF.
With the preliminary agenda just published (or soon will be), I wanted to report what Birds-of-Feather (BoF) sessions there will be at IETF-95. This time there is quite a lot of work following up on a recent IAB workshop on the effect of encryption on network operators.
Some time ago I mentioned the Internet of Things Semantic Interoperability (IOTSI) workshop organised by the IAB. This workshop is important for the work on application data formats, semantic definitions, and interoperability in the Internet of Things space.
This blog post is not about technology. A while ago I asked for volunteers to help us understand some of the non-technical changes around the IETF.
Thinking of some new ideas that could be worked on by the IETF? This Friday, February 19th, 23:59 UTC is the deadline to submit proposals for what we call Bird-of-a-Feather (BoF) sessions at IETF-95 in Buenos Aires.
I cannot think of a better example where interoperability is important than the Internet of Things. Without interoperability, lights won’t work with the switches, sensor’s can’t be read by your smartphone, and devices cannot use the networks around them.
The IETF turns 30! As we work on the day-to-day tasks needed to make the Internet work better, or even as we look back over last year and gaze ahead to the year to come, from time-to-time it is useful to consider our work on timescales that are a bit larger.
With the year closing, I wanted to make a post highlighting some of the events and hot topics of the year. And say a few words about the challenges that lie ahead.
It’s been a while since we’ve had a diversity related update and with the approval of the Anti-Harassment BCP and publication of the Independent Stream Editor (ISE) document, RFC7704 it seems timely.
Perhaps the topmost thing on my mind is how friendly and welcoming place Japan is for the IETF.
The Internet Governance Forum or IGF is an organisation that enables the discussion of public policy issues pertaining to the Internet. It is an open meeting for many different types of participants ranging from (some) technical community members to governments.
The Yokohama IETF Hackathon is now in progress!
The Yokohama Code Sprint is in progress! There are a few new code sprinters, and part our efforts has been in setting up development environments for them, as well as building a Docker image so that future setup will be easier.
Welcome to IETF-94, and back to Yokohama! We were here in 2002, yet I remember it like yesterday. The impression left by the scenery, the Japanese friendliness, food, and many other things was lasting!
Both the IETF and the W3C are meeting in Japan this month.
A recent paper on shortcomings of Diffie-Hellman key exchange has received attention and raised questions about security on the Internet, as Diffie-Hellman is used for cryptographic handshakes in popular Internet protocols.
IETF Chair Jari Arkko and IAB Chair Andrew Sullivan are both at ICANN 54 in Dublin, and of course a big topic is the IANA transition.
The ICANN 54 meeting is now starting in Dublin, Ireland. On the agenda are various topics around the IANA stewardship transition.
横浜のIETFのためのプログラミング!
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.
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.
MaRNEW 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.
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.
The IETF community approved document using the Special-Use Domain Names registry established by RFC 6761 to register ‘.onion’ as a special-use name.
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.
Our meeting in Prague ended last Friday, and I wanted to thank everyone who participated! I hope you all have had an opportunity to return to home and rest after the trip.
The combined proposal from three communities has today gone out from the IANA Transition Coordination Group. This is important.
The IETF meeting rooms and registration desk are ready for the meetings to start. A lot of activity is already going on on Saturday this time, but actual registration opens on Sunday at 1000 in the Congress Hall Foyer on the Lower Lobby level.
The IETF is once again in Prague! The city is clearly one of our favourites, given that we’ve been there also in 2007 and 2011.
The 90th IETF starts next Sunday in Toronto, Canada. Canada is one of our favourite places to meet at.
I would like to update you on the IANA transition, including important events that took place at the 53rd ICANN meeting in Buenos Aires.
Earlier this week, I was sitting on a train ride through Finland. As usual, my iPad acted as a mobile broadband gateway, and I suddenly realized that my other devices were using IPv6 to reach the Internet through the gateway.
What will our first meeting next year be like?
Before an IETF meeting, we sometimes receive a few requests to extend the deadlines related to Internet Draft submissions.
The Internet Architecture Board (IAB) and the Internet Society (ISOC) hosted day-long Coordinating Attack Response at Internet Scale (CARIS) workshop took place last Friday in coordination with the Forum for Incident Response and Security Teams (FIRST) Conference in Berlin.
Education and newcomer orientation activities have existed in the IETF in various forms from the early 1990s (if not earlier). As the IETF and the world around us evolves, we are now rethinking what types of activities are best suited for the future.
We will once again have a Code Sprint in Prague prior to IETF-93.
This is a good time to submit more new proposals for the IETF!
An IETF meeting is a busy time for the Area Directors. We do not have much time for discussing IETF-wide topics or getting to know new team members. Every year we meet for a couple of days as a team, outside the IETF meeting.
The first flow-related BoF (birds of a feather) took place in London in summer 2001 during the IETF meeting 51.
On the weekend before the IETF meeting in Prague (July 18-19), we will hold our second IETF Hackathon event at the Hilton Prague.
This is a brief report from a meeting between a number of Internet organisations that took place last week in London.
Every year, IETF’s leadership groups (IAB, IESG, IAOC) meet for retreats. This year all the three groups meet in London.
End-to-end (e2e) encryption for email is hard. We know this from OpenPGP and S/MIME efforts with the main problem being around obtaining, installing, and exchanging keys.
One of the great scientific challenges of our time is the construction of a practical quantum computer.
IETF Chair Jari Arkko explains IANA protocol parameters. To begin with, what are protocol parameters? What is the role of IAB? What is oversight? Who draws contracts at the IETF? What role does the IAOC play? How can you ensure that the IETF leadership works according to the community’s wishes?
La semana pasada, al hablar de Internet abierta para un evento de Gobernanza en Moscú, Jari se reunió con gente del Capítulo Rusia de Internet Society.
The upgrade to the datatracker UI mentioned in plenary at IETF 92 has just been released. This effort has been underway for more than a year.
Last week, while speaking about open Internet in Moscow for an Internet Governance event, Jari met with folks from the Internet Society Russia Chapter. They had recently made a translation of the IETF Journal to Russian!
April 7 marks the anniversary of the publication of the first RFC.
Thank you all for a wonderful meeting. I wanted to thank all the sponsors and participants, and our host Google for their support. And the wonderful social event. Well done, you all!
Coordinating incident response at Internet scale as a concept sounds fabulous, but can we achieve it? What will it take?
First things first, the network for IETF-92 is up and works well! Both the meeting area and hotel room networks are operational.
There is just 10 days until our next meeting begins, in Dallas, Texas. This is our third visit to Dallas
We will once again have a Code Sprint, now in Dallas prior to IETF-92.
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.
After more than two years of discussion, over 200 design issues, 17 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 deadline for submitting proposals for new working groups for IETF-92 is approaching fast.
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.
In less than 9 months–representing just two IETF meeting cycles–the DiffServ Applied to Real-time Transports (DART) working group (WG) moved from a concept to Internet Engineering Steering Group (IESG) approval of the Internet Draft it was chartered to produce.
The IETF traces its start back to a meeting that took place 29 years ago today, January 16th. Happy birthday, IETF!
In March of 2014, the US government announced their intent to move their role in overseeing the IANA system to the Internet community. Last month the IESG approved the IETF response, and after small editorial changes, draft-ietf-ianaplan-icg-response-09.txt was formally approved on January 6. The IAB has signified their support of this document as well.
In March the US government announced their intent to move their role in overseeing the IANA system to the Internet community. Since the announcement, the communities impacted by IANA functions have been working hard to develop a transition proposal.
Just after the IETF 90 meeting last July, I posted this “YANG Takes Off in the Industry” blog.
Our meeting in Honolulu is over. How did it go? Let us know. In the following I have collected some of my own observations.
This week at IETF91 we carried out an experiment to randomize Wi-Fi MAC addresses of users to improve privacy.
New to the IETF, or exploring new topics for your work? I wanted to point people to the various introductory sessions and materials that we have about the IETF and Internet technology.
I wanted to welcome everyone to the 91st IETF meeting that is starting tomorrow, November 9th, here in Honolulu, Hawaii. I also wanted to welcome our remote attendees!
We wanted to let you know that a number of Chinese participants have had trouble for getting visas to this meeting.
The network for the IETF is a bit of a unique beast.
The IETF meeting in Honolulu starts a week from now.
A brief summary from IETF Chair of some of the things that have happened at ICANN 51 related to the transition of the IANA Stewardship.
New IETF work begins often as a proposed new working group, through something called a Birds-of-a-Feather (BoF) session.
We will once again have a Code Sprint in Honolulu prior to IETF-91.
The transition of NTIA’s stewardship of IANA has been discussed extensively. Just last week there was a meeting of the IANA Stewardship Transition Coordination Group or ICG.
The OpenStand approach to creating global standards has never been more relevant—or important—than it is today.
The IETF has had another lively discussion about mailing list usage in the ietf@ietf.org mailing list, followed by a long plenary debate on how to make it more useful to the community.
In 2003, RFC 3535, “Overview of the 2002 IAB Network Management Workshop” documented the outcomes of a dialog started between network operators and protocol developers to guide the IETFs focus on future work regarding network management.
IETF-90 is over and I wanted to provide a summary of what I saw in the meeting.
We have built a lot of support for remote attendance in the IETF, but this week I saw something new.
On Thursday morning of the IETF 90 meeting, we had a Birds of a Feather (BoF) session called IANAPLAN: Planning for the IANA/NTIA Transition.
Last week, I visited the ICANN50 meeting in London. The meeting was held at a location well known to us at the IETF – the Hilton London Metropole.
For every IETF meeting, the steering group receives a number of proposals for new work. Not all new work in the IETF has to go through a public meeting to be accepted.
New IETF work begins often as a proposed new working group, through something called a Birds-of-a-Feather (BoF) session.
The NETmundial meeting was held last week in São Paulo, Brazil. I wanted to provide a brief report of my view of the meeting and its outcome.
I have previously talked about the upcoming changes at IANA.
The two-day NETmundial conference that starts on Wednesday. Me, Russ, and several other IETFers are attending this event.
The previous blog post talked about the IANA discussions at the ICANN meeting. But of course that was not the only topic that we talked about.
I wanted to share two excellent videos in this post.
With the IETF week over, I wanted to write a brief summary of the main discussions. And what a week! I spent ten days in London due to a workshop preceding the IETF and even some meetings that took place after the IETF.
IETF Chair Jari Arkko looks ahead to the IETF-89 meeting, the IETF meeting's second time in London.
The IETF’s relevance in the marketplace was the subject of a workshop held by the IAB in December in Cambridge UK on Internet Technology Adoption and Transition (ITAT).
Today is International Data Privacy Day, and I wanted to let Alissa Cooper say a few words about how we are working on privacy topics at the IETF. - Jari Arkko, IETF Chair
I wanted to draw attention to Mark Nottingham’s excellent blog article about strengthening HTTP.
In this article I wanted to highlight an important but often hidden part in the IETF ecosystem: Internet Assigned Numbers Authority (IANA).
The last days of the year seems like a good opportunity to reflect on some of things that happened during 2013.
Wow what a week! Working with Internet technology often involves details deep inside the technology. But it seems that this week has been a perfect storm of highly visible and important technical developments:
Reports about pervasive surveillance have been the big discussion topic in the Internet community in the last couple of months. Our commerce, business, and personal communications all depend on the Internet being secure and trusted, so the situation is disturbing.
Many students were brought to IETF 87 by a pilot university outreach programme, run by ISOC with 15 universities in Germany and Austria.
The IETF network for the meeting is up. Even the network in the hotel rooms switched to IETF network by mid-Friday. Everything is ready for the IETFers to come!
The IETF-88 meeting is starting next week in Vancouver. Vancouver is a long-time IETF favourite city, as this will be our fifth time there. And we were there just last year. Vancouver works well for the IETF, and I’m very happy to return again!
When I visited the ICANN meeting last summer, they were about to launch a set of panels to advice themselves about strategic topics in coming years. Those panels are now operational.
As I mentioned in “Security and Pervasive Monitoring” article in September, the IETF community has expressed concerned about the large-scale monitoring of Internet traffic.
I visited the RIPE meeting and IGF meetings recently, and wanted to post two speeches that I held in these events.
Last week I toured China, talking to the local IETF contributors. And there are so many! I talked to people from equipment vendors, operators, researcher institutions, and local standards organisations.
The Internet community and the IETF care deeply about how much we can trust commonly used Internet services and the protocols that these services use.
It seems like yesterday when we were in Berlin, but I wanted to highlight that our Vancouver meeting is coming up soon.
The IETF meeting in Berlin is now over. I hope everyone has been able to return home safely, and that you all can enjoy at least a weekend if not some vacation time after a busy meeting week.
I wanted to return to a topic that we have talked about before: increasing diversity at the IETF.
A while ago I wrote about the issue of the IETF document process being quite heavy-weight in its final stages. Documents go through a lot of review and changes in their last few months. Some of this is natural as the document gains more exposure.
This week I’m visiting the ICANN meeting in Durban, South Africa. It has been an opportunity to meet many interesting people and get a glimpse of the issues that other important organisations in the Internet ecosystem deal with.
The Internet of Things is about embedding communications technology in all objects that can benefit from it, from cars to buildings, everyday objects and even materials. This is an ongoing revolution in the scope and scale of networking.
In two weeks, we will have the IETF-87 meeting in Berlin! The previous time IETF was in Germany was in August 1997 in Munich – that was too long ago and it is a pleasure to be back!
I would like to talk about standards and what kind of approaches are suitable for developing them when it comes to Internet technology and applications.
One of the most rewarding parts of my job is talking to various IETF contributors or people who rely on our results, and trying to understand their experiences about the IETF process and what kinds of technical topics they expect us to tackle. This article focuses on the process aspects.
Diversity has been a recent big discussion topic at the IETF, which IETF Chair Jari Arkko covers in this blog post.
I wanted to return to the topic of Bits-n-Bites which we briefly reported on already earlier. Dan York and Paul Brigner from ISOC shot a few videos of some of the interesting demos, and the videos are now available below.
As we were preparing for the Orlando meeting, we talked about ways to make the Bits-N-Bites program more dynamic and provide a place for the IETF community to perform experimentation and get running code in a production like network setting.
Our meeting in Orlando ended on Friday. I thought it was a very successful meeting, and brought up many new topics that we should pursue.
I would like to welcome you all to Orlando, where the 86th IETF meeting starts on Sunday!
The previous article talked about how exciting and important the work at the IETF is. And it is. But there are also challenges, both for the Internet as a whole and for us at the IETF.
Welcome to a new publication from the IETF, a blog from the (incoming) IETF chair!