Author Archives: Jari Arkko

Reflections from IETF 97

iloveseoul

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.)

The meeting was supported by our host Huawei and co-hosts CNNIC and KISA (Korean Internet & Security Agency), and a long list of sponsors. Thank you for your support!

The topic of the meeting was of course Internet tech and its evolution. The two most active discussion topics were the increasingly serious Denial-of-Service attacks that we are seeing, and the development of a new transport protocol, QUIC, as an alternative to TCP and TLS, especially being more optimized for HTTP/2 usage.

The most recent Denial-of-Service attacks involved a number of compromised Internet of Things devices attacking DNS infrastructure. The IAB had organised a discussion of these attacks as an example of a more general concern: the addition of millions of new hosts has the capability to overwhelm the Internet infrastructure when those hosts misbehave. There are ways to mitigate the attacks, but not without impacts in other ways — such as finding it necessary to deploy your services on large providers.

At the very least, I think it would be beneficial for the IETF community to continue to call attention to folks that the minimum bar when introducing a large number of devices (or any device) to the Internet includes things like automatic software updates and avoiding default passwords. I used to think this was so obvious and it needn’t be said, but I’m not so sure anymore. Nevertheless, the area for us to have an impact is improving on defence and mitigation mechanisms.

You can watch the video from the IAB plenary discussion here:

The IETF recently chartered a working group to specify QUIC (Quick UDP Internet Connections). This new protocol combines the TCP and TLS layers, is typically implemented in user space rather than kernel space, and aims for faster connection setups using resumption, integrated security, and capabilities to evolve the protocol faster (not being in the kernel).

A previous version of the protocol is also already in relatively wide use at Google, and was taken as a starting point for discussion in the working group.

I’m quite excited about this development, and eager to see where it takes us, and it seems that I’m not alone:

Once again the IETF Hackathon was running the weekend before the IETF. I thought it was outstanding to see large student groups among the participants. A student team from SungKyunKwan University worked on the Interface to Network Security Functions (I2NSF) framework, for instance. With jackets made for the event!

There was also a second large student team – on the other side of the world! The team from Université Catholique de Louvain worked on Multipath TCP, but much of their team did their work from back home in Belgium. They won the best of show award:

The Hackathon demos can be viewed in YouTube:

All videos from the sessions, interviews, etc from the meeting are available as a YouTube playlist. The official proceedings with slides, minutes and everything else are on the IETF website. See also the blog post on routing area outcomes from IETF 97, and the blog post from Srimal Andrahennadi from his experiences in participating as an ISOC fellow at the IETF.

Besides the ISOC fellows group, there are a number of other gatherings happening during the IETF week. ISOC also runs a “Policy Fellows” program, with participants from regulators, governments, and other policy makers that do not usually attend technical conferences. Contact Konstantinos Komaitis at ISOC if you want to participate in this program! The IEPG meeting on Sundays is a discussion among network operators. And the Systers Lunch gathers the women participants. Contact Allison Mankin if you want to join!

So, what’s next? The work has already been going on in the mailing lists and virtual meetings after IETF-97, and will intensify as people come back from holidays. IETF’s official work happens on the mailing list. Our next meeting is at the end of March in Chicago, hosted by Ericsson:

Jari Arkko, IETF Chair

Photo credits: Tero Kivinen, Charles Eckel, Olivier Bonaventure, and unknown. Thanks!

Internet Governance Forum (IGF) 2016

dciot

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.

There are other reports from this meeting, including the official transcripts and videos, Multistakeholder Advisory Group (MAG) Chair’s summary (Lynn St. Amour became the MAG Chair in 2016) article, Constance Bommelaer de Leusse’s (ISOC) article “Reflections on a successful IGF 2016”, Samantha Dickinson’s article “Despite Renewal, the Internet Governance Forum Is Still on Life Support”, and the Geneva Internet Platform’s excellent report “Reflecting on IGF 2016”.

General

From an IETF geek perspective 2000+ people gathering to discuss policy issues in the Internet was quite amazing. The best moments are when people with very different backgrounds can connect. When the medical doctor from India explains the benefits of telemedicine just in reduced travel costs, let alone faster start of treatments. Or when you can connect the Bollywood movie director’s difficulties in getting paid for content in the sharing economy to your friends’ difficulties in your local newspaper industry. I felt we learned to understand the world better in some of these discussions.

