Internet Society’s Rough Guide to IETF 79’s Hot Topics #ietf @Internet Society

IETF 79 in Beijing is rapidly approaching (7-12 November). Newcomers’ training and technical tutorials take place on Sunday (7 November), with the working group, BoF, and plenary sessions happening during the week.

Once again, the Internet Society is pleased to bring you our regular rough guide to the sessions most relevant to our current work.

Details below:


We have turned our attention to the following broad categories:

  • Common and Open Internet
  • Global Addressing
  • Security and Stability
  • Trust and Identity

In addition to these categories, a session of general interest to those who participate in IETF activities is:

iddtspec (Review of Datatracker Specifications to Follow Internet-Draft Activities) BoF

The goal of this BoF is to review specifications for datatracker enhancements that allow IETF Participants to easily follow the activities associated with particular Internet-Drafts. This is an IETF “meta-level” session — the output of this discussion will help frame how the operational work of IETF participants is supported, going forward. The current datatracker tool is accessible here: https://datatracker.ietf.org/.  It provides an index of finalized and in-progress documents, as well as an overview of IESG comments and positions on document review.

Draft charter: N/A
Agenda: http://www.ietf.org/proceedings/79/agenda/iddtspec.txt
(November 8, 2010; 1300-1500 and 1510-1610)

Of course, with more than 100 working groups, there are many other important technologies under discussion. So for full details of the IETF 79 agenda, see:

https://datatracker.ietf.org/meeting/79/agenda.html

(All times are local China Standard Time, UTC +8)

Remote participation information is available at:

http://www.ietf.org/meeting/79/remote-participation.html

_____________________________________
Common and Open Internet
As P2P and VoIP technologies become more prevalent, and network usage patterns sometimes deviate from their architects’ expectations, managing bandwidth to allow best use for customers becomes an increasingly important topic.
_____________________________________

behave WG

The behave Working Group creates documents to make NATs function in as deterministic manner as possible. Much of the recent work has been to document the behavior of IPv6/IPv4 protocol and address translation. A set of documents for these operations are now in the RFC Editor’s queue. There is some continuing work on remaining documents to complete this set. There is discussion of proposed new work related to these documents and processes of transition from IPv4 to IPv6 networks that may be related to NAT type operations during transition.

WG charter: https://datatracker.ietf.org/wg/behave/charter/
Agenda: http://www.ietf.org/proceedings/79/agenda/behave.html
(11 November 2010; 1520-1720)

————–

conex (Congestion Exposure) WG

The conex WG is concerned with exposing the congestion on the forward path of a flow to the network elements along that path. The mechanism will provide a ‘building block’ for ISPs and application developers to better share available capacity between users and competing applications in the presence of congested bottleneck links. The WG is defining use-cases for the mechanism as well as an abstract mechanism specification and a concrete implementation for IPv6 networks.

Charter: http://datatracker.ietf.org/wg/conex/charter/
Agenda: http://www.ietf.org/proceedings/79/agenda/conex.txt
(11 November 2010; 0900-1130)

————–

ippm (IP Performance Metrics) WG

The IPPM WG has developed a set of standard metrics that can be applied to the quality, performance, and reliability of Internet data delivery services. These metrics are designed such that they can be performed by network operators, end users, or independent testing groups. As the quality of broadband service offerings, and meaningful comparison between competitive ISPs becomes increasingly important to consumers and regulators, so the work of this group becomes more important and relevant.

Charter: http://datatracker.ietf.org/wg/ippm/charter/
Agenda: http://www.ietf.org/proceedings/79/agenda/ippm.txt
(8 November 2010; 0900-1130)

————–

ledbat (Low Extra Delay Background Transport) WG

The ledbat WG is defining a congestion control algorithm that automatically yields to TCP in the presence of congested bottleneck links. It is delay-based, as opposed to TCP’s loss-based algorithm and is beneficial for bulk-transfer applications that are not time-critical such as P2P file sharing. The WG is nearing completion, and is now fine-tuning the specification in light of simulation results.

Charter: http://datatracker.ietf.org/wg/ledbat/charter/
Agenda: http://www.ietf.org/proceedings/79/agenda/ledbat.txt
(9 November 2010; 1300-1500)

_____________________________________
Global Addressing
There is steadily increasing momentum to deploy IPv6 as the IPv4 address pool approaches depletion. While much work is ongoing to support interoperability in coexisting IPv4 and IPv6 network environments, there are also interesting developments in emerging IPv6 environments.
_____________________________________

6lowpan (IPv6 Over Low Power Networks) WG

The 6lowpan Working Group exists to develop IETF standards for IPv6 over low-power personal area networks. A lot of the work has focused on developing a version of IPv6 neighbor discovery that is more suited to networks with intermittent and irregular connectivity, where use of the radio resources is limited. A version of this document has been sent to working group last call since the last IETF. There is also work to document routing requirements, use cases, and to develop a header compression algorithm for these networks.

WG charter: https://datatracker.ietf.org/wg/6lowpan/charter/
Agenda: http://www.ietf.org/proceedings/79/agenda/6lowpan.txt
(9 November 2010; 1520-1700)

————–

armd (Address Resolution for Massive amount of hosts in cloud/internet Data center) BoF

This is an INT Area BoF to look at challenges that clusters of virtualized machines (VMs) and clouds can face in basic switching architectures. The particular import is in how these types of hosts are impacted by, and may impact, networking requirements.

Draft charter: http://trac.tools.ietf.org/bof/trac/attachment/wiki/WikiStart/armd-charter.rtf
Agenda: http://www.ietf.org/proceedings/79/agenda/armd.txt
(9 November 2010; 0900-1130)

