[Chapter-delegates] IETF 77 Rough Guide
Sabrina Wilmot
wilmot at isoc.org
Thu Mar 18 03:26:49 PDT 2010
Dear Colleagues,
Following on our tradition from last IETF meetings, ISOC has put
together the following "Rough Guide" to IETF 77 touching on topics of
interest.
Please feel free to share it with any of your members, or any one else
you think might make use of it. We hope it is of interest and helpful.
Kind regards,
Sabrina Wilmot
ISOC
-----------------------------------------------
ISOC's Rough Guide to IETF 77's Hot Topics
-----------------------------------------------
IETF 77, the first IETF meeting of the year, will be held in Anaheim,
California, USA, from 21-26 March 2010. Newcomers' training and
technical tutorials take place on the Sunday, with the working group,
BoF, and plenary sessions happening during the week.
Once again, the Internet Society's Standards and Technology team, with
help from the Trust and Identity team, is pleased to bring you our
regular rough guide to the sessions most relevant to our current work.
We have turned our attention to the following broad categories:
- Common and Open Internet
- Global Addressing
- Security and Stability
- Trust and Identity
Of course, with more than 100 working groups, there are many other
important technologies under discussion. So for full details of the IETF
77 agenda, see:
https://datatracker.ietf.org/meeting/77/agenda.html
(All times below are local US Pacific Daylight Time, UTC-7)
_____________________________________
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.
_____________________________________
alto (Application-Layer Traffic Optimization) WG
The alto WG is occupied with designing a service to provide applications
with information from the network that enables them to perform
better-than-random peer selection. In this context, there are various
definitions of "better" (such as maximum throughput, minimum
cross-domain traffic, and lowest cost to the user).
Full charter: http://www.ietf.org/dyn/wg/charter/alto-charter.html
Agenda: http://tools.ietf.org/wg/alto/agenda
(22 March, 17:40-19:40)
--------------
conex (Congestion Exposure) BOF
Congestion Exposure (ConEx) is a proposed new IETF activity to enable
congestion to be exposed along the forwarding path of the Internet. By
revealing expected congestion in the IP header of packets, congestion
exposure provides a generic network capability which allows greater
freedom over how capacity is shared. Such information could be used for
many purposes, including congestion policing, accountability and
inter-domain SLAs. It may also open new approaches to QoS and traffic
engineering.
This will be the second ConEx BOF, with discussions aiming to tighten up
the intent and scope of the work plan for a proposed charterable WG
activity.
Proposed charter: http://www.ietf.org/iesg/evaluation/conex-charter.txt
Related drafts:
http://tools.ietf.org/html/draft-moncaster-conex-problem-00
http://tools.ietf.org/html/draft-tschofenig-conex-ps-02
Agenda: http://www.ietf.org/proceedings/10mar/agenda/conex.txt
(24 March, 15:10-16:10 and 25 March 15:10-16:10)
--------------
decade (Decoupled Application Data Enroute) BOF
This BOF has been formed to investigate ways to define a standard way
for P2P applications to make use of in-network storage.
Draft charter:
http://www.ietf.org/mail-archive/web/decade/current/msg00175.html
This BOF expected to become a working group.
Agenda: http://www.ietf.org/proceedings/10mar/agenda/decade.txt
(26 March, 13:00-15:15)
--------------
ledbat (Low Extra Delay Background Transport) WG
This Working Group is working on defining a congestion control algorithm
that enables bandwidth intensive, background file-transfer applications
(such as P2P) to automatically get out of the way when real-time,
conversational, or interactive applications (such as VoIP or Web
browsing) need service from the network.
Full charter: http://www.ietf.org/dyn/wg/charter/ledbat-charter.html
Agenda: Not yet available.
(22 March, 09:00-11:30)
--------------
mptcp (Multipath TCP) WG
This working group is developing mechanisms that add the capability of
simultaneously using multiple paths to a regular TCP session. The
primary output of the group will be the protocol extensions needed to
deploy MPTCP, and adaptations to congestion control to safely support
multipath resource sharing. This work has the potential to greatly
improve robustness and resilience of Internet connectivity for
multihomed sites.
Full charter: http://www.ietf.org/dyn/wg/charter/mptcp-charter.html
Agenda: http://tools.ietf.org/wg/mptcp/agenda
(23 March, 15:20-17:20)
_____________________________________
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.
_____________________________________
behave (Behavior Engineering for Hindrance Avoidance) WG
While behave was chartered to create mechanisms for transiting NATs in
reliable ways, most of its activity is now focused on protocol
translation from IPv4 to IPv6 in a number of different scenarios. Of
particular interest in these scenarios is how the proposed mechanisms
deal with DNS operation across the two protocol realms (and whether it
is possible to maintain any kind of reasonable operation of secure DNS
in such a scenario).
Full charter: http://www.ietf.org/html.charters/behave-charter.html
The IETF and 3GPP held a joint workshop on IPv6 deployment strategies
for 3GPP networks on 1 and 2 March. Dan Wing has produced a summary
meeting report of that meeting, which will be published in the
forthcoming IETF Journal. There may also be a discussion of this meeting
during the INT area meeting at IETF (at time of writing, an agenda has
not yet been posted). One of the important outcomes seemed to be a
recognition that there is not community support for PNAT based
proposals. The first session is set aside to close out the remaining
comments on the 6to4 protocol translation documents (address format,
dns64, v6v4 framework, 64 translation).
Agenda: http://tools.ietf.org/wg/behave/agenda
(25 March, 13:00-15:15)
--------------
core (Constrained RESTful Environments) WG
(formed from 6lowapp (Application Protocols for Low-power v6 Networks) BOF
The 6lowapp BOF has indeed been chartered as a working group, called
CoRE. CoRE is providing a framework for resource-oriented applications
intended to run on constrained IP networks. A constrained IP network
has limited packet sizes, may exhibit a high degree of packet loss, and
may have a substantial number of devices that may be powered off at any
point in time but periodically "wake up" for brief periods of time.
Full charter: http://www.ietf.org/dyn/wg/charter/core-charter.html
CoRE will hold its first working group meeting at IETF 77. The 6lowapp
BOF has been considering whether different protocols, or modifications
to existing protocols, are needed for very low power devices that may
proliferate for sensor type networks.
Agenda: http://tools.ietf.org/wg/core/agenda
(25 March, 09:00-11:30)
--------------
intarea (Internet Area)
A request has been made to present draft-ford-shared-addressing-issues
(http://tools.ietf.org/html/draft-ford-shared-addressing-issues-02) at
this meeting and to request adoption as a working group work item. This
work was co-authored and edited by ISOC staff.
Agenda: not available
--------------
v6ops (IPv6 Operations) WG
The IPv6 Operations Working Group (v6ops) develops guidelines for the
operation of a shared IPv4/IPv6 Internet and provides operational
guidance on how to deploy IPv6 into existing IPv4-only networks, as well
as into new network installations.
Full charter: http://www.ietf.org/html.charters/v6ops-charter.html
Agenda: http://tools.ietf.org/wg/v6ops/agenda
(26 March, 09:00-11:30)
_____________________________________
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.
_____________________________________
dnsop (Domain Name System Operations) WG
The dnsop WG works on various operational aspects of the Domain Name System.
Full charter: http://www.ietf.org/dyn/wg/charter/dnsop-charter.html
Yahoo! has a proposal for improving the behavior of recursive name
resolvers for IPv6. There is no draft for this yet, but there is a
planned discussion of this in the DNSOP working group. Yahoo has
presented this proposal in NANOG and this is an opportunity for a wider
audience review.
Agenda: http://tools.ietf.org/wg/dnsop/agenda
(24 March, 13:00-15:00)
--------------
karp (Keying and Authentication for Routing Protocols) WG
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 needs to be fixed. Additionally, key management for
routing protocols needs to be added to easily address the
terminated-employee problem of compromised shared secrets. Such key
management needs to work over multicast media, and needs to work
directly over the link layer in some cases (since routing depends upon it).
Full charter: http://tools.ietf.org/wg/karp/charters
This recently chartered working group will address a package of
framework docments drawn from the work of the original BOF participants
Agenda: http://tools.ietf.org/wg/karp/agenda
(23 March, 09:00-11:30)
--------------
RRG (Routing Research Group)
The Routing Research Group (RRG) is chartered to explore routing and
addressing problems that are important to the development of the
Internet but are not yet mature enough for engineering work within the IETF.
Group charter: http://www.irtf.org/charter?gtype=rg&group=rrg
The RRG has been considering a number of proposals for solving the route
scaling "problem" in the routing infrastructure. During the meeting on
Friday these proposals will be reviewed and discussed. The RADIR
produced an Internet draft that may be used as input to this discussion,
available here:
https://datatracker.ietf.org/doc/draft-narten-radir-problem-statement.
One of the key issues is to what extent the problem has been analyzed
since the IAB workshop on routing and addressing in October, 2006.
Agenda: http://trac.tools.ietf.org/group/irtf/trac/wiki/RRGagendaAnaheim
(26 March, 09:00-11:30)
_____________________________________
Trust and identity
As public concerns increase about security of infrastructure, privacy,
trust, and identity on the Internet, these themes recur in several
working group discussions.
_____________________________________
Applications Area Open Meeting
At this session, two new SASL related drafts of interest to identity
providers will be covered.
A SASL Mechanism for SAML
(http://tools.ietf.org/html/draft-wierenga-ietf-sasl-saml-00)
- This memo specifies a SASL mechanism for SAML 2.0 that allows the
integration of existing SAML Identity Providers with applications using
SASL.
A SASL Mechanism for OpenID
http://tools.ietf.org/html/draft-lear-ietf-sasl-openid-00
- This memo specifies a SASL mechanism for OpenID that allows the
integration of existing OpenID Identity Providers with applications
using SASL.
Participants at this meeting can expect some cross-over with the
Moonshot Bar BOF participants.
(22 March, 09:00-11:30)
--------------
httpstate (HTTP State Management Mechanism) WG
The HTTP State Management Mechanism (aka Cookies) was originally
created by Netscape Communications in their informal Netscape cookie
specification ("cookie_spec.html"), from which formal specifications
RFC 2109 and RFC 2965 evolved. The formal specifications, however,
were never fully implemented in practice; RFC 2109, in addition to
cookie_spec.html, more closely resemble real-world implementations
than RFC 2965, even though RFC 2965 officially obsoletes the former.
Compounding the problem are undocumented features (such as HTTPOnly),
and varying behaviors among real-world implementations.
Full charter: http://www.ietf.org/dyn/wg/charter/httpstate-charter
This working group will create a new RFC that:
- obsoletes RFC 2109,
- updates RFC 2965 to the extent it overlaps or voids RFC 2109, and
- specifies Cookies as they are actually used in existing
implementations and deployments.
Agenda: http://tools.ietf.org/wg/httpstate/agenda
(23 March, 17:40-19:40)
--------------
The Moonshot Bar BOF
This Bar BOF (outside the formal agenda) will discuss federated
authentication beyond the web.
Description: http://www.painless-security.com/blog/2010/02/12/moonshot1
Related:
A GSS-API Mechanism for the Extensible Authentication Protocol,
http://www.ietf.org/internet-drafts/draft-howlett-eap-gss-00.txt
"Project Moonshot: Community briefing paper for the TF-EMC2 &
TF-Mobility meetings, Vienna, 16-18 February 2010", 5 February 2010,
Josh Howlett, JANET(UK)
http://www.terena.org/mail-archives/mobility/pdfEKnl2kkFsw.pdf
(20 March, 21:00, Manhattan Room)
--------------
newprep (Stringprep after IDNA2008) BOF
The handling of non-ASCII strings in Internet protocols is a difficult
problem that has still not been solved in a generalized way. In 2002,
the IETF defined a method for preparation and comparison of
internationalized strings that could be re-used by various applications.
This method, stringprep (RFC 3454), has been re-used in several Internet
protocols that have defined "profiles".
In completing revisions to the IDN technology, the IETF's IDNAbis WG
decided to move away from the use of stringprep in domain names, instead
defining sets of allowed and disallowed characters based on Unicode
character properties (often called an "inclusion approach") rather than
defining explicit mappings of Unicode characters as in stringprep (an
"exclusion approach").
However, any move away from stringprep by existing profiles would
introduce backward compatibility issues and migration challenges, which
need to be weighed against the benefits of a new string preparation
technology.
Draft charter: http://trac.tools.ietf.org/area/app/trac/wiki/NewPrep
Agenda: Not yet available
(23 March, 15:20-17:20)
--------------
oauth (Open Authentication Protocol) WG
OAuth allows a user to grant a third-party Web site or application
access to their resources, without necessarily revealing their
credentials, or even their identity.
Full charter: http://tools.ietf.org/wg/oauth/charters
Current topics include a discussion of signatures. The focus is on
"signing requests" not on "signing tokens" Requests signing secures the
direct communication between two parties (consumer and authorization
server / consumer and protected resource). In contrast, signed tokens
are used in stateless authorization server designs to protect token
contents from modification thus establishing trust between authorization
server and protected resource.
http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy
Also on the agenda is the disposition of OAuth Web Resource
Authorization Profiles (WRAP)
http://tools.ietf.org/html/draft-hardt-oauth-01.
There will also be a discussion of use cases
(http://trac.tools.ietf.org/wg/oauth/trac/wiki/OauthUseCases) as well as
work on the OAuth 2 specification.
Agenda: http://tools.ietf.org/wg/oauth/agenda
(22 March, 13:00-15:00)
--------------
rydeirde (Registry Data Escrow/Internet Registration Escrow) BOF
In the context of domain name registries, registration data escrow is a
requirement for the current generic top-level domains and it is expected
to be for new registries. Some country code top-level domain managers
are also interested in implementing registration data escrow for
themselves. There is also such a requirement for ICANN's generic
top-level domain accredited registrars.
The desired outcome of this BOF is to have a mutually agreed
specification of the contents and format of the deposits, allowing
extensions for new services and objects.
Draft charter: http://trac.tools.ietf.org/area/app/trac/wiki/IRDE
Agenda: http://trac.tools.ietf.org/area/app/trac/wiki/IRDE
(24 March, 10:30-11:30)
==================================================================
More information about the Chapter-delegates
mailing list