IANA, and its transition had dominated global discussions of Internet Governance for the last couple of years. Perhaps unfairly; IANA is not the only and certainly not the most complex issue in this space.

But with the IANA transition behind us, you could feel the change from last year. There was a positive feeling about the community being able to complete this change and a even clearer support for the multistakeholder model of working together on Internet issues than in previous years. And of course, the forum was now able to concentrate more on other issues.

larry

Role of the IGF

The IGF meeting is not all happy progress, however. First off, many of the issues are difficult and global trends run their own course. What can you or me or the Bollywood movie director do about the sharing economy, for instance?

Secondly, people really are different, ranging from the government officials to business specialists to lawyers to techies. And in many cases our ability to be multilingual, to speak both about our tech, policies, and business aspects is limited. You see the (rare) government official who just reads statements, you see people who have a difficult to understand that the world really has changed, us techies sometimes struggle to see the big picture, and all of us would benefit from even better connection to ongoing Internet practical reality.

But the value of the IGF in our view is that it offers a place for discussion, place for understanding the global challenges and opportunities better. It is not a perfect solution to get rid of your favourite Internet annoyance; but there may not be perfect solutions.

We’re also kind of fond of the IGF’s new working methods that focus on Best Practice Forums (BPFs) and Dynamic Coalitions (DCs) that operate throughout the year, and produce guidance that is voluntary but can help various parties recognise how they can deal with a particular issue.

As an example, the Dynamic Coalition on the Internet of Things (DC-IoT) has produced a document that outlines guidelines for “ethical” IOT applications, including meaningful transparency, user-control of data collected by the application, and so on.

Also, in the Geneva Internet Platform’s report, they asked IGF-longtimer Markus Kummer if he thinks the IGF being ‘just a talking-shop’ is really a weakness. I thought Markus’s answer was spot on:

This is one of the reasons why some governments don’t come here; they feel it is not serious enough, it is not some place we negotiate. But this is precisely the strength of the IGF – the absence of pressure to negotiate outcomes allows people to speak freely and also to think a bit outside the box, to do some brainstorming, and then go home and actually try to implement the ideas.

Key Topics at the 2016 IGF

Connecting the next billions of people remains as a key focus in many of the discussions. This is obviously very important, but we were also glad to see many references to more complex goals, such as ensuring the openness of the Internet; quality and not just quantity is important. And lets not forget that connecting all the people will not be the end of our efforts. Think of how much, say, agriculture or traffic would benefit of the optimisations that Internet communications can bring. This is true of both the developing and developed world.

The Internet of Things was also a key issue in many sessions, with a lot of focus on how it can be sufficiently secured. While Internet of Things as a technology in its own right, it also seen as an enabler for sustainable development, education, and helping the “global south” catch up.

Free and open source software is also considered as another enabler for the global south. Open source can help the poor use the tools they need, without having to afford additional expenses. It also allows auditing to protect people’s rights and information. A concern was raised from the floor of the meeting that big companies don’t care about open source. It’s important that the IETF continues putting our efforts into connecting with open source projects and supporting development of free and open source software (Hackathon, encouraging open-source implementations as we develop protocols, etc). And contrary to the concern perhaps, we think that is likely inline with what small and big businesses also want us to do.

The growing digital divide was referenced many times. While a lot of progress has been made in enabling more and more people to use the Internet, at the same time the divide is also growing. Think of the elderly who may be falling behind on the ability to use new technology, and are being shut out of many functions of the society that have moved online. Or the poor who cannot afford connectivity, which in turn may lead to the even worse outcomes due to more difficult access to commercial services, job markets, etc.

There was also discussion of big data, with suitable anonymisation and privacy protection, to assist governments and other actors in providing services, being aware of important trends, and the like – but data must be timely, relevant, and local.

Other topics of high interest included gender and diversity, freedom of expression, education, and legal matters.

co-operation

The thinking sparked by these discussions will continue throughout the coming year at local and regional IGF gatherings. And, IGF 2017 will be held in Geneva, Switzerland on 18-21 December.

Best regards,

Jari Arkko, Andrew Sullivan, Ted Hardie, and Barry Leiba

Photos: The IOT Dynamic Coalition meeting with Max Senges speaking with Joe Alhadeff, Vint Cerf, Maarten Botterman and Avri Doria in the background (photo by Jari Arkko), Larry Strickling speaking at the IGF Opening Session (photo by Jari Arkko), and your IETF and IAB chairs hard at work on the in-the-meeting-compound Tequila farm (photo by Ted Hardie).