————–

pcp (Port Control Protocol) WG

The PCP working group is chartered to standardize a client/server Port Control Protocol (PCP) to enable an explicit dialog with a middlebox such as a NAT or a firewall to open up and/or forward TCP or UDP port, regardless of the location of that middlebox. Today, an end host behind a CPE NAT is able to use UPnP or NAT-PMP to open an inbound port on the NAT for applications that require such a port to operate, e.g. P2P or VoIP. In the presence of a centralised ‘carrier-grade’ NAT, such protocols will fail to operate, hence the desire for PCP. This work is enabling technology for Internet operators to continue providing IPv4 Internet service after the IPv4 free-pool of addresses is depleted.

Charter: http://datatracker.ietf.org/wg/pcp/charter/
Agenda: TBD
(11 November 2010; 1740-1940)

————–

v6ops (IP v6 Operations) WG

The v6ops Working Group continues to work on the development of operational guidelines for IPv6 deployment as IPv6 deployment continues in the global Internet. Documents in progress range from informational guidance on IPv6 deployment, updates to deployment guidance based on deployment experience, to requirements for components needed for large scale IPv6 deployment.

WG charter: https://datatracker.ietf.org/wg/v6ops/
Agenda: http://www.ietf.org/proceedings/79/agenda/v6ops.html
(10 November, 0900-1130; 12 November 2010, 1300-1530)

_____________________________________
Security and Stability
Securing the DNS and greater assurance in routing is critical for the ongoing expansion and evolution of the Internet in all areas of our societies and economies.
_____________________________________

karp (Keying and Authentication for Routing Protocols) WG

The karp WG is focused on improving the state of authentication in all the Internet routing protocols. Many routing protocol deployments, if they use authentication at all, are using older (possibly deprecated) cryptographic algorithms and missing some modern security mechanisms, like replay protection, algorithm agility, or key rollover. In addition, many use the same key permanently. This meeting will be focused on progressing the three foundational documents. These documents form the basis for all subsequent karp WG efforts. Additionally, the working group will discuss a database of long-lived cryptographic keys, an operations model for router keying, and multicast router key management.

The full charter is available at: http://tools.ietf.org/wg/karp/charters
Agenda: http://www.ietf.org/proceedings/79/agenda/karp.html
(11 November 2010; 1740-1940)

————–

kidns (Cryptographically Secured Communication by Using Information in the DNS) BoF

This BoF meeting is seeking to form a chartered effort within the IETF to specify mechanisms and techniques that allow Internet applications to establish cryptographically secured communications by using information distributed through the DNS for discovering and authenticating public keys which are associated with a service located at a domain name. Building upon the implementation and deployment of DNSSEC, this work seeks to use the chain of trust established in the DNS to enable on-demand establishment of secure channels for a multiplicity of applications. The technical and business implications of this work are significant and this is expected to be a lively meeting.

Draft Charter: http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure
Agenda: http://www.ietf.org/proceedings/79/agenda/kidns.txt
(11 November 2010; 1520-1720)

————–

sidr (Secure Inter-Domain Routing) WG

The SIDR WG is focused on securing inter-domain routing. The approach being developed is Resource PKI (RPKI). RPKI adds an authentication framework to BGP. It is going to require a certificate management infrastructure, and models that accommodate infrastructure are on the agenda. This is a key technology for improving trust in the routing infrastructure.

The full charter is available at: http://tools.ietf.org/wg/sidr/charters
Agenda: http://www.ietf.org/proceedings/79/agenda/sidr.txt
(11 November 2010; 0900-1130)

————–

websec (Web Security) WG

The websec Working Group, currently in formation is a follow-on to the successful hasmat BoF held at IETF 78. The agenda includes a discussion of sniffing and well as updates on several recent drafts. The hasmat mailing list is at: http://www.ietf.org/mail-archive/web/hasmat/current/maillist.html

Draft Charter: http://tools.ietf.org/wg/websec/
Agenda: http://www.ietf.org/proceedings/79/agenda/websec.txt
(9 November 2010; 1300-1500)

_____________________________________
Trust and identity
As public concerns increase about security of infrastructure, privacy, trust, and dentity on the Internet, these themes recur in several working group discussions.
_____________________________________

abfab (Application Bridging for Federated Access Beyond Web) WG

This working group was created after two recent meetings: Moonshot (http://www.project-moonshot.org/bof/agenda/), a Bar BoF at IETF 77 and the FedAuth Bof at IETF 78. The agenda includes an introduction to the current work plan for new entrants and a review of three current drafts.

Charter: http://tools.ietf.org/wg/abfab/
Agenda: http://www.ietf.org/proceedings/79/agenda/abfab.txt
(11 November 2010; 0900-1130)

————–

oauth WB
Open Authentication Protocol (Active WG) will not meet in Beijing

There may be an on-site tutorial and an informal meeting for participants
interested in OAuth and Security. Details will be posted to the OAuth list:
http://www.ietf.org/mail-archive/web/oauth/current/maillist.html

Charter: http://tools.ietf.org/wg/abfab/

————–

scap (Secure Content Automation Protocol) BoF
Synergy of SCAP Program and IETF Activities

This BoF is intended to introduce the IETF community to the Security Content Automation Protocol (SCAP), discuss areas of synergy and overlap with IETF activities, and consider whether this technology is sufficiently mature for standardization. Finally, explore whether the IETF would be an appropriate venue for such standardization when ready.

Agenda: http://www.ietf.org/proceedings/79/agenda/scap.txt
(9 November 2010; 1520-1810)