IESG and Chair Report, 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. The plan is to provide only a brief summary in the in-person presentation at the plenary.

If you have topics that you think the IESG should, or should already have, discussed, please send email to iesg@ietf.org with details and we’ll get back to you.

Jari Arkko, IETF Chair

THE REPORT

This report covers

  • notable things about IETF 97, and our technical program
  • IANA stewardship transition
  • proposed IASA 2.0 project
  • what our professional standards of behaviour are
  • how to see what the IESG does
  • working groups created, rechartered, proposed, or closed after IETF 96
  • a note on new non-WG mailing lists
  • pointers to ongoing discussions on general process or IESG procedure issues
  • currently running (non-technical) experiments
  • appeals
  • other matters

In addition, there are several other reports elsewhere:

  • The RFC-Editor report can be found here.
  • The Secretariat report can be found here.
  • The IANA, NOC, and Hackathon reports can be found under the technical
    plenary on the meeting materials page.
  • The IETF blog is frequently updated with posts from the chair and others.
  • The IAB report is here.

IETF 97 AND NOTABLE ACTIVITIES

The meeting and pre-events are running from Saturday November 12 to Friday, November 18th. All information is available from the meeting website, but here are some of the highlights:

  • IETF Hackathon is running from Saturday to Sunday, please join and work on interesting topics. See Hackathon web page.
  • IETF Code Sprint is running on Saturday, please join and program the IETF tools that *you* need. See Code Sprint web page.
  • Thursday speaker series, Thursday Lunch slot in Park Ballroom 1: We will hear from Andrew G. Malis on “Quasi Assured Network Transport (QUANT)”. See the talk page.
  • Female and at the IETF-97? Join the IETF Systers, see the blog article and the invitation from Allison Mankin.

As usual, there are also a number of events around the IETF. This time I will mention two:

  • The IEPG discusses operational issues on their Sunday meeting.
  • The OPNFV meetup, taking place on Friday, November 11. But OPNF folks are also participating throughout the week, for instance in the Hackathon and the Bits-n-Bites.

Sponsor: Our meeting host is Huawei. Thank you! Other hosts and sponsors include KISA, CNNIC, Google, Nokia, OSI Hardware, ISOC Korea Chapter, NTT Communications, Comcast, ETRI, Netpia, OPNFV, Korea Tourism Organisation, Seoul Metropolitan Government, and the Hackathon sponsor for 2016 is Huawei Developer Zone. The Hackathon is also supported by Cisco DevNet.

Thanks, all!

THE TECHNICAL PROGRAM

But now on to our actual technical program! Some of the highlights have been listed in the Welcome to IETF-97 blog article and some of the proposed new work in the New Work in Seoul blog article.

Note in particular the technical plenary program which focuses on distributed denial-of-service attacks against the Internet architecture. See the article for more details.

IANA STEWARDSHIP TRANSITION

The transition was executed on September 30, 2016 as planned by the various communities. The relevant contracts have come into effect, including the new SLA between the IETF and ICANN, and the role of the IETF Trust as holding IPR related to IANA. The domain name parts of this IPR are being technically transferred and the arrangements are being setup with appropriate providers.

PROPOSED IASA 2.0 PROJECT

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 arrangements have served the IETF well, but there’s been considerable change in the necessary tasks, in the world around us, and our own expectations since the creation of the IASA. Looking forward, this is a good time to ask what administrative arrangements best support the IETF in the next ten years.

The IETF Chair is planning to start a project to assess those arrangements. Included in this project are the various challenges and frustrations* we’ve experienced along the way, but we also need to ask the bigger questions about how the organisations are structured. The project should assess what kind of support we need in the coming years, from the point of view of the community, IESG, IAB, IAOC, Trust, and partners (such as ISOC, long-term hosts or contractors). Areas to look at include structure, financing & sponsorship arrangements, organisation, and ways of working.

This project is to be done to serve the IETF community, hence the final determination of results and actions will rest on the community. Obviously there is a role for the IAOC & Trust in particular to provide direction in what they see is appropriate. And likewise for the the IESG and IAB in their respective roles, or ISOC for discussion of the relationship and arrangements with IETF. But I feel that the IETF chair needs to own the project and be responsible for ensuring that the community views are what finally determines the actions.

At this point, the project is a proposal, and the chair is soliciting feedback on the overall plan. We will be working to create specific mailing lists for the substantial discussion later, but for setting up the project the proper place for discussion is probably here at ietf@ietf.org.

(*) Some of these issues have been prominently visible in the IETF community, such as the discussions about early community involvement in making meeting site decisions. Others are internal to IASA operations, such as workload due to increasing IETF responsibilities. There are also structural question marks, such as the way that we select people to serve as board members, or the partial separation between the IAOC and the Trust.

For more information, see the proposal and participate in the discussion on the mailing list.

PROFESSIONAL BEHAVIOUR

IETF meetings, virtual meetings, and mailing lists are intended for professional collaboration and networking (as defined in RFC 7154 and RFC 7776). If there are any concerns or deviations from this model, please talk to the Ombudsteam who are on site during IETF 97: team page.

We’ve also talked about a lot about proper behaviour on the ietf@ietf discussion list. There are multiple mechanisms to help the discussion on this list stay focused and appropriate. Indeed multiple, perhaps to the extent that it can be difficult to know who to contact. This brief note helps explain what one can expect the facilitators, ombudsteam, etc. to help with, and how to contact them. See the note. Feedback on the note is welcome.

FINDING OUT WHAT THE IESG DOES

The IESG continues to work on increasing transparency. We’d welcome feedback on what aspects need improvement. The IESG formal telechat calls are open for observation, and we also post both short and
narrative minutes. The minutes are available on the web, at minutes 2016. If you are interested in the upcoming agenda, it can be seen at https://datatracker.ietf.org/iesg/agenda and the invitiation is mailed out to the IETF main discussion list. The calendar and connection details can also be found at the IESG page. And of course, the best place to follow what is going on with a document is the datatracker. Of course, the relevant actions such as significant comments from the IESG continue to be automatically emailed to the relevant WG mailing list.

The IAB and IESG also hold a BOF coordination call before each IETF meeting. In this call, we go through the set of proposed BOFs and other possible new meetings, in an effort to help the responsible AD decide how the specific proposals should go ahead. Since IETF 96, the IESG and IAB have started publishing the minutes from these calls. These minutes can be found from the IESG page. The October 2016 call minutes for instance are at here.

NEW WORKING GROUPS

The following changes have happened after IETF 96:

Approved: SIDROPS, L2SM, QUIC, SECEVENT, IPWAVE, and LPWAN. Note that SIDROPS, L2SM, and SECEVENT were chartered after community e-mail discussion but no preceding BOF. Not all new efforts go or need to go through the BOF stage, and it can often be the recommended approach if the relevance of the topic and broad interest for it can be demonstrated in other ways.

Rechartered: IPSECME and SACM.

Proposed WGs, BOFs, or otherwise under consideration (outcomes undecided before community has had sufficient discussion, of course): DNSBUNDLED and BANANA.

Closed: IANAPLAN, LAGER, ABFAB, and JOSE.

New non-wg mailing lists: DLNEX hosts a discussion of reliable and deterministic latency attributes, ledger discusses interledger, originally a protocol stack for moving digital assets between accounts operating on different payment networks or ledgers, ideas has discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks, dnsoverhttp hosts a discussion of running DNS over HTTP, rtg-open-source discusses routing-related open source efforts, and art is an area-wide discussion list for the Applications and Real-Time Area.

STATEMENTS AND NOTABLE DOCUMENTS

The IESG has decided to make a small modification of the IPR-related web pages to be even clearer about the role of the statements submitted as IPR declarations. This decision was based on feedback on earlier suggestion of issuing an IESG statement on the matter. Once the modification is in place, we will inform the community of the change.

The IESG is currently working on a statement regarding the role of supporting documentation (use cases, requirements, etc.) in a working group. The IESG wants to emphasize the importance of chartering solution work immediately and reducing focus on supporting documents; represents how the IESG has been focused for a while now and is an effort to speed up WGs producing solutions that have an effect in the way that people build and test networks.

RUNNING EXPERIMENTS

These (non-technical) experiments are running at this time:

  • The ietf main discussion list facilitator arrangements was an experiment, and its results are now under evaluation. See the experiment announcement. The main question is whether the facilitators (who were quite active) made a significant positive impact. Based on this the experiment should be either turned to an ongoing effort or ended. There is a mailing list thread on the IETF main discussion list about this topic.
  • A number of IETF Hubs are going on – in South America, in India (Bangalore) and Boston.
  • The IESG is encouraging WG Chairs to try and use different meeting formats than “present and listen”. The WG Chairs’ training session will be discussing this among other things in Seoul.
  • Several working groups are using github as a platform for specification development, markdown to write drafts.

In general, the IESG would like to encourage experimenting and trying new things. If you have ideas about potentially useful things to try, try them and tell the rest of us!

APPEALS

There have been no appeals since IETF-96. The appeals list is on the web.

OTHER

The IETF website is being renewed. See the blog post from Joe Hildebrand. We were originally planning to have a live version of the website for IETF-96, but have pushed the launch to happen before IETF-98, due to integration to the rest of the IETF system taking more time than expected. The team is also following up with more detail on exactly how the community feedback will be incorporated along the way before calling the project complete.

The website to document coding projects based on IETF specifications has been renamed to CodeStand due to conflict with other uses of an earlier name. The new site is: https://codestand.ietf.org. We’re looking for volunteers willing to create “Code Requests” for their specifications, and feedback can be sent to codestand-develop@ietf.org.

The IESG is considering what to do about email lists policies regarding DMARC, and its effect on people’s ability to send and receive list email. Some of us will meet during the Seoul IETF meeting and try to come up with the least worst Mailman change based on previously discussed suggestions. Any suggested configuration change will be advertised on the IETF mailing list first. Please stay tuned.

Welcome to IETF-97!

seoul-han-river-yeoido-bridge-01

IETF-97 is starting in a couple of days in Seoul, Korea, as well as running online for many participants connecting over the Internet. Either way, I hope to see you in the meeting! Agenda, registration, and remote attendance instruction can all be found from the IETF-97 meeting page.

There are more than a hundred meetings during the week on different topics, but I wanted to highlight a few ones that I think are significant or particularly interesting.

  • The topic erschrecklichewasserfluth of the technical plenary in the 97th IETF meeting will be “Attacks Against the Architecture”, a discussion about large-scale denial-of-service attacks involving Internet of Things devices and how the attacks leverage the Internet architecture. We will also talk about possible ways to think about solutions. Read more about this topic from the blog post.
  • The QUIC working group has just been chartered, and will meet for the first time in Seoul. This working group is taking Google’s pre-standardization QUIC protocol that has been deployed in production for several years, quicpic2 and will use it as a starting point to develop a UDP-based, stream-multiplexing, encrypted transport protocol with standardized congestion control, TLS 1.3 by default, a mapping for HTTP/2 semantics over QUIC, and multipath extensions. This is a significant development, because it changes the traditional layering from TCP, TLS, and HTTP to a more closely integrated transport functionality.
  • The TLS WG meets on Tuesday and Friday. The group has started working group last call on TLS1.3. It’ll be an extended and two part last call so we can get the WG participant feedback handled and then leave some time for the cryptographers to check that nothing bad’s happened since they last looked at a draft version. That “planned hold” has been on the cards since the start of the work. Expected end of the last call is in January and then all going well IETF last call.
  • In the Routing Area, YANG work is of high interest. A Joint YANG session among four Working Groups (CCAMP, MPLS, PCE, and TEAS) will be held on Monday to coordinate the work. Topics will include TE topology models, MPLS, PCE, Microwave Radio Link, and Transport.
  • IPWAVE is a new working group, focusing on communications in vehicular networks. For further information, bsb_04_2008_412_ets see the agenda. They are meeting on Wednesday.
  • LPWAN is a new working group that is focused on running internet protocols on a Low Power Wide Area Networks. See the agenda. They are meeting on Monday.

There are also a number of Birds-of-Feather or BOF meetings, focusing on the question of whether new work is needed on some topic:

  • DNSBUNDLED will be having a non-WG forming BOF on Wednesday. It is concerned with mapping and maintaining one DNS domain and all of its underlying name structure into another domain. For instance, being able to map the same labels across TLDs, such as example.com to example.net. The agenda for this BOF is here.
  • BANdwidth Aggregation for interNet Access (BANANA) will banana be having a non-WG forming BOF on Thursday. BANANA is concerned with providing coordinated Internet Access to a device over multiple links of different types to allow for increased bandwidth utilization, load-balancing and/or higher reliability. The goal of this BoF is to come up with a shared understanding of the problems that the IETF would like to solve in this space, complementing on and in collaboration with work ongoing in the MPTCP working group and the Broadband Forum. The group’s agenda is here.

For more information on these and other new proposals, there’s more information in the new work blog article.

Jari Arkko, IETF Chair

Photo credits: Seoul bridge Wikimedia (d’n’c – http://www.flickr.com/photos/fukagawa/195944150/), Burchardi flood Wikimedia (Contemporary picture), QUIC IETF (Jana Iyengar), road traffic controls Wikimedia (Mariordo Mario Roberto Duran Ortiz), and Multipath TCP Wikimedia (Aclarembeau).

Proposed Project: IETF Administrative Support 2.0

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 arrangements have served the IETF well, but there’s been considerable change in the necessary tasks, in the world around us, and our own expectations since the creation of the IASA. Looking forward, this is a good time to ask what administrative arrangements best support the IETF in the next ten years.

I am planning to start a project to assess those arrangements. Included in this project are the various challenges and frustrations* we’ve experienced along the way, but we also need to ask the bigger questions about how the organisations are structured. The project should assess what kind of support we need in the coming years, from the point of view of the community, IESG, IAB, IAOC, Trust, and partners (such as ISOC, long-term hosts or contractors). Areas to look at include structure, financing & sponsorship arrangements, organisation, and ways of working.

This project is to be done to serve the IETF community, hence the final determination of results and actions will rest on the community. Obviously there is a role for the IAOC & Trust in particular to provide direction in what they see is appropriate. And likewise for the the IESG and IAB in their respective roles, or ISOC for discussion of the relationship and arrangements with IETF. But I feel that the IETF chair needs to own the project and be responsible for ensuring that the community views are what finally determines the actions.

At this point, the project is a proposal, and I am soliciting feedback on the overall plan. Would be happy to revise per feedback. We will be working to create specific mailing lists for the substantial discussion later, but for setting up the project the proper place for discussion is probably here at ietf@ietf.org.

Here are stages of the project that I see:

Stage 1: Background documentation

  • -documenting the evolution of the IASA system implementation from 2005 to 2016 (an initial version in draft-daigle-iasa-retrospective)
  • sharing this background information with the community for review & update

Stage 2: Collecting input on challenges and requirements

  • understanding the situation from the IAOC internal perspective
  • understanding the situation from the IAB and IESG perspective
  • discussion in the community about the challenges and changed requirements
  • discussion with ISOC about the challenges and changed requirements
  • discussion with the long term hosts about the challenges and changed requirements
  • discussion with contractors about the challenges and changed requirements
  • the collection effort is facilitated by a design team (it is to be determined if the same team or different teams will be used in stages 2-4)
  • setting up a new working group for the discussions is also necessary
  • IAOC/IESG/IAB assistance will also be needed in the facilitation and discussion

Stage 3: Analysis and documentation

  • collect acquired information
  • discuss in the community
  • the analysis effort is again to be facilitated by a design team

Stage 4: Proposed improvements

  • suggest improvements that would address the key challenges
  • initial proposals created with the help of a design team, the results to be discussed in the community

Stage 5: Discussion of the improvements

  • community discussion

Stage 6: Specification and execution

  • specify the changes in RFCs, agreements
  • execute the changes

I have not yet assigned timelines for the stages, but the idea is to start the project in 2016 and use the winter and spring 2017 for the discussions, main results to be put in place sometime in 2017.

Jari Arkko, IETF Chair

(*) Some of these issues have been prominently visible in the IETF community, such as the discussions about early community involvement in making meeting site decisions. Others are internal to IASA operations, such as workload due to increasing IETF responsibilities. There are also structural question marks, such as the way that we select people to serve as board members, or the partial separation between the IAOC and the Trust.

Attacks Against the Architecture

erschrecklichewasserfluth

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?

In many cases the attacks are facilitated by very poor security practices on the devices, and improvements in that area are sorely needed. However, even with such improvement it seems important to improve the ability to defend the network against such attacks.

Enormous effort is being brought to bear on this issue, which has aspects ranging from the characteristics of specific internet protocols and services, through operations, public policy, and economics. But there are also some basic technical questions that are worth discussing: is the Internet architecture enabling compromised end nodes to wreak havoc on the network? Does it suggest anything about how to defend the network better? Is there a particular role for the IETF?

The topic of the technical plenary in the 97th IETF meeting will be “Attacks Against the Architecture”, a discussion about large-scale attacks, how they leverage the internet architecture, and possible ways to think about solutions.

Join us for the discussion in the IETF technical plenary on Wednesday, November 16, 16:40-19:10. The meeting will be held in Seoul, South Korea, but there are also remote participation tools available. To register for the meeting, click here.

Andrew Sullivan, IAB Chair
Suzanne Woolf, IAB Member
Jari Arkko, IETF Chair

Graphic: A flood that hit Germany and Denmark in 1634, source: wikipedia.

New Work in Seoul

seoul_at_night

A month before the meeting our steering group collects proposals for new working groups. We decide which ones are ready enough for the community to discuss the proposals in the meeting. We did this last week, and I wanted to report what new meetings will be held.

There are also a number of new working groups that have had their community consideration earlier, and are being considered to be created, or were recently created. I will also mention some of these working groups.

Here are the new meetings:

  • The QUIC working group has just been chartered, and will meet for the first time in Seoul. This working group is taking Google’s pre-standardization QUIC protocol that has been deployed in production for several years, and will use it as a starting point to develop a UDP-based, stream-multiplexing, encrypted transport protocol with standardized congestion control, TLS 1.3 by default, a mapping for HTTP/2 semantics over QUIC, and multipath extensions. This is the IETF’s first standardized always-encrypted transport protocol, so careful consideration of applicability and operational capabilities will be key for success.
  • DNSBUNDLED will be having a non-WG forming BOF in Seoul. The responsible AD is Terry Manderson, with Andrew Sullivan as the IAB Shepherd. DNSBUNDLED is concerned with a problem statement of mapping and maintaining one DNS domain and all of its underlying name structure into another domain. The following related use cases have been proposed: 1) map across TLDs such as example.com to example.net; 2) map different label within a TLD, i.e example1.com to example2.com; 3) map different labels across different TLDs, for instance example1.com to eaxmple2.net, and lastly 4) where multiple domains map to one domain such as example.com, example.net, example.org all map to example.gTLD. The mailing list for this BOF is here and one of the Internet Drafts on this topic is here.
  • BANdwidth Aggregation for interNet Access (BANANA) will be having a non-WG forming BOF in Seoul. BANANA is concerned with providing coordinated Internet Access to a device over multiple links of different types to allow for increased bandwidth utilization, load-balancing and/or higher reliability. The goal of this BoF is to come up with a shared understanding of the problems that the IETF would like to solve in this space, complementing on and in collaboration with work ongoing in the MPTCP working group and the Broadband Forum. The group’s mailing list is here.
  • IPWAVE is a new working group, focusing on communications in vehicular networks. Vehicles are increasingly connected to the Internet. Comfort-enhancing entertainment applications, road safety applications using bidirectional data flows, and connected automated driving are some of the few new features expected in this area. This group will work on use-cases where IP is well-suited as a networking technology and will develop an IPv6 based solution to establish direct and secure connectivity between a vehicle and other vehicles or stationary systems.
  • LPWAN is a new working group that is focused on running internet protocols on a Low Power Wide Area Networks. There are several very diverse LPWA lower layer technologies such as NB-IoT, SIGFOX, LoRa, and WI-SUN. and The goal of this working group is to converge these radio technologies towards a common hour glass model, with a highly compressed form of IPv6 and CoAP between the end-device and the network gateway. This will enable the creation of common mechanisms for management of the gateway and for providing secure, Internet-based services to the applications.
  • L2SM is a proposed working group, currently under consideration. It is intended as a short-lived WG, tasked to create a YANG data model that describes a L2VPN service (a L2VPN service model) that can be used for communication between customers and network operators, and to provide input to automated control and configuration applications. The working group will attempt to derive a single data model that includes support for point-to-point Virtual Private Wire Services (VPWS) and multipoint Virtual Private LAN services (VPLS) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFC4761 and RFC6624.
  • SECEVENT is a new working group. The group works on a mechanism to convey messages between systems in order to prevent or mitigate security risks, or to provide out-of-band information as necessary.
  • SIDROPS is another new working group currently under consideration to be created. This group discusses operational experiences around the global deployment of RPKI, Origin Validation of BGP announcements and BGPSEC, collectively called SIDR. This technology helps protect the Internet routing infrastructure against various kinds of attacks.

Join our meeting to discuss these and many other interesting topics! If you haven’t registered yet, you can do so on the IETF-97 web page.

Jari Arkko, IETF Chair

Photo credits: By travel oriented – Flickr, CC BY-SA 2.0, https://commons.wikimedia.org/w/index.php?curid=41839161

IANA Stewardship Transition Goes Ahead

wordle14

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.

A large number of people have worked hard in the communities to make this day possible. Thank you for your efforts!

This is a good day — but also in many ways just like previous days. It is what we are already doing. The Internet will continue to work as it has before. The communities continue to work with the IANA system to make sure it responds to the needs of the users, as we have. Networks and people co-operate, voluntarily, so that they can connect over the Internet. Just like what the world has been doing since the dawn of the Internet.

chairs600

green600

I asked Andrew Sullivan, IAB Chair, what he thinks. He said: “Like many things on the Internet, this is the result of many incremental steps by many people. It is incremental change that brings us the stability of the Internet.”

And I also asked Alissa Cooper, Chair of the IANA stewardship transition Coordination Group (ICG). She said: “We rarely get the opportunity to witness a global consensus as broad and diverse as the one in favor of this transition. Hundreds of people and organizations from across sectors and across the world had the courage and endurance to see this process through, and as a result the Internet is running as smoothly today as it did yesterday.”

I agree with them. This is business as usual: we will continue to be a part of the IANA system, and feel responsible for ensuring that it stays healthy and responds to community needs.

Jari Arkko, IETF Chair

Photo and graphics credits: www.wordle.net and Alain Durand

BOFs for IETF-97

Downtown skyline of Seoul, South Korea with Seoul Tower.

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 cut-off date for new working group proposals — we call them “Birds of a Feather” or BOFs — is September 30, in two weeks.

Please talk to your Area Directors about your ideas!

If you are considering submitting a new idea, please read RFC 5434: Considerations for Having a Successful Birds-of-a-Feather Session and BOF Procedures.

All the IETF-97-related dates and deadlines can be found here. You can register at the meeting here.

Jari Arkko, IETF Chair

Working with the IEEE 802

mtg

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. From the IETF perspective, the most relevant IEEE standards group is the IEEE 802 LAN/MAN Standards Committee. It develops and maintains networking standards and recommended practices for local, metropolitan, and other area networks.

IETF and IEEE 802 leadership and liaison managers are in contact regularly, and every couple of years we also meet in person to better understand what work is happening on the other side, and make sure we stay coordinated. Last week, we held our fourth such meeting, continuing our tradition of meeting in outskirts of large airports in nondescript hotels 🙂 this time outside Charles-de-Gaulle airport in Paris.

But the surroundings don’t matter as much as the substance. Also, both organisations are very clear that the best way to collaborate is to make sure that there are joint participants who work through topics that are important for them, in both organisations. This collaboration cannot be done through the management chain, people actually doing the standards and implementing them have to be the ones in the driver’s seat.

However, light coordination is useful to understand what things are coming down the pipeline, understand the official situation on some topic, and so on. For this purpose, we’ve defined ways of working together in RFC 7241, we’ve set up a team for the coordination, have a mailing list (https://www.ietf.org/mailman/listinfo/ieee-ietf-coord), and hold monthly conference calls and meet at the IETFs. We also have official liaisons in place, as part of inter-organisation coordination being an official activity of the IAB. If you have any topic that needs the attention of the coordination team, please contact Dan and Pat for further information.

In our meeting last week, we talked about a number of interesting topics:

  • Internet of Things standardisation efforts. iot There are many joint or connected efforts here, for instance those relating to various 802.15.4 needs, such as the IETF 6TISCH WG. It was also interesting to learn that IEEE 802 is working on a couple of projects that deal with the local administration of MAC addresses, and has developed new cabling and Ethernet standards for low-speed, low cost/energy consumption markets. One example of these projects is the 10Mbit/s specification for Ethernet over a single twisted pair cable. More information IOT-related projects at IEEE can be found here.
  • Both organisations are pursuing better privacy in the Internet and networks connected to it. For instance, IEEE has worked on MAC privacy, which was also tested in IETF meeting networks, and both organisations are keen on continuing with further improvements.
  • Ongoing efforts in both the IETF and IEEE 802 to develop “deterministic” networking standards. For more information, see the related activities in IEEE 802 and the IETF DETNET WG.
  • We also noted upcoming work on future technologies, such as 5G, and discussed the role of IEEE and IETF in these efforts. We agreed to collaborate when any joint work would be needed.

The minutes of the Paris meeting are available here.

Jari Arkko, Chair, IETF
Dan Romascanu, IETF liaison to IEEE SA
Pat Thaler, Vice Chair, IEEE 802
Suresh Krishnan, Internet Area Director, IETF