16ng 6lowpan 6man adslmib alto ancp autoconf avt behave bfd bliss bmwg btns calsify capwap ccamp csi dccp dhc dime dispatch dkim dnsext dnsop drinks eai ecrit emu enum fecframe forces geopriv grow hip hokey httpbis idnabis idr ipdvb ipfix ippm ipsecme isis isms keyprov kitten krb-wg l2tpext l2vpn l3vpn ledbat lemonade lisp ltans ltru manet mboned mediactrl mext mif mip4 mipshop mmusic morg mpls mptcp msec multimob nea netconf netext netlmm netmod nfsv4 nsis ntp oauth opsawg opsec ospf p2psip pana pce pcn pim pkix pmol pppext pwe3 radext rmt rohc roll rtgwg sasl savi shim6 sidr sieve simple sipclf sipcore smime softwire speechsc speermint storm syslog tcpm tictoc tls trill tsvwg v6ops vcarddav vrrp vwrap xcon xmpp yam IP over IEEE 802.16 Networks (16ng) ----------------------------------- Charter Last Modified: 2009-10-05 Current Status: Active Working Group Chair(s): Gabriel Montenegro Soohong Daniel Park Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Technical Advisor(s): Maximilian Riegel Dave Thaler Secretary(ies): Jihoon Lee Mailing Lists: General Discussion:16ng@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/16ng Archive: http://www.ietf.org/mail-archive/web/16ng Description of Working Group: Broadband Wireless Access Networks address the inadequacies of low bandwidth wireless communication for user requirements such as high quality data/voice service, wide coverage, etc. The IEEE 802.16 Working Group on Broadband Wireless Access Standards develops standards and recommended practices to support the development and deployment of Broadband Wireless Metropolitan Area Networks. A particularity of IEEE 802.16 is that it does not include a rigid upper edge MAC service interface. Instead, it provides multiple "convergence sublayers (CS)" with the assumption that the choice and configuration of the upper edge will be done in accordance with the needs of a specific deployment environment (which might be DSL replacement, mobile access, 802.11 or CDMA backhaul etc.). Specifically, immediately subsequent to network entry, an 802.16 subscriber station has no capability whatsoever for data (as opposed to management) connectivity. Especially, in IP CS case, the criteria by which the Base Station (or other headend elements) sets up the 802.16 MAC connections for data transport are not part of the 802.16 standard, and depend on the type of data services being offered (e.g., the set up of link layer connections will be different for IPv4 and IPv6 services). Additionally - as IEEE 802.16 is a point-to-multipoint network - an 802.16 subscriber station is not capable of multicasting (e.g., for neighbor discovery, ARP, IP multicasting services, etc.) or direct communication to the other nodes attached to the same Base Station within the same subnet (prefix). Unlike 3G or xDSL technologies, IEEE 802.16 is not part of an end-to- end system definition. Currently, the WiMAX Forum, and, in particular, its NWG (Network Working Group) is defining a network architecture based on IEEE 802.16. The principal objective of the 16ng working group is to specify the operation of IPv4 and IPv6 over IEEE 802.16, taking into account the IPv4, IPv6 and Ethernet Convergence Sublayers. The working group may issue recommendations to IEEE 802.16 and WiMax aiming at improving support for IP. The scope of this working group is as follows (WG Deliverables); - Produce "16ng Problem Statement, Goal and Requirement" to identify the specific gaps in the 802.16 MAC for IPv4/IPv6 support, describe possible network models (ie. point-to-point, broadcast etc.), and provide 16ng related terminology to be used for the base guideline while defining solution frameworks. [Informational RFC] - Produce "IPv6 over IEEE 802.16 Networks in conjunction with IPv6 CS" to define IPv6 operation including the transmission of IPv6 over IEEE 802.16 link, Neighbor Discovery Protocol, Stateful (DHCPv6) and Stateless Address Configuration, Broadcast, Multicast, etc. [Proposed Standard RFC] - Produce "IPv6 over IEEE 802.16 Networks in conjunction with Ethernet CS" to define IPv6 operation including the transmission of IPv6 over IEEE 802.16 link, Neighbor Discovery Protocol, Stateful (DHCPv6) and Stateless Address Configuration, Broadcast, Multicast, etc. [Proposed Standard RFC] - Produce "IPv4 over IEEE 802.16 Networks in conjunction with IPv4 CS" to define IPv4 operation including the transmission of IPv4 over IEEE 802.16 links, ARP operation, Stateful Address Configuration (DHCPv4), Broadcast, Multicast, etc [Proposed Standard RFC] - Produce "IPv4 over IEEE 802.16 Networks in conjunction with Ethernet CS" to define IPv4 operation including the transmission of IPv4 over IEEE 802.16 links, ARP operation, Stateful Address Configuration (DHCPv4), Broadcast, Multicast, etc [Proposed Standard RFC] - Produce "IP deployment over IEEE 802.16 Networks" to illustrate the IP deployment scenarios including IP CS and Ethernet CS considerations over IEEE 802.16 networks based on the WiMAX and WiBro. [Informational RFC] This working group will take dual stack operation into account in its specifications, and reuse existing specifications whenever reasonable and possible. The ability to negotiate the used Convergence Sublayer is required, as no single mandatory CS can be specified for the clients. Work based on the Ethernet CS needs to take into account interoperability with existing hosts and other devices that employ Ethernet, to allow bridging. 16ng will not initially consider other work items than the ones listed above; however, other related work may occur in other WGs, and 16ng will participate and help such efforts. Description of Working Group: Broadband Wireless Access Networks address the inadequacies of low bandwidth wireless communication for user requirements such as high quality data/voice service, wide coverage, etc. The IEEE 802.16 Working Group on Broadband Wireless Access Standards develops standards and recommended practices to support the development and deployment of Broadband Wireless Metropolitan Area Networks. A particularity of IEEE 802.16 is that it does not include a rigid upper edge MAC service interface. Instead, it provides multiple "convergence sublayers (CS)" with the assumption that the choice and configuration of the upper edge will be done in accordance with the needs of a specific deployment environment (which might be DSL replacement, mobile access, 802.11 or CDMA backhaul etc.). Specifically, immediately subsequent to network entry, an 802.16 subscriber station has no capability whatsoever for data (as opposed to management) connectivity. Especially, in IP CS case, the criteria by which the Base Station (or other headend elements) sets up the 802.16 MAC connections for data transport are not part of the 802.16 standard, and depend on the type of data services being offered (e.g., the set up of link layer connections will be different for IPv4 and IPv6 services). Additionally - as IEEE 802.16 is a point-to-multipoint network - an 802.16 subscriber station is not capable of multicasting (e.g., for neighbor discovery, ARP, IP multicasting services, etc.) or direct communication to the other nodes attached to the same Base Station within the same subnet (prefix). Unlike 3G or xDSL technologies, IEEE 802.16 is not part of an end-to- end system definition. Currently, the WiMAX Forum, and, in particular, its NWG (Network Working Group) is defining a network architecture based on IEEE 802.16. The principal objective of the 16ng working group is to specify the operation of IPv4 and IPv6 over IEEE 802.16, taking into account the IPv4, IPv6 and Ethernet Convergence Sublayers. The working group may issue recommendations to IEEE 802.16 and WiMax aiming at improving support for IP. The scope of this working group is as follows (WG Deliverables); - Produce "16ng Problem Statement, Goal and Requirement" to identify the specific gaps in the 802.16 MAC for IPv4/IPv6 support, describe possible network models (ie. point-to-point, broadcast etc.), and provide 16ng related terminology to be used for the base guideline while defining solution frameworks. [Informational RFC] - Produce "IPv6 over IEEE 802.16 Networks in conjunction with IPv6 CS" to define IPv6 operation including the transmission of IPv6 over IEEE 802.16 link, Neighbor Discovery Protocol, Stateful (DHCPv6) and Stateless Address Configuration, Broadcast, Multicast, etc. [Proposed Standard RFC] - Produce "IPv6 over IEEE 802.16 Networks in conjunction with Ethernet CS" to define IPv6 operation including the transmission of IPv6 over IEEE 802.16 link, Neighbor Discovery Protocol, Stateful (DHCPv6) and Stateless Address Configuration, Broadcast, Multicast, etc. [Proposed Standard RFC] - Produce "IPv4 over IEEE 802.16 Networks in conjunction with IPv4 CS" to define IPv4 operation including the transmission of IPv4 over IEEE 802.16 links, ARP operation, Stateful Address Configuration (DHCPv4), Broadcast, Multicast, etc [Proposed Standard RFC] - Produce "IPv4 over IEEE 802.16 Networks in conjunction with Ethernet CS" to define IPv4 operation including the transmission of IPv4 over IEEE 802.16 links, ARP operation, Stateful Address Configuration (DHCPv4), Broadcast, Multicast, etc [Proposed Standard RFC] - Produce "IP deployment over IEEE 802.16 Networks" to illustrate the IP deployment scenarios including IP CS and Ethernet CS considerations over IEEE 802.16 networks based on the WiMAX and WiBro. [Informational RFC] This working group will take dual stack operation into account in its specifications, and reuse existing specifications whenever reasonable and possible. The ability to negotiate the used Convergence Sublayer is required, as no single mandatory CS can be specified for the clients. Work based on the Ethernet CS needs to take into account interoperability with existing hosts and other devices that employ Ethernet, to allow bridging. 16ng will not initially consider other work items than the ones listed above; however, other related work may occur in other WGs, and 16ng will participate and help such efforts. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- May 2007 Jun 2009 Transmission of IPv4 packets over IEEE 802.16's IP Convergence Sublayer IPv6 over Low power WPAN (6lowpan) ---------------------------------- Charter Last Modified: 2009-04-13 Current Status: Active Working Group Chair(s): Carsten Bormann Geoffrey Mulligan Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion:6lowpan@lists.ietf.org To Subscribe: 6lowpan-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/6lowpan/current/maillist.html Description of Working Group: Background/Introduction: Well-established fields such as control networks, and burgeoning ones such as "sensor" (or transducer) networks, are increasingly being based on wireless technologies. Most (but certainly not all) of these nodes are amongst the most constrained that have ever been networked wirelessly. Extreme low power (such that they will run potentially for years on batteries) and extreme low cost (total device cost in single digit dollars, and riding Moore's law to continuously reduce that price point) are seen as essential enablers towards their deployment in networks with the following characteristics: * Significantly more devices than current local area networks * Severely limited code and ram space (e.g., highly desirable to fit the required code--MAC, IP and anything else needed to execute the embedded application--in, for example, 32K of flash memory, using 8-bit microprocessors) * Unobtrusive but very different user interface for configuration (e.g., using gestures or interactions involving the physical world) A chief component of these devices is wireless communication technology. In particular, the IEEE 802.15.4 standard is very promising for the lower (physical and link) layers. As for higher layer functions, there is considerable interest from non-IETF groups in using IP technology. The IEEE 1451.5 standard for wireless transducers has a chapter for 6LoWPAN and the ISA SP100 standard for wireless industrial networks has adopted 6LoWPAN for their network layer. This working group is expected to coordinate and interact with such groups. Description of Working Group: ----------------------------- The Working Group has completed two RFCs: "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" (RFC4919) that documents and discusses the problem space and "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" (RFC4944) which defines the format for the adaptation between IPv6 and 802.15.4. The Working Group will generate the necessary documents to ensure interoperable implementations of 6LoWPAN networks and will define the necessary security and management protocols and constructs for building 6LoWPAN networks, paying particular attention to protocols already available. 6lowpan will work closely with the Routing Over Low power and Lossy networks (roll) working group which is developing IPv6 routing solutions for low power and lossy networks (LLNs). Work Items: ----------- 1. Produce "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations" to define limited extensions to IPv6 Neighbor Discovery [RFC4861] for use specifically in low-power networks. This document (or documents) will define how to bootstrap a 6LoWPAN network and explore ND optimizations such as reusing the structure of the 802.15.4 network (e.g., by using the coordinators), and reduce the need for multicast by having devices talk to coordinators (without creating a single point-of-failure, or changing the semantics of the IPv6 ND multicasts). This document or documents will be a proposed standard. 2. Produce "6LoWPAN Improved Header Compression" to describe mechanisms to allow enhancements to the 6LoWPAN headers. Specifically this document will describe compression of addresses that are not link-local. Additionally this document may include other enhancements or optimizations of the HC1 or HC2 6LoWPAN headers. This document will be a proposed standard. 3. Produce "6LoWPAN Architecture" to describe the design and implementation of 6LoWPAN networks. This document will cover the concepts of "Mesh Under" and "Route Over", 802.15.4 design issues such as operation with sleeping nodes, network components (both battery- and line-powered), addressing, and IPv4/IPv6 network connections. This document will be informational. 4. As a separate Internet Draft, "6LoWPAN Routing Requirements" will describe 6LoWPAN-specific requirements on routing protocols used in 6LoWPANs, addressing both the "route-over" and "mesh-under" approach. This document will be created and owned by this working group but is expected to be reviewed by the ROLL WG. This document will be informational. 5. Produce "Use Cases for 6LoWPAN" to define, for a small set of applications with sufficiently unique requirements, how 6LoWPANs can solve those requirements, and which protocols and configuration variants can be used for these scenarios. The use cases will cover protocols for transport, application layer, discovery, configuration and commissioning. This document will be informational. 6. Produce "6LoWPAN Security Analysis" to define the threat model of 6LoWPANs, to document suitability of existing key management schemes and to discuss bootstrapping/installation/commissioning/setup issues. This document will be referenced from the "security considerations" of the other 6LoWPAN documents. This document will be informational. The working group will continue to reuse existing protocols and mechanisms whenever reasonable and possible. Non-milestone work items: ------------------------- The Working Group will keep two running, often-respun documents: -- implementers guide, collecting clarifying information based on input from implementers, in particular as it becomes available from interoperability events. -- interoperability guide, providing information for interoperability events, such as temporary interoperability testing strategies or information about test harnesses used for interoperability testing. Both documents will be WG documents, but their disposition is not decided at this point (one example for such a document became RFC 4815 after five years of maintenance and 22 revisions). Description of Working Group: Background/Introduction: Well-established fields such as control networks, and burgeoning ones such as "sensor" (or transducer) networks, are increasingly being based on wireless technologies. Most (but certainly not all) of these nodes are amongst the most constrained that have ever been networked wirelessly. Extreme low power (such that they will run potentially for years on batteries) and extreme low cost (total device cost in single digit dollars, and riding Moore's law to continuously reduce that price point) are seen as essential enablers towards their deployment in networks with the following characteristics: * Significantly more devices than current local area networks * Severely limited code and ram space (e.g., highly desirable to fit the required code--MAC, IP and anything else needed to execute the embedded application--in, for example, 32K of flash memory, using 8-bit microprocessors) * Unobtrusive but very different user interface for configuration (e.g., using gestures or interactions involving the physical world) A chief component of these devices is wireless communication technology. In particular, the IEEE 802.15.4 standard is very promising for the lower (physical and link) layers. As for higher layer functions, there is considerable interest from non-IETF groups in using IP technology. The IEEE 1451.5 standard for wireless transducers has a chapter for 6LoWPAN and the ISA SP100 standard for wireless industrial networks has adopted 6LoWPAN for their network layer. This working group is expected to coordinate and interact with such groups. Description of Working Group: ----------------------------- The Working Group has completed two RFCs: "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" (RFC4919) that documents and discusses the problem space and "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" (RFC4944) which defines the format for the adaptation between IPv6 and 802.15.4. The Working Group will generate the necessary documents to ensure interoperable implementations of 6LoWPAN networks and will define the necessary security and management protocols and constructs for building 6LoWPAN networks, paying particular attention to protocols already available. 6lowpan will work closely with the Routing Over Low power and Lossy networks (roll) working group which is developing IPv6 routing solutions for low power and lossy networks (LLNs). Work Items: ----------- 1. Produce "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations" to define limited extensions to IPv6 Neighbor Discovery [RFC4861] for use specifically in low-power networks. This document (or documents) will define how to bootstrap a 6LoWPAN network and explore ND optimizations such as reusing the structure of the 802.15.4 network (e.g., by using the coordinators), and reduce the need for multicast by having devices talk to coordinators (without creating a single point-of-failure, or changing the semantics of the IPv6 ND multicasts). This document or documents will be a proposed standard. 2. Produce "6LoWPAN Improved Header Compression" to describe mechanisms to allow enhancements to the 6LoWPAN headers. Specifically this document will describe compression of addresses that are not link-local. Additionally this document may include other enhancements or optimizations of the HC1 or HC2 6LoWPAN headers. This document will be a proposed standard. 3. Produce "6LoWPAN Architecture" to describe the design and implementation of 6LoWPAN networks. This document will cover the concepts of "Mesh Under" and "Route Over", 802.15.4 design issues such as operation with sleeping nodes, network components (both battery- and line-powered), addressing, and IPv4/IPv6 network connections. This document will be informational. 4. As a separate Internet Draft, "6LoWPAN Routing Requirements" will describe 6LoWPAN-specific requirements on routing protocols used in 6LoWPANs, addressing both the "route-over" and "mesh-under" approach. This document will be created and owned by this working group but is expected to be reviewed by the ROLL WG. This document will be informational. 5. Produce "Use Cases for 6LoWPAN" to define, for a small set of applications with sufficiently unique requirements, how 6LoWPANs can solve those requirements, and which protocols and configuration variants can be used for these scenarios. The use cases will cover protocols for transport, application layer, discovery, configuration and commissioning. This document will be informational. 6. Produce "6LoWPAN Security Analysis" to define the threat model of 6LoWPANs, to document suitability of existing key management schemes and to discuss bootstrapping/installation/commissioning/setup issues. This document will be referenced from the "security considerations" of the other 6LoWPAN documents. This document will be informational. The working group will continue to reuse existing protocols and mechanisms whenever reasonable and possible. Non-milestone work items: ------------------------- The Working Group will keep two running, often-respun documents: -- implementers guide, collecting clarifying information based on input from implementers, in particular as it becomes available from interoperability events. -- interoperability guide, providing information for interoperability events, such as temporary interoperability testing strategies or information about test harnesses used for interoperability testing. Both documents will be WG documents, but their disposition is not decided at this point (one example for such a document became RFC 4815 after five years of maintenance and 22 revisions). Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2008 Oct 2009 Compression Format for IPv6 Datagrams in 6LoWPAN Networks Oct 2008 Nov 2009 Design and Application Spaces for 6LoWPANs Nov 2008 Oct 2009 6LoWPAN Neighbor Discovery Nov 2008 Jul 2009 Problem Statement and Requirements for 6LoWPAN Routing IPv6 Maintenance (6man) ----------------------- Charter Last Modified: 2008-12-16 Current Status: Active Working Group Chair(s): Robert Hinden Brian Haberman Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:ipv6@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipv6 Archive: http://www.ietf.org/mail-archive/web/ipv6 Description of Working Group: The 6man working group is responsible for the maintenance, upkeep, and advancement of the IPv6 protocol specifications and addressing architecture. It is not chartered to develop major changes or additions to the IPv6 specifications. The working group will address protocol limitations/issues discovered during deployment and operation. It will also serve as a venue for discussing the proper location for working on IPv6-related issues within the IETF. The working group's work items are as follows: o Complete work on RA Flags Option o Complete work on RH0 Deprecation o Complete work on IPv6 over PPP Compression Negotiation o Complete work on Centrally Allocated Unique Local Addresses (ULA-C) All new work items not listed above require the approval of the working group and the sponsoring Area Director before they will be taken on by the working group. Description of Working Group: The 6man working group is responsible for the maintenance, upkeep, and advancement of the IPv6 protocol specifications and addressing architecture. It is not chartered to develop major changes or additions to the IPv6 specifications. The working group will address protocol limitations/issues discovered during deployment and operation. It will also serve as a venue for discussing the proper location for working on IPv6-related issues within the IETF. The working group's work items are as follows: o Complete work on RA Flags Option o Complete work on RH0 Deprecation o Complete work on IPv6 over PPP Compression Negotiation o Complete work on Centrally Allocated Unique Local Addresses (ULA-C) All new work items not listed above require the approval of the working group and the sponsoring Area Director before they will be taken on by the working group. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jan 2008 Jul 2009 Solution approaches for address-selection problems Feb 2008 Jul 2009 IPv6 Node Requirements RFC 4294-bis May 2008 Nov 2009 IPv6 Subnet Model: the Relationship between Links and Subnet Prefixes Sep 2008 Jul 2009 Handling of overlapping IPv6 fragments Aug 2009 Nov 2009 A Recommendation for IPv6 Address Text Representation Oct 2009 Oct 2009 IANA Allocation Guidelines for the IPv6 Routing Header Oct 2009 Oct 2009 Considerations for IPv6 Address Selection Policy Changes ADSL MIB (adslmib) ------------------ Charter Last Modified: 2009-08-24 Current Status: Active Working Group Chair(s): Michael Sneed Menachem Dodge Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Technical Advisor(s): Randy Presuhn Editor(s): Faye Ly Greg Bathrick Bob Ray Rajesh Abbi Scott Baillie Menachem Dodge Clay Sikes Moti Morgenstern Umberto Bonollo Mailing Lists: General Discussion:adslmib@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/adslmib Archive: http://www.ietf.org/mail-archive/web/adslmib/current/maillist.html Description of Working Group: The working group will define: 1. A set of managed objects to be used for management of newer versions of Digital Subscriber Line (xDSL) as defined in ITU-T Recommendation G.997.1 (02/2006). 2. A set of managed objects to handle the bonding of xDSL lines according to the ITU-T Recommendations G.998.1 (ATM), G.998.2 (Ethernet) and G.998.3 (TDIM). A common MIB module will be developed to handle the common objects and three specific MIB modules will be developed to handle the three separate layer-2 technologies. Use will be made of the ifStack and ifInvStack Tables defined in RFC 2863 and RFC 2864 respectively. Use will also be made of the ifAvailableStack and ifInvAvailableStack tables as defined by the Hubmib WG. The MIB modules defined by this group will be generated using SMIv2, will be consistent with the SNMP management framework, and will describe the relationship of the objects defined to existing MIBs such as those described in other work products of this Working Group, the interfaces MIB, the Ethernet MIB modules and the AToM MIB. The working group will consider the input of the DSL forum and the ITU in the definition of these MIBs. Description of Working Group: The working group will define: 1. A set of managed objects to be used for management of newer versions of Digital Subscriber Line (xDSL) as defined in ITU-T Recommendation G.997.1 (02/2006). 2. A set of managed objects to handle the bonding of xDSL lines according to the ITU-T Recommendations G.998.1 (ATM), G.998.2 (Ethernet) and G.998.3 (TDIM). A common MIB module will be developed to handle the common objects and three specific MIB modules will be developed to handle the three separate layer-2 technologies. Use will be made of the ifStack and ifInvStack Tables defined in RFC 2863 and RFC 2864 respectively. Use will also be made of the ifAvailableStack and ifInvAvailableStack tables as defined by the Hubmib WG. The MIB modules defined by this group will be generated using SMIv2, will be consistent with the SNMP management framework, and will describe the relationship of the objects defined to existing MIBs such as those described in other work products of this Working Group, the interfaces MIB, the Ethernet MIB modules and the AToM MIB. The working group will consider the input of the DSL forum and the ITU in the definition of these MIBs. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- May 2007 Aug 2009 xDSL multi-pair bonding using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB Application-Layer Traffic Optimization (alto) --------------------------------------------- Charter Last Modified: 2009-11-19 Current Status: Active Working Group Chair(s): Jon Peterson Enrico Marocco Vijay Gurbani Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion:alto@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/alto Archive: http://www.ietf.org/mail-archive/web/alto/current/maillist.html Description of Working Group: A significant part of the Internet traffic today is generated by peer-to-peer (P2P) applications used for file sharing, real-time communications, and live media streaming. P2P applications exchange large amounts of data, often uploading as much as downloading. In contrast to client/server architectures, P2P applications often must choose one or more suitable candidates from a selection of peers offering the same resource or service. One of the advantages of P2P systems comes from redundancy in resource availability. This requires choosing among a list of peers, yet applications have at best incomplete information to help the selection, e.g., topology of the network. Applications can sometimes obtain network information dynamically or measure link performance with respect to particular peers, but even when this is an option it takes time. The application cannot always start out with an optimal arrangement of peers, thus risking at least temporary poor performance and excessive cross-domain traffic. Providing more information for use in peer selection can improve P2P performance and lower ISP costs. The Working Group will design and specify an Application-Layer Traffic Optimization (ALTO) service that will provide applications with information to perform better-than-random initial peer selection. ALTO services may take different approaches at balancing factors such as maximum bandwidth, minimum cross-domain traffic, lowest cost to the user, etc. The WG will consider the needs of BitTorrent, tracker-less P2P, and other applications, such as content delivery networks (CDN) and mirror selection. The WG will focus on the following items: - A "problem statement" document providing a description of the problem and a common terminology. - A requirements document. This document will list requirements for the ALTO service, identifying, for example, types of information P2P applications may need for optimizing their choices. - A request/response protocol for querying the ALTO service to obtain information useful for peer selection, and a format for requests and responses If the requirements analysis identifies the need to allow clients to delegate third-parties to query the ALTO service on their behalf, the WG will ensure that the protocol provides a mechanism to assert the consent of the delegating client. - A document defining core request and response formats and semantics to communicate network preferences to applications. Since ALTO services may be run by entities with different level of knowledge about the underlying network, such preferences may have different representations. Initially the WG will consider: IP ranges to prefer and to avoid, ranked lists of the peers requested by the client, information about topological proximity and approximate geographic locations. Other usages will be considered as charter additions once the work for the initial services has been completed. - In order to query the ALTO server, clients must first know one or more ALTO servers that might provide useful information. The WG will look at service discovery mechanisms that are in use, or defined elsewhere (e.g. based on DNS SRV records or DHCP options). If such discovery mechanisms can be reused, the WG will produce a document to specify how they may be adopted for locating such servers. However, a new, general-purpose service discovery mechanism is not in scope. When the WG considers standardizing information that the ALTO server could provide, the following criteria are important to ensure real feasibility. - Can the ALTO service realistically discover that information? - Is the distribution of that information allowed by the operators of that service? - Is it information that a client will find useful? - Can a client get that information without excessive privacy concerns (e.g. by sending large lists of peers)? - Is it information that a client cannot find easily some other way? After these criteria are met, the importance of the data will be considered for prioritizing standardization work, for example the number of operators and clients that are likely to be able to provide or use that particular data. In any case, this WG will not propose standards on how congestion is signaled, remediated, or avoided, and will not deal with information representing instantaneous network state. Such issues belong to other IETF areas and will be treated accordingly by the specific area. This WG will focus solely on the communication protocol between applications and ALTO servers. Note that ALTO services may be useful in client-server environments as well as P2P environments, although P2P environments are the first focus. If, in the future, the IETF considers changes to other protocols for actually implementing ALTO services (e.g. application-layer protocols for Internet coordinate systems, routing protocol extensions for ISP-based solutions), such work will be done in strict coordination with the appropriate WGs. Issues related to the content exchanged in P2P systems are also excluded from the WG's scope, as is the issue dealing with enforcing the legality of the content. Description of Working Group: A significant part of the Internet traffic today is generated by peer-to-peer (P2P) applications used for file sharing, real-time communications, and live media streaming. P2P applications exchange large amounts of data, often uploading as much as downloading. In contrast to client/server architectures, P2P applications often must choose one or more suitable candidates from a selection of peers offering the same resource or service. One of the advantages of P2P systems comes from redundancy in resource availability. This requires choosing among a list of peers, yet applications have at best incomplete information to help the selection, e.g., topology of the network. Applications can sometimes obtain network information dynamically or measure link performance with respect to particular peers, but even when this is an option it takes time. The application cannot always start out with an optimal arrangement of peers, thus risking at least temporary poor performance and excessive cross-domain traffic. Providing more information for use in peer selection can improve P2P performance and lower ISP costs. The Working Group will design and specify an Application-Layer Traffic Optimization (ALTO) service that will provide applications with information to perform better-than-random initial peer selection. ALTO services may take different approaches at balancing factors such as maximum bandwidth, minimum cross-domain traffic, lowest cost to the user, etc. The WG will consider the needs of BitTorrent, tracker-less P2P, and other applications, such as content delivery networks (CDN) and mirror selection. The WG will focus on the following items: - A "problem statement" document providing a description of the problem and a common terminology. - A requirements document. This document will list requirements for the ALTO service, identifying, for example, types of information P2P applications may need for optimizing their choices. - A request/response protocol for querying the ALTO service to obtain information useful for peer selection, and a format for requests and responses If the requirements analysis identifies the need to allow clients to delegate third-parties to query the ALTO service on their behalf, the WG will ensure that the protocol provides a mechanism to assert the consent of the delegating client. - A document defining core request and response formats and semantics to communicate network preferences to applications. Since ALTO services may be run by entities with different level of knowledge about the underlying network, such preferences may have different representations. Initially the WG will consider: IP ranges to prefer and to avoid, ranked lists of the peers requested by the client, information about topological proximity and approximate geographic locations. Other usages will be considered as charter additions once the work for the initial services has been completed. - In order to query the ALTO server, clients must first know one or more ALTO servers that might provide useful information. The WG will look at service discovery mechanisms that are in use, or defined elsewhere (e.g. based on DNS SRV records or DHCP options). If such discovery mechanisms can be reused, the WG will produce a document to specify how they may be adopted for locating such servers. However, a new, general-purpose service discovery mechanism is not in scope. When the WG considers standardizing information that the ALTO server could provide, the following criteria are important to ensure real feasibility. - Can the ALTO service realistically discover that information? - Is the distribution of that information allowed by the operators of that service? - Is it information that a client will find useful? - Can a client get that information without excessive privacy concerns (e.g. by sending large lists of peers)? - Is it information that a client cannot find easily some other way? After these criteria are met, the importance of the data will be considered for prioritizing standardization work, for example the number of operators and clients that are likely to be able to provide or use that particular data. In any case, this WG will not propose standards on how congestion is signaled, remediated, or avoided, and will not deal with information representing instantaneous network state. Such issues belong to other IETF areas and will be treated accordingly by the specific area. This WG will focus solely on the communication protocol between applications and ALTO servers. Note that ALTO services may be useful in client-server environments as well as P2P environments, although P2P environments are the first focus. If, in the future, the IETF considers changes to other protocols for actually implementing ALTO services (e.g. application-layer protocols for Internet coordinate systems, routing protocol extensions for ISP-based solutions), such work will be done in strict coordination with the appropriate WGs. Issues related to the content exchanged in P2P systems are also excluded from the WG's scope, as is the issue dealing with enforcing the legality of the content. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Apr 2009 Oct 2009 Application-Layer Traffic Optimization (ALTO) Requirements Access Node Control Protocol (ancp) ----------------------------------- Charter Last Modified: 2009-10-13 Current Status: Active Working Group Chair(s): Wojciech Dec Matthew Bocci Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Technical Advisor(s): Dan Romascanu Mailing Lists: General Discussion:ancp@ietf.org To Subscribe: ancp-request@ietf.org In Body: In Body: subscribe your_email_address Archive: http://www.ietf.org/mail-archive/web/ancp/current/maillist.html Description of Working Group: Purpose: The purpose of the ANCP WG is to standardize an IP-based Access Node Control Protocol (ANCP) for use in service provider Digital Subscriber Line (DSL) and Passive Optical Network (PON) access and aggregation networks. ANCP operates between an Access Node (AN) and Network Access Server (NAS). Necessary Terminology: Access Node (AN) - Network device, usually located at a service provider central office or street cabinet, that terminates access loop connections from Subscribers. In DSL, this is often referred to as a Digital Subscriber Line Access Multiplexer (DSLAM). In PON, this is usually comprised of an Optical Network Termination (ONT) / Optical Network Unit (ONU) and an Optical Line Termination (OLT). Network Access Server (NAS) - Network device which aggregates multiplexed Subscriber traffic from a number of Access Nodes. The NAS plays a central role in per-subscriber policy enforcement and QoS. This is often referred to as a Broadband Network Gateway (BNG) or Broadband Remote Access Server (BRAS). A detailed definition of the NAS is given in RFC2881. Goals: ANCP is intended to address the requirement for a bidirectional, IP- based, control protocol that operates across multiple types (i.e., Ethernet, ATM) of DSL and PON access and aggregation networks. The goal of an ANCP message exchange is to convey status and control information between one or more ANs and one or more NASs without going through intermediate element managers. The ANCP WG will address the following four use-cases: 1. Dynamic Access Loop Attributes Various queuing and scheduling mechanisms are used in access networks to avoid congestion while dealing with multiple flows and distinct QoS profiles. Communicating the access-loop status, attributes and current DSL synchronization rate between the AN and Subscriber up to the NAS is desirable, particularly when the NAS is providing QoS for individual flows and subscribers. ANCP will provide a mechanism to communicate dynamic access-loop attributes from the AN to the NAS. 2. Access Loop Configuration In additional to reporting Access Loop characteristics from the AN to the NAS, ANCP will allow a NAS to send loop-specific configuration information to an AN based on the results of subscriber authentication and authorization (e.g., after AAA responses have been received at the NAS). 3. Remote Connectivity Test Traditional DSL access and aggregation networks employ point-to-point ATM circuits between the AN and NAS for each subscriber, allowing troubleshooting of the local loop from the NAS via ATM OAM tools. With the increasing deployment of Ethernet in the access and aggregation network, operators require consistent methods to test and troubleshoot connectivity for mixed Ethernet and ATM access networks (including the local loop). ANCP will allow a remote procedure for a local loop connectivity test to be triggered from the NAS with results communicated back to the NAS. 4. Multicast When multicast replication for subscriber-bound traffic is performed at the AN, it offloads the network between the AN and NAS. However, a subscriber's policy and configuration for multicast traffic may only be known at the NAS. ANCP will provide a mechanism to communicate the necessary information exchange between the AN and NAS so as to allow the AN to perform subscriber bound multicast group replication in line with the subscriber's policy and configuration, and also allow the NAS to follow each subscriber's multicast group membership. Non-Goals: ANCP is an IP-based protocol that operates between the AN and NAS. It will not address setup or configuration of circuits or connections in the access and aggregation network itself. The focus of this WG is on one very specific application space. While the design of the protocol must be general as to not preclude other uses in the future should a need arise, it is not a goal of this WG to address specific requirements outside of service provider broadband (such as xDSL, xPON) access and aggregation networks. Security: The ANCP working group will provide a threat analysis and address the associated security aspects of the control protocol. Resiliency and Scalability: A graceful restart mechanism will be defined to enable the protocol to be resilient to network failures between the AN and NAS. Scalability at the NAS is of primary concern, as it may be aggregating traffic from a large number of ANs, which in turn may be serving a large number of Subscribers. ANCP traffic should not become a denial of service attack on the NAS control plane. Format of messages, pacing, transport over UDP or TCP, etc. will be considered with this in mind. For reasons of aggregation network scalability, some use cases require that aspects of NAS or AN functionality may be distributed in nodes in the aggregation network. In these cases, ANCP can run between these nodes. Deliverables: The working group will define a basic framework and requirements document intended for Informational publication, focusing on the four use-cases outlined in this charter. This document will include a security threat analysis and associated requirements. The WG will then investigate and define a solution for an IP based control protocol meeting these requirements. There are early interoperable implementations of an ANCP-like protocol which are based on an extended subset of the GSMPv3 protocol. This running code will be the the starting point for the working group solution, and will be abandoned only if the WG determines it is not adequate to meet requirements going forward. Coordination with other Working Groups or Organizations: The working group will coordinate with the ADSL MIB working group so the management framework and MIB modules are consistent for DSL access environments. The working group will re-use, as far as possible, standard MIB modules that have already been defined. The remote connectivity test use case may require coordination with ITU-T Ethernet OAM and PON work and with IEEE 802.1ag. Description of Working Group: Purpose: The purpose of the ANCP WG is to standardize an IP-based Access Node Control Protocol (ANCP) for use in service provider Digital Subscriber Line (DSL) and Passive Optical Network (PON) access and aggregation networks. ANCP operates between an Access Node (AN) and Network Access Server (NAS). Necessary Terminology: Access Node (AN) - Network device, usually located at a service provider central office or street cabinet, that terminates access loop connections from Subscribers. In DSL, this is often referred to as a Digital Subscriber Line Access Multiplexer (DSLAM). In PON, this is usually comprised of an Optical Network Termination (ONT) / Optical Network Unit (ONU) and an Optical Line Termination (OLT). Network Access Server (NAS) - Network device which aggregates multiplexed Subscriber traffic from a number of Access Nodes. The NAS plays a central role in per-subscriber policy enforcement and QoS. This is often referred to as a Broadband Network Gateway (BNG) or Broadband Remote Access Server (BRAS). A detailed definition of the NAS is given in RFC2881. Goals: ANCP is intended to address the requirement for a bidirectional, IP- based, control protocol that operates across multiple types (i.e., Ethernet, ATM) of DSL and PON access and aggregation networks. The goal of an ANCP message exchange is to convey status and control information between one or more ANs and one or more NASs without going through intermediate element managers. The ANCP WG will address the following four use-cases: 1. Dynamic Access Loop Attributes Various queuing and scheduling mechanisms are used in access networks to avoid congestion while dealing with multiple flows and distinct QoS profiles. Communicating the access-loop status, attributes and current DSL synchronization rate between the AN and Subscriber up to the NAS is desirable, particularly when the NAS is providing QoS for individual flows and subscribers. ANCP will provide a mechanism to communicate dynamic access-loop attributes from the AN to the NAS. 2. Access Loop Configuration In additional to reporting Access Loop characteristics from the AN to the NAS, ANCP will allow a NAS to send loop-specific configuration information to an AN based on the results of subscriber authentication and authorization (e.g., after AAA responses have been received at the NAS). 3. Remote Connectivity Test Traditional DSL access and aggregation networks employ point-to-point ATM circuits between the AN and NAS for each subscriber, allowing troubleshooting of the local loop from the NAS via ATM OAM tools. With the increasing deployment of Ethernet in the access and aggregation network, operators require consistent methods to test and troubleshoot connectivity for mixed Ethernet and ATM access networks (including the local loop). ANCP will allow a remote procedure for a local loop connectivity test to be triggered from the NAS with results communicated back to the NAS. 4. Multicast When multicast replication for subscriber-bound traffic is performed at the AN, it offloads the network between the AN and NAS. However, a subscriber's policy and configuration for multicast traffic may only be known at the NAS. ANCP will provide a mechanism to communicate the necessary information exchange between the AN and NAS so as to allow the AN to perform subscriber bound multicast group replication in line with the subscriber's policy and configuration, and also allow the NAS to follow each subscriber's multicast group membership. Non-Goals: ANCP is an IP-based protocol that operates between the AN and NAS. It will not address setup or configuration of circuits or connections in the access and aggregation network itself. The focus of this WG is on one very specific application space. While the design of the protocol must be general as to not preclude other uses in the future should a need arise, it is not a goal of this WG to address specific requirements outside of service provider broadband (such as xDSL, xPON) access and aggregation networks. Security: The ANCP working group will provide a threat analysis and address the associated security aspects of the control protocol. Resiliency and Scalability: A graceful restart mechanism will be defined to enable the protocol to be resilient to network failures between the AN and NAS. Scalability at the NAS is of primary concern, as it may be aggregating traffic from a large number of ANs, which in turn may be serving a large number of Subscribers. ANCP traffic should not become a denial of service attack on the NAS control plane. Format of messages, pacing, transport over UDP or TCP, etc. will be considered with this in mind. For reasons of aggregation network scalability, some use cases require that aspects of NAS or AN functionality may be distributed in nodes in the aggregation network. In these cases, ANCP can run between these nodes. Deliverables: The working group will define a basic framework and requirements document intended for Informational publication, focusing on the four use-cases outlined in this charter. This document will include a security threat analysis and associated requirements. The WG will then investigate and define a solution for an IP based control protocol meeting these requirements. There are early interoperable implementations of an ANCP-like protocol which are based on an extended subset of the GSMPv3 protocol. This running code will be the the starting point for the working group solution, and will be abandoned only if the WG determines it is not adequate to meet requirements going forward. Coordination with other Working Groups or Organizations: The working group will coordinate with the ADSL MIB working group so the management framework and MIB modules are consistent for DSL access environments. The working group will re-use, as far as possible, standard MIB modules that have already been defined. The remote connectivity test use case may require coordination with ITU-T Ethernet OAM and PON work and with IEEE 802.1ag. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2006 Oct 2009 Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks Jan 2007 Jul 2009 Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) Mar 2007 Nov 2009 Protocol for Access Node Control Mechanism in Broadband Networks Jun 2007 Jul 2009 Access Node Control Protocol (ANCP) MIB module for Access Nodes Jul 2009 Oct 2009 Additional Multicast Control Extensions for ANCP Ad-Hoc Network Autoconfiguration (autoconf) ------------------------------------------- Charter Last Modified: 2009-04-02 Current Status: Active Working Group Chair(s): Ryuji Wakikawa Thomas Clausen Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:autoconf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf Archive: http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html Description of Working Group: In order to communicate among themselves, ad hoc nodes (refer to RFC 2501) need to configure their network interface(s) with local addresses that are valid within an ad hoc network. Ad hoc nodes may also need to configure globally routable addresses, in order to communicate with devices on the Internet. From the IP layer perspective, an ad hoc network presents itself as a L3 multi-hop network formed over a collection of links. The main purpose of the AUTOCONF WG is to describe the addressing model for ad hoc networks and how nodes in these networks configure their addresses. It is required that such models do not cause problems for ad hoc-unaware parts of the system, such as standard applications running on an ad hoc node or regular Internet nodes attached to the ad hoc nodes. This group's effort may include the development of new protocol mechanisms, should the existing IP autoconfiguration mechanisms be found inadequate. However, the first task of the working group is to describe one practical addressing model for ad hoc networks. Once this sole work item is completed, the group can be rechartered to work on additional issues. Description of Working Group: In order to communicate among themselves, ad hoc nodes (refer to RFC 2501) need to configure their network interface(s) with local addresses that are valid within an ad hoc network. Ad hoc nodes may also need to configure globally routable addresses, in order to communicate with devices on the Internet. From the IP layer perspective, an ad hoc network presents itself as a L3 multi-hop network formed over a collection of links. The main purpose of the AUTOCONF WG is to describe the addressing model for ad hoc networks and how nodes in these networks configure their addresses. It is required that such models do not cause problems for ad hoc-unaware parts of the system, such as standard applications running on an ad hoc node or regular Internet nodes attached to the ad hoc nodes. This group's effort may include the development of new protocol mechanisms, should the existing IP autoconfiguration mechanisms be found inadequate. However, the first task of the working group is to describe one practical addressing model for ad hoc networks. Once this sole work item is completed, the group can be rechartered to work on additional issues. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2009 Oct 2009 IP Addressing Model in Ad Hoc Networks Audio/Video Transport (avt) --------------------------- Charter Last Modified: 2009-05-01 Current Status: Active Working Group Chair(s): Roni Even Tom Taylor Real-time Applications and Infrastructure Area Director(s): Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Cullen Jennings Mailing Lists: General Discussion:avt@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/avt Archive: http://www.ietf.org/mail-archive/web/avt/index.html Description of Working Group: The Audio/Video Transport Working Group was formed to specify a protocol for real-time transmission of audio and video over unicast and multicast UDP/IP. This is the Real-time Transport Protocol, RTP, together with its associated profiles and payload formats. The current aims of the working group are: - to review and revise existing payload formats to advance those which are useful to Draft Standard, and to declare others as Historic. Milestones will be established as a champion for each payload format is identified. - to develop payload formats for new media codecs, and to document best-current practices in payload format design. The group continues to be precluded from work on codecs themselves because of overlap with the other standards bodies, and because the IETF does not have the ability to effectively review new codecs. An exception was made for the freeware iLBC codec on a highly experimental basis, but acceptance of new codec work is unexpected and subject to rechartering. - to complete the forward error correction work to update RFC 2733 in the form of the ULP payload format - to extend RTP to work with Source-Specific Multicast sessions with unicast feedback - to provide a framing mechanism for RTP over TCP and TLS - in collaboration with the MPLS and ROHC WGs, to develop a solution for header compression of RTP across MPLS networks that avoid decompression and compression at each MPLS node. - to develop a new RTP profile for the combination of the SRTP profile and the Extended RTP Profile for RTCP-based Feedback (RTP/SAVPF) - to maintain and enhance the SRTP Profile, with review and input from the Security Area - to develop a new RTP profile for usage of TFRC (RFC 3448) with RTP over UDP to allow application developers to gain experience with TCP friendly congestion control. - to develop a MIB for RTCP XR (RFC 3611). - to update the RTP MIB, including aligning it with RFC 3550. - to clarify how RTP is used for media in conferencing with centralised nodes performing relay, translation or mixing of media. - to develop the mechanisms needed for efficient control of media and its encoding process in RTP based conferencing, both over multicast and transport containing relays, translators and mixers. An example of such a mechanism is a method to request a full intra coded frame of video. This would be used to allow joining participants to receive video immediately after joining instead of waiting for the next intra coded frame. It also allows mixers to perform switching between media sources without the need to re-encode the media. - to develop a solution for carrying media meta data, specifically SMPTE timestamps, to enhance the media stream. Such transport may be done in either RTP or RTCP depending on which is most suitable. The WG may consider if a generalized mechanism should be developed to enable future types of meta data to be easier to include. - to develop two new metric blocks for the RTCP XR (RFC 3611) framework to provide information on the media quality experienced by the receiver of RTP flows. One metrics block is for high resolution measurements of audio and speech quality. A second one for providing information on the quality of video. The timescale to complete this second block and the included metrics are highly dependable on the development of standardized subjective metrics for video quality. The WG will consider what metrics that are available and if they should be included or not. The metrics blocks shall not duplicate signalling information anyway necessary for the establishment of the session. - to specify how the RFC 3550 requirement on RTCP senders to always send compound packets can be relaxed to allow for non-compound packets. The specification need to define under which criteria non-compound RTCP packets may be sent while maintaining the functionality that motivated the usage of compound RTCP packets and keep the bandwidth within specified limits. The longer term goals of the working group are to advance the SRTP Profile, the Extended RTP Profile for RTCP-based Feedback, the Compressed RTP framework, and the RTP MIB to Draft Standard. The group has no plans to develop new RTP profiles beyond those listed above, but will consider rechartering to produce profile level extensions if appropriate. Description of Working Group: The Audio/Video Transport Working Group was formed to specify a protocol for real-time transmission of audio and video over unicast and multicast UDP/IP. This is the Real-time Transport Protocol, RTP, together with its associated profiles and payload formats. The current aims of the working group are: - to review and revise existing payload formats to advance those which are useful to Draft Standard, and to declare others as Historic. Milestones will be established as a champion for each payload format is identified. - to develop payload formats for new media codecs, and to document best-current practices in payload format design. The group continues to be precluded from work on codecs themselves because of overlap with the other standards bodies, and because the IETF does not have the ability to effectively review new codecs. An exception was made for the freeware iLBC codec on a highly experimental basis, but acceptance of new codec work is unexpected and subject to rechartering. - to complete the forward error correction work to update RFC 2733 in the form of the ULP payload format - to extend RTP to work with Source-Specific Multicast sessions with unicast feedback - to provide a framing mechanism for RTP over TCP and TLS - in collaboration with the MPLS and ROHC WGs, to develop a solution for header compression of RTP across MPLS networks that avoid decompression and compression at each MPLS node. - to develop a new RTP profile for the combination of the SRTP profile and the Extended RTP Profile for RTCP-based Feedback (RTP/SAVPF) - to maintain and enhance the SRTP Profile, with review and input from the Security Area - to develop a new RTP profile for usage of TFRC (RFC 3448) with RTP over UDP to allow application developers to gain experience with TCP friendly congestion control. - to develop a MIB for RTCP XR (RFC 3611). - to update the RTP MIB, including aligning it with RFC 3550. - to clarify how RTP is used for media in conferencing with centralised nodes performing relay, translation or mixing of media. - to develop the mechanisms needed for efficient control of media and its encoding process in RTP based conferencing, both over multicast and transport containing relays, translators and mixers. An example of such a mechanism is a method to request a full intra coded frame of video. This would be used to allow joining participants to receive video immediately after joining instead of waiting for the next intra coded frame. It also allows mixers to perform switching between media sources without the need to re-encode the media. - to develop a solution for carrying media meta data, specifically SMPTE timestamps, to enhance the media stream. Such transport may be done in either RTP or RTCP depending on which is most suitable. The WG may consider if a generalized mechanism should be developed to enable future types of meta data to be easier to include. - to develop two new metric blocks for the RTCP XR (RFC 3611) framework to provide information on the media quality experienced by the receiver of RTP flows. One metrics block is for high resolution measurements of audio and speech quality. A second one for providing information on the quality of video. The timescale to complete this second block and the included metrics are highly dependable on the development of standardized subjective metrics for video quality. The WG will consider what metrics that are available and if they should be included or not. The metrics blocks shall not duplicate signalling information anyway necessary for the establishment of the session. - to specify how the RFC 3550 requirement on RTCP senders to always send compound packets can be relaxed to allow for non-compound packets. The specification need to define under which criteria non-compound RTCP packets may be sent while maintaining the functionality that motivated the usage of compound RTCP packets and keep the bandwidth within specified limits. The longer term goals of the working group are to advance the SRTP Profile, the Extended RTP Profile for RTCP-based Feedback, the Compressed RTP framework, and the RTP MIB to Draft Standard. The group has no plans to develop new RTP profiles beyond those listed above, but will consider rechartering to produce profile level extensions if appropriate. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2002 Nov 2009 RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback Aug 2006 Oct 2009 The use of AES-192 and AES-256 in Secure RTP Oct 2006 Aug 2007 Multiplexing RTP Data and Control Packets on a Single Port Dec 2006 Oct 2009 RTP Payload Format for SVC Video Jan 2007 Aug 2009 RTP Payload Format for MIDI Jun 2007 Jun 2009 Application Mechanism for maintaining alive the Network Address Translator (NAT) mappings associated to RTP flows. Jul 2007 Feb 2009 Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP) Oct 2007 Jun 2009 The SEED Cipher Algorithm and Its Use with the Secure Real-time Transport Protocol (SRTP) Dec 2007 Oct 2009 RTP Payload Format for H.264 RCDO Video Apr 2008 Oct 2009 RTP Payload Format for IP-MR Speech Codec draft-ietf-avt-rtp-ipmr-10.txt Jul 2008 Nov 2009 Post-Repair Loss RLE Report Block Type for RTCP XR Jul 2008 Jul 2009 Why RTP Does Not Mandate a Single Security Mechanism Oct 2008 Sep 2009 RTP Payload Format for H.264 Video Oct 2008 Oct 2009 RTP payload format for G.718 speech/audio Apr 2009 Nov 2009 Rapid Synchronisation of RTP Flows Apr 2009 Sep 2009 RTP Payload format for GSM-HR May 2009 Nov 2009 Unicast-Based Rapid Acquisition of Multicast RTP Sessions Jul 2009 Jul 2009 AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- Charter Last Modified: 2009-10-13 Current Status: Active Working Group Chair(s): Dan Wing Dave Thaler Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Magnus Westerlund Mailing Lists: General Discussion:behave@ietf.org To Subscribe: behave-request@ietf.org In Body: In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/behave Description of Working Group: The behavior of NATs varies from one implementation to another. As a result it is very difficult for applications to predict or discover the behavior of these devices. Predicting and/or discovering the behavior of NATs is important for designing application protocols and NAT traversal techniques that work reliably in existing networks. This situation is especially problematic for end-to-end applications where one or both end-points are behind a NAT, such as multiuser games, interactive multimedia and P2P download. The working group documents best current practices to enable NATs to function in as deterministic a fashion as possible. The NAT behavior practices will be application independent. This has already completed for UDP, TCP, DCCP, Multicast and ICMP. It continues with SCTP and any additional protocol deemed necessary to handle. The WG has documented approaches for characterizing and testing NAT devices. BEHAVE will develop protocol-independent toolkits usable by application protocols for NAT traversal. The WG has already produced an update of the binding discovery protocol STUN. It will now produce a relay protocol that focuses on security and is usable with both IPv4 and IPv6, and capable of relaying between the two IP versions. Due to the WG's experience with translators and their behavior it has been given the following tasks to help encourage migration to IPv6. To support deployments where communicating hosts require using different address families (IPv4 or IPv6), address family translation is needed to establish communication. In BEHAVE's specification work on this topic it will coordinate with the V6ops WG on requirements and operational considerations. "An IPv4 network" or "an IPv6 network" in the descriptions below refer to a network with a clearly identifiable administrative domain (e.g., an enterprise campus network, a mobile operator's cellular network, a residential subscriber network, etc.). It will also be that network that deploys the necessary equipment for translation. The BEHAVE WG will design solutions for the following six translation scenarios; other scenarios are out of scope: 1. An IPv6 network to IPv4 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translator function is intended to service a specific IPv6 network of arbitary size. Port translation is necessary on the IPv4 side for efficient IPv4 address usage. 2. IPv6 Internet to an IPv4 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translator function is intended to service a specific IPv4 network using either private or public IPv4 addresses. This scenario has different constraints compared to (1), e.g. the IPv4 hosts that are to be reachable over IPv6 can be enumerated. Therefore, the WG should attempt to design a simpler solution with less impact on applications. 3. An IPv4 network to IPv6 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv4 network using either public or private IPv4 address space. 4. IPv4 Internet to an IPv6 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv6 network where selected IPv6 hosts and services are to be reachable. 5. An IPv6 network to an IPv4 network, i.e., perform translation between IPv6 and IPv4 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translation function is intended to service a specific IPv6 network of arbitrary size and a specific IPv4 network of arbitrary size (neither of which are the Internet). 6. An IPv4 network to an IPv6 network, i.e., perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translation function is intended to service a specific IPv6 network of arbitrary size and a specific IPv4 network of arbitrary size (neither of which are the Internet). All translation solutions shall be capable of handling flows using TCP, UDP, DCCP, and SCTP, unless they prevent a timely completion of the work item. The parts of ICMP that can be translated are also required to work across a translation solution. Additional protocols directly on top of IP may be supported. Translation mechanisms must handle IP fragmentation. The translators should support multicast traffic and its control traffic (IGMP and MLD) across them, both Single Source Multicast (SSM) and Any Source Multicast (ASM). However, the WG may determine that it becomes too complex or too difficult to realize with maintained functionality, for some or all cases of multicast functionality. Translation mechanisms cannot transparently support protocols that embed network addresses within their protocol messages without application level gateways (ALGs). Because ALGs have security issues (like blocking usage of TLS), are error prone and brittle, and hinder application development, the usage of ALGs in the defined translators should be avoided. Instead application developers will need to be aware and use mechanisms that handle the address family translation. ALGs may be considered only for the most crucial of legacy applications. DNS is a crucial part in making a large number of applications work across a translator. Thus the solution to the above translation cases shall include recommendations for DNS. If additional DNS functionality is needed, it may be developed. Any DNS extensions must be developed together with the DNSEXT WG, including issuing a joint WG last call for any documents. The WG needs to determine the best method for providing address space to a translator in the different deployment cases and documenting the pros and cons of the suggested approaches. The WG is to seek input from the Routing, Operations and Internet areas. Solutions may solve more than one of the cases, however timely delivery is more important than a unified solution. Description of Working Group: The behavior of NATs varies from one implementation to another. As a result it is very difficult for applications to predict or discover the behavior of these devices. Predicting and/or discovering the behavior of NATs is important for designing application protocols and NAT traversal techniques that work reliably in existing networks. This situation is especially problematic for end-to-end applications where one or both end-points are behind a NAT, such as multiuser games, interactive multimedia and P2P download. The working group documents best current practices to enable NATs to function in as deterministic a fashion as possible. The NAT behavior practices will be application independent. This has already completed for UDP, TCP, DCCP, Multicast and ICMP. It continues with SCTP and any additional protocol deemed necessary to handle. The WG has documented approaches for characterizing and testing NAT devices. BEHAVE will develop protocol-independent toolkits usable by application protocols for NAT traversal. The WG has already produced an update of the binding discovery protocol STUN. It will now produce a relay protocol that focuses on security and is usable with both IPv4 and IPv6, and capable of relaying between the two IP versions. Due to the WG's experience with translators and their behavior it has been given the following tasks to help encourage migration to IPv6. To support deployments where communicating hosts require using different address families (IPv4 or IPv6), address family translation is needed to establish communication. In BEHAVE's specification work on this topic it will coordinate with the V6ops WG on requirements and operational considerations. "An IPv4 network" or "an IPv6 network" in the descriptions below refer to a network with a clearly identifiable administrative domain (e.g., an enterprise campus network, a mobile operator's cellular network, a residential subscriber network, etc.). It will also be that network that deploys the necessary equipment for translation. The BEHAVE WG will design solutions for the following six translation scenarios; other scenarios are out of scope: 1. An IPv6 network to IPv4 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translator function is intended to service a specific IPv6 network of arbitary size. Port translation is necessary on the IPv4 side for efficient IPv4 address usage. 2. IPv6 Internet to an IPv4 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translator function is intended to service a specific IPv4 network using either private or public IPv4 addresses. This scenario has different constraints compared to (1), e.g. the IPv4 hosts that are to be reachable over IPv6 can be enumerated. Therefore, the WG should attempt to design a simpler solution with less impact on applications. 3. An IPv4 network to IPv6 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv4 network using either public or private IPv4 address space. 4. IPv4 Internet to an IPv6 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv6 network where selected IPv6 hosts and services are to be reachable. 5. An IPv6 network to an IPv4 network, i.e., perform translation between IPv6 and IPv4 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translation function is intended to service a specific IPv6 network of arbitrary size and a specific IPv4 network of arbitrary size (neither of which are the Internet). 6. An IPv4 network to an IPv6 network, i.e., perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translation function is intended to service a specific IPv6 network of arbitrary size and a specific IPv4 network of arbitrary size (neither of which are the Internet). All translation solutions shall be capable of handling flows using TCP, UDP, DCCP, and SCTP, unless they prevent a timely completion of the work item. The parts of ICMP that can be translated are also required to work across a translation solution. Additional protocols directly on top of IP may be supported. Translation mechanisms must handle IP fragmentation. The translators should support multicast traffic and its control traffic (IGMP and MLD) across them, both Single Source Multicast (SSM) and Any Source Multicast (ASM). However, the WG may determine that it becomes too complex or too difficult to realize with maintained functionality, for some or all cases of multicast functionality. Translation mechanisms cannot transparently support protocols that embed network addresses within their protocol messages without application level gateways (ALGs). Because ALGs have security issues (like blocking usage of TLS), are error prone and brittle, and hinder application development, the usage of ALGs in the defined translators should be avoided. Instead application developers will need to be aware and use mechanisms that handle the address family translation. ALGs may be considered only for the most crucial of legacy applications. DNS is a crucial part in making a large number of applications work across a translator. Thus the solution to the above translation cases shall include recommendations for DNS. If additional DNS functionality is needed, it may be developed. Any DNS extensions must be developed together with the DNSEXT WG, including issuing a joint WG last call for any documents. The WG needs to determine the best method for providing address space to a translator in the different deployment cases and documenting the pros and cons of the suggested approaches. The WG is to seek input from the Routing, Operations and Internet areas. Solutions may solve more than one of the cases, however timely delivery is more important than a unified solution. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Mar 2006 Jul 2009 Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) Mar 2006 Oct 2009 Traversal Using Relays around NAT (TURN) Extension for IPv6 Feb 2007 Sep 2009 NAT Behavior Discovery Using STUN Nov 2007 Oct 2009 Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations Dec 2007 Nov 2008 Test vectors for STUN Dec 2008 Nov 2009 Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers Jun 2009 Nov 2009 IP/ICMP Translation Algorithm Jul 2009 Oct 2009 DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers Jul 2009 Nov 2009 NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers Jul 2009 Oct 2009 Framework for IPv4/IPv6 Translation Aug 2009 Oct 2009 IPv6 Addressing of IPv4/IPv6 Translators Bidirectional Forwarding Detection (bfd) ---------------------------------------- Charter Last Modified: 2008-07-21 Current Status: Active Working Group Chair(s): David Ward Jeffrey Haas Routing Area Director(s): Ross Callon Adrian Farrel Routing Area Advisor: Ross Callon Technical Advisor(s): Dave Katz Mailing Lists: General Discussion:rtg-bfd@ietf.org To Subscribe: rtg-bfd-request@ietf.org In Body: With a subject line: subscribe Archive: http://www.ietf.org/mail-archive/web/rtg-bfd/ Description of Working Group: The BFD Working Group is chartered to specify a protocol for bidirectional forwarding detection (BFD), as well as extensions to be used within the scope of BFD and IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations. BFD is a protocol intended to detect faults in the bidirectional path between two forwarding engines, including physical interfaces, subinterfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. An additional goal is to provide a single mechanism that can be used for liveness detection over any media, at any protocol layer, with a wide range of detection times and overhead, to avoid a proliferation of different methods. Important characteristics of BFD include: - Simple, fixed-field encoding to facilitate implementations in hardware - Independence of the data protocol being forwarded between two systems. BFD packets are carried as the payload of whatever encapsulating protocol is appropriate for the medium and network. - Path independence: BFD can provide failure detection on any kind of path between systems, including direct physical links, virtual circuits, tunnels, MPLS LSPs, multihop routed paths, and unidirectional links (so long as there is some return path, of course.) - Ability to be bootstrapped by any other protocol that automatically forms peer, neighbor or adjacency relationships to seed BFD endpoint discovery. At this time the WG is chartered to complete the following work items (additional items will require rechartering): 1. Develop the base BFD protocol specification and submit it to the IESG for publication as a Proposed Standard 2. Document BFD encapsulation and usage profile for single-hop IPv4 and IPv6 adjacencies (e.g, physical links and IP/GRE tunnels for static routes, IS-IS, OSPFv2, OSPFv3, single-hop BGP) and submit the specification to the IESG for publication as a Proposed Standard. 3. Document BFD encapsulation and usage profile for MPLS LSPs and submit the specification to the IESG for publication as a Proposed Standard. 4. Develop the MIB module for BFD and submit it to the IESG for publication as a Proposed Standard. 5. Document BFD encapsulation and usage profile for multi-hop IPv4 and IPv6 adjacencies (e.g. OSPF virtual links and iBGP sessions) and submit the specification to the IESG for publication as a Proposed Standard. Topics for Possible Future Work: 1. Document BFD directly over 802.3 in close collaboration and synchronization with the IEEE. Description of Working Group: The BFD Working Group is chartered to specify a protocol for bidirectional forwarding detection (BFD), as well as extensions to be used within the scope of BFD and IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations. BFD is a protocol intended to detect faults in the bidirectional path between two forwarding engines, including physical interfaces, subinterfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. An additional goal is to provide a single mechanism that can be used for liveness detection over any media, at any protocol layer, with a wide range of detection times and overhead, to avoid a proliferation of different methods. Important characteristics of BFD include: - Simple, fixed-field encoding to facilitate implementations in hardware - Independence of the data protocol being forwarded between two systems. BFD packets are carried as the payload of whatever encapsulating protocol is appropriate for the medium and network. - Path independence: BFD can provide failure detection on any kind of path between systems, including direct physical links, virtual circuits, tunnels, MPLS LSPs, multihop routed paths, and unidirectional links (so long as there is some return path, of course.) - Ability to be bootstrapped by any other protocol that automatically forms peer, neighbor or adjacency relationships to seed BFD endpoint discovery. At this time the WG is chartered to complete the following work items (additional items will require rechartering): 1. Develop the base BFD protocol specification and submit it to the IESG for publication as a Proposed Standard 2. Document BFD encapsulation and usage profile for single-hop IPv4 and IPv6 adjacencies (e.g, physical links and IP/GRE tunnels for static routes, IS-IS, OSPFv2, OSPFv3, single-hop BGP) and submit the specification to the IESG for publication as a Proposed Standard. 3. Document BFD encapsulation and usage profile for MPLS LSPs and submit the specification to the IESG for publication as a Proposed Standard. 4. Develop the MIB module for BFD and submit it to the IESG for publication as a Proposed Standard. 5. Document BFD encapsulation and usage profile for multi-hop IPv4 and IPv6 adjacencies (e.g. OSPF virtual links and iBGP sessions) and submit the specification to the IESG for publication as a Proposed Standard. Topics for Possible Future Work: 1. Document BFD directly over 802.3 in close collaboration and synchronization with the IEEE. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2004 Jun 2008 BFD For MPLS LSPs Jul 2004 Feb 2009 Bidirectional Forwarding Detection Jul 2004 Oct 2009 BFD for Multihop Paths Jul 2004 Oct 2009 BFD for IPv4 and IPv6 (Single Hop) Jul 2005 Feb 2009 Generic Application of BFD Basic Level of Interoperability for SIP Services (bliss) -------------------------------------------------------- Charter Last Modified: 2009-09-25 Current Status: Active Working Group Chair(s): Shida Schubert Scott Lawrence Real-time Applications and Infrastructure Area Director(s): Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Robert Sparks Technical Advisor(s): Jonathan Rosenberg Mailing Lists: General Discussion:bliss@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/bliss Archive: http://www.ietf.org/mail-archive/web/bliss Description of Working Group: The focus of the group is to facilitate effective feature interoperability for features sharing common functional primitives utilizing SIP in heterogeneous network environments as noted below. SIP's approach to supporting more advanced features and applications has been to specify a number of primitive operations, including refer, dialog replacement and joining, and event packages, and then to allow those primitives to be combined in many ways to realize different features. This approach avoids the need for standardized definitions of a feature, which can severely limit innovation and broad applicability. While this approach brings great flexibility and generality, it complicates interoperability. Without any kind of standardized definition of a particular feature, each implementation creates its own definition and corresponding set of call flows and primitives used to realize this feature. In practice, this has resulted in a poor track record for interoperability for more advanced features which make assumptions on supported SIP extensions and behaviors from other elements. The problem is exacerbated by the desire for these features to work across many types of SIP endpoints, including SIP hardphones, softphones, and gateways to the PSTN and other VoIP networks including non-centralized environments, and for the desire to work across domain boundaries and to interwork with the PSTN, when applicable. The focus will not be on rigorous definition of what the specific feature is and exactly how it works. Rather, the focus will be on documenting the variations that exist in the wild sharing common interop problems, figuring out a minimum baseline requirement for a UA and servers (minimum set of primitives etc.), defining minimum levels of functionality and functional primitives required to realize a broad class of related features, and on interoperating with other elements which might implement one of those features in different ways. The BLISS working group will coordinate closely with the SIP and SIPPING working groups. Like SIPPING, its role is to focus on applications of the SIP protocol and not on core extensions to SIP itself. The difference between SIPPING and BLISS, is that BLISS is focused on a particular type of SIP application - call features, and in particular, advanced call features requiring non-trivial call control. SIP applications such as configuration, presence, SIP extensions for IM, and session policy are clearly out of scope for BLISS and remain the sole province of SIPPING. Of course, any features considered by BLISS will support the full range of multimedia supported by SIP - audio, video, text, messaging, and so on. The BLISS working group will focus on resolving interpretability issues on four functional primitives as an initial milestone. Summary for each of the functional primitives are as follows. A "Problem Statement" document will also be charted as the first deliverable of this working group. This document will describe the problem this working group is trying to address, the criteria to be met for items to be accepted and a template for documenting a draft for this working group. Line Sharing Description: this covers the functionality required for multiple UA instances to be able to see and utilize sessions made to/from either one. It covers a range of features including: * multiple call appearances * call suspend/resume * retrieve * conference across appearances Parking Description: this covers functionality required to move calls from one instance to another without pre-arranged knowledge of the set of instances on which the call is to be shared. Basically a dynamic version of line sharing in a sense. It would cover features including: * park * parked retrieval * directed park * directed pickup Automated Handling Description: this covers functionality required for a user to indicate, asynchronously from the time of a call, what the handling of a future call should be. It covers the rules on who implements the processing and how it is signaled. Covers features including: * DND * CFU * CFNA Call Queuing Description: this covers functionality required to queue a call when the callee is not available, handling of a queue and notifying when callee is ready to receive a call. Covers features including: * CCBS * CCNR Guiding principles for this working group work will include: - Identify functional primitives with interoperability issues, based on an analysis of variations of features sharing same or similar functional primitives within heterogeneous network(s). Provide a clear description of any interoperability problems that are identified by documenting the variations that exist in the wild for features that is already implemented. - Document minimum baseline requirements relevant to the functional requirements for addressing the interoperability issue. Criteria to consider: * who is responsible for invoking? * who is responsible for implementing? * how does the functional primitive interact with multiple media types? * how does the functional primitive work between administrative domains? - Initiate analysis of the pros and cons of key approaches to addressing the requirements. - Where the requirements can be satisfied within the capabilities of the current standards, produce BCPs [and appropriate call-flows] to document the best approach. - Where normal event packages or SIP uri parameter is all what's needed to prevent interoperability issues, appropriate extensions and its usage would be defined and documented. - Where extensions to standards are required beyond what's mentioned above, bring the analysis, requirements and need for new extensions to the appropriate working group (SIP, SIPPING or SIMPLE). - As in the SIPPING charter, the security of all the deliverables will be of special importance. *Deliverable may attempt to... 1. Define a single approach to solve the problem. 2. Allow variations but mandate support for more than one mechanism. 3. Demonstrate that interoperability is possible even when entities provide the feature with the functional primitive differently. Description of Working Group: The focus of the group is to facilitate effective feature interoperability for features sharing common functional primitives utilizing SIP in heterogeneous network environments as noted below. SIP's approach to supporting more advanced features and applications has been to specify a number of primitive operations, including refer, dialog replacement and joining, and event packages, and then to allow those primitives to be combined in many ways to realize different features. This approach avoids the need for standardized definitions of a feature, which can severely limit innovation and broad applicability. While this approach brings great flexibility and generality, it complicates interoperability. Without any kind of standardized definition of a particular feature, each implementation creates its own definition and corresponding set of call flows and primitives used to realize this feature. In practice, this has resulted in a poor track record for interoperability for more advanced features which make assumptions on supported SIP extensions and behaviors from other elements. The problem is exacerbated by the desire for these features to work across many types of SIP endpoints, including SIP hardphones, softphones, and gateways to the PSTN and other VoIP networks including non-centralized environments, and for the desire to work across domain boundaries and to interwork with the PSTN, when applicable. The focus will not be on rigorous definition of what the specific feature is and exactly how it works. Rather, the focus will be on documenting the variations that exist in the wild sharing common interop problems, figuring out a minimum baseline requirement for a UA and servers (minimum set of primitives etc.), defining minimum levels of functionality and functional primitives required to realize a broad class of related features, and on interoperating with other elements which might implement one of those features in different ways. The BLISS working group will coordinate closely with the SIP and SIPPING working groups. Like SIPPING, its role is to focus on applications of the SIP protocol and not on core extensions to SIP itself. The difference between SIPPING and BLISS, is that BLISS is focused on a particular type of SIP application - call features, and in particular, advanced call features requiring non-trivial call control. SIP applications such as configuration, presence, SIP extensions for IM, and session policy are clearly out of scope for BLISS and remain the sole province of SIPPING. Of course, any features considered by BLISS will support the full range of multimedia supported by SIP - audio, video, text, messaging, and so on. The BLISS working group will focus on resolving interpretability issues on four functional primitives as an initial milestone. Summary for each of the functional primitives are as follows. A "Problem Statement" document will also be charted as the first deliverable of this working group. This document will describe the problem this working group is trying to address, the criteria to be met for items to be accepted and a template for documenting a draft for this working group. Line Sharing Description: this covers the functionality required for multiple UA instances to be able to see and utilize sessions made to/from either one. It covers a range of features including: * multiple call appearances * call suspend/resume * retrieve * conference across appearances Parking Description: this covers functionality required to move calls from one instance to another without pre-arranged knowledge of the set of instances on which the call is to be shared. Basically a dynamic version of line sharing in a sense. It would cover features including: * park * parked retrieval * directed park * directed pickup Automated Handling Description: this covers functionality required for a user to indicate, asynchronously from the time of a call, what the handling of a future call should be. It covers the rules on who implements the processing and how it is signaled. Covers features including: * DND * CFU * CFNA Call Queuing Description: this covers functionality required to queue a call when the callee is not available, handling of a queue and notifying when callee is ready to receive a call. Covers features including: * CCBS * CCNR Guiding principles for this working group work will include: - Identify functional primitives with interoperability issues, based on an analysis of variations of features sharing same or similar functional primitives within heterogeneous network(s). Provide a clear description of any interoperability problems that are identified by documenting the variations that exist in the wild for features that is already implemented. - Document minimum baseline requirements relevant to the functional requirements for addressing the interoperability issue. Criteria to consider: * who is responsible for invoking? * who is responsible for implementing? * how does the functional primitive interact with multiple media types? * how does the functional primitive work between administrative domains? - Initiate analysis of the pros and cons of key approaches to addressing the requirements. - Where the requirements can be satisfied within the capabilities of the current standards, produce BCPs [and appropriate call-flows] to document the best approach. - Where normal event packages or SIP uri parameter is all what's needed to prevent interoperability issues, appropriate extensions and its usage would be defined and documented. - Where extensions to standards are required beyond what's mentioned above, bring the analysis, requirements and need for new extensions to the appropriate working group (SIP, SIPPING or SIMPLE). - As in the SIPPING charter, the security of all the deliverables will be of special importance. *Deliverable may attempt to... 1. Define a single approach to solve the problem. 2. Allow variations but mandate support for more than one mechanism. 3. Demonstrate that interoperability is possible even when entities provide the feature with the functional primitive differently. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jan 2008 Oct 2009 An Analysis of Automatic Call Handling Implementation Issues in the Session Initiation Protocol (SIP) Feb 2008 Oct 2009 Call Completion for Session Initiation Protocol (SIP) Sep 2008 Oct 2009 Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR) Jul 2009 Oct 2009 Implementing Call Park and Retrieve using the Session Initiation Protocol (SIP) Benchmarking Methodology (bmwg) ------------------------------- Charter Last Modified: 2009-10-19 Current Status: Active Working Group Chair(s): Al Morton Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Ronald Bonica Mailing Lists: General Discussion:bmwg@ietf.org To Subscribe: bmwg-request@ietf.org In Body: subscribe your_email_address Archive: http://www.ietf.org/mail-archive/web/bmwg/index.html Description of Working Group: The major goal of the Benchmarking Methodology Working Group is to make a series of recommendations concerning the measurement of the performance characteristics of various internetworking technologies; further, these recommendations may focus on the systems or services that are built from these technologies. Each recommendation will describe the class of equipment, system, or service being addressed; discuss the performance characteristics that are pertinent to that class; clearly identify a set of metrics that aid in the description of those characteristics; specify the methodologies required to collect said metrics; and lastly, present the requirements for the common, unambiguous reporting of benchmarking results. To better distinguish the BMWG from other measurement initiatives in the IETF, the scope of the BMWG is limited to technology characterization using simulated stimuli in a laboratory environment. Said differently, the BMWG does not attempt to produce benchmarks for live, operational networks. Moreover, the benchmarks produced by this WG shall strive to be vendor independent or otherwise have universal applicability to a given technology class. Because the demands of a particular technology may vary from deployment to deployment, a specific non-goal of the Working Group is to define acceptance criteria or performance requirements. An ongoing task is to provide a forum for discussion regarding the advancement of measurements designed to provide insight on the operation inter-networking technologies. In addition to its current work plan, the BMWG is explicitly tasked to develop benchmarks and methodologies for the following technologies: * MPLS Forwarding: Develop specific methods to characterize the latency and forwarding performance of MPLS devices, extending the fundamental recommendations of RFC 1242 and RFC 2544 to this networking technology. * SIP Networking Devices: Develop new terminology and methods to characterize the key performance aspects of network devices using SIP, including the signaling plane scale and service rates while considering load conditions on both the signaling and media planes. This work will be harmonized with related SIP performance metric definitions prepared by the PMOL working group. Description of Working Group: The major goal of the Benchmarking Methodology Working Group is to make a series of recommendations concerning the measurement of the performance characteristics of various internetworking technologies; further, these recommendations may focus on the systems or services that are built from these technologies. Each recommendation will describe the class of equipment, system, or service being addressed; discuss the performance characteristics that are pertinent to that class; clearly identify a set of metrics that aid in the description of those characteristics; specify the methodologies required to collect said metrics; and lastly, present the requirements for the common, unambiguous reporting of benchmarking results. To better distinguish the BMWG from other measurement initiatives in the IETF, the scope of the BMWG is limited to technology characterization using simulated stimuli in a laboratory environment. Said differently, the BMWG does not attempt to produce benchmarks for live, operational networks. Moreover, the benchmarks produced by this WG shall strive to be vendor independent or otherwise have universal applicability to a given technology class. Because the demands of a particular technology may vary from deployment to deployment, a specific non-goal of the Working Group is to define acceptance criteria or performance requirements. An ongoing task is to provide a forum for discussion regarding the advancement of measurements designed to provide insight on the operation inter-networking technologies. In addition to its current work plan, the BMWG is explicitly tasked to develop benchmarks and methodologies for the following technologies: * MPLS Forwarding: Develop specific methods to characterize the latency and forwarding performance of MPLS devices, extending the fundamental recommendations of RFC 1242 and RFC 2544 to this networking technology. * SIP Networking Devices: Develop new terminology and methods to characterize the key performance aspects of network devices using SIP, including the signaling plane scale and service rates while considering load conditions on both the signaling and media planes. This work will be harmonized with related SIP performance metric definitions prepared by the PMOL working group. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Mar 2003 Jul 2009 Terminology for Benchmarking IPsec Devices Jun 2003 Oct 2009 Benchmarking Methodology for Link-State IGP Data Plane Route Convergence Jun 2003 Oct 2009 Terminology for Benchmarking Link-State IGP Data Plane Route Convergence Oct 2005 Jul 2009 Methodology for Benchmarking IPsec Devices Oct 2006 Oct 2009 Benchmarking Terminology for Protection Performance Oct 2006 Oct 2009 Methodology for benchmarking MPLS protection mechanisms Better-Than-Nothing Security (btns) ----------------------------------- Charter Last Modified: 2009-02-11 Current Status: Active Working Group Chair(s): Love Hornquist Astrand Julien Laganier Security Area Director(s): Tim Polk Pasi Eronen Security Area Advisor: Tim Polk Mailing Lists: General Discussion:btns@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/btns Archive: http://www.ietf.org/mail-archive/web/btns/current/maillist.html Description of Working Group: Current Internet Protocol security protocol (IPsec) and Internet Key Exchange protocol (IKE) present somewhat of an all-or-nothing alternative; these protocols provide protection from a wide array of possible threats, but are sometimes not deployed because of the need for pre-existing credentials. There is significant interest in providing anonymous (unauthenticated) keying for IPsec to create security associations (SAs) with peers who do not possess authentication credentials that can be validated. Examples of such credentials include self-signed certificates or "bare" public keys. This mode would protect against passive attacks but would be vulnerable to active attacks. The primary purpose of this working group is to specify extensions to the IPsec architecture, and possibly extensions or profiles of IKE, so that IPsec will support creation of unauthenticated SAs. The goal of the resulting RFCs is to enable and encourage simpler and more rapid deployment of IPsec in contexts where use of unauthenticated SAs is deemed appropriate, to enable and encourage the use of network security where it has been difficult to deploy--notably, to enable simpler, more rapid deployment. Any IKE and IPsec extensions/profiles developed in this WG must not undermine the security facilities already defined for IPsec. Specifically, the access control facilities that are central to IPsec must not be degraded when unauthenticated SAs are employed concurrently with authenticated SAs in the same IPsec implementation. Two related problems emerged during the discussion of this problem. First, there is a desire in the KITTEN, RDDP, NFSv4 and potentially other working groups to make use of unauthenticated IPsec SAs, and later cryptographically bind these SAs to applications, which perform their own authentication. The specification of how this binding is performed for IPsec and the specification of how the binding interacts with application authentication protocols are out of scope for this working group. However, interactions between this cryptographic channel binding and IPsec (e.g., the PAD, SPD, SAD, etc.) are expected to be similar to those for the unauthenticated mode with no binding. To avoid duplication of effort, This working group needs to consider how to support channel bindings when developing extensions to IPsec, specifically the PAD and SPD elements. Secondly, BTNS and the channel bindings work both encourage IPsec to be used to secure higher layer protocols. As such we need to determine what information these higher layer protocols need from IPsec. Two proposals are under discussion for providing unauthenticated SA support for IPsec: bare RSA keys transported by IKE and self-signed certificates transported by IKE. The WG has the following specific goals: a) Develop an informational framework document to describe the motivation and goals for having security protocols that support anonymous keying of security associations in general, and IPsec and IKE in particular b) Develop an informational applicability statement, describing a set of threat models with relaxed adversary capability assumptions, to characterize the contexts in which use of unauthenticated SAs is appropriate c) If necessary, specify standards-track IKE extensions or profiles that support one or both of the bare RSA keys or self-signed certificates d) Specify standards-track extensions to the SPD and PAD to support unauthenticated SAs for IPsec and cryptographic channel bindings for IPsec e) Develop an informational document describing the interfaces that IPsec implementations should provide to allow IPsec SAs to be used to secure higher layer protocols The final goal is expected to complement work going on elsewhere in establishing best current practice for higher layer protocols secured by IPsec. Description of Working Group: Current Internet Protocol security protocol (IPsec) and Internet Key Exchange protocol (IKE) present somewhat of an all-or-nothing alternative; these protocols provide protection from a wide array of possible threats, but are sometimes not deployed because of the need for pre-existing credentials. There is significant interest in providing anonymous (unauthenticated) keying for IPsec to create security associations (SAs) with peers who do not possess authentication credentials that can be validated. Examples of such credentials include self-signed certificates or "bare" public keys. This mode would protect against passive attacks but would be vulnerable to active attacks. The primary purpose of this working group is to specify extensions to the IPsec architecture, and possibly extensions or profiles of IKE, so that IPsec will support creation of unauthenticated SAs. The goal of the resulting RFCs is to enable and encourage simpler and more rapid deployment of IPsec in contexts where use of unauthenticated SAs is deemed appropriate, to enable and encourage the use of network security where it has been difficult to deploy--notably, to enable simpler, more rapid deployment. Any IKE and IPsec extensions/profiles developed in this WG must not undermine the security facilities already defined for IPsec. Specifically, the access control facilities that are central to IPsec must not be degraded when unauthenticated SAs are employed concurrently with authenticated SAs in the same IPsec implementation. Two related problems emerged during the discussion of this problem. First, there is a desire in the KITTEN, RDDP, NFSv4 and potentially other working groups to make use of unauthenticated IPsec SAs, and later cryptographically bind these SAs to applications, which perform their own authentication. The specification of how this binding is performed for IPsec and the specification of how the binding interacts with application authentication protocols are out of scope for this working group. However, interactions between this cryptographic channel binding and IPsec (e.g., the PAD, SPD, SAD, etc.) are expected to be similar to those for the unauthenticated mode with no binding. To avoid duplication of effort, This working group needs to consider how to support channel bindings when developing extensions to IPsec, specifically the PAD and SPD elements. Secondly, BTNS and the channel bindings work both encourage IPsec to be used to secure higher layer protocols. As such we need to determine what information these higher layer protocols need from IPsec. Two proposals are under discussion for providing unauthenticated SA support for IPsec: bare RSA keys transported by IKE and self-signed certificates transported by IKE. The WG has the following specific goals: a) Develop an informational framework document to describe the motivation and goals for having security protocols that support anonymous keying of security associations in general, and IPsec and IKE in particular b) Develop an informational applicability statement, describing a set of threat models with relaxed adversary capability assumptions, to characterize the contexts in which use of unauthenticated SAs is appropriate c) If necessary, specify standards-track IKE extensions or profiles that support one or both of the bare RSA keys or self-signed certificates d) Specify standards-track extensions to the SPD and PAD to support unauthenticated SAs for IPsec and cryptographic channel bindings for IPsec e) Develop an informational document describing the interfaces that IPsec implementations should provide to allow IPsec SAs to be used to secure higher layer protocols The final goal is expected to complement work going on elsewhere in establishing best current practice for higher layer protocols secured by IPsec. Internet-Drafts: No Current Internet-Drafts. Calendaring and Scheduling Standards Simplification (calsify) ------------------------------------------------------------- Charter Last Modified: 2008-04-23 Current Status: Active Working Group Chair(s): Aki Niemi Eliot Lear Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion:ietf-calsify@osafoundation.org To Subscribe: http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Archive: http://lists.osafoundation.org/pipermail/ietf-calsify/ Description of Working Group: The Calendaring and Scheduling standards, defined in RFC's 2445, 2446, and 2447 were released in November 1998, and further described in RFC 3283. They were designed to progress the level of interoperability between dissimilar calendaring and scheduling systems. The Calendaring and Scheduling Core Object Specification, iCalendar, succeeded in establishing itself as the common format for exchanging calendaring information across the Internet. On the other hand, only basic interoperability has been achieved between different scheduling systems. The Calsify working group is chartered to: (1) Revise the Calendaring and Scheduling Standards to advance the state of interoperable calendaring and scheduling by addressing the known interoperability issues, errata, and problems found based on implementation experience. (2) Clarify the registration process for iCalendar extensions (i.e., the current core object specification only provides a template to register new properties). (3) Provide a means to ease transition from, and to co-exist with, the earlier iCalendar standards to the new ones. Proposing an XML representation or transformation of iCalendar objects is out of the scope of this working group. Depending on the results of the update process on the standards documents the working group will consider whether advancing the documents to draft standard is appropriate. If we decide to move the documents to draft status, milestones may get changed and/or added to allow for any additional work necessary to advance the documents. Description of Working Group: The Calendaring and Scheduling standards, defined in RFC's 2445, 2446, and 2447 were released in November 1998, and further described in RFC 3283. They were designed to progress the level of interoperability between dissimilar calendaring and scheduling systems. The Calendaring and Scheduling Core Object Specification, iCalendar, succeeded in establishing itself as the common format for exchanging calendaring information across the Internet. On the other hand, only basic interoperability has been achieved between different scheduling systems. The Calsify working group is chartered to: (1) Revise the Calendaring and Scheduling Standards to advance the state of interoperable calendaring and scheduling by addressing the known interoperability issues, errata, and problems found based on implementation experience. (2) Clarify the registration process for iCalendar extensions (i.e., the current core object specification only provides a template to register new properties). (3) Provide a means to ease transition from, and to co-exist with, the earlier iCalendar standards to the new ones. Proposing an XML representation or transformation of iCalendar objects is out of the scope of this working group. Depending on the results of the update process on the standards documents the working group will consider whether advancing the documents to draft standard is appropriate. If we decide to move the documents to draft status, milestones may get changed and/or added to allow for any additional work necessary to advance the documents. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Aug 2005 Oct 2009 iCalendar Message-Based Interoperability Protocol (iMIP) Oct 2005 Oct 2009 iCalendar Transport-Independent Interoperability Protocol (iTIP) Control And Provisioning of Wireless Access Points (capwap) ----------------------------------------------------------- Charter Last Modified: 2008-08-21 Current Status: Active Working Group Chair(s): Mahalingam Mani Dorothy Gellert Margaret Wasserman Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Technical Advisor(s): David Borman Scott Kelly Bob O'Hara Charles Clancy Mailing Lists: General Discussion:capwap@frascone.com To Subscribe: http://lists.frascone.com/mailman/listinfo/capwap Archive: http://lists.frascone.com/pipermail/capwap Description of Working Group: The original CAPWAP WG charter included drafting a problem statement and a taxonomy of architectures. The new charter of the CAPWAP WG proposes building upon the original charter and developing a CAPWAP protocol to provide interoperability among WLAN backend architectures. The intent of the CAPWAP protocol is to facilitate control, management and provisioning of WLAN Termination Points (WTPs) specifying the services, functions and resources relating to 802.11 WLAN Termination Points in order to allow for interoperable implementations of WTPs and ACs. The revised CAPWAP WG will reference two classes of the Centralized WLAN Architecture family, namely the Local MAC and the Split MAC, as described in the CAPWAP Architecture Taxonomy draft. The protocol will define the CAPWAP control plane including the primitives to control data access. An effective Centralized CAPWAP Architecture impacts how WLAN data traffic is managed over the backend network. This implies the abilitiy to control how data is forwarded by negotiating existng data encapsulation mechanisms and specifying data payload formats in order to ensure interoperability between CAPWAP vendors. No other specifications of the CAPWAP data plane are within the scope of this charter. The CAPWAP WG will strive for extensibility in the protocol design to favor future applicability to other access technologies, especially IEEE 802.16. While accommodation of any access technology other than IEEE 802.11 is not required for successful completion, there are clear deployment advantages if a wide range of access technologies are accommodated. In summary, the primary goals of the group will be: 1. Defining a set of Objectives based on the architecture taxonomy work that lists the requirements for an interoperable CAPWAP protocol. In addition, the WG will incorporate requirements derived from the inputs provided by Enterprise and (hotspot) Providers based on the WLAN deployment challenges addressed by CAPWAP architecture. This document will: a. include objectives to address problems described in the CAPWAP Problem statement document b. Describe each objective, its benefit to the protocol and how it satisfies the problem statement. c. Prioritize and classify the objectives into 3 categories: i. Mandatory and Accepted ii. Desirable iii. Rejected d. Undergo review in IEEE 802 as needed This should result in the first WG Last Call for Objectives draft. To avoid requirements bloat and stalemate, the WG has a hard deadline on the Objectives phase. The WG MUST reach WG consensus on the objectives draft by Feb 2005. This is for several reasons: * We must send this for review to IEEE at that time. * We must have a reasonably stable set of objectives so that candidate submissions are aware of the objectives to be met. The 2nd WG Last Call (in April) for the objectives draft is to ensure that the WG has consensus on any changes that may result from IEEE and expert review. So it is not the intention that the WG keeps adding new Objectives after Feb 2005. If the WG cannot reach consensus on the Objectives draft by the May 2005 milestone to the IESG, the WG will close. 2. Evaluating a set of candidate proposals that include existing IETF protocols and any proposals leading to the selection of a protocol on which to base the CAPWAP standard. 3. Developing a CAPWAP protocol standard that meets the Mandatory and Accepted objectives from the Evaluation draft and contains the minimal set of feature needed to control and provision WLAN Access Points. Specifically The CAPWAP protocol document will address the following considerations: a. Architecture b. Operations c. Security d. Network Management e. Scalability f. Performance 4. A MIB Document to support the CAPWAP protocol. In addition, the CAPWAP WG will maintain its Liaison with the IEEE to ensure consistency of its work with the IEEE 802.11 Standard. Deliverables: * Objectives/Criteria Document for CAPWAP protocol * Protocol evaluation and base protocol selection document * CAPWAP Protocol standard * MIB support standard Description of Working Group: The original CAPWAP WG charter included drafting a problem statement and a taxonomy of architectures. The new charter of the CAPWAP WG proposes building upon the original charter and developing a CAPWAP protocol to provide interoperability among WLAN backend architectures. The intent of the CAPWAP protocol is to facilitate control, management and provisioning of WLAN Termination Points (WTPs) specifying the services, functions and resources relating to 802.11 WLAN Termination Points in order to allow for interoperable implementations of WTPs and ACs. The revised CAPWAP WG will reference two classes of the Centralized WLAN Architecture family, namely the Local MAC and the Split MAC, as described in the CAPWAP Architecture Taxonomy draft. The protocol will define the CAPWAP control plane including the primitives to control data access. An effective Centralized CAPWAP Architecture impacts how WLAN data traffic is managed over the backend network. This implies the abilitiy to control how data is forwarded by negotiating existng data encapsulation mechanisms and specifying data payload formats in order to ensure interoperability between CAPWAP vendors. No other specifications of the CAPWAP data plane are within the scope of this charter. The CAPWAP WG will strive for extensibility in the protocol design to favor future applicability to other access technologies, especially IEEE 802.16. While accommodation of any access technology other than IEEE 802.11 is not required for successful completion, there are clear deployment advantages if a wide range of access technologies are accommodated. In summary, the primary goals of the group will be: 1. Defining a set of Objectives based on the architecture taxonomy work that lists the requirements for an interoperable CAPWAP protocol. In addition, the WG will incorporate requirements derived from the inputs provided by Enterprise and (hotspot) Providers based on the WLAN deployment challenges addressed by CAPWAP architecture. This document will: a. include objectives to address problems described in the CAPWAP Problem statement document b. Describe each objective, its benefit to the protocol and how it satisfies the problem statement. c. Prioritize and classify the objectives into 3 categories: i. Mandatory and Accepted ii. Desirable iii. Rejected d. Undergo review in IEEE 802 as needed This should result in the first WG Last Call for Objectives draft. To avoid requirements bloat and stalemate, the WG has a hard deadline on the Objectives phase. The WG MUST reach WG consensus on the objectives draft by Feb 2005. This is for several reasons: * We must send this for review to IEEE at that time. * We must have a reasonably stable set of objectives so that candidate submissions are aware of the objectives to be met. The 2nd WG Last Call (in April) for the objectives draft is to ensure that the WG has consensus on any changes that may result from IEEE and expert review. So it is not the intention that the WG keeps adding new Objectives after Feb 2005. If the WG cannot reach consensus on the Objectives draft by the May 2005 milestone to the IESG, the WG will close. 2. Evaluating a set of candidate proposals that include existing IETF protocols and any proposals leading to the selection of a protocol on which to base the CAPWAP standard. 3. Developing a CAPWAP protocol standard that meets the Mandatory and Accepted objectives from the Evaluation draft and contains the minimal set of feature needed to control and provision WLAN Access Points. Specifically The CAPWAP protocol document will address the following considerations: a. Architecture b. Operations c. Security d. Network Management e. Scalability f. Performance 4. A MIB Document to support the CAPWAP protocol. In addition, the CAPWAP WG will maintain its Liaison with the IEEE to ensure consistency of its work with the IEEE 802.11 Standard. Deliverables: * Objectives/Criteria Document for CAPWAP protocol * Protocol evaluation and base protocol selection document * CAPWAP Protocol standard * MIB support standard Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- May 2008 Aug 2009 CAPWAP Protocol Base MIB Jun 2008 Aug 2009 CAPWAP Protocol Binding MIB for IEEE 802.11 Common Control and Measurement Plane (ccamp) -------------------------------------------- Charter Last Modified: 2009-06-15 Current Status: Active Working Group Chair(s): Deborah Brungard Lou Berger Routing Area Director(s): Ross Callon Adrian Farrel Routing Area Advisor: Adrian Farrel Secretary(ies): Daniel King Mailing Lists: General Discussion:ccamp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ccamp Archive: http://www.ietf.org/mail-archive/web/ccamp/current/maillist.html Description of Working Group: Organizational Overview The CCAMP working group coordinates the work within the IETF defining a common control plane and a separate common measurement plane for physical path and core tunneling technologies of Internet and telecom service providers (ISPs and SPs), e.g. O-O and O-E-O optical switches, TDM Switches, Ethernet Switches, ATM and Frame Relay switches, IP encapsulation tunneling technologies, and MPLS in cooperation with the MPLS WG. In this context, measurement refers to the acquisition and distribution of attributes relevant to the setting up of tunnels and paths. CCAMP WG work scope includes: - Definition of protocol-independent metrics and parameters (measurement attributes) for describing links and paths that are required for routing and signaling. These will be developed in conjunction with requests and requirements from other WGs to ensure overall usefulness. - Definition of protocol(s) and extensions to them required for link and path attribute measurement. Link Management Protocol (LMP) is included here. - Functional specification of extensions for routing (OSPF, ISIS) and signalling (RSVP-TE) required for path establishment. Protocol formats and procedures that embody these extensions will be done jointly with the WGs supervising those protocols. - Definition of the mechanisms required to determine the route and properties of an established path (tunnel tracing). - Definition of management objects (e.g. as part of MIB modules) and OAM techniques relevant to the protocols and extensions specified within the WG. - Work on traffic-engineering GMPLS mechanisms and protocol extensions to support source-controlled and explicitly-routed Ethernet data paths for Ethernet data planes that are already approved by an Standards Development Organization (SDO) with responsibility for the Ethernet data plane. It is expected that the primary SDO in this case is the IEEE. Note that the specification or modification of Ethernet data planes is out of scope. - Work on GMPLS mechanisms and protocol extensions to support the transport profile of MPLS (MPLS-TP) in cooperation with the MPLS, L2VPN, and PWE3 Working Group and in coordination with the requirements expressed jointly by the IETF and ITU-T. CCAMP WG currently works on the following tasks: - Define how the properties of network resources gathered by a measurement protocol can be distributed in existing routing protocols, such as OSPF and IS-IS. CCAMP defines the generic description of the properties and how they are distributed in OSPF. The specifics of distribution within IS-IS are being addressed in the ISIS WG. - Define signaling and routing mechanisms and extensions to allow path and tunnel setup and maintenance across multiple domains, where a domain may be an IGP area, an Autonomous System, or any other region of topological visibility. To this end, work cooperatively with the PCE and MPLS WGs. - Define abstract link and path properties needed for link and path protection. Specify signalling mechanisms for path protection, diverse routing and fast path restoration. Ensure that multi-layer path protection and restoration functions are achievable using the defined signalling, routing, and measurement protocols, either separately or in combination. - Identify which requirements for signaling and routing for Automatically Switched Optical Network (ASON) are not currently met by protocols defined in CCAMP; based on these, define mechanisms to address these requirements. - Produce extensions to the CCAMP WG protocols and RFCs necessary to create an MPLS Transport Profile (MPLS TP). The work on the MPLS TP will be coordinated between the MPLS, L2VPN, PWE3, and CCAMP working groups that are jointly chartered to do MPLS TP work. In doing this work, the WG will work closely with at least the following other WGs: MPLS, L2VPN, PWE3, ISIS, OSPF, IDR, L1VPN and PCE. The WG will also cooperate with the ITU-T and the IEEE 802.1. Description of Working Group: Organizational Overview The CCAMP working group coordinates the work within the IETF defining a common control plane and a separate common measurement plane for physical path and core tunneling technologies of Internet and telecom service providers (ISPs and SPs), e.g. O-O and O-E-O optical switches, TDM Switches, Ethernet Switches, ATM and Frame Relay switches, IP encapsulation tunneling technologies, and MPLS in cooperation with the MPLS WG. In this context, measurement refers to the acquisition and distribution of attributes relevant to the setting up of tunnels and paths. CCAMP WG work scope includes: - Definition of protocol-independent metrics and parameters (measurement attributes) for describing links and paths that are required for routing and signaling. These will be developed in conjunction with requests and requirements from other WGs to ensure overall usefulness. - Definition of protocol(s) and extensions to them required for link and path attribute measurement. Link Management Protocol (LMP) is included here. - Functional specification of extensions for routing (OSPF, ISIS) and signalling (RSVP-TE) required for path establishment. Protocol formats and procedures that embody these extensions will be done jointly with the WGs supervising those protocols. - Definition of the mechanisms required to determine the route and properties of an established path (tunnel tracing). - Definition of management objects (e.g. as part of MIB modules) and OAM techniques relevant to the protocols and extensions specified within the WG. - Work on traffic-engineering GMPLS mechanisms and protocol extensions to support source-controlled and explicitly-routed Ethernet data paths for Ethernet data planes that are already approved by an Standards Development Organization (SDO) with responsibility for the Ethernet data plane. It is expected that the primary SDO in this case is the IEEE. Note that the specification or modification of Ethernet data planes is out of scope. - Work on GMPLS mechanisms and protocol extensions to support the transport profile of MPLS (MPLS-TP) in cooperation with the MPLS, L2VPN, and PWE3 Working Group and in coordination with the requirements expressed jointly by the IETF and ITU-T. CCAMP WG currently works on the following tasks: - Define how the properties of network resources gathered by a measurement protocol can be distributed in existing routing protocols, such as OSPF and IS-IS. CCAMP defines the generic description of the properties and how they are distributed in OSPF. The specifics of distribution within IS-IS are being addressed in the ISIS WG. - Define signaling and routing mechanisms and extensions to allow path and tunnel setup and maintenance across multiple domains, where a domain may be an IGP area, an Autonomous System, or any other region of topological visibility. To this end, work cooperatively with the PCE and MPLS WGs. - Define abstract link and path properties needed for link and path protection. Specify signalling mechanisms for path protection, diverse routing and fast path restoration. Ensure that multi-layer path protection and restoration functions are achievable using the defined signalling, routing, and measurement protocols, either separately or in combination. - Identify which requirements for signaling and routing for Automatically Switched Optical Network (ASON) are not currently met by protocols defined in CCAMP; based on these, define mechanisms to address these requirements. - Produce extensions to the CCAMP WG protocols and RFCs necessary to create an MPLS Transport Profile (MPLS TP). The work on the MPLS TP will be coordinated between the MPLS, L2VPN, PWE3, and CCAMP working groups that are jointly chartered to do MPLS TP work. In doing this work, the WG will work closely with at least the following other WGs: MPLS, L2VPN, PWE3, ISIS, OSPF, IDR, L1VPN and PCE. The WG will also cooperate with the ITU-T and the IEEE 802.1. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Apr 2006 Oct 2009 Procedures for Dynamically Signaled Hierarchical Label Switched Paths Apr 2006 Nov 2009 Ethernet Traffic Parameters Jul 2006 Aug 2009 OSPFv2 Routing Protocols Extensions for ASON Routing Sep 2006 Sep 2009 Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks Sep 2006 Jul 2009 draft-ietf-ccamp-gmpls-vcat-lcas-08.txt Nov 2006 Oct 2009 Traffic Engineering Database Management Information Base in support of MPLS-TE/GMPLS Nov 2007 Nov 2009 Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) Feb 2008 Oct 2009 Generalized Multi-Protocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework Mar 2008 Oct 2009 Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks Mar 2008 Nov 2009 Data Channel Status Confirmation Extensions for the Link Management Protocol Mar 2008 Sep 2009 RSVP-TE Signaling Extension For Management Plane To Control Plane LSP Handover In A GMPLS Enabled Transport Network. Apr 2008 Oct 2009 Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User-Network Interface (UNI) Apr 2008 Oct 2009 Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching Apr 2008 Oct 2009 Generalized Multiprotocol Label Switching (GMPLS) control of Ethernet PBB-TE May 2008 Sep 2009 Document: draft-ietf-ccamp-gmpls-g-694-lambda-labels-04.txt Jun 2008 Jun 2009 Service Provider Requirements for Ethernet control with GMPLS Aug 2008 Oct 2009 Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions Aug 2008 Oct 2009 Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks Dec 2008 Oct 2009 Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) Dec 2008 Oct 2009 Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks Dec 2008 Oct 2009 OAM Configuration Framework and Requirements for GMPLS RSVP-TE Dec 2008 Oct 2009 GMPLS RSVP-TE Extensions for Ethernet OAM Configuration Jun 2009 Oct 2009 A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments Cga & Send maIntenance (csi) ---------------------------- Charter Last Modified: 2009-04-13 Current Status: Active Working Group Chair(s): Marcelo Bagnulo Gabriel Montenegro Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion:cga-ext@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/cga-ext Archive: http://www.ietf.org/mail-archive/web/cga-ext/current/maillist.html Description of Working Group: The Secure Neighbor Discovery (SEND) protocol defined by RFC 3971 provides security mechanisms protecting different functions of the Neighbor Discovery (ND) protocol defined by RFC 2461. This includes address resolution (discovering link layer address of another node attached to the link), router discovery (discovering routers attached to the link), and neighbor unreachability detection (detecting that a node attached to the link is no longer reachable). SEND protection of address resolution and neighbor unreachability detection functions relies on IPv6 address proof-of-ownership and message integrity protection provided respectively via Cryptographically Generated Addresses (CGAs) and RSA Digital Signatures. CGAs are defined in RFC 3972, and are extended with a CGA extension format defined in RFC 4581, and a support for multiple hash functions defined in RFC 4982. While CGAs were originally defined for the SEND protocol, they have proved to be a useful security tool in other environments too, and its usage has been proposed to secure other protocols such as the Shim6 multihoming protocol and the Mobile IPv6 protocol. While there is very little deployment of SEND to date, there are a number of implementations, recommendations in the NIST and DOD profiles call for use of SEND, and operating system vendors are considering adding SEND to their next releases. As a result, it is desirable to review the current state of the SEND and CGA specifications, maintain and complement them where necessary. Up to date cryptographic algorithms are needed, and the protocols need to be able to deal with certain common situations currently not supported. Specifically, the WG will look at the following issues: - Develop an informational document analyzing the implications of recent attacks on hash functions used by SeND protocol. Current SeND specification uses the SHA-1 hash algorithm and does not provides support for hash algorithm agility, hence the critical need for understanding the impact of the attacks on the SeND protocol. In addition, if as a result of the aforementioned analysis it is deemed necessary, standard-track extensions to the SeND protocol to support multiple hash algorithms will be defined. - Specify a standards-track CGA and SeND extensions to support multiple public key algorithms. As currently defined CGA and SeND can only use RSA keys, and they lack support for other public key algorithms (e.g. Elliptic Curve Cryptography -- ECC). - Develop X.509 certificate management tools for SeND. SeND utilizes X.509v3 certificates for performing router authorization. It uses the X.509 extension for IP addresses to verify whether the router is authorized to advertise the mentioned IP addresses. Since the IP addresses extension does not explicitly mention what functions the node can perform for the IP addresses it becomes impossible to know the reason for which the certificate was allowed. In order to facilitate issuance of certificates for specific functions, we need to encode the functions permitted for the certificate into the certificate itself. The WG will develop a certificate profile, including a definition of X.509 Extended Key Usage for SeND . In addition, the WG will recommend best practices for (1) enrollment, (2) revocation checking, and (3) publishing of certificates. This WG will ensure that the profile and recommended practices will cover usage by hosts in addition to routers. The working group will coordinate this activity with the PKIX and SIDR WGs. Prior to IESG submission of the certificate profile, the working group will seek input from and coordinate with other groups enabling cryptographic identification of device-related properties (e.g., IEEE 802.1ar, IEEE 802.16, WiMAX Forum, IETF CAPWAP WG). - Develop a standard track document defining a mechanism to perform SeND certificate provisioning for routers. SeND protocol as defined in RFC3971 specifies how IPv6 nodes can trust the prefixes advertised by a router. The solution is based on the use of the IP Address Delegation extension (RFC3779) in X.509 v3 certificates (RFC3280). This work will provide the tools require to provision with the certificates to the routers in an automatic manner. The working will coordinate this activity with the PKIX WG. - Produce a problem statement document for Neighbor Discovery Proxies and then specify standards-track SEND Extensions to support Neighbor Discovery Proxies: SEND protocol as currently defined in RFC 3971 lacks of support for ND Proxies defined in RFC 3775 and RFC 4389. Extensions to the SEND protocol will be defined in order to provide equivalent SEND security capabilities to ND Proxies. - Develop an informational document analysing different approaches to allow SeND and CGAs to be used in conjunction with DHCP, and making recommendations on which are the best suited. Recharter based on the result of the analysis. - Update base specifications (RFC 3971 and 3972). Description of Working Group: The Secure Neighbor Discovery (SEND) protocol defined by RFC 3971 provides security mechanisms protecting different functions of the Neighbor Discovery (ND) protocol defined by RFC 2461. This includes address resolution (discovering link layer address of another node attached to the link), router discovery (discovering routers attached to the link), and neighbor unreachability detection (detecting that a node attached to the link is no longer reachable). SEND protection of address resolution and neighbor unreachability detection functions relies on IPv6 address proof-of-ownership and message integrity protection provided respectively via Cryptographically Generated Addresses (CGAs) and RSA Digital Signatures. CGAs are defined in RFC 3972, and are extended with a CGA extension format defined in RFC 4581, and a support for multiple hash functions defined in RFC 4982. While CGAs were originally defined for the SEND protocol, they have proved to be a useful security tool in other environments too, and its usage has been proposed to secure other protocols such as the Shim6 multihoming protocol and the Mobile IPv6 protocol. While there is very little deployment of SEND to date, there are a number of implementations, recommendations in the NIST and DOD profiles call for use of SEND, and operating system vendors are considering adding SEND to their next releases. As a result, it is desirable to review the current state of the SEND and CGA specifications, maintain and complement them where necessary. Up to date cryptographic algorithms are needed, and the protocols need to be able to deal with certain common situations currently not supported. Specifically, the WG will look at the following issues: - Develop an informational document analyzing the implications of recent attacks on hash functions used by SeND protocol. Current SeND specification uses the SHA-1 hash algorithm and does not provides support for hash algorithm agility, hence the critical need for understanding the impact of the attacks on the SeND protocol. In addition, if as a result of the aforementioned analysis it is deemed necessary, standard-track extensions to the SeND protocol to support multiple hash algorithms will be defined. - Specify a standards-track CGA and SeND extensions to support multiple public key algorithms. As currently defined CGA and SeND can only use RSA keys, and they lack support for other public key algorithms (e.g. Elliptic Curve Cryptography -- ECC). - Develop X.509 certificate management tools for SeND. SeND utilizes X.509v3 certificates for performing router authorization. It uses the X.509 extension for IP addresses to verify whether the router is authorized to advertise the mentioned IP addresses. Since the IP addresses extension does not explicitly mention what functions the node can perform for the IP addresses it becomes impossible to know the reason for which the certificate was allowed. In order to facilitate issuance of certificates for specific functions, we need to encode the functions permitted for the certificate into the certificate itself. The WG will develop a certificate profile, including a definition of X.509 Extended Key Usage for SeND . In addition, the WG will recommend best practices for (1) enrollment, (2) revocation checking, and (3) publishing of certificates. This WG will ensure that the profile and recommended practices will cover usage by hosts in addition to routers. The working group will coordinate this activity with the PKIX and SIDR WGs. Prior to IESG submission of the certificate profile, the working group will seek input from and coordinate with other groups enabling cryptographic identification of device-related properties (e.g., IEEE 802.1ar, IEEE 802.16, WiMAX Forum, IETF CAPWAP WG). - Develop a standard track document defining a mechanism to perform SeND certificate provisioning for routers. SeND protocol as defined in RFC3971 specifies how IPv6 nodes can trust the prefixes advertised by a router. The solution is based on the use of the IP Address Delegation extension (RFC3779) in X.509 v3 certificates (RFC3280). This work will provide the tools require to provision with the certificates to the routers in an automatic manner. The working will coordinate this activity with the PKIX WG. - Produce a problem statement document for Neighbor Discovery Proxies and then specify standards-track SEND Extensions to support Neighbor Discovery Proxies: SEND protocol as currently defined in RFC 3971 lacks of support for ND Proxies defined in RFC 3775 and RFC 4389. Extensions to the SEND protocol will be defined in order to provide equivalent SEND security capabilities to ND Proxies. - Develop an informational document analysing different approaches to allow SeND and CGAs to be used in conjunction with DHCP, and making recommendations on which are the best suited. Recharter based on the result of the analysis. - Update base specifications (RFC 3971 and 3972). Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Sep 2008 Nov 2009 SeND Hash Threat Analysis Oct 2008 Oct 2009 Securing Neighbor Discovery Proxy Problem Statement Nov 2008 Jul 2009 Secure Proxy ND Support for SEND Jul 2009 Oct 2009 Certificate profile and certificate management for SEND Oct 2009 Oct 2009 DHCPv6 and CGA Interaction: Problem Statement Datagram Congestion Control Protocol (dccp) ------------------------------------------- Charter Last Modified: 2009-06-26 Current Status: Active Working Group Chair(s): Thomas Phelan Pasi Sarolahti Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Lars Eggert Mailing Lists: General Discussion:dccp@ietf.org To Subscribe: dccp-request@ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/dccp/index.html Description of Working Group: The Datagram Congestion Control Protocol working group is maintaining the Datagram Congestion Control Protocol (DCCP). DCCP is a minimal, general-purpose transport protocol that provides two main functions: (1) the establishment, maintenance and tear-down of an unreliable packet flow and (2) congestion control of that packet flow. The DCCP WG is chartered to work in four areas: * maintenance of the core DCCP protocol * maintenance of the TFRC congestion control protocol * promoting the use of DCCP by upper layers * modular extensions to DCCP In the first area, the WG focuses on maintenance issues (i.e., bug fixes) to the current DCCP specifications. It also provides the venue for moving the DCCP specifications along the Standards Track. To maintain stable specifications, work in this area is tightly controlled and requires strong justification. The second area of work, maintains the TCP Friendly Rate Control (TFRC) congestion control protocol. This includes identification of issues, bug fixes, and progression of the specification along the Standards Track. In the third area, the WG will promote and support the adoption and use of DCCP by upper-layer applications and protocols. This includes specifications for using existing and emerging protocols and applications with DCCP (such as RTP over DCCP and DTLS over DCCP) as well as supporting documents that enhance DCCP deployment and management. In the fourth area, the WG identifies and develops modular extensions to the DCCP specifications that increase the usefulness of DCCP. The goal of this work is to make DCCP attractive to upper-layer protocols and applications. The WG will consider both requirements brought to it from external groups that develop or use upper-layer protocols and applications and may also itself identify a limited number of prospective applications and upper-layer protocols to investigate. This work will provide refinements to the existing congestion control schemes currently provided by DCCP and may also include, for example, mobility support for DCCP. (The acceptance of new work items on mobility requires the approval of the IESG.) This work includes the provision of new congestion control profiles, which are variants of existing ones, that better serve certain applications, for example, interactive applications. The WG may consider to recharter in the future to support the IRTF Internet Congestion Control Research Group (ICCRG) in the development of new congestion control algorithms through the definition of concrete specifications for these algorithms. New work items in the latter two areas must satisfy four conditions: (1) WG consensus on the suitability and projected quality of the proposed work item. (2) A core group of WG participants with sufficient energy and expertise to advance the work item according to the proposed schedule. (3) Commitment from the WG as a whole to provide sufficient and timely review of the proposed work item. (4) Agreement by the AD, who, depending on the scope of the proposed work item, may decide that an IESG review is needed first. The DCCP WG pursues its work in close collaboration with several other IETF WGs and IRTF RGs, including TSVWG, AVT, MMUSIC, BEHAVE, ICCRG and TMRG. Description of Working Group: The Datagram Congestion Control Protocol working group is maintaining the Datagram Congestion Control Protocol (DCCP). DCCP is a minimal, general-purpose transport protocol that provides two main functions: (1) the establishment, maintenance and tear-down of an unreliable packet flow and (2) congestion control of that packet flow. The DCCP WG is chartered to work in four areas: * maintenance of the core DCCP protocol * maintenance of the TFRC congestion control protocol * promoting the use of DCCP by upper layers * modular extensions to DCCP In the first area, the WG focuses on maintenance issues (i.e., bug fixes) to the current DCCP specifications. It also provides the venue for moving the DCCP specifications along the Standards Track. To maintain stable specifications, work in this area is tightly controlled and requires strong justification. The second area of work, maintains the TCP Friendly Rate Control (TFRC) congestion control protocol. This includes identification of issues, bug fixes, and progression of the specification along the Standards Track. In the third area, the WG will promote and support the adoption and use of DCCP by upper-layer applications and protocols. This includes specifications for using existing and emerging protocols and applications with DCCP (such as RTP over DCCP and DTLS over DCCP) as well as supporting documents that enhance DCCP deployment and management. In the fourth area, the WG identifies and develops modular extensions to the DCCP specifications that increase the usefulness of DCCP. The goal of this work is to make DCCP attractive to upper-layer protocols and applications. The WG will consider both requirements brought to it from external groups that develop or use upper-layer protocols and applications and may also itself identify a limited number of prospective applications and upper-layer protocols to investigate. This work will provide refinements to the existing congestion control schemes currently provided by DCCP and may also include, for example, mobility support for DCCP. (The acceptance of new work items on mobility requires the approval of the IESG.) This work includes the provision of new congestion control profiles, which are variants of existing ones, that better serve certain applications, for example, interactive applications. The WG may consider to recharter in the future to support the IRTF Internet Congestion Control Research Group (ICCRG) in the development of new congestion control algorithms through the definition of concrete specifications for these algorithms. New work items in the latter two areas must satisfy four conditions: (1) WG consensus on the suitability and projected quality of the proposed work item. (2) A core group of WG participants with sufficient energy and expertise to advance the work item according to the proposed schedule. (3) Commitment from the WG as a whole to provide sufficient and timely review of the proposed work item. (4) Agreement by the AD, who, depending on the scope of the proposed work item, may decide that an IESG review is needed first. The DCCP WG pursues its work in close collaboration with several other IETF WGs and IRTF RGs, including TSVWG, AVT, MMUSIC, BEHAVE, ICCRG and TMRG. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2006 Jun 2007 RTP and the Datagram Congestion Control Protocol (DCCP) Dynamic Host Configuration (dhc) -------------------------------- Charter Last Modified: 2009-04-16 Current Status: Active Working Group Chair(s): John Jason Brzozowski Ted Lemon Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion:dhcwg@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/dhcwg Archive: http://www.ietf.org/mail-archive/web/dhcwg/current/maillist.html Description of Working Group: The dhc working group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCPv4 is currently a "Draft Standard" and is documented in RFC 2131 and RFC 2132. DHCPv6 is currently a "Proposed Standard" and is documented in RFC 3315. Subsequent RFCs document additional options and other enhancements to the specifications. The DHC WG is responsible for reviewing DHCP options or other extensions (for both IPv4 and IPv6). The DHC WG is expected to review all proposed extensions to DHCP to ensure that they are consistent with the DHCP specification and other option formats, that they do not duplicate existing mechanisms, etc. Generally speaking, the DHC WG will not be responsible for evaluating the semantic content of proposed options. Similarly, the ownership of specifications typically belongs the relevant working group that needs more functionality from DHCP, not the DHC WG. The DHC WG coordinates reviews of the proposed options together with those working groups. It is required that those working groups have consensus to take on the work and that the work is within their charter. Exceptionally, with AD agreement, this same process can also be used for Individual Submissions originating outside WGs. However, the DHC WG can in some cases develop its own options that relate to either maintenance of existing specifications or improvements in the operation of the DHCP infrastructure itself. The DHC WG has the following main objectives: * Develop extensions to the DHCP infrastructure as required to meet new applications and deployments of DHCP. The topics currently in development are: - Subnet allocation mechanisms - Virtual subnet identification option - Option for passing DNS domain information in DHCPv6 - DHCP relay agent assignment notification in DHCPv6 - Option for DHCPv6 server reply sequence numbers - Rebinding capability for DHCPv6 Reconfigure messages - Behavior of layer 2 relay agents The adoption of new items requires explicit agreement from the AD or rechartering. * Write analyses of the DHCPv4 and DHCPv6 specifications, including RFC 2131, RFC 2132, RFC 3315 and other RFCs defining additional options, which identifies ambiguities, contradictory specifications and other obstacles to development of interoperable implementations. Recommend a process for resolving identified problems and incorporating the resolutions into the DHCP specification. Secondly, advance DHCPv4 (RFC 2131 and RFC 2132) and DHCPv6 (RFC 3315) in IETF Standards Track. Thirdly, specify guidelines for creating new DHCP options, and report on the status of DHCPv4 option reclassification. * Assess the requirements for a dual-stack host to use DHCP to obtain configuration settings for both IPv4 and IPv6. Hosts that include implementations of both IPv4 and IPv6 ("dual-stack hosts") may use DHCP to obtain configuration settings (including assigned addresses) for both IPv4 and IPv6. The DHCPv4 and DHCPv6 specifications (RFC 2131, RFC 2132, RFC 3315 and subsequent RFCs) do not explicitly explain how a dual-stack host uses DHCP to obtain configuration settings for both IP stacks. The DHC WG will evaluate solutions for configuration of dual-stack hosts through DHCP and select a solution that will be developed and published by the WG. * Hold a discussion whether on-link prefix information and default router information is needed in DHCP in addition to router advertisements. Actual solutions are out of scope for the WG, however. Description of Working Group: The dhc working group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCPv4 is currently a "Draft Standard" and is documented in RFC 2131 and RFC 2132. DHCPv6 is currently a "Proposed Standard" and is documented in RFC 3315. Subsequent RFCs document additional options and other enhancements to the specifications. The DHC WG is responsible for reviewing DHCP options or other extensions (for both IPv4 and IPv6). The DHC WG is expected to review all proposed extensions to DHCP to ensure that they are consistent with the DHCP specification and other option formats, that they do not duplicate existing mechanisms, etc. Generally speaking, the DHC WG will not be responsible for evaluating the semantic content of proposed options. Similarly, the ownership of specifications typically belongs the relevant working group that needs more functionality from DHCP, not the DHC WG. The DHC WG coordinates reviews of the proposed options together with those working groups. It is required that those working groups have consensus to take on the work and that the work is within their charter. Exceptionally, with AD agreement, this same process can also be used for Individual Submissions originating outside WGs. However, the DHC WG can in some cases develop its own options that relate to either maintenance of existing specifications or improvements in the operation of the DHCP infrastructure itself. The DHC WG has the following main objectives: * Develop extensions to the DHCP infrastructure as required to meet new applications and deployments of DHCP. The topics currently in development are: - Subnet allocation mechanisms - Virtual subnet identification option - Option for passing DNS domain information in DHCPv6 - DHCP relay agent assignment notification in DHCPv6 - Option for DHCPv6 server reply sequence numbers - Rebinding capability for DHCPv6 Reconfigure messages - Behavior of layer 2 relay agents The adoption of new items requires explicit agreement from the AD or rechartering. * Write analyses of the DHCPv4 and DHCPv6 specifications, including RFC 2131, RFC 2132, RFC 3315 and other RFCs defining additional options, which identifies ambiguities, contradictory specifications and other obstacles to development of interoperable implementations. Recommend a process for resolving identified problems and incorporating the resolutions into the DHCP specification. Secondly, advance DHCPv4 (RFC 2131 and RFC 2132) and DHCPv6 (RFC 3315) in IETF Standards Track. Thirdly, specify guidelines for creating new DHCP options, and report on the status of DHCPv4 option reclassification. * Assess the requirements for a dual-stack host to use DHCP to obtain configuration settings for both IPv4 and IPv6. Hosts that include implementations of both IPv4 and IPv6 ("dual-stack hosts") may use DHCP to obtain configuration settings (including assigned addresses) for both IPv4 and IPv6. The DHCPv4 and DHCPv6 specifications (RFC 2131, RFC 2132, RFC 3315 and subsequent RFCs) do not explicitly explain how a dual-stack host uses DHCP to obtain configuration settings for both IP stacks. The DHC WG will evaluate solutions for configuration of dual-stack hosts through DHCP and select a solution that will be developed and published by the WG. * Hold a discussion whether on-link prefix information and default router information is needed in DHCP in addition to router advertisements. Actual solutions are out of scope for the WG, however. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2001 Sep 2009 Virtual Subnet Selection Options for DHCPv4 and DHCPv6 Feb 2003 Nov 2009 Subnet Allocation Option Jan 2006 Jul 2009 DHCPv6 Relay Agent Assignment Notification (RAAN) Option Aug 2006 Nov 2009 Rebind Capability in DHCPv6 Reconfigure Messages Jan 2008 Mar 2009 Container Option for Server Configuration Jun 2008 Jul 2009 The DHCPv4 Relay Agent Identifier Suboption Aug 2008 Oct 2009 DHCPv6 option for network boot Oct 2008 Oct 2009 DHCPv4 Leasequery by relay agent remote ID Jan 2009 Aug 2009 DHCPv6 Vendor-specific Message Jan 2009 Aug 2009 DHCPv4 Vendor-specific Message Feb 2009 Oct 2009 Bulk DHCPv4 Lease Query Jun 2009 Jun 2009 Forcerenew Nonce Authentication Jul 2009 Oct 2009 Lightweight DHCPv6 Relay Agent Diameter Maintenance and Extensions (dime) ------------------------------------------ Charter Last Modified: 2009-07-07 Current Status: Active Working Group Chair(s): Hannes Tschofenig Victor Fajardo Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion:dime@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dime Archive: http://www.ietf.org/mail-archive/web/dime/current/maillist.html Description of Working Group: The Diameter Maintenance and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use for authentication, authorization, accounting and provisioning in network access as well as for other applications environments (e.g., IP telephony, mobility). The IETF has completed work on the Diameter Base protocol and is working on revising the base protocol specification. There is on-going work on defining RADIUS extensions and the DIME WG will ensure that work done in RADEXT is also available for Diameter. The DIME working group plains to address the following items: - Maintaining and/or progressing, along the standards track, the Diameter Base protocol and Diameter Applications. This includes extensions to Diameter Base protocol that can be considered as enhanced features or bug fixes, such NAI routing or capability update extensions. - Diameter application design guideline. This document will provide guidelines for design of Diameter extensions. It will detail when to consider reusing an existing application and when to develop a new application. - Diameter QoS extensions. This work focuses on extensions to Diameter to support QoS information to be authorized and provisioned in AAA deployments. - Protocol extensions for the management of Diameter entities. This work focuses on the standardization of Management Information Bases (MIBs) to configure Diameter entities (such as the Diameter Base protocol or Diameter Credit Control nodes). The usage of other management protocols for configuring Diameter entities may be future work within the group. - Diameter extensions for mobility protocols, such as Mobile IPv6 and Proxy Mobile IPv6. Diameter extensions to support handover keying developed in the HOKEY WG are part of this effort. - New Diameter applications, such as the Diameter NAT control application. This group will also conduct work on new Diameter applications with a Diameter application for configuring NATs as the first item. Additionally, AAA systems require interoperability in order to work. The working group, along with the AD, will need to evaluate any potential extensions and require verification that the proposed extension is needed. Coordination with other IETF working groups and other SDOs will used to ensure this. Description of Working Group: The Diameter Maintenance and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use for authentication, authorization, accounting and provisioning in network access as well as for other applications environments (e.g., IP telephony, mobility). The IETF has completed work on the Diameter Base protocol and is working on revising the base protocol specification. There is on-going work on defining RADIUS extensions and the DIME WG will ensure that work done in RADEXT is also available for Diameter. The DIME working group plains to address the following items: - Maintaining and/or progressing, along the standards track, the Diameter Base protocol and Diameter Applications. This includes extensions to Diameter Base protocol that can be considered as enhanced features or bug fixes, such NAI routing or capability update extensions. - Diameter application design guideline. This document will provide guidelines for design of Diameter extensions. It will detail when to consider reusing an existing application and when to develop a new application. - Diameter QoS extensions. This work focuses on extensions to Diameter to support QoS information to be authorized and provisioned in AAA deployments. - Protocol extensions for the management of Diameter entities. This work focuses on the standardization of Management Information Bases (MIBs) to configure Diameter entities (such as the Diameter Base protocol or Diameter Credit Control nodes). The usage of other management protocols for configuring Diameter entities may be future work within the group. - Diameter extensions for mobility protocols, such as Mobile IPv6 and Proxy Mobile IPv6. Diameter extensions to support handover keying developed in the HOKEY WG are part of this effort. - New Diameter applications, such as the Diameter NAT control application. This group will also conduct work on new Diameter applications with a Diameter application for configuring NATs as the first item. Additionally, AAA systems require interoperability in order to work. The working group, along with the AD, will need to evaluate any potential extensions and require verification that the proposed extension is needed. Coordination with other IETF working groups and other SDOs will used to ensure this. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Mar 2006 Apr 2009 The Diameter API Jun 2006 Apr 2009 Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction Dec 2006 Sep 2009 Diameter Base Protocol Feb 2007 Oct 2009 Diameter Quality of Service Application May 2007 Jul 2009 Diameter Applications Design Guidelines Jul 2007 Oct 2009 Quality of Service Attributes for Diameter Jan 2009 Oct 2009 Diameter User-Name and Realm Based Request Routing Clarifications Jan 2009 Sep 2009 Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server Jan 2009 Oct 2009 Diameter Support for EAP Re-authentication Protocol (ERP) May 2009 Jul 2009 Diameter Credit Control Application MIB May 2009 Nov 2009 Diameter Base Protocol MIB Jun 2009 Jul 2009 Updated IANA Considerations for Diameter Command Code Allocations Jul 2009 Oct 2009 Realm-Based Redirection In Diameter Jul 2009 Jul 2009 The Diameter Capabilities Update Application Aug 2009 Oct 2009 Diameter NAT Control Application Dispatch (dispatch) ------------------- Charter Last Modified: 2009-04-20 Current Status: Active Working Group Chair(s): Gonzalo Camarillo Mary Barnes Real-time Applications and Infrastructure Area Director(s): Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Cullen Jennings Secretary(ies): Oscar Novo Mailing Lists: General Discussion:dispatch@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dispatch Archive: http://www.ietf.org/mail-archive/web/dispatch/ Description of Working Group: The Dispatch working group is chartered to consider proposals for new work in the RAI area and identify, or help create, an appropriate venue for the work. Options for handling new work include: - Directing the work to an existing WG. - Developing a proposal for a BOF. - Developing a charter and establishing consensus for a new WG or Exploratory Group. This option will primarily be used with fairly mature and well-defined efforts. - Rejecting and deferring work. A major objective of the DISPATCH WG is to provide timely, clear dispositions of new efforts. Where there is consensus to take on new work, the WG will strive to quickly find a home for it. Reconsideration of proposals which have failed to gather consensus will be prioritized behind proposals for new work which have not yet been considered. In general, requests for reconsideration should only be made once a proposal has been significantly revised. Guiding principles will include: 1. Providing a clear problem statement for proposed new work. 2. Prioritizing new efforts so that RAI does not take on more work than it can effectively complete. 3. Looking for commonalities among ongoing development efforts. Such commonalities may indicate the need to develop more general, reusable components. 4. Protecting the architectural integrity of RAI protocols and ensuring that work has general applicability. If the group decides that a particular topic needs to be addressed by a new or existing WG, the normal IETF chartering process will be followed, including, for instance, IETF-wide review of the proposed changes. Proposal for large work efforts SHOULD lead to a BOF where the topic can be discussed in front of the entire IETF community. Prior experience in RAI, particularly in SIPPING, indicates that the activities described here are significantly hindered when trying to complete the identified protocol work items in the same venue. The DISPATCH working group will not direct protocol work to itself. Description of Working Group: The Dispatch working group is chartered to consider proposals for new work in the RAI area and identify, or help create, an appropriate venue for the work. Options for handling new work include: - Directing the work to an existing WG. - Developing a proposal for a BOF. - Developing a charter and establishing consensus for a new WG or Exploratory Group. This option will primarily be used with fairly mature and well-defined efforts. - Rejecting and deferring work. A major objective of the DISPATCH WG is to provide timely, clear dispositions of new efforts. Where there is consensus to take on new work, the WG will strive to quickly find a home for it. Reconsideration of proposals which have failed to gather consensus will be prioritized behind proposals for new work which have not yet been considered. In general, requests for reconsideration should only be made once a proposal has been significantly revised. Guiding principles will include: 1. Providing a clear problem statement for proposed new work. 2. Prioritizing new efforts so that RAI does not take on more work than it can effectively complete. 3. Looking for commonalities among ongoing development efforts. Such commonalities may indicate the need to develop more general, reusable components. 4. Protecting the architectural integrity of RAI protocols and ensuring that work has general applicability. If the group decides that a particular topic needs to be addressed by a new or existing WG, the normal IETF chartering process will be followed, including, for instance, IETF-wide review of the proposed changes. Proposal for large work efforts SHOULD lead to a BOF where the topic can be discussed in front of the entire IETF community. Prior experience in RAI, particularly in SIPPING, indicates that the activities described here are significantly hindered when trying to complete the identified protocol work items in the same venue. The DISPATCH working group will not direct protocol work to itself. Internet-Drafts: No Current Internet-Drafts. Domain Keys Identified Mail (dkim) ---------------------------------- Charter Last Modified: 2008-08-21 Current Status: Active Working Group Chair(s): Stephen Farrell Barry Leiba Security Area Director(s): Tim Polk Pasi Eronen Security Area Advisor: Pasi Eronen Mailing Lists: General Discussion:ietf-dkim@mipassoc.org To Subscribe: http://mipassoc.org/mailman/listinfo/ietf-dkim Archive: http://mipassoc.org/pipermail/ietf-dkim/ Description of Working Group: The Internet mail protocols and infrastructure allow mail sent from one domain to purport to be from another. While there are sometimes legitimate reasons for doing this, it has become a source of general confusion, as well as a mechanism for fraud and for distribution of spam (when done illegitimately, it's called "spoofing"). The DKIM working group will produce standards-track specifications that allow a domain to take responsibility, using digital signatures, for having taken part in the transmission of an email message and to publish "policy" information about how it applies those signatures. Taken together, these will assist receiving domains in detecting (or ruling out) certain forms of spoofing as it pertains to the signing domain. The DKIM working group will produce a summary of the threats that are addressed by the proposed standards-track specifications, while acknowledging their limitations and scope. The DKIM working group will also produce security requirements to guide their efforts, and will analyze the impact on senders and receivers who are not using DKIM, particularly any cases in which mail may be inappropriately labeled as suspicious or spoofed. While the techniques specified by the DKIM working group will not prevent fraud or spam, they will provide a tool for defense against them by assisting receiving domains in detecting some spoofing of known domains. The standards-track specifications will not mandate any particular action by the receiving domain when a signature fails to validate. That said, with the understanding that guidance is necessary for implementers, the DKIM documents should discuss a reasonable set of possible actions and strategies, and analyze their likely effects on attacks and on normal email delivery. The DKIM working group will not attempt to establish requirements for trust relationships between domains nor to specify reputation or accreditation systems. The DKIM working group will consider mailing-list behaviour that is currently deemed acceptable, will make every effort to allow such mailing lists to continue to operate in a DKIM environment, and will provide a plan for smooth transition of mailing lists that fail to operate. The specifications will also advise mailing lists on how to take advantage of DKIM if they should choose to do so. The signatures will use public-key cryptography and will be based on domain name identifiers. Public keys needed to validate the signatures will be stored in the responsible identity's DNS hierarchy. The specifications will be based on the following Internet Drafts: * draft-fenton-dkim-threats * draft-allman-dkim-base * draft-allman-dkim-ssp These documents represent experimentation and consensus from a number of designers and early implementors. Experimentation has resulted in Internet deployment of these specifications. Although not encouraged, non-backwards-compatible changes to these specifications will be acceptable if the DKIM working group determines that the changes are required to meet the group's technical objectives. The resulting protocols must meet typical criteria for success. In addition to security, these include usability, scalability, ease of deployment, and cryptographic algorithm independence. To prevent this task from becoming unwieldy, several related topics are considered out of scope for the DKIM working group. These topics include: * Reputation and accreditation systems. While we expect these to add value to what is defined by the DKIM working group, their development will be separate, and is out of scope for the DKIM working group. * Message content encryption. * Additional key management protocols or infrastructure. * Signatures that are intended to make long-term assertions beyond the expected transit time of a message from originator to recipient, which is normally only a matter of a few days at most. * Signatures that attempt to make strong assertions about the identity of the message author, and details of user-level signing of messages (as distinguished from domain-level keys that are restricted to specific users). * Duplication of prior work in signed email, including S/MIME and OpenPGP. Once the primary goals are met, the DKIM working group may also study whether to adopt a work item for specifying a common mechanism to communicate the results of message verification to the message recipient. The generation of a standards-track specification on this topic will require an update to the DKIM working group charter. The deliverables for the DKIM working group are these: * An informational RFC presenting a detailed threat analysis of, and security requirements for, DKIM. IESG approval of this document is a prerequisite for the submission of the standards-track specifications. * A standards-track specification for DKIM signature and verification. * A standards-track specification for DKIM policy handling. * A standards-track specification for DKIM DNS Resource Record(s). * An informational RFC providing an overview of DKIM and how it can fit into overall messaging systems, how it relates to other IETF message signature technologies, implementation and migration considerations, and outlining potential DKIM applications and future extensions. Description of Working Group: The Internet mail protocols and infrastructure allow mail sent from one domain to purport to be from another. While there are sometimes legitimate reasons for doing this, it has become a source of general confusion, as well as a mechanism for fraud and for distribution of spam (when done illegitimately, it's called "spoofing"). The DKIM working group will produce standards-track specifications that allow a domain to take responsibility, using digital signatures, for having taken part in the transmission of an email message and to publish "policy" information about how it applies those signatures. Taken together, these will assist receiving domains in detecting (or ruling out) certain forms of spoofing as it pertains to the signing domain. The DKIM working group will produce a summary of the threats that are addressed by the proposed standards-track specifications, while acknowledging their limitations and scope. The DKIM working group will also produce security requirements to guide their efforts, and will analyze the impact on senders and receivers who are not using DKIM, particularly any cases in which mail may be inappropriately labeled as suspicious or spoofed. While the techniques specified by the DKIM working group will not prevent fraud or spam, they will provide a tool for defense against them by assisting receiving domains in detecting some spoofing of known domains. The standards-track specifications will not mandate any particular action by the receiving domain when a signature fails to validate. That said, with the understanding that guidance is necessary for implementers, the DKIM documents should discuss a reasonable set of possible actions and strategies, and analyze their likely effects on attacks and on normal email delivery. The DKIM working group will not attempt to establish requirements for trust relationships between domains nor to specify reputation or accreditation systems. The DKIM working group will consider mailing-list behaviour that is currently deemed acceptable, will make every effort to allow such mailing lists to continue to operate in a DKIM environment, and will provide a plan for smooth transition of mailing lists that fail to operate. The specifications will also advise mailing lists on how to take advantage of DKIM if they should choose to do so. The signatures will use public-key cryptography and will be based on domain name identifiers. Public keys needed to validate the signatures will be stored in the responsible identity's DNS hierarchy. The specifications will be based on the following Internet Drafts: * draft-fenton-dkim-threats * draft-allman-dkim-base * draft-allman-dkim-ssp These documents represent experimentation and consensus from a number of designers and early implementors. Experimentation has resulted in Internet deployment of these specifications. Although not encouraged, non-backwards-compatible changes to these specifications will be acceptable if the DKIM working group determines that the changes are required to meet the group's technical objectives. The resulting protocols must meet typical criteria for success. In addition to security, these include usability, scalability, ease of deployment, and cryptographic algorithm independence. To prevent this task from becoming unwieldy, several related topics are considered out of scope for the DKIM working group. These topics include: * Reputation and accreditation systems. While we expect these to add value to what is defined by the DKIM working group, their development will be separate, and is out of scope for the DKIM working group. * Message content encryption. * Additional key management protocols or infrastructure. * Signatures that are intended to make long-term assertions beyond the expected transit time of a message from originator to recipient, which is normally only a matter of a few days at most. * Signatures that attempt to make strong assertions about the identity of the message author, and details of user-level signing of messages (as distinguished from domain-level keys that are restricted to specific users). * Duplication of prior work in signed email, including S/MIME and OpenPGP. Once the primary goals are met, the DKIM working group may also study whether to adopt a work item for specifying a common mechanism to communicate the results of message verification to the message recipient. The generation of a standards-track specification on this topic will require an update to the DKIM working group charter. The deliverables for the DKIM working group are these: * An informational RFC presenting a detailed threat analysis of, and security requirements for, DKIM. IESG approval of this document is a prerequisite for the submission of the standards-track specifications. * A standards-track specification for DKIM signature and verification. * A standards-track specification for DKIM policy handling. * A standards-track specification for DKIM DNS Resource Record(s). * An informational RFC providing an overview of DKIM and how it can fit into overall messaging systems, how it relates to other IETF message signature technologies, implementation and migration considerations, and outlining potential DKIM applications and future extensions. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Nov 2007 Oct 2009 DomainKeys Identified Mail (DKIM) Development, Deployment and Operations DNS Extensions (dnsext) ----------------------- Charter Last Modified: 2009-09-16 Current Status: Active Working Group Chair(s): Olafur Gudmundsson Andrew Sullivan Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion:namedroppers@ops.ietf.org To Subscribe: namedroppers-request@ops.ietf.org Archive: http://ops.ietf.org/lists/namedroppers/ Description of Working Group: The DNS has a large installed base and repertoire of protocol specifications. The DNSEXT WG group will actively advance DNS protocol-related RFCs on the standards track while thoroughly reviewing further proposed extensions. The scope of the DNSEXT WG is confined to the DNS protocol, particularly changes that affect DNS protocols "on the wire" or the internal processing of DNS data. DNS operations are out of scope for the WG. The WG will limit itself to review of proposals for new extensions and clarification to the DNS protocol, including DNSSEC. Adoption of new work targeted for standards track will require changes to this charter. The working group can nevertheless undertake work in following subjects without a charter change: DNSSEC and TSIG/TKEY algorithm maintenance Hardening DNS protocol and providing guidance to implementors Advancing existing Proposed Standard RFCs to Draft/Full Standard Obsoleting RFCs. Maintaining a Wiki containing a guide to DNS protocol RFC's. Improving DNS zone synchronization mechanisms Examining transport protocols, possibly adding new ones. Before formal adoption of any such items at least 5 working group participants must publicly state that the item is within charter and is worthwhile item for further study. The DNSEXT WG will conduct the specified RFC5395 review of RR templates as they are posted, and EDNS0 Option templates if EDNS0-bis updates registration requirements. The WG will review DNS protocol related work which may originate elsewhere in the IETF, including AD-sponsored submissions or drafts in other working group. The WG does not intend to hold face to face meetings, though may do so if deemed necessary for resolution of a specific issue at hand. Description of Working Group: The DNS has a large installed base and repertoire of protocol specifications. The DNSEXT WG group will actively advance DNS protocol-related RFCs on the standards track while thoroughly reviewing further proposed extensions. The scope of the DNSEXT WG is confined to the DNS protocol, particularly changes that affect DNS protocols "on the wire" or the internal processing of DNS data. DNS operations are out of scope for the WG. The WG will limit itself to review of proposals for new extensions and clarification to the DNS protocol, including DNSSEC. Adoption of new work targeted for standards track will require changes to this charter. The working group can nevertheless undertake work in following subjects without a charter change: DNSSEC and TSIG/TKEY algorithm maintenance Hardening DNS protocol and providing guidance to implementors Advancing existing Proposed Standard RFCs to Draft/Full Standard Obsoleting RFCs. Maintaining a Wiki containing a guide to DNS protocol RFC's. Improving DNS zone synchronization mechanisms Examining transport protocols, possibly adding new ones. Before formal adoption of any such items at least 5 working group participants must publicly state that the item is within charter and is worthwhile item for further study. The DNSEXT WG will conduct the specified RFC5395 review of RR templates as they are posted, and EDNS0 Option templates if EDNS0-bis updates registration requirements. The WG will review DNS protocol related work which may originate elsewhere in the IETF, including AD-sponsored submissions or drafts in other working group. The WG does not intend to hold face to face meetings, though may do so if deemed necessary for resolution of a specific issue at hand. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- May 2005 Sep 2009 Clarifications and Implementation Notes for DNSSECbis Sep 2006 Nov 2009 Update to DNAME Redirection in the DNS Dec 2007 Jul 2009 Extension Mechanisms for DNS (EDNS0) Sep 2009 Sep 2009 Cryptographic Algorithm Identifier Allocation for DNSSEC Sep 2009 Nov 2009 Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records for DNSSEC Sep 2009 Sep 2009 Handling of Unknown DNS Resource Record (RR) Types Oct 2009 Oct 2009 DNS Transport over TCP Oct 2009 Nov 2009 DNS Security (DNSSEC) DNSKEY IANA Registry Algorithm Status Addition Domain Name System Operations (dnsop) ------------------------------------- Charter Last Modified: 2008-12-16 Current Status: Active Working Group Chair(s): Peter Koch Rob Austein Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Ronald Bonica Mailing Lists: General Discussion:dnsop@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/dnsop Archive: http://www.ietf.org/mail-archive/web/dnsop Description of Working Group: The DNS Operations Working Group will develop guidelines for the operation of DNS software servers and the administration of DNS zone files. These guidelines will provide technical information relating to the implementation of the DNS protocol by the operators and administrators of DNS zones. The group will perform the following activities: 1. Define the processes by which Domain Name System (DNS) software may be efficiently and correctly administered, configured, and operated on Internet networks. This will include root zone name servers, gTLD name servers, name servers for other DNS zones, iterative DNS resolvers, and recursive DNS resolvers. As part of this effort, the group will produce documents explaining to the general Internet community what processes and mechanisms should be employed for the effective management and operation of DNS software. 2. Publish documents concerning DNSSEC operational procedures. 3. Publish documents concerning the IPv6 DNS operational procedures and DNS-related IPv6 transition and coexistence issues. 4. Publish documents concerning the operations of the root and TLD services, and DNS resolvers. Description of Working Group: The DNS Operations Working Group will develop guidelines for the operation of DNS software servers and the administration of DNS zone files. These guidelines will provide technical information relating to the implementation of the DNS protocol by the operators and administrators of DNS zones. The group will perform the following activities: 1. Define the processes by which Domain Name System (DNS) software may be efficiently and correctly administered, configured, and operated on Internet networks. This will include root zone name servers, gTLD name servers, name servers for other DNS zones, iterative DNS resolvers, and recursive DNS resolvers. As part of this effort, the group will produce documents explaining to the general Internet community what processes and mechanisms should be employed for the effective management and operation of DNS software. 2. Publish documents concerning DNSSEC operational procedures. 3. Publish documents concerning the IPv6 DNS operational procedures and DNS-related IPv6 transition and coexistence issues. 4. Publish documents concerning the operations of the root and TLD services, and DNS resolvers. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jun 2006 Nov 2009 Locally-served DNS Zones Feb 2007 Oct 2009 I'm Being Attacked by PRISONER.IANA.ORG! Feb 2007 Oct 2009 AS112 Nameserver Operations Jul 2007 Oct 2009 Initializing a DNS Resolver with Priming Queries Data for Reachability of Inter/tra-NetworK SIP (drinks) ------------------------------------------------------- Charter Last Modified: 2009-03-30 Current Status: Active Working Group Chair(s): Richard Shockey Alexander Mayrhofer Debbie Guyton Real-time Applications and Infrastructure Area Director(s): Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Cullen Jennings Mailing Lists: General Discussion:drinks@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/drinks Archive: http://www.ietf.org/mail-archive/web/drinks/current/maillist.html Description of Working Group: The IETF has been working on various aspects of SIP-enabled Multimedia administrative domains among SIP Service Providers (SSP's). SSP's are entities that provide session services utilizing SIP signaling to their customers. In addition, the IETF has done significant work on data exchanges among various network elements. The DRINKS working group is chartered with a scope that is orthogonal to SPEERMINT and ENUM. The protocol work of DRINKS will be designed to build from the work of SPEERMINT and ENUM to identify and define the data structures and data exchange protocol(s) among SIP based Multimedia administrative domains. The ENUM working group is specifically chartered to develop protocols that involve the translation of E.164 numbers to URIs. While the SPEERMINT working group has been chartered to develop requirements and best current practices among real-time application SSPs and to describe how such services may best interconnect across administrative boundaries. These administrative domains may be of any practical size and could be any type of SSP, such as recognized telephony carriers, enterprises, end-user groups, or Federations. Data exchanges among these administrative domains may be bi-lateral or multi-lateral in nature, and could include bulk updates and/or more granular real-time updates. Administrative domains may exchange data through the use of an external registry to aggregate data from multiple administrative domains or multiple data providers into a single view. The DRINKS WG will provide details of how Session Establishment Data (SED) is collected, what comprises SED, how SED should be used to properly identify an optimal path to a destination SIP user agent (UA),either internally or externally to the SSP. In addition DRINKS will insure that the SED and the SIP session data is securely exchanged between the peering functions. Typical SED data might include: + Routes - Destination SIP/SIPS/TEL URI Egress and Ingress Routes - Relevant route names, identifiers, and services - Attributes affecting route selection - PSTN database information + Targets - Individual, ranges, or groups of user-agent identifiers - Target aggregation entities (e.g. service areas) and target-to-aggregate associations + Treatment Profiles - Priority - Location Potential SED Data types not in scope will be session rating or other billing or pricing information between SSP's The working group will draw upon expert advice and on-going consultation from the ENUM and SPEERMINT working groups, and also the XML Directorate. The working group will consider the reuse of elements of RFC 4114. The final work product(s) from this working group will utilize and be based on XML documents and XML document exchanges. Description of Working Group: The IETF has been working on various aspects of SIP-enabled Multimedia administrative domains among SIP Service Providers (SSP's). SSP's are entities that provide session services utilizing SIP signaling to their customers. In addition, the IETF has done significant work on data exchanges among various network elements. The DRINKS working group is chartered with a scope that is orthogonal to SPEERMINT and ENUM. The protocol work of DRINKS will be designed to build from the work of SPEERMINT and ENUM to identify and define the data structures and data exchange protocol(s) among SIP based Multimedia administrative domains. The ENUM working group is specifically chartered to develop protocols that involve the translation of E.164 numbers to URIs. While the SPEERMINT working group has been chartered to develop requirements and best current practices among real-time application SSPs and to describe how such services may best interconnect across administrative boundaries. These administrative domains may be of any practical size and could be any type of SSP, such as recognized telephony carriers, enterprises, end-user groups, or Federations. Data exchanges among these administrative domains may be bi-lateral or multi-lateral in nature, and could include bulk updates and/or more granular real-time updates. Administrative domains may exchange data through the use of an external registry to aggregate data from multiple administrative domains or multiple data providers into a single view. The DRINKS WG will provide details of how Session Establishment Data (SED) is collected, what comprises SED, how SED should be used to properly identify an optimal path to a destination SIP user agent (UA),either internally or externally to the SSP. In addition DRINKS will insure that the SED and the SIP session data is securely exchanged between the peering functions. Typical SED data might include: + Routes - Destination SIP/SIPS/TEL URI Egress and Ingress Routes - Relevant route names, identifiers, and services - Attributes affecting route selection - PSTN database information + Targets - Individual, ranges, or groups of user-agent identifiers - Target aggregation entities (e.g. service areas) and target-to-aggregate associations + Treatment Profiles - Priority - Location Potential SED Data types not in scope will be session rating or other billing or pricing information between SSP's The working group will draw upon expert advice and on-going consultation from the ENUM and SPEERMINT working groups, and also the XML Directorate. The working group will consider the reuse of elements of RFC 4114. The final work product(s) from this working group will utilize and be based on XML documents and XML document exchanges. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- May 2009 May 2009 DRINKS Use cases and Protocol Requirements Email Address Internationalization (eai) ---------------------------------------- Charter Last Modified: 2009-04-03 Current Status: Active Working Group Chair(s): Harald Alvestrand XiaoDong Lee Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Alexey Melnikov Mailing Lists: General Discussion:ima@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ima Archive: http://www.ietf.org/mail-archive/web/ima Description of Working Group: Since early in the effort to internationalize domain names, which resulted in the standards associated with IDNA, it has been understood that internationalization of email address local parts is required. At the same time, email address internationalization poses a series of special problems. Constraints on the interpretation of local-parts by any system other than the final delivery one make address encoding nearly impossible. The need to use addresses in both the email envelope and in header fields, and to do so in ways that are at least compatible, suggests that this is not a simple and isolated problem. This working group will address one basic approach to email internationalization. That approach is based on the use of an SMTP extension to enable both the use of UTF-8 in envelope address local- parts and optionally in domain-parts and the use of UTF-8 in mail headers -- both in address contexts and wherever encoded-words are permitted today. Its initial target will be a set of experimental RFCs that specify the details of this approach and provide the basis for generating and testing interoperable implementations. Its work will include examining whether "downgrading" -- transforming an internationalized message to one that is compatible with unextended SMTP clients and servers and unextended MUAs -- is feasible and appropriate and, if it is, specifying a way to do so. If it is not, the WG will evaluate whether the effort is worth taking forward. Other approaches may be considered by the formation of other working groups. Key parts of this effort include extended analyses and, if necessary, proof of concept in three areas in addition to smooth operation when all systems and components along a message path have been upgraded to support the new facilities. They are o Examination of scenarios for the appearance of these facilities to users, including ways in which alternate addresses may be specified if those are needed for downgrading. o Examination of different locations at which downgrading might be required and accomplished, differentiating between requirements and capabilities at the point of origin (at or before the submission server), those that exist while the message is in transit, and those that apply after SMTP "final delivery" or in the logical vicinity or an IMAP or POP server. o Examination of the "mailing list question", i.e., how a mixture of traditional and internationalized addresses on a mailing list will impact message flows, error reports, and delivery notifications in all plausible combinations of servers and addresses, including internationalizated and traditional reverse paths. Once the Experimental RFCs are completed and implemented, the experience gathered will be evaluated. If the approach is found to have been successful (using criteria the WG will establish as an early work item), the WG will be rechartered to update the documents for processing onto the standards track. 1.6. Deliverables The following deliverables are foreseen in this charter. The WG chairs may structure the deliverables into specific documents or document sets as needed. Adding or removing documents outside of these deliverables will require a charter update. o Overview and architecture (Info) o Interworking scenarios, including the "mailing list question" (Info) o SMTP extensions specification (Exp) o Header format specification (Exp) o Downgrading specification in SMTP (Exp) o Downgrading specification in POP servers (Exp) o Downgrading specification in IMAP servers (Exp) o Results and evaluation of experiment (Info) Going forward, it is possible that the SMTP downgrading specification will go for Informational due to the difficulty of fully specifying all necessary behavior. Additional possible documents suggested: Advice for MUA implementors (Info) Description of Working Group: Since early in the effort to internationalize domain names, which resulted in the standards associated with IDNA, it has been understood that internationalization of email address local parts is required. At the same time, email address internationalization poses a series of special problems. Constraints on the interpretation of local-parts by any system other than the final delivery one make address encoding nearly impossible. The need to use addresses in both the email envelope and in header fields, and to do so in ways that are at least compatible, suggests that this is not a simple and isolated problem. This working group will address one basic approach to email internationalization. That approach is based on the use of an SMTP extension to enable both the use of UTF-8 in envelope address local- parts and optionally in domain-parts and the use of UTF-8 in mail headers -- both in address contexts and wherever encoded-words are permitted today. Its initial target will be a set of experimental RFCs that specify the details of this approach and provide the basis for generating and testing interoperable implementations. Its work will include examining whether "downgrading" -- transforming an internationalized message to one that is compatible with unextended SMTP clients and servers and unextended MUAs -- is feasible and appropriate and, if it is, specifying a way to do so. If it is not, the WG will evaluate whether the effort is worth taking forward. Other approaches may be considered by the formation of other working groups. Key parts of this effort include extended analyses and, if necessary, proof of concept in three areas in addition to smooth operation when all systems and components along a message path have been upgraded to support the new facilities. They are o Examination of scenarios for the appearance of these facilities to users, including ways in which alternate addresses may be specified if those are needed for downgrading. o Examination of different locations at which downgrading might be required and accomplished, differentiating between requirements and capabilities at the point of origin (at or before the submission server), those that exist while the message is in transit, and those that apply after SMTP "final delivery" or in the logical vicinity or an IMAP or POP server. o Examination of the "mailing list question", i.e., how a mixture of traditional and internationalized addresses on a mailing list will impact message flows, error reports, and delivery notifications in all plausible combinations of servers and addresses, including internationalizated and traditional reverse paths. Once the Experimental RFCs are completed and implemented, the experience gathered will be evaluated. If the approach is found to have been successful (using criteria the WG will establish as an early work item), the WG will be rechartered to update the documents for processing onto the standards track. 1.6. Deliverables The following deliverables are foreseen in this charter. The WG chairs may structure the deliverables into specific documents or document sets as needed. Adding or removing documents outside of these deliverables will require a charter update. o Overview and architecture (Info) o Interworking scenarios, including the "mailing list question" (Info) o SMTP extensions specification (Exp) o Header format specification (Exp) o Downgrading specification in SMTP (Exp) o Downgrading specification in POP servers (Exp) o Downgrading specification in IMAP servers (Exp) o Results and evaluation of experiment (Info) Going forward, it is possible that the SMTP downgrading specification will go for Informational due to the difficulty of fully specifying all necessary behavior. Additional possible documents suggested: Advice for MUA implementors (Info) Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- May 2006 Sep 2009 IMAP Support for UTF-8 Jun 2006 Oct 2009 POP3 Support for UTF-8 Oct 2008 Sep 2009 Displaying Downgraded Messages for Email Address Internationalization Dec 2008 Jul 2009 Internationalized Delivery Status and Disposition Notifications Jul 2009 Jul 2009 Guidelines for Internationalized Email Clients Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- Charter Last Modified: 2009-09-30 Current Status: Active Working Group Chair(s): Hannes Tschofenig Marc Linsner Real-time Applications and Infrastructure Area Director(s): Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Cullen Jennings Secretary(ies): Roger Marshall Mailing Lists: General Discussion:ecrit@ietf.org To Subscribe: https://www.ietf.org/mailman//listinfo/ecrit Archive: http://www.ietf.org/mail-archive/web/ecrit/current/maillist.html Description of Working Group: In a number of areas, the public switched telephone network (PSTN) has been configured to recognize an explicitly specified number (commonly one that is short and easily memorized) as a call for emergency services. These numbers (e.g. 911, 112) relate to an emergency service context and depend on a broad, regional configuration of service contact methods and a geographically-constrained context of service delivery. These calls are intended to be delivered to special call centers equipped to manage emergency response. Successful delivery of an emergency service call within those systems requires both an association of the physical location of the originator with an appropriate emergency service center and call routing to deliver the call to the center. Calls placed using Internet technologies do not use the same systems to achieve those goals, and the common use of overlay networks and tunnels (either as VPNs or for mobility) makes meeting them more challenging. There are, however, Internet technologies available to describe location and to manage call routing. This working group will describe when these may be appropriate and how they may be used. Explicitly outside the scope of this group is the question of pre-emption or prioritization of emergency services traffic. This group is considering emergency services calls which might be made by any user of the Internet, as opposed to government or military services that may impose very different authentication and routing requirements. The group will show how the availability of location data and call routing information at different steps in session setup would enable communication between a user and a relevant emergency response center. Though the term "call routing" is used in this document, it should be understood that some of the mechanisms which will be described might be used to enable other types of media streams. Video and text messaging, for example, might be used to request emergency services. While this group anticipates a close working relationship with groups such as NENA and ETSI EMTEL, any solution presented must be useful regardless of jurisdiction, and it must be possible to use without a single, central authority. Further, it must be possible for multiple delegations within a jurisdiction to be handled independently, as call routing for specific emergency types may be independent. This working group cares about privacy and security concerns, and will address them within its documents. Description of Working Group: In a number of areas, the public switched telephone network (PSTN) has been configured to recognize an explicitly specified number (commonly one that is short and easily memorized) as a call for emergency services. These numbers (e.g. 911, 112) relate to an emergency service context and depend on a broad, regional configuration of service contact methods and a geographically-constrained context of service delivery. These calls are intended to be delivered to special call centers equipped to manage emergency response. Successful delivery of an emergency service call within those systems requires both an association of the physical location of the originator with an appropriate emergency service center and call routing to deliver the call to the center. Calls placed using Internet technologies do not use the same systems to achieve those goals, and the common use of overlay networks and tunnels (either as VPNs or for mobility) makes meeting them more challenging. There are, however, Internet technologies available to describe location and to manage call routing. This working group will describe when these may be appropriate and how they may be used. Explicitly outside the scope of this group is the question of pre-emption or prioritization of emergency services traffic. This group is considering emergency services calls which might be made by any user of the Internet, as opposed to government or military services that may impose very different authentication and routing requirements. The group will show how the availability of location data and call routing information at different steps in session setup would enable communication between a user and a relevant emergency response center. Though the term "call routing" is used in this document, it should be understood that some of the mechanisms which will be described might be used to enable other types of media streams. Video and text messaging, for example, might be used to request emergency services. While this group anticipates a close working relationship with groups such as NENA and ETSI EMTEL, any solution presented must be useful regardless of jurisdiction, and it must be possible to use without a single, central authority. Further, it must be possible for multiple delegations within a jurisdiction to be handled independently, as call routing for specific emergency types may be independent. This working group cares about privacy and security concerns, and will address them within its documents. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2006 Jul 2009 Best Current Practice for Communications Services in support of Emergency Calling Oct 2006 Jul 2009 Framework for Emergency Calling using Internet Multimedia Jun 2008 Jul 2009 Location Hiding: Problem Statement and Requirements Jun 2008 Oct 2008 Specifying Holes in LoST Service Boundaries Jul 2008 Oct 2009 Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements Oct 2009 Nov 2009 Location-to-Service Translation Protocol (LoST) Extension: ServiceListBoundary Oct 2009 Oct 2009 Using Imprecise Location for Emergency Context Resolution EAP Method Update (emu) ----------------------- Charter Last Modified: 2009-02-11 Current Status: Active Working Group Chair(s): Joseph Salowey Alan DeKok Alan DeKok Security Area Director(s): Tim Polk Pasi Eronen Security Area Advisor: Pasi Eronen Mailing Lists: General Discussion:emu@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/emu Archive: http://www.ietf.org/mail-archive/web/emu/current/maillist.html Description of Working Group: The Extensible Authentication Protocol (EAP) [RFC 3748] is a network access authentication framework used in the PPP, 802.11, 802.16, VPN, PANA, and in some functions in 3G networks. EAP itself is a simple protocol and actual authentication happens in EAP methods. Over 40 different EAP methods exist. Most of these methods are proprietary methods, but some are documented in informational RFCs. In the past the lack of documented, open specifications has been a deployment and interoperability problem. There are currently only two EAP methods in the standards track that implement features such as key derivation that are required for many modern applications. Authentication types and credentials continue to evolve as do requirements for EAP methods. This group is chartered to work on the following types of mechanisms to meet requirements relevant to EAP methods in RFC 3748, RFC 4017, RFC 4962 and EAP Keying: - A mechanism based on strong shared secrets. This mechanism should strive to be simple and compact for implementation in resource constrained environments. - A document that defines EAP channel bindings and provides guidance for establishing EAP channel bindings within EAP methods. - Enable TLS-based EAP methods to support channel bindings. This item will not generate a new method; rather, it will focus on adding support for EAP channel bindings to the tunneled method (described below), and if possible, other TLS-based EAP methods. Potential mechanisms for adding channel binding support will be investigated, including tunneling of channel binding parameters, or a TLS extension, or other standard TLS mechanism - A mechanism to support extensible communication within a TLS protected tunnel. This mechanism will support meeting the requirements of an enhanced TLS mechanism, a password based authentication mechanism, and additional inner authentication mechanisms. It will also support channel bindings (as described above) in order to meet RFC 4962 requirements. - A mechanism that makes use of existing password databases such as AAA databases. This item will be based on the above tunnel method. Description of Working Group: The Extensible Authentication Protocol (EAP) [RFC 3748] is a network access authentication framework used in the PPP, 802.11, 802.16, VPN, PANA, and in some functions in 3G networks. EAP itself is a simple protocol and actual authentication happens in EAP methods. Over 40 different EAP methods exist. Most of these methods are proprietary methods, but some are documented in informational RFCs. In the past the lack of documented, open specifications has been a deployment and interoperability problem. There are currently only two EAP methods in the standards track that implement features such as key derivation that are required for many modern applications. Authentication types and credentials continue to evolve as do requirements for EAP methods. This group is chartered to work on the following types of mechanisms to meet requirements relevant to EAP methods in RFC 3748, RFC 4017, RFC 4962 and EAP Keying: - A mechanism based on strong shared secrets. This mechanism should strive to be simple and compact for implementation in resource constrained environments. - A document that defines EAP channel bindings and provides guidance for establishing EAP channel bindings within EAP methods. - Enable TLS-based EAP methods to support channel bindings. This item will not generate a new method; rather, it will focus on adding support for EAP channel bindings to the tunneled method (described below), and if possible, other TLS-based EAP methods. Potential mechanisms for adding channel binding support will be investigated, including tunneling of channel binding parameters, or a TLS extension, or other standard TLS mechanism - A mechanism to support extensible communication within a TLS protected tunnel. This mechanism will support meeting the requirements of an enhanced TLS mechanism, a password based authentication mechanism, and additional inner authentication mechanisms. It will also support channel bindings (as described above) in order to meet RFC 4962 requirements. - A mechanism that makes use of existing password databases such as AAA databases. This item will be based on the above tunnel method. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jun 2008 Oct 2009 Requirements for a Tunnel Based EAP Method Dec 2008 Oct 2009 Channel Binding Support for EAP Methods Telephone Number Mapping (enum) ------------------------------- Charter Last Modified: 2009-03-30 Current Status: Active Working Group Chair(s): Richard Shockey Patrik Faltstrom Real-time Applications and Infrastructure Area Director(s): Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Cullen Jennings Secretary(ies): Alexander Mayrhofer Mailing Lists: General Discussion:enum@ietf.org To Subscribe: enum-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/enum/index.html Description of Working Group: The ENUM working group has defined a DNS-based architecture and protocol [RFC 3761] by which an E.164 number, as defined in ITU Recommendation E.164, can be expressed as a Fully Qualified Domain Name in a specific Internet Infrastructure domain defined for this purpose (e164.arpa). Background: E.164 numbers are globally unique, language independent identifiers for resources on Public Telecommunication Networks that can support many different services and protocols. There is an emerging desire for network operators to utilize aspects of RFC 3761 to discover points of interconnection necessary to terminate communications sessions identified by a E164 number,in addition to identifying end point protocols and services. Working Group Revised Goals and Scope: 1. The working group will update RFC 3761 and advance to Draft Standard. 2. The working group will examine and document the use of RFC 3761 to facilitate network interconnection for services using E.164 addressing. The working group will coordinate its activities with other IETF working groups, existing or to be chartered, that are investigating elements of peering and or interconnection for VoIP or other services that typically use E.164 addressing. 3. The working group will continue examine and document various aspects of ENUM administrative and /or operational procedures irrespective of whether e164.arpa domain is used. 4. The working group will also examine the use of RFC 3761 technology for storing and delivering other information about services addressed by E.164 numbers, for example PSTN call routing and signaling data. 5. The Working Group will continue to maintain appropriate contact and liaison with other standards bodies and groups, specifically ITU-T SG2, to provide technical or educational information and address, as needed, issues related to the use of the E.164 numbering plan for services on IP networks. In addition the Working Group will continue to encourage the exchange of technical information within the emerging global ENUM community as well as documentation on practical experiences with implementations, alternate technology uses and the administration and provisioning of RFC 3761. 6. As described in RFC 3761, the IETF documents and registers the Enumservices. While extant, it is the ENUM working group that performs the technical review and development of the Enumservices for the Internet community. The working group determines whether to advance them and how to progress them technically. Coordination with other WGs will be taken into account on these. Other than Enumservices, all proposed deliverables of the working group will be discussed with and approved by the Area Directors, who may require wider review due to the broad impact of the subject. Description of Working Group: The ENUM working group has defined a DNS-based architecture and protocol [RFC 3761] by which an E.164 number, as defined in ITU Recommendation E.164, can be expressed as a Fully Qualified Domain Name in a specific Internet Infrastructure domain defined for this purpose (e164.arpa). Background: E.164 numbers are globally unique, language independent identifiers for resources on Public Telecommunication Networks that can support many different services and protocols. There is an emerging desire for network operators to utilize aspects of RFC 3761 to discover points of interconnection necessary to terminate communications sessions identified by a E164 number,in addition to identifying end point protocols and services. Working Group Revised Goals and Scope: 1. The working group will update RFC 3761 and advance to Draft Standard. 2. The working group will examine and document the use of RFC 3761 to facilitate network interconnection for services using E.164 addressing. The working group will coordinate its activities with other IETF working groups, existing or to be chartered, that are investigating elements of peering and or interconnection for VoIP or other services that typically use E.164 addressing. 3. The working group will continue examine and document various aspects of ENUM administrative and /or operational procedures irrespective of whether e164.arpa domain is used. 4. The working group will also examine the use of RFC 3761 technology for storing and delivering other information about services addressed by E.164 numbers, for example PSTN call routing and signaling data. 5. The Working Group will continue to maintain appropriate contact and liaison with other standards bodies and groups, specifically ITU-T SG2, to provide technical or educational information and address, as needed, issues related to the use of the E.164 numbering plan for services on IP networks. In addition the Working Group will continue to encourage the exchange of technical information within the emerging global ENUM community as well as documentation on practical experiences with implementations, alternate technology uses and the administration and provisioning of RFC 3761. 6. As described in RFC 3761, the IETF documents and registers the Enumservices. While extant, it is the ENUM working group that performs the technical review and development of the Enumservices for the Internet community. The working group determines whether to advance them and how to progress them technically. Coordination with other WGs will be taken into account on these. Other than Enumservices, all proposed deliverables of the working group will be discussed with and approved by the Area Directors, who may require wider review due to the broad impact of the subject. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2006 Feb 2009 IANA Registration for IAX Enumservice Feb 2006 Sep 2009 IANA Registration of Enumservices: Guide, Template and IANA Considerations Apr 2006 Sep 2008 IANA Registration for an Enumservice Calling Name Delivery (CNAM) Information and IANA Registration for URI type 'pstndata' Sep 2006 Sep 2006 ENUM Requirement for EDNS0 Support Oct 2006 May 2009 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) Jan 2007 Mar 2008 IANA Registration for Enumservice UNUSED Feb 2009 Oct 2009 Update of legacy IANA Registrations of Enumservices FEC Framework (fecframe) ------------------------ Charter Last Modified: 2009-11-09 Current Status: Active Working Group Chair(s): Greg Shepherd Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Magnus Westerlund Mailing Lists: General Discussion:fecframe@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/fecframe Archive: http://www.ietf.org/mail-archive/web/fecframe Description of Working Group: The object of this group is to develop specifications for using forward error correction (FEC) codes with applications in the Internet to provide protection against packet loss. The group will develop a protocol framework for application of FEC codes to arbitrary packet flows over unreliable transport protocols over both IP multicast and unicast. The application of the FEC codec on an aggregate of multiple packet flows may be investigated and considered to be included in the solution. The FECFrame working group will use the building block approach (RFC 3269), especially the FEC Building Block (RFC 3452), developed by the RMT working group. The FEC Building Block was developed to ensure that the RMT framework developed can support multiple FEC codes and maintain independence between FEC codes and protocols based on the framework. The FECFrame WG may develop new FEC schemes if necessary to provide substantial performance gains for the intended applications. However the acceptance of any FEC scheme will require multiple, prior, detailed reviews of the FEC code by independent experts from both the IETF and the broader community, since it is likely that the IETF working group will not include a large enough number of suitable experts in its working set. If these reviews are positive, then Working Group acceptance of an FEC scheme work item still needs the approval of the responsible Area Director. A primary objective of this framework is to support FEC for real-time media applications using RTP over UDP, such as on demand streaming and audio/video broadcast. Other potential usages of the framework may be brought to the working group for consideration during the development of the requirements, to enable future support of those usages. The group will coordinate closely with the AVT and MMUSIC working groups to ensure that the streaming use-case is fully specified both in terms of interactions with RTP/RTCP and application layer signalling. The group will also coordinate with the DCCP working group, at least to consider that transport protocol's role in streaming media. The interactions of the framework with existing and used security mechanisms must also be considered. The group will work with the RMT working group to ensure that the FEC Building Block defined in RMT supports both the RMT use-cases (object delivery over multicast) and the more general FEC protection of flow(s) over unreliable unicast and multicast transport. Specification of hybrid schemes involving both retransmission and forward error correction is out of scope of the group. Description of Working Group: The object of this group is to develop specifications for using forward error correction (FEC) codes with applications in the Internet to provide protection against packet loss. The group will develop a protocol framework for application of FEC codes to arbitrary packet flows over unreliable transport protocols over both IP multicast and unicast. The application of the FEC codec on an aggregate of multiple packet flows may be investigated and considered to be included in the solution. The FECFrame working group will use the building block approach (RFC 3269), especially the FEC Building Block (RFC 3452), developed by the RMT working group. The FEC Building Block was developed to ensure that the RMT framework developed can support multiple FEC codes and maintain independence between FEC codes and protocols based on the framework. The FECFrame WG may develop new FEC schemes if necessary to provide substantial performance gains for the intended applications. However the acceptance of any FEC scheme will require multiple, prior, detailed reviews of the FEC code by independent experts from both the IETF and the broader community, since it is likely that the IETF working group will not include a large enough number of suitable experts in its working set. If these reviews are positive, then Working Group acceptance of an FEC scheme work item still needs the approval of the responsible Area Director. A primary objective of this framework is to support FEC for real-time media applications using RTP over UDP, such as on demand streaming and audio/video broadcast. Other potential usages of the framework may be brought to the working group for consideration during the development of the requirements, to enable future support of those usages. The group will coordinate closely with the AVT and MMUSIC working groups to ensure that the streaming use-case is fully specified both in terms of interactions with RTP/RTCP and application layer signalling. The group will also coordinate with the DCCP working group, at least to consider that transport protocol's role in streaming media. The interactions of the framework with existing and used security mechanisms must also be considered. The group will work with the RMT working group to ensure that the FEC Building Block defined in RMT supports both the RMT use-cases (object delivery over multicast) and the more general FEC protection of flow(s) over unreliable unicast and multicast transport. Specification of hybrid schemes involving both retransmission and forward error correction is out of scope of the group. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2007 Jul 2009 Forward Error Correction (FEC) Framework Feb 2008 Aug 2009 SDP Elements for FEC Framework Aug 2008 May 2009 RTP Payload Format for 1-D Interleaved Parity FEC Aug 2008 Sep 2009 DVB-IPTV Application-Layer Hybrid FEC Protection Oct 2008 Jul 2009 Raptor FEC Schemes for FECFRAME Oct 2008 May 2009 RTP Payload Format for Non-Interleaved and Interleaved Parity FEC Mar 2009 Oct 2009 RTP Payload Format for Raptor FEC Forwarding and Control Element Separation (forces) -------------------------------------------------- Charter Last Modified: 2008-11-17 Current Status: Active Working Group Chair(s): Patrick Droz Jamal Hadi Salim Routing Area Director(s): Ross Callon Adrian Farrel Routing Area Advisor: Ross Callon Mailing Lists: General Discussion:forces@peach.ease.lsoft.com To Subscribe: listserv@peach.ease.lsoft.com In Body: (un)subscribe forces Archive: http://www.ietf.org/mail-archive/web/forces/ Description of Working Group: The emergence of off-the-shelf network processor devices that implement the fast path or forwarding plane in network devices such as routers, along with the appearance of a new generation of third party signaling, routing, and other router control plane software, has created the need for standard mechanisms to allow these components to be combined into functional wholes. ForCES aims to define a framework and associated mechanisms for standardizing the exchange of information between the logically separate functionality of the control plane, including entities such as routing protocols, admission control, and signaling, and the forwarding plane, where per-packet activities such as packet forwarding, queuing, and header editing occur. By defining a set of standard mechanisms for control and forwarding separation, ForCES will enable rapid innovation in both the control and forwarding planes. A standard separation mechanism allows the control and forwarding planes to innovate in parallel while maintaining interoperability. The products of this working group will be: o A set of requirements for mechanisms to logically separate the control and data forwarding planes of an IP network element (NE) o An applicability statement for the ForCES model and protocol o Informational RFCs as necessary documenting current approaches to the functional model and controlled objects therein o An architectural framework defining the entities comprising a ForCES network element and identifying the interactions between them. o A description of the functional model of a Forwarding Element o A formal definition of the controlled objects in the functional model of a forwarding element. This includes IP forwarding, IntServ and DiffServ QoS. An existing specification language shall be used for this task. o Specification of IP-based protocol for transport of the controlled objects. When the control and forwarding devices are separated beyond a single hop, ForCES will make use of an existing RFC2914 compliant L4 protocol with adequate reliability, security and congestion control (e.g. TCP, SCTP) for transport purposes. The main focus area of the working group will be control and forwarding separation for IP forwarding devices where the control and forwarding elements are in close (same room/small number of hops) or very close (same box/one hop) proximity. Other scenarios will be considered but at not the main focus of the work. The functional model of the forwarding element will include QoS (DiffServ and IntServ) capabilities of modern networking devices such as routers. In order to minimize the effort to integrate forwarding elements and control elements, a mechanism for auto discovery and capability information exchange will form an integral part of the standardized interface. ForCES will coordinate with other standards bodies and working groups as appropriate. Examples of such bodies include IETF/GSMP, IETF/Megaco, the Network Processing Forum (NPF), the Multiservice Switching Forum (MSF), IEEE P1520, and SoftSwitch. ForCES will review relevant protocol efforts such as GSMP and Megaco and will extend or reuse them if appropriate. If protocol reuse is accepted as satisfactory for fulfilling the ForCES requirements then ForCES may recharter to adopt specific deliverables around the selected protocol. Description of Working Group: The emergence of off-the-shelf network processor devices that implement the fast path or forwarding plane in network devices such as routers, along with the appearance of a new generation of third party signaling, routing, and other router control plane software, has created the need for standard mechanisms to allow these components to be combined into functional wholes. ForCES aims to define a framework and associated mechanisms for standardizing the exchange of information between the logically separate functionality of the control plane, including entities such as routing protocols, admission control, and signaling, and the forwarding plane, where per-packet activities such as packet forwarding, queuing, and header editing occur. By defining a set of standard mechanisms for control and forwarding separation, ForCES will enable rapid innovation in both the control and forwarding planes. A standard separation mechanism allows the control and forwarding planes to innovate in parallel while maintaining interoperability. The products of this working group will be: o A set of requirements for mechanisms to logically separate the control and data forwarding planes of an IP network element (NE) o An applicability statement for the ForCES model and protocol o Informational RFCs as necessary documenting current approaches to the functional model and controlled objects therein o An architectural framework defining the entities comprising a ForCES network element and identifying the interactions between them. o A description of the functional model of a Forwarding Element o A formal definition of the controlled objects in the functional model of a forwarding element. This includes IP forwarding, IntServ and DiffServ QoS. An existing specification language shall be used for this task. o Specification of IP-based protocol for transport of the controlled objects. When the control and forwarding devices are separated beyond a single hop, ForCES will make use of an existing RFC2914 compliant L4 protocol with adequate reliability, security and congestion control (e.g. TCP, SCTP) for transport purposes. The main focus area of the working group will be control and forwarding separation for IP forwarding devices where the control and forwarding elements are in close (same room/small number of hops) or very close (same box/one hop) proximity. Other scenarios will be considered but at not the main focus of the work. The functional model of the forwarding element will include QoS (DiffServ and IntServ) capabilities of modern networking devices such as routers. In order to minimize the effort to integrate forwarding elements and control elements, a mechanism for auto discovery and capability information exchange will form an integral part of the standardized interface. ForCES will coordinate with other standards bodies and working groups as appropriate. Examples of such bodies include IETF/GSMP, IETF/Megaco, the Network Processing Forum (NPF), the Multiservice Switching Forum (MSF), IEEE P1520, and SoftSwitch. ForCES will review relevant protocol efforts such as GSMP and Megaco and will extend or reuse them if appropriate. If protocol reuse is accepted as satisfactory for fulfilling the ForCES requirements then ForCES may recharter to adopt specific deliverables around the selected protocol. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jun 2002 Oct 2009 ForCES Applicability Statement Aug 2003 Oct 2008 ForCES Forwarding Element Model Sep 2004 Mar 2009 ForCES Protocol Specification Jan 2006 Sep 2008 ForCES MIB Nov 2007 Sep 2009 SCTP based TML (Transport Mapping Layer) for ForCES protocol Mar 2009 Sep 2009 ForCES Interoperability Draft Jun 2009 Jun 2009 ForCES LFB Library Sep 2009 Sep 2009 Implementation Report for ForCES Oct 2009 Oct 2009 ForCES Implementation Experience Draft Geographic Location/Privacy (geopriv) ------------------------------------- Charter Last Modified: 2009-11-17 Current Status: Active Working Group Chair(s): Richard Barnes Alissa Cooper Real-time Applications and Infrastructure Area Director(s): Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Cullen Jennings Technical Advisor(s): Lisa Dusseault Mailing Lists: General Discussion:geopriv@ietf.org To Subscribe: geopriv-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/geopriv/index.html Description of Working Group: The IETF has recognized that many applications are emerging that require geographic and civic location information about resources and entities, and that the representation and transmission of that information has significant privacy and security implications. We have created a suite of protocols that allow such applications to represent and transmit such location objects and to allow users to express policies on how these representations are exposed and used. The IETF has also begun working on creating applications that use these capabilities, for emergency services, general real-time communication, and other usages. The GEOPRIV working group is chartered to continue to develop and refine representations of location in Internet protocols, and to analyze the authorization, integrity, and privacy requirements that must be met when these representations of location are created, stored, and used. The group will create and refine mechanisms for the transmission of these representations that address the requirements that have been identified. The working group will work with other IETF working groups and other standards development organizations that are building applications that use location information to ensure that the requirements are well understood and met, and that no additional security or privacy issues related to location are left unaddressed as these location information is incorporated into other protocols. It remains a goal of the GEOPRIV working group to deliver specifications of broad applicability that will become mandatory to implement for IETF protocols that are location aware. This working group will not develop location-determining technology. However, the IETF acknowledges that information used in the location- determination process will in some cases need to be carried over the Internet. Where necessary, this working group will develop protocols or protocol extensions to encode location-determination data structures defined elsewhere. This working group will not develop technologies to directly address any particular regulatory requirements (e.g. 9-1-1). The group will continue to coordinate with any other IETF entities that are working on those problems to ensure the technologies created here meet the needs of those entities, and that the authorization, integrity, and privacy requirements on the mechanisms provided by these technologies continue to be met. Description of Working Group: The IETF has recognized that many applications are emerging that require geographic and civic location information about resources and entities, and that the representation and transmission of that information has significant privacy and security implications. We have created a suite of protocols that allow such applications to represent and transmit such location objects and to allow users to express policies on how these representations are exposed and used. The IETF has also begun working on creating applications that use these capabilities, for emergency services, general real-time communication, and other usages. The GEOPRIV working group is chartered to continue to develop and refine representations of location in Internet protocols, and to analyze the authorization, integrity, and privacy requirements that must be met when these representations of location are created, stored, and used. The group will create and refine mechanisms for the transmission of these representations that address the requirements that have been identified. The working group will work with other IETF working groups and other standards development organizations that are building applications that use location information to ensure that the requirements are well understood and met, and that no additional security or privacy issues related to location are left unaddressed as these location information is incorporated into other protocols. It remains a goal of the GEOPRIV working group to deliver specifications of broad applicability that will become mandatory to implement for IETF protocols that are location aware. This working group will not develop location-determining technology. However, the IETF acknowledges that information used in the location- determination process will in some cases need to be carried over the Internet. Where necessary, this working group will develop protocols or protocol extensions to encode location-determination data structures defined elsewhere. This working group will not develop technologies to directly address any particular regulatory requirements (e.g. 9-1-1). The group will continue to coordinate with any other IETF entities that are working on those problems to ensure the technologies created here meet the needs of those entities, and that the authorization, integrity, and privacy requirements on the mechanisms provided by these technologies continue to be met. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Nov 2003 Jul 2009 Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information Mar 2006 Nov 2009 Filtering Location Notifications in the Session Initiation Protocol (SIP) Jan 2007 Jul 2009 GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements Jun 2007 Aug 2009 HTTP Enabled Location Delivery (HELD) Sep 2007 Nov 2009 Requirements for a Location-by-Reference Mechanism Dec 2007 Nov 2009 Discovering the Local Location Information Server (LIS) Feb 2008 Sep 2009 Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI) Oct 2008 Jul 2009 Considerations for Civic Addresses in PIDF-LO - Guidelines and IANA Registry Definition Jun 2009 Nov 2009 A Uniform Resource Identifier for Geographic Locations ('geo' URI) Jun 2009 Nov 2009 Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information Jul 2009 Oct 2009 An Architecture for Location and Location Privacy in Internet Applications Sep 2009 Oct 2009 Use of Device Identity in HTTP-Enabled Location Delivery (HELD) Global Routing Operations (grow) -------------------------------- Charter Last Modified: 2008-12-16 Current Status: Active Working Group Chair(s): Peter Schoenmaker Christopher Morrow Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Ronald Bonica Technical Advisor(s): Bill Fenner Vijay Gill Mailing Lists: General Discussion:grow@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/grow Archive: http://www.ietf.org/mail-archive/web/grow Description of Working Group: The Border Gateway Protocol (BGP) is fundamental to the operation of the Internet. In recent years, occurrences of BGP related operational issues have increased, and while overall understanding of the default-free routing system has improved, there is still a long and growing list of concerns. Among these are routing table growth rates, interaction of interior and exterior routing protocols, dynamic properties of the routing system, and the effects of routing policy on both the size and dynamic nature of the routing table. In addition, new and innovative uses of BGP, such as the use of BGP as a signaling protocol for some types of Virtual Private Networks, have created new and unexpected operational issues. The purpose of the GROW is to consider the operational problems associated with the IPv4 and IPv6 global routing systems, including but not limited to routing table growth, the effects of the interactions between interior and exterior routing protocols, and the effect of address allocation policies and practices on the global routing system. Finally, where appropriate, the GROW documents the operational aspects of measurement, policy, security, and VPN infrastructures. GROW will also advise various working groups, including the IDR and RPSEC working groups, with respect to whether it is addressing the relevant operational needs, and where appropriate, suggest course corrections. Finally, operational requirements developed in GROW can also be used by any new working group charged with standardizing a next generation inter-domain routing protocol. GOALS: ----- (i). Evaluate and develop various methodologies of controlling policy information in order to reduce the effect of prefix sub-aggregates beyond the necessary diameter, so as to reduce the Network Layer Reachability Information (or NLRI; see e.g.,draft-ietf-idr-bgp4-23.txt) load on network infrastructure. (ii). Document and suggest operational solutions to problematic aspects of the currently deployed routing system. Examples include instability caused by oscillation of MULTI_EXIT_DISC (or MED; see RFC 3345) values. (iii). Analyze aspects of supporting new applications, including extending existing routing protocols and creating new ones. This includes risk, interference and application fit. (iv). Determine the effect of IGP extensions on the stability of the Internet routing system. (v). Document the operational aspects of securing the Internet routing system, and provide recommendations to other WGs. Some Relevant References: ------------------------- http://www.routeviews.org http://bgp.potaroo.net http://www.cidr-report.org http://www.pch.net/routing/BGP_table_size.ital http://moat.nlanr.net/AS http://www.apnic.net/stats/bgp http://www.merit.edu/ipma http://www.caida.org/projects/routing/atoms Description of Working Group: The Border Gateway Protocol (BGP) is fundamental to the operation of the Internet. In recent years, occurrences of BGP related operational issues have increased, and while overall understanding of the default-free routing system has improved, there is still a long and growing list of concerns. Among these are routing table growth rates, interaction of interior and exterior routing protocols, dynamic properties of the routing system, and the effects of routing policy on both the size and dynamic nature of the routing table. In addition, new and innovative uses of BGP, such as the use of BGP as a signaling protocol for some types of Virtual Private Networks, have created new and unexpected operational issues. The purpose of the GROW is to consider the operational problems associated with the IPv4 and IPv6 global routing systems, including but not limited to routing table growth, the effects of the interactions between interior and exterior routing protocols, and the effect of address allocation policies and practices on the global routing system. Finally, where appropriate, the GROW documents the operational aspects of measurement, policy, security, and VPN infrastructures. GROW will also advise various working groups, including the IDR and RPSEC working groups, with respect to whether it is addressing the relevant operational needs, and where appropriate, suggest course corrections. Finally, operational requirements developed in GROW can also be used by any new working group charged with standardizing a next generation inter-domain routing protocol. GOALS: ----- (i). Evaluate and develop various methodologies of controlling policy information in order to reduce the effect of prefix sub-aggregates beyond the necessary diameter, so as to reduce the Network Layer Reachability Information (or NLRI; see e.g.,draft-ietf-idr-bgp4-23.txt) load on network infrastructure. (ii). Document and suggest operational solutions to problematic aspects of the currently deployed routing system. Examples include instability caused by oscillation of MULTI_EXIT_DISC (or MED; see RFC 3345) values. (iii). Analyze aspects of supporting new applications, including extending existing routing protocols and creating new ones. This includes risk, interference and application fit. (iv). Determine the effect of IGP extensions on the stability of the Internet routing system. (v). Document the operational aspects of securing the Internet routing system, and provide recommendations to other WGs. Some Relevant References: ------------------------- http://www.routeviews.org http://bgp.potaroo.net http://www.cidr-report.org http://www.pch.net/routing/BGP_table_size.ital http://moat.nlanr.net/AS http://www.apnic.net/stats/bgp http://www.merit.edu/ipma http://www.caida.org/projects/routing/atoms Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2005 Jul 2009 MRT routing information export format Nov 2008 Jul 2009 BGP Monitoring Protocol May 2009 May 2009 MPLS Tunnels for Virtual Aggregation May 2009 Oct 2009 FIB Suppression with Virtual Aggregation Jun 2009 Oct 2009 Requirements for the graceful shutdown of BGP sessions Jun 2009 Oct 2009 Graceful BGP session shutdown Jul 2009 Jul 2009 GRE and IP-in-IP Tunnels for Virtual Aggregation Aug 2009 Jul 2009 Performance of Virtual Aggregation Sep 2009 Sep 2009 Proposal to use an inner MPLS label to identify the remote ASBR VA Oct 2009 Oct 2009 Proposal for Auto-Configuration in Virtual Aggregation Host Identity Protocol (hip) ---------------------------- Charter Last Modified: 2009-04-13 Current Status: Active Working Group Chair(s): David Ward Gonzalo Camarillo Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion:hipsec@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/hipsec Archive: http://www.ietf.org/mail-archive/web/hipsec/current/maillist.html Description of Working Group: The Host Identity Protocol (HIP) provides a method of separating the end-point identifier and locator roles of IP addresses. It introduces a new Host Identity (HI) name space, based on public keys. The public keys are typically, but not necessarily, self generated. The specifications for the architecture and protocol details for these mechanisms consist of: HIP Architecture (RFC 4423) Host Identity Protocol (RFC 5201) There are several publicly known interoperating implementations, some of which are open source. Currently, the HIP base protocol works well with any pair of co-operating end-hosts. However, to be more useful and more widely deployable, HIP needs some support from the existing infrastructure, including the DNS, and a new piece of infrastructure, called the HIP rendezvous server. +-------------------------------------------------------+ | The purpose of this Working Group is to define the | | minimal infrastructure elements that are needed for | | HIP experimentation on a wide scale. | +-------------------------------------------------------+ At this point, the missing elements for running such wide-scale experiments are a NAT traversal solution, a description on the interactions between legacy (i.e., HIP unaware) applications and HIP, and a native API for HIP. Additionally, the working group will specify, also in Experimental RFCs, how to build HIP-based overlays. HIP-based overlays have received a lot of attention in different fora and are seen as a key area for HIP experimentation where the benefits HIP brings may be most relevant. Note that even though the specifications are chartered for Experimental, it is understood that their quality and security properties should match the standards track requirements. The main purpose for producing Experimental documents instead of standards track ones are the unknown effects that the mechanisms may have on applications and on the Internet at large. In parallel to this working group, there is an IRTF Research Group with a broader scope that includes efforts both on developing the more forward looking aspects of the HIP architecture and on exploring the effects that HIP may have on the applications and the Internet. The following are charter items for the working group: o Specify how legacy (i.e., HIP unaware) applications can be made to work with HIP. o Specify a solution for HIP to traverse legacy (i.e., HIP unaware) NATs. This solution will be based on existing NAT traversal mechanisms such as ICE (Interactive Connectivity Establishment). o Specify a native HIP socket API. o Specify a framework to build HIP-based overlays. This framework will describe how HIP can perform some of the tasks needed to build an overlay and how technologies developed somewhere else (e.g., a peer protocol developed in the P2PSIP WG) can complement HIP by performing the tasks HIP was not designed to perform. o Specify how to generate ORCHIDs from other node identifiers including both cryptographic ones (leading to cryptographic delegation) and non-cryptographic ones (e.g., identifiers defined by a peer protocol). o Specify how to carry certificates in the base exchange. This was removed from the base HIP spec so that the mechanism is specified in a stand-alone spec. o Specify how to carry upper-layer data over specified HIP packets. These include some of the existing HIP packets and possibly new HIP packets (e.g., a HIP packet that occurs outside a HIP base exchange). Description of Working Group: The Host Identity Protocol (HIP) provides a method of separating the end-point identifier and locator roles of IP addresses. It introduces a new Host Identity (HI) name space, based on public keys. The public keys are typically, but not necessarily, self generated. The specifications for the architecture and protocol details for these mechanisms consist of: HIP Architecture (RFC 4423) Host Identity Protocol (RFC 5201) There are several publicly known interoperating implementations, some of which are open source. Currently, the HIP base protocol works well with any pair of co-operating end-hosts. However, to be more useful and more widely deployable, HIP needs some support from the existing infrastructure, including the DNS, and a new piece of infrastructure, called the HIP rendezvous server. +-------------------------------------------------------+ | The purpose of this Working Group is to define the | | minimal infrastructure elements that are needed for | | HIP experimentation on a wide scale. | +-------------------------------------------------------+ At this point, the missing elements for running such wide-scale experiments are a NAT traversal solution, a description on the interactions between legacy (i.e., HIP unaware) applications and HIP, and a native API for HIP. Additionally, the working group will specify, also in Experimental RFCs, how to build HIP-based overlays. HIP-based overlays have received a lot of attention in different fora and are seen as a key area for HIP experimentation where the benefits HIP brings may be most relevant. Note that even though the specifications are chartered for Experimental, it is understood that their quality and security properties should match the standards track requirements. The main purpose for producing Experimental documents instead of standards track ones are the unknown effects that the mechanisms may have on applications and on the Internet at large. In parallel to this working group, there is an IRTF Research Group with a broader scope that includes efforts both on developing the more forward looking aspects of the HIP architecture and on exploring the effects that HIP may have on the applications and the Internet. The following are charter items for the working group: o Specify how legacy (i.e., HIP unaware) applications can be made to work with HIP. o Specify a solution for HIP to traverse legacy (i.e., HIP unaware) NATs. This solution will be based on existing NAT traversal mechanisms such as ICE (Interactive Connectivity Establishment). o Specify a native HIP socket API. o Specify a framework to build HIP-based overlays. This framework will describe how HIP can perform some of the tasks needed to build an overlay and how technologies developed somewhere else (e.g., a peer protocol developed in the P2PSIP WG) can complement HIP by performing the tasks HIP was not designed to perform. o Specify how to generate ORCHIDs from other node identifiers including both cryptographic ones (leading to cryptographic delegation) and non-cryptographic ones (e.g., identifiers defined by a peer protocol). o Specify how to carry certificates in the base exchange. This was removed from the base HIP spec so that the mechanism is specified in a stand-alone spec. o Specify how to carry upper-layer data over specified HIP packets. These include some of the existing HIP packets and possibly new HIP packets (e.g., a HIP packet that occurs outside a HIP base exchange). Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Nov 2006 Oct 2009 Basic HIP Extensions for Traversal of Network Address Translators Nov 2006 Sep 2009 Basic Socket Interface Extensions for Host Identity Protocol (HIP) Oct 2008 Oct 2009 HIP Certificates Oct 2008 Oct 2009 HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment Oct 2009 Oct 2009 HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper-layer Protocol Signaling (HICCUPS) Oct 2009 Oct 2009 Host Identity Protocol (HIP) Multi-hop Routing Extension Handover Keying (hokey) ----------------------- Charter Last Modified: 2009-07-20 Current Status: Active Working Group Chair(s): Glen Zorn Tina Tsou (Ting ZOU) Security Area Director(s): Tim Polk Pasi Eronen Security Area Advisor: Tim Polk Mailing Lists: General Discussion:hokey@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/hokey Archive: http://www.ietf.org/mail-archive/web/hokey/current/maillist.html Description of Working Group: Most deployments of EAP in wireless networks employ an authenticator in pass-through mode, usually located at the edge, coupled with a backend AAA/EAP server. Many EAP methods generate an MSK and an EMSK. The MSK is used by several EAP lower layers. The EMSK remains at the peer and server, but it is not presently used in any specifications. Different EAP lower layers make use of the MSK differently; the most common usage is to derive Transient Session Keys (TSKs) to provide access link security in networks (e.g., IEEE 802.11i, IEEE 802.16e), although some lower layers (e.g., IKEv2) use the MSK for other purposes. Extensions to current EAP key framework will be needed to facilitate inter-authenticator handover and roaming. Some problems that need to be addressed with extensions to EAP keying include: 1) Inter-authenticator handovers require re-execution of EAP authentication even though the same EAP authentication server is used. Handover scenarios vary considerably in their fundamental assumptions. In scenarios where hosts remain connected during the handover period, EAP authentication need not be in the critical path for handover. However, there are scenarios where necessary connectivity is not available to support "make before break" communications. In these scenarios, significant handover latency can result. To avoid this latency, SDOs have employed methods such as context transfer and anchoring that are inefficient or insecure or both. 2) EAP peers with unexpired keying material from a full EAP exchange must take part in a full EAP exchange with the same AAA server to extend a session. While some EAP methods provide fast re- authentication mechanisms, a consistent, EAP-method-independent, low- latency re-authentication mechanism is needed. 3) EAP generates keys (MSK and EMSK). When the EAP WG updated the protocol and specified the keying framework, many details regarding the use of the EMSK were not specified. The EMSK can be used as the root of a cryptographic key hierarchy, and then the keys in the hierarchy are used in various ways to provide the needed security services. In order to ensure that different keys derived from the EMSK are cryptographically separate and that the key derivations are coordinated in an acceptable manner, it is important to clearly specify the top of the topology for the key hierarchy and some guidelines for child key derivations. 4) When wireless networks employ AAA infrastructures, the cross-domain roaming is handled by inter-domain authentication via the "home" AAA/EAP server. Any authentication must pass through the home server, which increases latency. Latency can be reduced by establishing a trust relationship between the EAP peer and the visited domain's AAA/EAP server. This trust relationship would be brokered by the home EAP/AAA server. Efficient re-authentication for the EAP peer can be supported locally within the visited domain. Some of the inconsistency in current handoff and roaming solutions can be attributed to different trade-offs between computational cost, mobility performance, and security. Specifications are not consistent in the way that the key derivation function (KDF) and KDF parameters are used. Clear direction by the IETF on the topology and construction of a key hierarchy could reduce some of the inconsistencies. However, the HOKEY WG will not attempt to standardize TSK derivation from the MSK, as this would interference with work of other SDOs. The solutions specified by the HOKEY WG fall into several categories, based on timing and mechanism. The authentication and key management may occur before handoff, when latency is much less critical. Alternatively, authentication and key management can occur as part of the handoff, where latency is critical. Solutions should reduce or eliminate the number of referrals to AAA servers, and solutions should avoid re-executing lengthy EAP method exc hanges.This may be accomplished by providing new mechanisms for cryptographic keying material in combination with a protocol for the timely delivery of appropriate keys to the appropriate entities. Solutions are expected to include "handover keying," "low-latency re-authentication," and "pre-authentication." All solution categories are useful, each supporting different scenarios. The HOKEY WG may provide multiple solutions, each addressing a different scenario. Solutions specified by the HOKEY WG must: 1) Be responsive to handover and re-authentication latency performance objectives within a mobile wireless access network. 2) Fulfill the requirements in draft-housley-aaa-key-mgmt and draft-ietf-eap-keying. 3) Be independent of the access-technology. Any key hierarchy topology or protocol defined must be independent of EAP lower layers. The protocols may require additional support from the EAP lower layers that use it. 4) Accommodate inter-technology heterogeneous handover and roaming. 5) No changes to EAP methods. Any extensions defined to EAP must not cause changes to existing EAP methods. In specifying an access-technology-independent solution, media independent guidelines for SDOs may also be needed to explain how the keying material and signaling can be employed in a specific access technology. HOKEY WG Deliverables ===================== All the specifications will be EAP-method-independent manner and access-technology-agnostic. EAP re-authentication and EAP pre- authentication authenticator are expected to use the same layer and the same protocol as the original EAP authentication used for the authenticator. They will provide enough semantics and guidance so that all SDOs can employ them and preserve cryptographic separation. 1) A Problem Statement that defines the problem of re-authentication and key management. The discussion will include security and performance goals for the solutions. Too often, mobility optimization discussions do not clearly identify the scenarios that are being addressed; this lack of clarity often makes it difficult to agree on whether the proposed optimizations offer real value. To avoid this situation, the Problem Statement must clearly describe the scenarios that are being addressed, and the assumptions about the handover environment associated with that scenario. 2) A specification of an EMSK-based key hierarchy topology. The specification will include a requirements, one or more KDF, and parameters. This is follow-on work EAP (RFC 3748) and EAP keying framework that was developed in the EAP WG. 3) A specification for the derivation of root keys, such as the handover root key (HRK), as well as any other media-independent keys (e.g., authenticator level keys) that need to be derived from such a root key, to support re-authentication and handover key management. The HOKEY WG can base these keys on either the MSK or the EMSK produced by EAP (pick one). If the consensus is to use the EMSK, then the HRK forms one branch in the EMSK-based key hierarchy. This specification will describe the properties of each key that is specified, and the topics must include caching, naming, scope, binding, storage, and key lifetime. 4) A protocol specification for media-independent, low-latency re-authentication. The protocol specification must support handovers between EAP authenticators. This protocol specification is expected to employ a re-authentication branch in the key hierarchy. 5) A protocol specification for secure and timely distribution of cryptographic keys to support roaming and handover. Use of AAA protocols is preferred, and if used, should leverage existing work if possible (such as RADEXT WG work on RFC 3576bis and RADIUS cryptographic algorithm agility). However, if AAA protocols cannot meet the objectives, other protocols for reactive or proactive distribution or retrieval of keys by the proper entities is permitted. 6) A specification for inter-EAP-authenticator roaming and re- authentication in visited domains that is brokered using inter-domain trust relationships to support efficient inter-domain roaming. 7) A specification for EAP pre-authentication to support low-latency inter-authenticator handoffs. Description of Working Group: Most deployments of EAP in wireless networks employ an authenticator in pass-through mode, usually located at the edge, coupled with a backend AAA/EAP server. Many EAP methods generate an MSK and an EMSK. The MSK is used by several EAP lower layers. The EMSK remains at the peer and server, but it is not presently used in any specifications. Different EAP lower layers make use of the MSK differently; the most common usage is to derive Transient Session Keys (TSKs) to provide access link security in networks (e.g., IEEE 802.11i, IEEE 802.16e), although some lower layers (e.g., IKEv2) use the MSK for other purposes. Extensions to current EAP key framework will be needed to facilitate inter-authenticator handover and roaming. Some problems that need to be addressed with extensions to EAP keying include: 1) Inter-authenticator handovers require re-execution of EAP authentication even though the same EAP authentication server is used. Handover scenarios vary considerably in their fundamental assumptions. In scenarios where hosts remain connected during the handover period, EAP authentication need not be in the critical path for handover. However, there are scenarios where necessary connectivity is not available to support "make before break" communications. In these scenarios, significant handover latency can result. To avoid this latency, SDOs have employed methods such as context transfer and anchoring that are inefficient or insecure or both. 2) EAP peers with unexpired keying material from a full EAP exchange must take part in a full EAP exchange with the same AAA server to extend a session. While some EAP methods provide fast re- authentication mechanisms, a consistent, EAP-method-independent, low- latency re-authentication mechanism is needed. 3) EAP generates keys (MSK and EMSK). When the EAP WG updated the protocol and specified the keying framework, many details regarding the use of the EMSK were not specified. The EMSK can be used as the root of a cryptographic key hierarchy, and then the keys in the hierarchy are used in various ways to provide the needed security services. In order to ensure that different keys derived from the EMSK are cryptographically separate and that the key derivations are coordinated in an acceptable manner, it is important to clearly specify the top of the topology for the key hierarchy and some guidelines for child key derivations. 4) When wireless networks employ AAA infrastructures, the cross-domain roaming is handled by inter-domain authentication via the "home" AAA/EAP server. Any authentication must pass through the home server, which increases latency. Latency can be reduced by establishing a trust relationship between the EAP peer and the visited domain's AAA/EAP server. This trust relationship would be brokered by the home EAP/AAA server. Efficient re-authentication for the EAP peer can be supported locally within the visited domain. Some of the inconsistency in current handoff and roaming solutions can be attributed to different trade-offs between computational cost, mobility performance, and security. Specifications are not consistent in the way that the key derivation function (KDF) and KDF parameters are used. Clear direction by the IETF on the topology and construction of a key hierarchy could reduce some of the inconsistencies. However, the HOKEY WG will not attempt to standardize TSK derivation from the MSK, as this would interference with work of other SDOs. The solutions specified by the HOKEY WG fall into several categories, based on timing and mechanism. The authentication and key management may occur before handoff, when latency is much less critical. Alternatively, authentication and key management can occur as part of the handoff, where latency is critical. Solutions should reduce or eliminate the number of referrals to AAA servers, and solutions should avoid re-executing lengthy EAP method exc hanges.This may be accomplished by providing new mechanisms for cryptographic keying material in combination with a protocol for the timely delivery of appropriate keys to the appropriate entities. Solutions are expected to include "handover keying," "low-latency re-authentication," and "pre-authentication." All solution categories are useful, each supporting different scenarios. The HOKEY WG may provide multiple solutions, each addressing a different scenario. Solutions specified by the HOKEY WG must: 1) Be responsive to handover and re-authentication latency performance objectives within a mobile wireless access network. 2) Fulfill the requirements in draft-housley-aaa-key-mgmt and draft-ietf-eap-keying. 3) Be independent of the access-technology. Any key hierarchy topology or protocol defined must be independent of EAP lower layers. The protocols may require additional support from the EAP lower layers that use it. 4) Accommodate inter-technology heterogeneous handover and roaming. 5) No changes to EAP methods. Any extensions defined to EAP must not cause changes to existing EAP methods. In specifying an access-technology-independent solution, media independent guidelines for SDOs may also be needed to explain how the keying material and signaling can be employed in a specific access technology. HOKEY WG Deliverables ===================== All the specifications will be EAP-method-independent manner and access-technology-agnostic. EAP re-authentication and EAP pre- authentication authenticator are expected to use the same layer and the same protocol as the original EAP authentication used for the authenticator. They will provide enough semantics and guidance so that all SDOs can employ them and preserve cryptographic separation. 1) A Problem Statement that defines the problem of re-authentication and key management. The discussion will include security and performance goals for the solutions. Too often, mobility optimization discussions do not clearly identify the scenarios that are being addressed; this lack of clarity often makes it difficult to agree on whether the proposed optimizations offer real value. To avoid this situation, the Problem Statement must clearly describe the scenarios that are being addressed, and the assumptions about the handover environment associated with that scenario. 2) A specification of an EMSK-based key hierarchy topology. The specification will include a requirements, one or more KDF, and parameters. This is follow-on work EAP (RFC 3748) and EAP keying framework that was developed in the EAP WG. 3) A specification for the derivation of root keys, such as the handover root key (HRK), as well as any other media-independent keys (e.g., authenticator level keys) that need to be derived from such a root key, to support re-authentication and handover key management. The HOKEY WG can base these keys on either the MSK or the EMSK produced by EAP (pick one). If the consensus is to use the EMSK, then the HRK forms one branch in the EMSK-based key hierarchy. This specification will describe the properties of each key that is specified, and the topics must include caching, naming, scope, binding, storage, and key lifetime. 4) A protocol specification for media-independent, low-latency re-authentication. The protocol specification must support handovers between EAP authenticators. This protocol specification is expected to employ a re-authentication branch in the key hierarchy. 5) A protocol specification for secure and timely distribution of cryptographic keys to support roaming and handover. Use of AAA protocols is preferred, and if used, should leverage existing work if possible (such as RADEXT WG work on RFC 3576bis and RADIUS cryptographic algorithm agility). However, if AAA protocols cannot meet the objectives, other protocols for reactive or proactive distribution or retrieval of keys by the proper entities is permitted. 6) A specification for inter-EAP-authenticator roaming and re- authentication in visited domains that is brokered using inter-domain trust relationships to support efficient inter-domain roaming. 7) A specification for EAP pre-authentication to support low-latency inter-authenticator handoffs. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2007 Oct 2009 Distribution of EAP based keys for handover and re-authentication Sep 2007 Jul 2009 Extensible Authentication Protocol (EAP) Early Authentication Problem Statement Hypertext Transfer Protocol Bis (httpbis) ----------------------------------------- Charter Last Modified: 2008-08-21 Current Status: Active Working Group Chair(s): Mark Nottingham Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion:ietf-http-wg@w3.org To Subscribe: http://lists.w3.org/Archives/Public/ietf-http-wg/ Archive: Description of Working Group: HTTP is one of the most successful and widely-used protocols on the Internet today. However, its specification has several editorial issues. Additionally, after years of implementation and extension, several ambiguities have become evident, impairing interoperability and the ability to easily implement and use HTTP. The working group will refine RFC2616 to: * Incorporate errata and updates (e.g., references, IANA registries, ABNF) * Fix editorial problems which have led to misunderstandings of the specification * Clarify conformance requirements * Remove known ambiguities where they affect interoperability * Clarify existing methods of extensibility * Remove or deprecate those features that are not widely implemented and also unduly affect interoperability * Where necessary, add implementation advice * Document the security properties of HTTP and its associated echanisms (e.g., Basic and Digest authentication, cookies, TLS) for common applications In doing so, it should consider: * Implementer experience * Demonstrated use of HTTP * Impact on existing implementations and deployments The Working Group must not introduce a new version of HTTP and should not add new functionality to HTTP. The WG is not tasked with producing new methods, headers, or extension mechanisms, but may introduce new protocol elements if necessary as part of revising existing functionality which has proven to be problematic The Working Group's specification deliverables are: * A document that is suitable to supersede RFC 2616 * A document cataloguing the security properties of HTTP Description of Working Group: HTTP is one of the most successful and widely-used protocols on the Internet today. However, its specification has several editorial issues. Additionally, after years of implementation and extension, several ambiguities have become evident, impairing interoperability and the ability to easily implement and use HTTP. The working group will refine RFC2616 to: * Incorporate errata and updates (e.g., references, IANA registries, ABNF) * Fix editorial problems which have led to misunderstandings of the specification * Clarify conformance requirements * Remove known ambiguities where they affect interoperability * Clarify existing methods of extensibility * Remove or deprecate those features that are not widely implemented and also unduly affect interoperability * Where necessary, add implementation advice * Document the security properties of HTTP and its associated echanisms (e.g., Basic and Digest authentication, cookies, TLS) for common applications In doing so, it should consider: * Implementer experience * Demonstrated use of HTTP * Impact on existing implementations and deployments The Working Group must not introduce a new version of HTTP and should not add new functionality to HTTP. The WG is not tasked with producing new methods, headers, or extension mechanisms, but may introduce new protocol elements if necessary as part of revising existing functionality which has proven to be problematic The Working Group's specification deliverables are: * A document that is suitable to supersede RFC 2616 * A document cataloguing the security properties of HTTP Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Dec 2007 Oct 2009 HTTP/1.1, part 1: URIs, Connections, and Message Parsing Dec 2007 Oct 2009 HTTP/1.1, part 2: Message Semantics Dec 2007 Oct 2009 HTTP/1.1, part 3: Message Payload and Content Negotiation Dec 2007 Oct 2009 HTTP/1.1, part 4: Conditional Requests Dec 2007 Oct 2009 HTTP/1.1, part 5: Range Requests and Partial Responses Dec 2007 Oct 2009 HTTP/1.1, part 6: Caching Dec 2007 Oct 2009 HTTP/1.1, part 7: Authentication Aug 2008 May 2009 Initial Hypertext Transfer Protocol (HTTP) Method Registrations Internationalized Domain Names in Applications, Revised (idnabis) ----------------------------------------------------------------- Charter Last Modified: 2009-09-01 Current Status: Active Working Group Chair(s): Vinton Cerf Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion:idna-update@alvestrand.no To Subscribe: http://www.alvestrand.no/mailman/listinfo/idna-update Archive: http://www.alvestrand.no/pipermail/idna-update/ Description of Working Group: The original Internationalized Domain Name (IDN) WG specified rules for the use of characters other than Latin A(a)-Z(z), digits 0-9 and the hyphen (-) in domain names in RFC3490, RFC3491 and RFC3492 in 2002 (published in 2003 and often referenced collectively as "IDNA2003"). These documents depend on RFC 3454 and were tied to Unicode version 3.2. An update to the current version (5.x) is required to accommodate additional scripts. In addition, experience has shown that significant improvements could be made in the protocol as presently specified. This WG is chartered to decouple IDNA from specific versions of Unicode using algorithms that define validity based on Unicode properties. It is recognized that some explicit exceptions may be necessary in any case, but attempts will be made to minimize these exceptions. Additional goals: - Separate requirements for valid IDNs at registration time (insertion of names into DNS zone files), vs. at resolution time (looking up those names) - Review, and if necessary revise, the algorithms and rules for handling right to left character sequences in an IDN context to allow labels based on additional scripts and languages and to make presentation as predictable as reasonably possible. - Permit use of some scripts that were inadvertently excluded by the original protocols. - Ensure practical stability of validity algorithms for IDNs. The constraints of the original IDN WG still apply to IDNABIS, namely to avoid disturbing the current use and operation of the domain name system, and for the DNS to continue to allow any system to resolve any domain name in a consistent way. The client-based approach of the original IDN work will be maintained -- substantially new protocols or mechanisms are not in scope. In particular, IDNs continue to use the "xn--" prefix and the same ASCII-compatible encoding, and the bidirectional algorithm follows the same basic design. The specifications are initially organized as four documents: overview and rationale, protocol, table algorithm, and improvements to the bidirectional algorithm. These documents are to be used as the basis for the discussion of the general direction of the work. This working group will be providing extended public review of the output of a design team that has been working on improvement of the IDNA specifications. This review-based approach is being used in part because of the way the work was undertaken by the team; in particular, the design team has been working with IETF visibility and has solicited and received significant amounts of technical review already from IETF participants and from others including experts in the Unicode specifications and the use of scripts in languages. If the public review provided by this Working Group confirms the basic method outlined in the input documents, it is expected that the working group will be able to respond with any needed changes and close in a short period of time. If technical issues arise that indicate a fundamentally different approach must be taken from the one outlined above, it is anticipated that this working group would close, and a new one with an appropriate charter would be considered. This work is intended to specify an improved means to produce and use stable and unambiguous IDN identifiers. There are a variety of generally unsolvable problems, notably the problem of characters that are confusingly similar in appearance (often known as the "phishing" problem) that are not specifically part of the scope of the WG although some of the preliminary results of the design team suggest that the improvements contemplated in the specifications might mitigate some of the ways in which the current IDNA specifications can be abused for phishing purposes. While it is referenced from the original IDNA2003 package, the original Stringprep specification, RFC 3454, is not formally part of the IDNA package and will not be altered by this work. The work will update or obsolete RFC 3490. It is not expected to continue to use Nameprep (RFC 3491). Nameprep is used by other specifications; determining how (or whether) to update those specifications and, consequently, the long-term status of Nameprep, are not part of this effort. The method for ASCII-compatible ("ACE") encoding of IDNs, "Punycode" (RFC 3492) will not be revised by this WG. Subject to the more general constraints described above, the WG is permitted to consider changes that are not strictly backwards- compatible. For any such change that is recommended, it is expected to document the reasons for the change, the characters affected, and possible transition strategies. The assumptions outlined above are considered critical to the WG constituted by this charter. The WG will stop work and recommend that a new charter be generated if it concludes that any of the following are necessary to meet its goals: (i) A change to the "punycode" algorithm or to the ACE approach to encoding names in the DNS. (ii) A change to the ACE prefix from "xn--" (iii) A change to the basic approach taken in the design team documents (Namely: independence from Unicode version and reduction of dependency on character mapping ) Description of Working Group: The original Internationalized Domain Name (IDN) WG specified rules for the use of characters other than Latin A(a)-Z(z), digits 0-9 and the hyphen (-) in domain names in RFC3490, RFC3491 and RFC3492 in 2002 (published in 2003 and often referenced collectively as "IDNA2003"). These documents depend on RFC 3454 and were tied to Unicode version 3.2. An update to the current version (5.x) is required to accommodate additional scripts. In addition, experience has shown that significant improvements could be made in the protocol as presently specified. This WG is chartered to decouple IDNA from specific versions of Unicode using algorithms that define validity based on Unicode properties. It is recognized that some explicit exceptions may be necessary in any case, but attempts will be made to minimize these exceptions. Additional goals: - Separate requirements for valid IDNs at registration time (insertion of names into DNS zone files), vs. at resolution time (looking up those names) - Review, and if necessary revise, the algorithms and rules for handling right to left character sequences in an IDN context to allow labels based on additional scripts and languages and to make presentation as predictable as reasonably possible. - Permit use of some scripts that were inadvertently excluded by the original protocols. - Ensure practical stability of validity algorithms for IDNs. The constraints of the original IDN WG still apply to IDNABIS, namely to avoid disturbing the current use and operation of the domain name system, and for the DNS to continue to allow any system to resolve any domain name in a consistent way. The client-based approach of the original IDN work will be maintained -- substantially new protocols or mechanisms are not in scope. In particular, IDNs continue to use the "xn--" prefix and the same ASCII-compatible encoding, and the bidirectional algorithm follows the same basic design. The specifications are initially organized as four documents: overview and rationale, protocol, table algorithm, and improvements to the bidirectional algorithm. These documents are to be used as the basis for the discussion of the general direction of the work. This working group will be providing extended public review of the output of a design team that has been working on improvement of the IDNA specifications. This review-based approach is being used in part because of the way the work was undertaken by the team; in particular, the design team has been working with IETF visibility and has solicited and received significant amounts of technical review already from IETF participants and from others including experts in the Unicode specifications and the use of scripts in languages. If the public review provided by this Working Group confirms the basic method outlined in the input documents, it is expected that the working group will be able to respond with any needed changes and close in a short period of time. If technical issues arise that indicate a fundamentally different approach must be taken from the one outlined above, it is anticipated that this working group would close, and a new one with an appropriate charter would be considered. This work is intended to specify an improved means to produce and use stable and unambiguous IDN identifiers. There are a variety of generally unsolvable problems, notably the problem of characters that are confusingly similar in appearance (often known as the "phishing" problem) that are not specifically part of the scope of the WG although some of the preliminary results of the design team suggest that the improvements contemplated in the specifications might mitigate some of the ways in which the current IDNA specifications can be abused for phishing purposes. While it is referenced from the original IDNA2003 package, the original Stringprep specification, RFC 3454, is not formally part of the IDNA package and will not be altered by this work. The work will update or obsolete RFC 3490. It is not expected to continue to use Nameprep (RFC 3491). Nameprep is used by other specifications; determining how (or whether) to update those specifications and, consequently, the long-term status of Nameprep, are not part of this effort. The method for ASCII-compatible ("ACE") encoding of IDNs, "Punycode" (RFC 3492) will not be revised by this WG. Subject to the more general constraints described above, the WG is permitted to consider changes that are not strictly backwards- compatible. For any such change that is recommended, it is expected to document the reasons for the change, the characters affected, and possible transition strategies. The assumptions outlined above are considered critical to the WG constituted by this charter. The WG will stop work and recommend that a new charter be generated if it concludes that any of the following are necessary to meet its goals: (i) A change to the "punycode" algorithm or to the ACE approach to encoding names in the DNS. (ii) A change to the ACE prefix from "xn--" (iii) A change to the basic approach taken in the design team documents (Namely: independence from Unicode version and reduction of dependency on character mapping ) Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Apr 2008 Sep 2009 The Unicode code points and IDNA May 2008 Oct 2009 Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale May 2008 Oct 2009 Internationalized Domain Names in Applications (IDNA): Protocol May 2008 Sep 2009 Right-to-left scripts for IDNA Oct 2008 Oct 2009 Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework May 2009 Oct 2009 Mapping Characters in IDNA Inter-Domain Routing (idr) -------------------------- Charter Last Modified: 2009-06-01 Current Status: Active Working Group Chair(s): Susan Hares John Scudder Routing Area Director(s): Ross Callon Adrian Farrel Routing Area Advisor: Ross Callon Technical Advisor(s): Randall Atkinson Sharon Chisholm Mailing Lists: General Discussion:idr@ietf.org To Subscribe: idr-request@ietf.org In Body: subscribe idr-post Archive: http://www.ietf.org/mail-archive/web/idr/index.html Description of Working Group: The Inter-Domain Routing Working Group is chartered to standardize and promote the Border Gateway Protocol Version 4 (BGP-4) [RFC 1771] capable of supporting policy based routing for TCP/IP internets. The objective is to promote the use of BGP-4 to support IP version 4 and IP version 6. The working group will continue to work on improving the scalability of BGP. The current tasks of the WG are limited to: - Revise and clarify the base BGP4 document (RFC 1771). Note that RFC 1771 no longer documents existing practice and one goal of the update is document existing practice. Determine whether the document can be advanced as full Standard or needs to recycle at Proposed or Draft Standard. - Submit updated base BGP4 MIB to accompany the revised base BGP4 document. Once these tasks are finished (means WG consensus, WG Last Call, AD Review, IETF Last Call, and IESG approval for publication), work will progress on the following: - Review and Evaluate Existing RFCs on AS Confederations and Route Reflection. If changes are needed, create and advance revisions. - Review and evaluate Multiprotocol BGP (RFC 2858) for advancement as Draft Standard. - Progress BGP Extended Communities along standards track. - Extend BGP to support a 4-byte AS number, develop plan for transitioning to usage of 4-byte AS numbers. Advance support for a 4-byte AS numbers along standards track. - Produce BGP MIB v2 that includes support for AS Confederations, Route Reflection, Communities, Multi-Protocol BGP, BGP Extended Communities, support for 4-byte AS numbers. - Progress along the IETF standards track a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of route filters that the peer would use to constrain/filter its outbound routing updates to the speaker. Currently defined in draft-ietf-idr-route-filter-03.txt. - Progress along standards track an Outbound Router Filter (ORF) type for BGP, that can be used to perform aspath based route filtering. The ORF-type will support aspath based route filtering as well as regular expression based matching for address groups. Currently defined in draft-ietf-idr-aspath-orf-00.txt. - Progress a BGP Graceful Restart mechanism along standards track. - Progress Subcodes for BGP Cease Notification Message along standards track. - Progress AS-wide Unique BGP Identifier for BGP-4 along standards track. - Progress Dynamic Capability for BGP-4 along standards track. - Progress Flow Specification rules along standards track. Tasks for this working group are limited to those listed above; new items to be added to the charter must be approved by the IESG. Description of Working Group: The Inter-Domain Routing Working Group is chartered to standardize and promote the Border Gateway Protocol Version 4 (BGP-4) [RFC 1771] capable of supporting policy based routing for TCP/IP internets. The objective is to promote the use of BGP-4 to support IP version 4 and IP version 6. The working group will continue to work on improving the scalability of BGP. The current tasks of the WG are limited to: - Revise and clarify the base BGP4 document (RFC 1771). Note that RFC 1771 no longer documents existing practice and one goal of the update is document existing practice. Determine whether the document can be advanced as full Standard or needs to recycle at Proposed or Draft Standard. - Submit updated base BGP4 MIB to accompany the revised base BGP4 document. Once these tasks are finished (means WG consensus, WG Last Call, AD Review, IETF Last Call, and IESG approval for publication), work will progress on the following: - Review and Evaluate Existing RFCs on AS Confederations and Route Reflection. If changes are needed, create and advance revisions. - Review and evaluate Multiprotocol BGP (RFC 2858) for advancement as Draft Standard. - Progress BGP Extended Communities along standards track. - Extend BGP to support a 4-byte AS number, develop plan for transitioning to usage of 4-byte AS numbers. Advance support for a 4-byte AS numbers along standards track. - Produce BGP MIB v2 that includes support for AS Confederations, Route Reflection, Communities, Multi-Protocol BGP, BGP Extended Communities, support for 4-byte AS numbers. - Progress along the IETF standards track a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of route filters that the peer would use to constrain/filter its outbound routing updates to the speaker. Currently defined in draft-ietf-idr-route-filter-03.txt. - Progress along standards track an Outbound Router Filter (ORF) type for BGP, that can be used to perform aspath based route filtering. The ORF-type will support aspath based route filtering as well as regular expression based matching for address groups. Currently defined in draft-ietf-idr-aspath-orf-00.txt. - Progress a BGP Graceful Restart mechanism along standards track. - Progress Subcodes for BGP Cease Notification Message along standards track. - Progress AS-wide Unique BGP Identifier for BGP-4 along standards track. - Progress Dynamic Capability for BGP-4 along standards track. - Progress Flow Specification rules along standards track. Tasks for this working group are limited to those listed above; new items to be added to the charter must be approved by the IESG. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2002 Aug 2009 AS-wide Unique BGP Identifier for BGP-4 May 2004 Jul 2009 Multisession BGP Dec 2008 Jul 2009 Revisions to the BGP 'Minimum Route Advertisement Interval' Dec 2008 Aug 2009 Advertisement of Multiple Paths in BGP Jan 2009 Oct 2009 Generic Subtype for BGP Four-octet AS specific extended community Apr 2009 Oct 2009 BGP Support for Four-octet AS Number Space Apr 2009 Oct 2009 Error Handling for Optional Transitive BGP Attributes May 2009 Oct 2009 The Accumulated IGP Metric Attribute for BGP Aug 2009 Aug 2009 BGP Bestpath Selection Criteria Oct 2009 Oct 2009 BGP Advisory Message IP over DVB (ipdvb) ------------------- Charter Last Modified: 2009-05-26 Current Status: Active Working Group Chair(s): Gorry Fairhurst Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Secretary(ies): Martin Stiemerling Mailing Lists: General Discussion:ipdvb@erg.abdn.ac.uk To Subscribe: majordomo@erg.abdn.ac.uk In Body: subscribe ipdvb at majordomo@erg.abdn.ac.uk Archive: http://www.erg.abdn.ac.uk/ipdvb/archive/ Description of Working Group: The WG will develop new protocols and architectures to enable better deployment of IP over MPEG-2 transport and provide easier interworking with IP networks. Specific properties of this subnetwork technology include link-layer support for unicast and multicast, large numbers of down-stream receivers, and efficiency of transmission. These properties resemble those in some other wireless networks. The specific focus of the group is on the use of MPEG-2 transport (examples include the Digital Video Broadcast (DVB) standards: DVB-RCS; DVB-S and DVB-T and related ATSC Specifications) in next generation networks and is not concerned with the development, replacement, or retention of existing protocols on the existing generation of networks. The WG will endeavour to reuse existing open standard technologies, giving guidance on usage in IP networks, whenever they are able to fulfill requirements. For instance, we acknowledge the existing Multiprotocol Encapsulation (MPE) [ATSC A/90;ETSI EN 301192] and that this will continue to be deployed in the future to develop new markets. Any alternative encapsulation would need to co-exist with MPE. Appropriate standards will be defined to support transmission of IPv4 and IPv6 datagrams between IP networks connected using MPEG-2 transport subnetworks. This includes options for encapsulation, dynamic unicast address resolution for IPv4/IPv6, and the mechanisms needed to map routed IP multicast traffic to the MPEG-2 transport subnetwork. The standards will be appropriate to both MPE and any alternative encapsulation method developed. The developed protocols may also be applicable to other multicast enabled subnetwork technologies supporting large numbers of directly connected systems. The current list of work items is: Specify the requirements and architecture for supporting IPv4/IPv6 via MPEG-2 transmission networks. Such requirements should consider the range of platforms currently (or anticipated to be) in use. This draft will be an Informational RFC. Define a standards-track RFC defining an efficient encapsulation method. The design will consider the need for MAC addresses, the potential need for synchronisation between streams, support for a wide range of IPv4/IPv6 and multicast traffic. Provide an Informational RFC describing a framework for unicast and multicast address resolution over MPEG-2 transmission networks. The document will describe options for the address resolution process, relating these to appropriate usage scenarios and suggesting appropriate protocol mechanisms for both the existing Multi-Protocol Encapsulation (MPE) and the efficient encapsulation (2). Consideration will be paid to existing standards, and the cases for IPv6 and IPv4 will be described. Define standards-track RFC(s) to specify procedures for dynamic address resolution for IPv4/IPv6. This will describe the protocol and syntax of the information exchanged to bind unicast and multicast flows to the MPEG-2 TS Logical Channels. This will include specific optimisations appropriate for networks reaching large numbers of down-stream systems. Description of Working Group: The WG will develop new protocols and architectures to enable better deployment of IP over MPEG-2 transport and provide easier interworking with IP networks. Specific properties of this subnetwork technology include link-layer support for unicast and multicast, large numbers of down-stream receivers, and efficiency of transmission. These properties resemble those in some other wireless networks. The specific focus of the group is on the use of MPEG-2 transport (examples include the Digital Video Broadcast (DVB) standards: DVB-RCS; DVB-S and DVB-T and related ATSC Specifications) in next generation networks and is not concerned with the development, replacement, or retention of existing protocols on the existing generation of networks. The WG will endeavour to reuse existing open standard technologies, giving guidance on usage in IP networks, whenever they are able to fulfill requirements. For instance, we acknowledge the existing Multiprotocol Encapsulation (MPE) [ATSC A/90;ETSI EN 301192] and that this will continue to be deployed in the future to develop new markets. Any alternative encapsulation would need to co-exist with MPE. Appropriate standards will be defined to support transmission of IPv4 and IPv6 datagrams between IP networks connected using MPEG-2 transport subnetworks. This includes options for encapsulation, dynamic unicast address resolution for IPv4/IPv6, and the mechanisms needed to map routed IP multicast traffic to the MPEG-2 transport subnetwork. The standards will be appropriate to both MPE and any alternative encapsulation method developed. The developed protocols may also be applicable to other multicast enabled subnetwork technologies supporting large numbers of directly connected systems. The current list of work items is: Specify the requirements and architecture for supporting IPv4/IPv6 via MPEG-2 transmission networks. Such requirements should consider the range of platforms currently (or anticipated to be) in use. This draft will be an Informational RFC. Define a standards-track RFC defining an efficient encapsulation method. The design will consider the need for MAC addresses, the potential need for synchronisation between streams, support for a wide range of IPv4/IPv6 and multicast traffic. Provide an Informational RFC describing a framework for unicast and multicast address resolution over MPEG-2 transmission networks. The document will describe options for the address resolution process, relating these to appropriate usage scenarios and suggesting appropriate protocol mechanisms for both the existing Multi-Protocol Encapsulation (MPE) and the efficient encapsulation (2). Consideration will be paid to existing standards, and the cases for IPv6 and IPv4 will be described. Define standards-track RFC(s) to specify procedures for dynamic address resolution for IPv4/IPv6. This will describe the protocol and syntax of the information exchanged to bind unicast and multicast flows to the MPEG-2 TS Logical Channels. This will include specific optimisations appropriate for networks reaching large numbers of down-stream systems. Internet-Drafts: No Current Internet-Drafts. IP Flow Information Export (ipfix) ---------------------------------- Charter Last Modified: 2009-09-29 Current Status: Active Working Group Chair(s): Nevil Brownlee Juergen Quittek Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion:ipfix@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/ipfix Archive: http://www.ietf.org/mail-archive/web/ipfix Description of Working Group: The IPFIX working group has specified the Information Model (to describe IP flows) and the IPFIX protocol (to transfer IP flow data from IPFIX exporters to collectors). Several implementers have already built applications using the IPFIX protocol. As a result of a series of IPFIX interoperability testing events the WG has produced guidelines for IPFIX implementation and testing as well as recommendations for handling special cases such as bidirectional flow reporting and reducing redundancy in flow records. Practical experiences with IPFIX implementations exposed new requirements for the IPFIX protocol that so far have not been addressed by the WG. The major current goal of the WG is developing solutions that meet the new requirements without modifying the core IPFIX protocol specifications. 1. The IPFIX WG has developed a MIB module for monitoring IPFIX implementations. Means for configuring these devices have not been standardized yet. The WG will develop an XML-based configuration data model that can be used for configuring IPFIX devices and for storing, modifying and managing IPFIX configurations parameter sets. This work will be performed in close collaboration with the NETCONF WG. 2. First applications of IPFIX at large operator networks showed the need for mediation of flow information, for example, for aggregating huge amounts of flow data and for anomymization of flow information. The IPFIX WG will investigate this issue and produce a problem statement and a framework for IPFIX flow mediation. 3. The PSAMP WG has developed a protocol for reporting observed packets. The PSAMP protocol is an extension of the IPFIX protocol. The IPFIX WG will develop a MIB module for monitoring PSAMP implementations. The new MIB module will be an extension of the IPFIX MIB module. 4. Anonymization of flow information has been identified as a requirement for flow information export already in RFC 3917. However, technologies for flow anonymization are still a research issue and have so far not been considered to be mature enough for standardization. As one step in this direction, the IPFIX WG will develop guidelines for the implementation of anonymized data export and storage over IPFIX and define an information model for configuring and reporting anonymization applied at IPFIX devices. 5. The IPFIX and PSAMP WGs have defined standards for selecting observed IP packets and collecting information in flow records. In order to reduce the amount of data to be processed, packet selection methods have been defined. Another method for reducing flow data is flow selection. The IPFIX WG will define methods for flow selection and provide an information model for configuring and reporting flow selection applied at IPFIX devices. 6. Being designed for the export of flow records the IPFIX protocol provides very limited means for structuring information elements within IPFIX records. With the increasing number of IPFIX applications there is a need for exporting more complex information. The IPFIX WG will develop an extension of the IPFIX protocol that supports hierarchically structured data and lists (sequences) of Information Elements in data records. Description of Working Group: The IPFIX working group has specified the Information Model (to describe IP flows) and the IPFIX protocol (to transfer IP flow data from IPFIX exporters to collectors). Several implementers have already built applications using the IPFIX protocol. As a result of a series of IPFIX interoperability testing events the WG has produced guidelines for IPFIX implementation and testing as well as recommendations for handling special cases such as bidirectional flow reporting and reducing redundancy in flow records. Practical experiences with IPFIX implementations exposed new requirements for the IPFIX protocol that so far have not been addressed by the WG. The major current goal of the WG is developing solutions that meet the new requirements without modifying the core IPFIX protocol specifications. 1. The IPFIX WG has developed a MIB module for monitoring IPFIX implementations. Means for configuring these devices have not been standardized yet. The WG will develop an XML-based configuration data model that can be used for configuring IPFIX devices and for storing, modifying and managing IPFIX configurations parameter sets. This work will be performed in close collaboration with the NETCONF WG. 2. First applications of IPFIX at large operator networks showed the need for mediation of flow information, for example, for aggregating huge amounts of flow data and for anomymization of flow information. The IPFIX WG will investigate this issue and produce a problem statement and a framework for IPFIX flow mediation. 3. The PSAMP WG has developed a protocol for reporting observed packets. The PSAMP protocol is an extension of the IPFIX protocol. The IPFIX WG will develop a MIB module for monitoring PSAMP implementations. The new MIB module will be an extension of the IPFIX MIB module. 4. Anonymization of flow information has been identified as a requirement for flow information export already in RFC 3917. However, technologies for flow anonymization are still a research issue and have so far not been considered to be mature enough for standardization. As one step in this direction, the IPFIX WG will develop guidelines for the implementation of anonymized data export and storage over IPFIX and define an information model for configuring and reporting anonymization applied at IPFIX devices. 5. The IPFIX and PSAMP WGs have defined standards for selecting observed IP packets and collecting information in flow records. In order to reduce the amount of data to be processed, packet selection methods have been defined. Another method for reducing flow data is flow selection. The IPFIX WG will define methods for flow selection and provide an information model for configuring and reporting flow selection applied at IPFIX devices. 6. Being designed for the export of flow records the IPFIX protocol provides very limited means for structuring information elements within IPFIX records. With the increasing number of IPFIX applications there is a need for exporting more complex information. The IPFIX WG will develop an extension of the IPFIX protocol that supports hierarchically structured data and lists (sequences) of Information Elements in data records. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2007 Oct 2009 Definitions of Managed Objects for IP Flow Information Export May 2008 Oct 2009 IPFIX Mediation: Problem Statement Jun 2008 Oct 2009 IPFIX Mediation: Framework Jul 2008 Nov 2009 IPFIX Export per SCTP Stream Jul 2008 Oct 2009 Configuration Data Model for IPFIX and PSAMP Oct 2009 Nov 2009 IP Flow Anonymisation Support Oct 2009 Oct 2009 Export of Structured Data in IPFIX Oct 2009 Oct 2009 Flow Selection Techniques IP Performance Metrics (ippm) ----------------------------- Charter Last Modified: 2009-04-22 Current Status: Active Working Group Chair(s): Matthew Zekauskas Henk Uijterwaal Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Lars Eggert Mailing Lists: General Discussion:ippm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ippm In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/ippm/current/maillist.html Description of Working Group: 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. It is important that the metrics not represent a value judgment (i.e. define "good" and "bad"), but rather provide unbiased quantitative measures of performance. Functions peripheral to Internet data delivery services, such as NOC/NIC services, are beyond the scope of this working group. The IPPM WG has produced documents that define specific metrics and procedures for accurately measuring and documenting these metrics. This is the current list of fundamental metrics and the existing set of derived metrics. - connectivity - one-way delay and loss - round-trip delay. - delay variation - loss patterns - packet reordering - bulk transport capacity - link bandwidth capacity - packet duplication The working group will advance these metrics along the standards track within the IETF. The WG will document the process of moving documents along the standards track, based on draft-bradner-metricstest. As this process is likely to be needed by other groups as well (in particular BMWG, PMOL), the group will collaborate with other groups in order to ensure that there is consensus amongst all groups expected to use the process. Additionally, the WG will produce Proposed Standard AS documents, comparable to applicability statements in RFC 2026, that will focus on procedures for measuring the individual metrics and how these metrics characterize features that are important to different service classes, such as bulk transport, periodic streams, packet bursts or multimedia streams. Each AS document will discuss the performance characteristics that are pertinent to a specified service class; clearly identify the set of metrics that aid in the description of those characteristics; specify the methodologies required to collect said metrics; and lastly, present the requirements for the common, unambiguous reporting of testing results. The AS documents can also discuss the use of the metrics to verify performance expectations, such as SLA's, report results to specific user groups or investigate network problems. The focus is, again, to define how this should be done, not to define a value judgment. The WG may define additional statistics for its metrics if needed. Specific topics of these AS documents must be approved by the Area Directors as charter additions. The WG will work on documents describing how to compose and decompose the results of its metrics over time or space. The WG has produced protocols to enable communication among test equipment that implements the one- and two-way metrics (OWAMP and TWAMP respectively). OWAMP and TWAMP will be advanced along the standards track. Further development of these protocols will also be done inside the WG. The metrics developed by the WG were developed inside an active measurement context, that is, the devices used to measure the metrics produce their own traffic. However, most metrics can be used inside a passive context as well. No work is planned is this area though, this may be changed with AD approval. The intent of the WG is to cooperate with other appropriate standards bodies and forums (such as ATIS IIF, ITU-T SG 12, 13 and 15, MEF) to promote consistent approaches and metrics. Within the IETF process, IPPM metrics definitions will be subject to as rigorous a scrutiny for usefulness, clarity, and accuracy as other protocol standards. The IPPM WG will interact with other areas of IETF activity whose scope intersect with the requirement of these specific metrics. The WG will, on request, provide input to other IETF WG on the use of these metrics. Description of Working Group: 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. It is important that the metrics not represent a value judgment (i.e. define "good" and "bad"), but rather provide unbiased quantitative measures of performance. Functions peripheral to Internet data delivery services, such as NOC/NIC services, are beyond the scope of this working group. The IPPM WG has produced documents that define specific metrics and procedures for accurately measuring and documenting these metrics. This is the current list of fundamental metrics and the existing set of derived metrics. - connectivity - one-way delay and loss - round-trip delay. - delay variation - loss patterns - packet reordering - bulk transport capacity - link bandwidth capacity - packet duplication The working group will advance these metrics along the standards track within the IETF. The WG will document the process of moving documents along the standards track, based on draft-bradner-metricstest. As this process is likely to be needed by other groups as well (in particular BMWG, PMOL), the group will collaborate with other groups in order to ensure that there is consensus amongst all groups expected to use the process. Additionally, the WG will produce Proposed Standard AS documents, comparable to applicability statements in RFC 2026, that will focus on procedures for measuring the individual metrics and how these metrics characterize features that are important to different service classes, such as bulk transport, periodic streams, packet bursts or multimedia streams. Each AS document will discuss the performance characteristics that are pertinent to a specified service class; clearly identify the set of metrics that aid in the description of those characteristics; specify the methodologies required to collect said metrics; and lastly, present the requirements for the common, unambiguous reporting of testing results. The AS documents can also discuss the use of the metrics to verify performance expectations, such as SLA's, report results to specific user groups or investigate network problems. The focus is, again, to define how this should be done, not to define a value judgment. The WG may define additional statistics for its metrics if needed. Specific topics of these AS documents must be approved by the Area Directors as charter additions. The WG will work on documents describing how to compose and decompose the results of its metrics over time or space. The WG has produced protocols to enable communication among test equipment that implements the one- and two-way metrics (OWAMP and TWAMP respectively). OWAMP and TWAMP will be advanced along the standards track. Further development of these protocols will also be done inside the WG. The metrics developed by the WG were developed inside an active measurement context, that is, the devices used to measure the metrics produce their own traffic. However, most metrics can be used inside a passive context as well. No work is planned is this area though, this may be changed with AD approval. The intent of the WG is to cooperate with other appropriate standards bodies and forums (such as ATIS IIF, ITU-T SG 12, 13 and 15, MEF) to promote consistent approaches and metrics. Within the IETF process, IPPM metrics definitions will be subject to as rigorous a scrutiny for usefulness, clarity, and accuracy as other protocol standards. The IPPM WG will interact with other areas of IETF activity whose scope intersect with the requirement of these specific metrics. The WG will, on request, provide input to other IETF WG on the use of these metrics. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2006 Oct 2009 Spatial Composition of Metrics Feb 2006 Jun 2009 Framework for Metric Composition Jun 2006 Jul 2009 Reporting IP Performance Metrics to Users Oct 2008 Oct 2009 TWAMP Reflect Octets and Symmetrical Size Features Oct 2008 Oct 2009 Individual Session Control Feature for TWAMP Oct 2009 Oct 2009 Reporting Metrics: Different Points of View IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ Charter Last Modified: 2008-08-21 Current Status: Active Working Group Chair(s): Paul Hoffman Yaron Sheffer Security Area Director(s): Tim Polk Pasi Eronen Security Area Advisor: Pasi Eronen Mailing Lists: General Discussion:ipsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: http://www.ietf.org/mail-archive/web/ipsec/ Description of Working Group: The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), IKEv2 (RFC 4306, RFC 4718, and associated RFCs), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group will continue the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions and improvements to IPsec, mostly to IKEv2. The working group will also be a focus point for other IETF Working Groups who use IPsec in their own protocols. The initial set of work items is: - A revision to IKEv2 (RFC 4306) that incorporates the clarifications from RFC 4718, and otherwise improves the quality of the specification, taking into account implementation and interoperability experience. In some cases, the revision may include small technical corrections; however, impact on existing implementations must be considered. Major changes and adding new features is beyond the scope of this work item. The starting point for this work is draft-hoffman-ikev2bis. - An IPsec document roadmap that describes the various RFC documents covering IPsec, including both the core RFC 240x and RFC 430x versions of IPsec, and extensions specified in other documents. Sections 2 and 3 of RFC 2411 can provide useful material, but the expected scope is slightly different from RFC 2411. This document will be informational. - A standards-track extension to IKEv2 that provides full IPv6 support for IPsec remote access clients that use configuration payloads. This work will be based on draft-eronen-ipsec-ikev2-ipv6-config. The WG shall solicit help and reviews from the 6MAN WG to ensure that all aspects of IPv6 are properly considered. - A standards-track extension that allows an IPsec remote access client to "resume" a session with a gateway; that is, to skip certain parts of IKE negotiation when connecting again to the same gateway (or possibly a cluster of closely cooperating gateways). The idea is similar to TLS session resumption without server-side state, specified in RFC 5077. The main goals for this extension are to avoid public-key computations (to reduce VPN gateway load when a large number of clients reconnect to the gateway within a short period of time, such as following a network outage), and remove the need for user interaction for authentication (which may be required by some authentication mechanisms). The extension shall not have negative impact on IKEv2 security features. Failover from one gateway to another, mechanisms for detecting when a session should be resumed, and specifying communication mechanisms between gateways are beyond the scope of this work item. Specifying the detailed contents of the "session ticket" is also beyond the scope of this document; if there is sufficient interest, this could be specified later in a separate document. To the degree its content falls within the scope of this work item, text and ideas from draft-sheffer-ipsec-failover will be used as a starting point. - A standards-track extension to IPsec that allows an IPsec remote access gateway to redirect VPN clients to another gateway. This extension should be aligned with the session resumption extension, (the previous work item), and if so decided by the WG, could be specified in the same document. The starting point will be draft-devarapalli-ipsec-ikev2-redirect. - A standards-track mechanism that allows an intermediary device, such as a firewall or intrusion detection system, to easily and reliably determine whether an ESP packet is encrypted with the NULL cipher; and if it is, determine the location of the actual payload data inside the packet. The starting points for this work item are draft-grewal-ipsec-traffic-visibility and draft-hoffman- esp-null-protocol. The initial scope of the WG is restricted to the work items listed above. The WG shall not consider adding new work items until one or more of its documents progress to IESG evaluation. At that time, the WG can propose rechartering. Chartering this WG is not intended to have effect on documents that beyond the initial scope. In particular, work on IPsec extensions that are not included in this charter can happen as usual in other WGs (and there are currently several other WGs working on IPsec extensions; for example, BTNS and ROHC), or as individual submissions. This charter will expire in July 2010 (24 months from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Description of Working Group: The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), IKEv2 (RFC 4306, RFC 4718, and associated RFCs), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group will continue the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions and improvements to IPsec, mostly to IKEv2. The working group will also be a focus point for other IETF Working Groups who use IPsec in their own protocols. The initial set of work items is: - A revision to IKEv2 (RFC 4306) that incorporates the clarifications from RFC 4718, and otherwise improves the quality of the specification, taking into account implementation and interoperability experience. In some cases, the revision may include small technical corrections; however, impact on existing implementations must be considered. Major changes and adding new features is beyond the scope of this work item. The starting point for this work is draft-hoffman-ikev2bis. - An IPsec document roadmap that describes the various RFC documents covering IPsec, including both the core RFC 240x and RFC 430x versions of IPsec, and extensions specified in other documents. Sections 2 and 3 of RFC 2411 can provide useful material, but the expected scope is slightly different from RFC 2411. This document will be informational. - A standards-track extension to IKEv2 that provides full IPv6 support for IPsec remote access clients that use configuration payloads. This work will be based on draft-eronen-ipsec-ikev2-ipv6-config. The WG shall solicit help and reviews from the 6MAN WG to ensure that all aspects of IPv6 are properly considered. - A standards-track extension that allows an IPsec remote access client to "resume" a session with a gateway; that is, to skip certain parts of IKE negotiation when connecting again to the same gateway (or possibly a cluster of closely cooperating gateways). The idea is similar to TLS session resumption without server-side state, specified in RFC 5077. The main goals for this extension are to avoid public-key computations (to reduce VPN gateway load when a large number of clients reconnect to the gateway within a short period of time, such as following a network outage), and remove the need for user interaction for authentication (which may be required by some authentication mechanisms). The extension shall not have negative impact on IKEv2 security features. Failover from one gateway to another, mechanisms for detecting when a session should be resumed, and specifying communication mechanisms between gateways are beyond the scope of this work item. Specifying the detailed contents of the "session ticket" is also beyond the scope of this document; if there is sufficient interest, this could be specified later in a separate document. To the degree its content falls within the scope of this work item, text and ideas from draft-sheffer-ipsec-failover will be used as a starting point. - A standards-track extension to IPsec that allows an IPsec remote access gateway to redirect VPN clients to another gateway. This extension should be aligned with the session resumption extension, (the previous work item), and if so decided by the WG, could be specified in the same document. The starting point will be draft-devarapalli-ipsec-ikev2-redirect. - A standards-track mechanism that allows an intermediary device, such as a firewall or intrusion detection system, to easily and reliably determine whether an ESP packet is encrypted with the NULL cipher; and if it is, determine the location of the actual payload data inside the packet. The starting points for this work item are draft-grewal-ipsec-traffic-visibility and draft-hoffman- esp-null-protocol. The initial scope of the WG is restricted to the work items listed above. The WG shall not consider adding new work items until one or more of its documents progress to IESG evaluation. At that time, the WG can propose rechartering. Chartering this WG is not intended to have effect on documents that beyond the initial scope. In particular, work on IPsec extensions that are not included in this charter can happen as usual in other WGs (and there are currently several other WGs working on IPsec extensions; for example, BTNS and ROHC), or as individual submissions. This charter will expire in July 2010 (24 months from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Aug 2008 Oct 2009 Internet Key Exchange Protocol: IKEv2 Oct 2008 Nov 2009 Wrapped ESP for Traffic Visibility Nov 2008 Oct 2009 IKEv2 Session Resumption Nov 2008 Oct 2009 IPv6 Configuration in IKEv2 Jan 2009 Oct 2009 IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap Apr 2009 Sep 2009 Heuristics for Detecting ESP-NULL packets Jul 2009 Sep 2009 Using Advanced Encryption Standard (AES) Counter Mode with IKEv2 IS-IS for IP Internets (isis) ----------------------------- Charter Last Modified: 2009-10-16 Current Status: Active Working Group Chair(s): Chris Hopps David Ward Routing Area Director(s): Ross Callon Adrian Farrel Routing Area Advisor: Ross Callon Mailing Lists: General Discussion:isis-wg@ietf.org To Subscribe: isis-wg-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/isis-wg/index.html Description of Working Group: IS-IS is an IGP specified and standarized by ISO and incorporating extensions to support IP. It has been deployed successfully in the Internet for several years years. The IS-IS Working Group is chartered to document current protocol implementation practices and improvements, as well as to propose further extensions to be used within the scope of IS-IS and IP routing. Short term, the WG is expected to deliver a set of documents describing common implementation practices and extensions necessary to scale the protocol. These specifications will encourage multiple, inter-operable vendor implementations. This working group will interact with other standards bodies that have responsibility for standardizing IS-IS. The status of the WG documents maintained by the WG chairs can be found at http://skat.usc.edu/~tli/Schedule.htm. Description of Working Group: IS-IS is an IGP specified and standarized by ISO and incorporating extensions to support IP. It has been deployed successfully in the Internet for several years years. The IS-IS Working Group is chartered to document current protocol implementation practices and improvements, as well as to propose further extensions to be used within the scope of IS-IS and IP routing. Short term, the WG is expected to deliver a set of documents describing common implementation practices and extensions necessary to scale the protocol. These specifications will encourage multiple, inter-operable vendor implementations. This working group will interact with other standards bodies that have responsibility for standardizing IS-IS. The status of the WG documents maintained by the WG chairs can be found at http://skat.usc.edu/~tli/Schedule.htm. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jan 2005 Sep 2009 IPv6 Traffic Engineering in IS-IS Feb 2008 Oct 2009 IS-IS Multi-Instance Mar 2009 Jul 2009 Extensions to IS-IS for Layer-2 Systems Integrated Security Model for SNMP (isms) ----------------------------------------- Charter Last Modified: 2009-08-04 Current Status: Active Working Group Chair(s): Juergen Schoenwaelder Russ Mundy Security Area Director(s): Tim Polk Pasi Eronen Security Area Advisor: Pasi Eronen Mailing Lists: General Discussion:isms@ietf.org To Subscribe: isms-request@ietf.org In Body: in body: (un)subscribe Archive: http://www.ietf.org/mail-archive/working-groups/isms/current/maillist.html Description of Working Group: The Simple Network Management Protocol version 3 (SNMPv3) provides message security services through the security subsystem. Previously the ISMS Working Group defined a Transport Subsystem definition, a new Transport Security Model, and a Secure Shell Transport Model and a method for authenticating SNMPv3 users via the Remote Authentication Dial-In User Service (RADIUS). The initial body of work to be tackled by the working group involved only these pieces. Additional work on other transport models and other security extensions were to wait until the initial transport architecture and defining documents were completed. It is now possible to authenticate SNMPv3 messages via a RADIUS when those messages are sent over the newly defined SSH transport. However, it still remains impossible to centrally authorize a given SNMP transaction as on-device pre-existing authorization configuration is still required. In order to leverage a centralized RADIUS service to its full extent, the access control decision in the Access Control Subsystem needs to be based on authorization information received from RADIUS as well. The result will be an extension to obtain authorization information for an authenticated principal from RADIUS. The authorization information will be limited to mapping the authenticated principal to existing named access control policies, defining session timeouts, and similar session parameters. This mechanism will not provision the detailed access control rules. Additionally, new work will be undertaken to define TLS and DTLS-based transports that can offer support for environments that prefer certificate authentication. Certificate based authentication is desirable for many environments with a centralized authentication service. DTLS also provides datagram-based transmissions which may be desired for environments where TCP performance suffers because of network anomalies (e.g. high packet loss rates). A combination of TLS and DTLS-based transports offers solutions that addresses both the need for certificate-based authentication and for datagram-based delivery. Operators will be able to chose the transport solution that best meets their needs. The current goal of the ISMS working group is two-fold: to develop a method for allowing for access control decisions to be based on information provide by an AAA provisioning service and to develop TLS-based and DTLS-based Transport Models. The new work must not modify any other aspects of SNMPv3 protocol as defined in STD 62 (e.g., it must not create new PDU types). The working group will cover the following work items: - Specify a mechanism to support centralization of SNMPv3 Access Control decisions by means of a RADIUS-provisioned policy name bound to a username, which the VACM extension will use to dynamically populate the securityToGroupname table. Additionally, specify a time limit for access decisions, and such a time limit should be used to garbage collect expired dynamic securityToGroup mappings. - Specify TLS and DTLS transport models for SNMP. Description of Working Group: The Simple Network Management Protocol version 3 (SNMPv3) provides message security services through the security subsystem. Previously the ISMS Working Group defined a Transport Subsystem definition, a new Transport Security Model, and a Secure Shell Transport Model and a method for authenticating SNMPv3 users via the Remote Authentication Dial-In User Service (RADIUS). The initial body of work to be tackled by the working group involved only these pieces. Additional work on other transport models and other security extensions were to wait until the initial transport architecture and defining documents were completed. It is now possible to authenticate SNMPv3 messages via a RADIUS when those messages are sent over the newly defined SSH transport. However, it still remains impossible to centrally authorize a given SNMP transaction as on-device pre-existing authorization configuration is still required. In order to leverage a centralized RADIUS service to its full extent, the access control decision in the Access Control Subsystem needs to be based on authorization information received from RADIUS as well. The result will be an extension to obtain authorization information for an authenticated principal from RADIUS. The authorization information will be limited to mapping the authenticated principal to existing named access control policies, defining session timeouts, and similar session parameters. This mechanism will not provision the detailed access control rules. Additionally, new work will be undertaken to define TLS and DTLS-based transports that can offer support for environments that prefer certificate authentication. Certificate based authentication is desirable for many environments with a centralized authentication service. DTLS also provides datagram-based transmissions which may be desired for environments where TCP performance suffers because of network anomalies (e.g. high packet loss rates). A combination of TLS and DTLS-based transports offers solutions that addresses both the need for certificate-based authentication and for datagram-based delivery. Operators will be able to chose the transport solution that best meets their needs. The current goal of the ISMS working group is two-fold: to develop a method for allowing for access control decisions to be based on information provide by an AAA provisioning service and to develop TLS-based and DTLS-based Transport Models. The new work must not modify any other aspects of SNMPv3 protocol as defined in STD 62 (e.g., it must not create new PDU types). The working group will cover the following work items: - Specify a mechanism to support centralization of SNMPv3 Access Control decisions by means of a RADIUS-provisioned policy name bound to a username, which the VACM extension will use to dynamically populate the securityToGroupname table. Additionally, specify a time limit for access decisions, and such a time limit should be used to garbage collect expired dynamic securityToGroup mappings. - Specify TLS and DTLS transport models for SNMP. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Sep 2009 Oct 2009 Transport Layer Security Transport Model for SNMP Provisioning of Symmetric Keys (keyprov) ---------------------------------------- Charter Last Modified: 2008-12-16 Current Status: Active Working Group Chair(s): Phillip Hallam-Baker Hannes Tschofenig Security Area Director(s): Tim Polk Pasi Eronen Security Area Advisor: Pasi Eronen Mailing Lists: General Discussion:keyprov@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/keyprov Archive: http://www.ietf.org/mail-archive/web/keyprov Description of Working Group: Current developments in deployment of Shared Symmetric Key (SSK) tokens have highlighted the need for a standard protocol for provisioning symmetric keys. The need for provisioning protocols in PKI architectures has been recognized for some time. Although the existence and architecture of these protocols provides a feasibility proof for the KEYPROV work assumptions built into these protocols mean that it is not possible to apply them to symmetric key architectures without substantial modification. In particular the ability to provision symmetric keys and associated attributes dynamically to already issued devices such as cell phones and USB drives is highly desirable. The working group will develop the necessary protocols and data formats required to support provisioning and management of symmetric key authentication tokens, both proprietary and standards based. Input Documents --------------- The following Internet drafts have been proposed by their authors as input documents: * Dynamic Symmetric Key Provisioning Protocol (M. Pei, S. Machani) * Portable Symmetric Key Container (A. Vassilev, J. Martinsson, M. Pei, P. Hoyer, S. Machani) * Extensions to CT-KIP to support one- and two-pass key initialization (M. Nystroem, S. Machani) Scope and Deliverables ---------------------- The scope of the working group shall be to define protocols and data formats necessary for provisioning of symmetric cryptographic keys and associated attributes. The group shall consider use cases related to use of Shared Symmetric Key Tokens. Other use cases may be considered for the purpose of avoiding unnecessary restrictions in the design and ensure the potential for future extensibility. The working group will produce the following deliverables: * Portable Symmetric Key Container * Dynamic Symmetric Key Provisioning Protocol Description of Working Group: Current developments in deployment of Shared Symmetric Key (SSK) tokens have highlighted the need for a standard protocol for provisioning symmetric keys. The need for provisioning protocols in PKI architectures has been recognized for some time. Although the existence and architecture of these protocols provides a feasibility proof for the KEYPROV work assumptions built into these protocols mean that it is not possible to apply them to symmetric key architectures without substantial modification. In particular the ability to provision symmetric keys and associated attributes dynamically to already issued devices such as cell phones and USB drives is highly desirable. The working group will develop the necessary protocols and data formats required to support provisioning and management of symmetric key authentication tokens, both proprietary and standards based. Input Documents --------------- The following Internet drafts have been proposed by their authors as input documents: * Dynamic Symmetric Key Provisioning Protocol (M. Pei, S. Machani) * Portable Symmetric Key Container (A. Vassilev, J. Martinsson, M. Pei, P. Hoyer, S. Machani) * Extensions to CT-KIP to support one- and two-pass key initialization (M. Nystroem, S. Machani) Scope and Deliverables ---------------------- The scope of the working group shall be to define protocols and data formats necessary for provisioning of symmetric cryptographic keys and associated attributes. The group shall consider use cases related to use of Shared Symmetric Key Tokens. Other use cases may be considered for the purpose of avoiding unnecessary restrictions in the design and ensure the potential for future extensibility. The working group will produce the following deliverables: * Portable Symmetric Key Container * Dynamic Symmetric Key Provisioning Protocol Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Aug 2007 Nov 2009 Dynamic Symmetric Key Provisioning Protocol (DSKPP) Sep 2007 Oct 2009 Symmetric Key Package Content Type Jan 2009 Oct 2009 Portable Symmetric Key Container (PSKC) Kitten (GSS-API Next Generation) (kitten) ----------------------------------------- Charter Last Modified: 2009-05-14 Current Status: Active Working Group Chair(s): Shawn Emery Tom Yu Security Area Director(s): Tim Polk Pasi Eronen Security Area Advisor: Tim Polk Mailing Lists: General Discussion:kitten@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/kitten Archive: http://www.ietf.org/mail-archive/web/kitten/current/maillist.html Description of Working Group: The Generic Security Services API [RFC 2743, RFC 2744] provides an API for applications to set up security contexts and to use these contexts for per-message protection services. The Common Authentication Technology Next Generation Working Group (Kitten) will work on standardizing extensions and improvements to the core GSSAPI specification and language bindings that the IETF believes are necessary based on experience using GSSAPI over the last 10 years. Extensions may be published as separate drafts or included in a GSSAPI version 3. While version 2 of the GSSAPI may be clarified, no backward incompatible changes will be made to this version of the API. This working group is chartered to revise the GSSAPI v2 RFCs for the purpose of clarifying areas of ambiguity: o Use of channel bindings o Thread safety restrictions o C language utilization clarifications and recommendations (e.g., type utilization, name spaces) o Guidelines for GSS-API mechanism designers o Guidelines for GSS-API application protocol designers This working group is chartered to specify a non-backward compatible GSSAPI v3 including support for the following extensions: o Clarify the portable use of channel bindings and better specify channel bindings in a language-independent manner. o Specify thread safety extensions to allow multi-threaded applications to use GSSAPI o Definitions of channel bindings for TLS, IPSec, SSH and other cryptographic channels based on work started in the NFSV4 working group. o Define a GSSAPI extension to allow applications to store credentials. Discussions to be started based upon: o draft-williams-gss-store-deleg-creds-xx.txt o Extensions to solve problems posed by the Global Grid Forum's GSSAPI extensions document. o Extensions to deal with mechanism-specific extensibility in a multi-mechanism environment. o Extend the GSS-API to support authorization by portable GSS applications while also supporting mechanisms that do not have a single canonical name for each authentication identity. o Specify a Domain-based GSS service principal name consisting of: service name, host name, and domain name for use by application services hosted across multiple servers. o Extensions to support stackable GSSAPI mechanisms. o Define a Psuedo-Random Function for GSSAPI This working group is chartered to perform the following GSSAPI mechanism specification work: o Specify a GSSAPI v2/v3 Channel Conjunction Mechanism o Revise RFC 2748 (SPNEGO) to correct problems that make the specification unimplementable and to document the problems found in widely-deployed attempts to implement this spec. o Update the GSSAPI Java Language Bindings to match actual implementation This working group is chartered to perform the following new GSSAPI Language Binding specification work: o Specify a language binding for C# DELIVERABLES Either: o Clarifications to GSSAPIv2 (May 2005 to IESG)Informational [editor: TBD] Or: o Generic Security Service Application Program Interface Version 2, Update 2 [editor: TBD] o Generic Security Service API Version 2, Update 1 : C-bindings [editor: TBD] End: o The Channel Conjunction Mechanism (CCM) for the GSSAPI [editors: Mike Eisler/Nicolas Williams] (based on draft-ietf-nfsv4-ccm, which has been discussed previously in the NFSv4 WG) o On the Use of Channel Bindings to Secure Channels [editor: Nicolas Williams] (based on draft-ietf-nfsv4-channel-bindings, which has been discussed previously in the NFSv4 WG) o GSSAPIv3 [editor: to be determined] o Stackable Generic Security Service Pseudo-mechanisms [editor: Nicolas Williams] draft-williams-gssapi-stackable-pseudo-mechs o GSS-APIv2 Extension for Storing Delegated Credentials [editor: Nicolas Williams] draft-williams-gssapi-store-deleg-creds o GSSAPI Mechanisms without a Unique Canonical Name [editor: Sam Hartman] draft-hartman-gss-naming o SPNEGO (RFC 2478) Revisions [editor: Wyllys Ingersoll / Larry Zhu] draft-zhu-spnego-2478bis o Guide to the GSS-APIv3 [editor: Nicolas Williams] draft-williams-gssapi-v3-guide-to o Namespace Considerations and Registries for GSS-API Extensions [editor: Nicolas Williams] draft-williams-gssapi-extensions-iana o GSS-API Domain-Based Service Names and Name Type [editor: Nicolas Williams] draft-williams-gssapi-domain-based-names o GSS-API Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism [editor: Nicolas Williams] draft-williams-krb5-gssapi-domain-based-names o A PRF API extension for the GSS-API [editor: Nicolas Williams] draft-williams-gssapi-prf o A PRF for the Kerberos V GSS-API Mechanism [editor: Nicolas Williams] draft-williams-krb5-gssapi-prf o Generic Security Service API Version 2 : Java & C# Bindings [editors: Larry Zhu / Corby Morris] draft-morris-java-gssapi-update-for-csharp Description of Working Group: The Generic Security Services API [RFC 2743, RFC 2744] provides an API for applications to set up security contexts and to use these contexts for per-message protection services. The Common Authentication Technology Next Generation Working Group (Kitten) will work on standardizing extensions and improvements to the core GSSAPI specification and language bindings that the IETF believes are necessary based on experience using GSSAPI over the last 10 years. Extensions may be published as separate drafts or included in a GSSAPI version 3. While version 2 of the GSSAPI may be clarified, no backward incompatible changes will be made to this version of the API. This working group is chartered to revise the GSSAPI v2 RFCs for the purpose of clarifying areas of ambiguity: o Use of channel bindings o Thread safety restrictions o C language utilization clarifications and recommendations (e.g., type utilization, name spaces) o Guidelines for GSS-API mechanism designers o Guidelines for GSS-API application protocol designers This working group is chartered to specify a non-backward compatible GSSAPI v3 including support for the following extensions: o Clarify the portable use of channel bindings and better specify channel bindings in a language-independent manner. o Specify thread safety extensions to allow multi-threaded applications to use GSSAPI o Definitions of channel bindings for TLS, IPSec, SSH and other cryptographic channels based on work started in the NFSV4 working group. o Define a GSSAPI extension to allow applications to store credentials. Discussions to be started based upon: o draft-williams-gss-store-deleg-creds-xx.txt o Extensions to solve problems posed by the Global Grid Forum's GSSAPI extensions document. o Extensions to deal with mechanism-specific extensibility in a multi-mechanism environment. o Extend the GSS-API to support authorization by portable GSS applications while also supporting mechanisms that do not have a single canonical name for each authentication identity. o Specify a Domain-based GSS service principal name consisting of: service name, host name, and domain name for use by application services hosted across multiple servers. o Extensions to support stackable GSSAPI mechanisms. o Define a Psuedo-Random Function for GSSAPI This working group is chartered to perform the following GSSAPI mechanism specification work: o Specify a GSSAPI v2/v3 Channel Conjunction Mechanism o Revise RFC 2748 (SPNEGO) to correct problems that make the specification unimplementable and to document the problems found in widely-deployed attempts to implement this spec. o Update the GSSAPI Java Language Bindings to match actual implementation This working group is chartered to perform the following new GSSAPI Language Binding specification work: o Specify a language binding for C# DELIVERABLES Either: o Clarifications to GSSAPIv2 (May 2005 to IESG)Informational [editor: TBD] Or: o Generic Security Service Application Program Interface Version 2, Update 2 [editor: TBD] o Generic Security Service API Version 2, Update 1 : C-bindings [editor: TBD] End: o The Channel Conjunction Mechanism (CCM) for the GSSAPI [editors: Mike Eisler/Nicolas Williams] (based on draft-ietf-nfsv4-ccm, which has been discussed previously in the NFSv4 WG) o On the Use of Channel Bindings to Secure Channels [editor: Nicolas Williams] (based on draft-ietf-nfsv4-channel-bindings, which has been discussed previously in the NFSv4 WG) o GSSAPIv3 [editor: to be determined] o Stackable Generic Security Service Pseudo-mechanisms [editor: Nicolas Williams] draft-williams-gssapi-stackable-pseudo-mechs o GSS-APIv2 Extension for Storing Delegated Credentials [editor: Nicolas Williams] draft-williams-gssapi-store-deleg-creds o GSSAPI Mechanisms without a Unique Canonical Name [editor: Sam Hartman] draft-hartman-gss-naming o SPNEGO (RFC 2478) Revisions [editor: Wyllys Ingersoll / Larry Zhu] draft-zhu-spnego-2478bis o Guide to the GSS-APIv3 [editor: Nicolas Williams] draft-williams-gssapi-v3-guide-to o Namespace Considerations and Registries for GSS-API Extensions [editor: Nicolas Williams] draft-williams-gssapi-extensions-iana o GSS-API Domain-Based Service Names and Name Type [editor: Nicolas Williams] draft-williams-gssapi-domain-based-names o GSS-API Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism [editor: Nicolas Williams] draft-williams-krb5-gssapi-domain-based-names o A PRF API extension for the GSS-API [editor: Nicolas Williams] draft-williams-gssapi-prf o A PRF for the Kerberos V GSS-API Mechanism [editor: Nicolas Williams] draft-williams-krb5-gssapi-prf o Generic Security Service API Version 2 : Java & C# Bindings [editors: Larry Zhu / Corby Morris] draft-morris-java-gssapi-update-for-csharp Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2005 Apr 2009 Namespace Considerations and Registries for GSS-API Extensions May 2005 Jul 2009 GSS-API Naming Extensions Kerberos (krb-wg) ----------------- Charter Last Modified: 2009-01-12 Current Status: Active Working Group Chair(s): Jeffrey Hutzelman Larry Zhu Security Area Director(s): Tim Polk Pasi Eronen Security Area Advisor: Tim Polk Mailing Lists: General Discussion:ietf-krb-wg@lists.anl.gov To Subscribe: https://lists.anl.gov/mailman/listinfo/ietf-krb-wg Archive: https://lists.anl.gov/pipermail/ietf-krb-wg/ Description of Working Group: Kerberos over the years has been ported to virtually every operating system. There are at least two open source versions, with numerous commercial versions based on these and other proprietary implementations. Kerberos evolution has continued in recent years, with the development of a new crypto framework, publication of a new version of the Kerberos specification, support for initial authentication using public keys, and numerous extensions developed in and out of the IETF. However, wider deployment and advances in technology bring with them both new challenges and new opportunities, particularly with regard to making initial authentication of users to the Kerberos system both convenient and secure. In addition, several key features remain undefined. The Kerberos Working Group will continue to improve the core Kerberos specification, develop extensions to address new needs and technologies related to improving the process of client authentication, and produce specifications for missing functionality. Specifically, the Working Group will: * Complete existing work: - ECC for PKINIT (draft-zhu-pkinit-ecc-03.txt) - Set/Change Password (draft-ietf-krb-wg-kerberos-set-passwd-05.txt) - Naming Constraints (draft-ietf-krb-wg-naming-02.txt) - Anonymity (draft-ietf-krb-wg-anon-03.txt) - Hash agility for GSS-KRB5 (draft-ietf-krb-wg-gss-cb-hash-agility-00.txt) - Hash agility for PKINIT (draft-ietf-krb-wg-pkinit-alg-agility-01.txt) - Referrals (draft-ietf-krb-wg-kerberos-referrals-08.txt) * Prepare and advance a specification for an updated, backward- compatible version of the Kerberos version 5 protocol which supports non-ASCII principal and realm names, salt strings, and passwords; insures that those portions of the protocol which are not encrypted are nonetheless authenticated whenever possible; and enables future protocol revisions and extensions. * Develop extensions which reduce or eliminate exposure of Kerberos clients' long-term keys to attack and enable the use of alternate mechanisms for initial authentication. This task will comprise the following items: - A model and framework for preauthentication mechanisms - A mechanism for providing a protected channel for carrying preauthentication data and/or a reply key between a Kerberos client and KDC, within the KDC_REQ/KDC_REP exchange. - Support for One-Time Passwords - Support for hardware authentication tokens - Support for using TLS to secure communications with Kerberos KDCs. * Examine issues related to the current cross-realm model, produce a list of problems to be solved, and evaluate approaches to solving them. * Develop extensions to Kerberos and a GSS-API mechanism (IAKERB) to enable Kerberos clients to communicate with a KDC by using a GSS-API acceptor as a proxy. * Produce a data model for information needed by the KDC, and an LDAP schema for management of that data. Description of Working Group: Kerberos over the years has been ported to virtually every operating system. There are at least two open source versions, with numerous commercial versions based on these and other proprietary implementations. Kerberos evolution has continued in recent years, with the development of a new crypto framework, publication of a new version of the Kerberos specification, support for initial authentication using public keys, and numerous extensions developed in and out of the IETF. However, wider deployment and advances in technology bring with them both new challenges and new opportunities, particularly with regard to making initial authentication of users to the Kerberos system both convenient and secure. In addition, several key features remain undefined. The Kerberos Working Group will continue to improve the core Kerberos specification, develop extensions to address new needs and technologies related to improving the process of client authentication, and produce specifications for missing functionality. Specifically, the Working Group will: * Complete existing work: - ECC for PKINIT (draft-zhu-pkinit-ecc-03.txt) - Set/Change Password (draft-ietf-krb-wg-kerberos-set-passwd-05.txt) - Naming Constraints (draft-ietf-krb-wg-naming-02.txt) - Anonymity (draft-ietf-krb-wg-anon-03.txt) - Hash agility for GSS-KRB5 (draft-ietf-krb-wg-gss-cb-hash-agility-00.txt) - Hash agility for PKINIT (draft-ietf-krb-wg-pkinit-alg-agility-01.txt) - Referrals (draft-ietf-krb-wg-kerberos-referrals-08.txt) * Prepare and advance a specification for an updated, backward- compatible version of the Kerberos version 5 protocol which supports non-ASCII principal and realm names, salt strings, and passwords; insures that those portions of the protocol which are not encrypted are nonetheless authenticated whenever possible; and enables future protocol revisions and extensions. * Develop extensions which reduce or eliminate exposure of Kerberos clients' long-term keys to attack and enable the use of alternate mechanisms for initial authentication. This task will comprise the following items: - A model and framework for preauthentication mechanisms - A mechanism for providing a protected channel for carrying preauthentication data and/or a reply key between a Kerberos client and KDC, within the KDC_REQ/KDC_REP exchange. - Support for One-Time Passwords - Support for hardware authentication tokens - Support for using TLS to secure communications with Kerberos KDCs. * Examine issues related to the current cross-realm model, produce a list of problems to be solved, and evaluate approaches to solving them. * Develop extensions to Kerberos and a GSS-API mechanism (IAKERB) to enable Kerberos clients to communicate with a KDC by using a GSS-API acceptor as a proxy. * Produce a data model for information needed by the KDC, and an LDAP schema for management of that data. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2004 Oct 2009 A Generalized Framework for Kerberos Pre-Authentication Nov 2004 Jul 2009 Using Kerberos V5 over the Transport Layer Security (TLS) protocol Oct 2007 Oct 2009 Problem statement on the cross-realm operation of Kerberos Oct 2007 Oct 2009 OTP Pre-authentication Oct 2007 Jul 2009 Initial and Pass Through Authentication Using Kerberos V5 and the GSS- API (IAKERB) Dec 2007 Oct 2009 An information model for Kerberos version 5 Layer Two Tunneling Protocol Extensions (l2tpext) ------------------------------------------------- Charter Last Modified: 2009-06-25 Current Status: Active Working Group Chair(s): Ignacio Goyret Carlos Pignataro Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion:l2tpext@ietf.org To Subscribe: l2tpext-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/l2tpext/index.html Description of Working Group: This group is responsible for extensions to the Layer 2 Tunneling Protocol. Examples of L2TP "extensions" include any changes to the L2TP encapsulation, control messages, or new AVPs sent in IETF standard control messages. I. L2TP Background: L2TP (RFC2661) provides a means for tunneling PPP over IP. Because PPP can effectivly carry any traffic (e.g., IP (RFC 1332), IPX (RFC 1552), etc.) it can effectively be used to tunnel arbitrary protocols over IP. L2TP provides: - An extensible control protocol for dynamic setup, maintenance, and teardown of multiple layer 2 tunnels between two logical endpoints. - An encapsulation method for tunneling PPP frames between each endpoint. This includes multiplexing of multiple, discrete, PPP streams between each endpoint. L2TP looks (in most ways) like just another point-to-point link to PPP and may thereby take advantage of the work done for any protocol defined for use over a traditional PPP WAN link. It should be noted, however, that the ability to dynamically establish a PPP connection between any two IP connected endpoints brings new applications and challenges of scale to existing PPP implementations and protocol definitions that must be considered. As high-speed broadband access to the home replaces traditional dialup infrastructure, L2TP has been utilized as one standard method for aggregation and delivery of PPP connections over packet networks. Thus, rather than a relatively small scale or low speed circuit-switched connection such as an analog modem or ISDN connection at the L2TP Access Concentrator (LAC), we see PPP being received over ATM PVCs which are generally higher speed and "always-on" vs. temporally connected. Further, there are non-IETF standard PPP tunneling protocols that have been developed and deployed, including PPPoE (RFC 2516) and the 3GPP2 Wireless GPRS Tunneling Protocol Standard (http://www.3gpp.org) that interface with L2TP at various points in the network. While it is unfortunate that there is more than one standard method for tunneling PPP defined, each of these have their own installed bases and specific application-driven nuances. Proper integration with these various tunneling methods as they "hand-off" to the L2TP portion of the network must be ensured. II. L2TP Interaction with PWE3 for Pseudo-Wire Transport: In addition to tunneling PPP, L2TPEXT will develop protocol extensions necessary for the tunneling of specific "pseudo-wires" as defined in the PWE3 WG. Specific milestone identification for this activity is currently subject to ongoing work and results from PWE3. III. WG Activities The Working Group is currently focussed on the following activities: - RFC2661 bundles data transport, protocol signaling, and PPP emulation methods into a single document. This working group will separate RFC2661 into stand-alone documents for greater modularity. This will consist of a base L2TP document defining common tunneling constructs and encapsulation, and a PPP document defining the use of these constructs for tunneling of PPP sessions as defined in RFC2661. Documents for tunneling of pseudo-wires defined in PWE3 will be forthcoming as well. As RFC2661 is rewritten to separate the tunnel setup and maintenance sections for support of new applications and increased modularity, some modifications to the base protocol may be necessary. This includes addition of a Pseudo Wire AVP to identify the pseudo wire being carried (with PPP identified as 0). In all cases, these will follow the extensible models offered in the L2TP base protocol design, with as much attention to backwards compatibility as possible given the new requirements. In addition to its broader scope, L2TPEXT has ongoing work to complete from its inception as a tunneling protocol for PPP only. While RFC2661 will ultimately be made obsolete by a new L2TP base specification and companion PPP over L2TP specification, documents based on RFC2661 which do not require this new degree of modularity will still be published in the near term. These include: - Identification of specific parameters and modes of IPsec in order to aid interoperability when IPsec is used to secure L2TP traffic. - An L2TP MIB for network management. - An L2TP Differentiated Services Extension to negotiate DSCP parameters to be set for packets associated with a given L2TP tunnel, sessions within a tunnel, or L2TP control traffic which may need differentiated QoS settings. - Extensions to L2TP for additional or more robust control information for informational or operational purposes as deemed necessary based on operational experience. These include better transfer of L2TP PPP LCP Information between tunnel endpoints when such state needs to be shared, PPP Disconnect codes within L2TP control messages for better debugging, and L2TP session information for enhanced logging, billing, and error reporting. - Standard methods for operation over such packet networks such as Frame Relay and AAL5. - L2TP defines a base encapsulation for operation in typical environments for tunneling PPP at the time RFC2661 was being developed. In cases where bandwidth cost is at a premium, the size of the L2TP header becomes more significant. L2TP will define a compressed version of the L2TP header for these environments that takes advantage of the L2TP control plane to establish operational parameters allowing removal of information from individual packets. Description of Working Group: This group is responsible for extensions to the Layer 2 Tunneling Protocol. Examples of L2TP "extensions" include any changes to the L2TP encapsulation, control messages, or new AVPs sent in IETF standard control messages. I. L2TP Background: L2TP (RFC2661) provides a means for tunneling PPP over IP. Because PPP can effectivly carry any traffic (e.g., IP (RFC 1332), IPX (RFC 1552), etc.) it can effectively be used to tunnel arbitrary protocols over IP. L2TP provides: - An extensible control protocol for dynamic setup, maintenance, and teardown of multiple layer 2 tunnels between two logical endpoints. - An encapsulation method for tunneling PPP frames between each endpoint. This includes multiplexing of multiple, discrete, PPP streams between each endpoint. L2TP looks (in most ways) like just another point-to-point link to PPP and may thereby take advantage of the work done for any protocol defined for use over a traditional PPP WAN link. It should be noted, however, that the ability to dynamically establish a PPP connection between any two IP connected endpoints brings new applications and challenges of scale to existing PPP implementations and protocol definitions that must be considered. As high-speed broadband access to the home replaces traditional dialup infrastructure, L2TP has been utilized as one standard method for aggregation and delivery of PPP connections over packet networks. Thus, rather than a relatively small scale or low speed circuit-switched connection such as an analog modem or ISDN connection at the L2TP Access Concentrator (LAC), we see PPP being received over ATM PVCs which are generally higher speed and "always-on" vs. temporally connected. Further, there are non-IETF standard PPP tunneling protocols that have been developed and deployed, including PPPoE (RFC 2516) and the 3GPP2 Wireless GPRS Tunneling Protocol Standard (http://www.3gpp.org) that interface with L2TP at various points in the network. While it is unfortunate that there is more than one standard method for tunneling PPP defined, each of these have their own installed bases and specific application-driven nuances. Proper integration with these various tunneling methods as they "hand-off" to the L2TP portion of the network must be ensured. II. L2TP Interaction with PWE3 for Pseudo-Wire Transport: In addition to tunneling PPP, L2TPEXT will develop protocol extensions necessary for the tunneling of specific "pseudo-wires" as defined in the PWE3 WG. Specific milestone identification for this activity is currently subject to ongoing work and results from PWE3. III. WG Activities The Working Group is currently focussed on the following activities: - RFC2661 bundles data transport, protocol signaling, and PPP emulation methods into a single document. This working group will separate RFC2661 into stand-alone documents for greater modularity. This will consist of a base L2TP document defining common tunneling constructs and encapsulation, and a PPP document defining the use of these constructs for tunneling of PPP sessions as defined in RFC2661. Documents for tunneling of pseudo-wires defined in PWE3 will be forthcoming as well. As RFC2661 is rewritten to separate the tunnel setup and maintenance sections for support of new applications and increased modularity, some modifications to the base protocol may be necessary. This includes addition of a Pseudo Wire AVP to identify the pseudo wire being carried (with PPP identified as 0). In all cases, these will follow the extensible models offered in the L2TP base protocol design, with as much attention to backwards compatibility as possible given the new requirements. In addition to its broader scope, L2TPEXT has ongoing work to complete from its inception as a tunneling protocol for PPP only. While RFC2661 will ultimately be made obsolete by a new L2TP base specification and companion PPP over L2TP specification, documents based on RFC2661 which do not require this new degree of modularity will still be published in the near term. These include: - Identification of specific parameters and modes of IPsec in order to aid interoperability when IPsec is used to secure L2TP traffic. - An L2TP MIB for network management. - An L2TP Differentiated Services Extension to negotiate DSCP parameters to be set for packets associated with a given L2TP tunnel, sessions within a tunnel, or L2TP control traffic which may need differentiated QoS settings. - Extensions to L2TP for additional or more robust control information for informational or operational purposes as deemed necessary based on operational experience. These include better transfer of L2TP PPP LCP Information between tunnel endpoints when such state needs to be shared, PPP Disconnect codes within L2TP control messages for better debugging, and L2TP session information for enhanced logging, billing, and error reporting. - Standard methods for operation over such packet networks such as Frame Relay and AAL5. - L2TP defines a base encapsulation for operation in typical environments for tunneling PPP at the time RFC2661 was being developed. In cases where bandwidth cost is at a premium, the size of the L2TP header becomes more significant. L2TP will define a compressed version of the L2TP header for these environments that takes advantage of the L2TP control plane to establish operational parameters allowing removal of information from individual packets. Internet-Drafts: No Current Internet-Drafts. Layer 2 Virtual Private Networks (l2vpn) ---------------------------------------- Charter Last Modified: 2009-10-19 Current Status: Active Working Group Chair(s): Shane Amante Giles Heron Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Technical Advisor(s): Alex Zinin Mailing Lists: General Discussion:l2vpn@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/l2vpn Archive: http://www.ietf.org/mail-archive/web/l2vpn/current/maillist.html Description of Working Group: The L2VPN working group is responsible for defining and specifying a limited number of solutions for supporting provider-provisioned Layer-2 Virtual Private Networks (L2VPNs). Layer-2 VPN's comprise the following: 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that emulates an Ethernet (V)LAN across an IP or an MPLS-enabled IP Packet Switched Network (PSN). 2. Virtual Private Wire Service (VPWS) -- A Layer 2 service that provides point-to-point connectivity for a variety of link layers, including Frame Relay, ATM, Ethernet, PPP, etc., across an IP or MPLS-enabled IP PSN. 3. Virtual Private Multicast Service (VPMS) -- A Layer 2 service that Provides point-to-multipoint connectivity for a variety of link layers, including Frame Relay, ATM, Ethernet, PPP, etc., across an IP or MPLS-enabled IP PSN. 4. IP-only L2VPN -- A point-to-point or point-to-multipoint "IP-only" service over an IP or MPLS-enabled PSN. This service is similar to VPWS because it supports a variety of link-layer protocols on the Attachment Circuits, including Frame Relay, ATM, Ethernet, PPP, etc. IP-only L2VPN's are different from both VPLS and VPWS because unicast Layer-2 frames containing IP data packets, either IPv4 or IPv6, are de- encapsulated leaving only the IP data packet to be transmitted over the PSN. An IP-only L2VPN service also differs from L3VPN service, since no routing protocol operates between the PE and CE; furthermore, connectivity from CE to CE is provided via an emulated Layer-2 service over the PSN, which results in the CE's appearing to be directly attached to each other at Layer-2. The WG will address two specific types of IP-only L2VPN: a) Those with Attachment Circuits (ACs) that use the same Layer 2 framing at all attachment points in the same L2VPN; and, b) Those with ACs that use different Layer 2 framing at various attachment points in the same L2VPN. For (b), inter-working between link-layers is strictly out of scope beyond that which is minimally necessary to ensure that IP packets are transported from an AC of one type, across the IP or MPLS-enabled IP PSN, and to an AC of another type in as transparent a manner as possible to the CEs on both sides of the service. VPLS, VPWS and VPMS operate over Pseudowires (PWs) as defined by the PWE3 WG. As with a single PW, an L2VPN emulates a "native" service over a PSN that is reasonably faithful to, but may not be entirely indistinguishable from, the native service itself. Further, following in the "edge-to-edge" nature of the PWs that it uses, the L2VPN WG will not define any new mechanisms which exert control over the underlying PSN. When necessary it may, however, recommend or require the use of existing PSN QoS and path control mechanisms between PW endpoints which make up the L2VPN. L2VPN's will make use of existing IETF specified mechanisms unless there are technical reasons why the existing mechanisms are insufficient or unnecessary. The L2VPN WG is responsible for specification of the discovery and membership of PE's participating in a VPLS, VPWS or IP-only L2VPN as well as the membership of CE devices to a specific instance of a L2VPN. The L2VPN WG will provide extensions of existing protocols that will be discussed in protocol-specific WG's. In particular, the L2VPN WG may define extensions to pseudowire management mechanisms (including OAM), specifically Pseudowire Virtual Circuit Connectivity Verification (VCCV), for VPLS. Those VCCV extensions will be reviewed by PWE3 to ensure they are inline with the overall design/architecture of VCCV and MPLS. The L2VPN WG will not define new encapsulations, control (set-up, configuration, maintenance or tear-down), or resiliency mechanisms specifically related to pseudowires, because those must be defined by the PWE3 WG. Furthermore, the L2VPN WG will not define protocol inter- working between a VPLS or VPWS and native service-layer control, OAM or or resiliency mechanisms, as those will be defined by the PWE3 WG. On the other hand, the L2VPN WG may define how to operate native service- layer control, IEEE 802.1 OAM or resiliency mechanisms on top of a VPLS or VPWS service. The L2VPN WG scope includes the following: 1. Discovery of PE's participating in a Layer-2 VPN and the associated topology required for connectivity of the VPLS or VPWS service. 2. Signaling of information related to the discovery and membership of PE's within a L2VPN. These procedures must use PWE3 control and management procedures, or define requirements for extensions of PWE3 protocols to suit the needs of an L2VPN. Once those requirements are reviewed by the L2VPN WG, they should be provided to the PWE3 WG to derive solutions. 3. MIB's for Layer-2 VPN solutions. 4. Specification of requirements and framework that will define Operations Administration and Management (OAM) procedures for VPLS and VPWS VPN's, related to the operation of VPLS and VPWS VPN's over IP/MPLS PSN's. In addition, the L2VPN WG will define OAM solutions for VPLS and VPWS VPN's. 5. Mechanisms to permit optimization of multicast data traffic within a VPLS or VPWS VPN over an IP/MPLS PSN. 6. Improved service convergence for multi-homed CE's to VPLS PE's. Specifically, upon failure of a primary path from a CE to VPLS PE, initiate a rapid switch-over to an alternate path. If required, interactions with native service-layer resiliency mechanisms will be provided via solutions from other IETF WG's such as PWE3. 7. Enhancements to increase the scalability of the Control Plane and Data Plane (e.g.: number of PW's and MAC Forwarding Database, respectively) of VPLS PE nodes. 8. Define requirements and solutions for Auto-Discovery and Signaling of Inter-AS VPLS and VPWS L2VPN's, in addition to Inter-AS solutions for multicast-optimized VPLS and VPMS Layer-2 VPN's. The L2VPN WG currently works on the following tasks: - Define MIB's appropriate for each type of Layer-2 VPN. - Specification of Operations Administration and Management (OAM) mechanisms for VPLS, VPWS and IP-only VPN's. - Specification of procedures to permit optimization of L2VPN multicast data traffic within the PSN. - Define enhancements to increase scalability of VPLS PE nodes, to provide aggregation of learned customer MAC addresses at VPLS PE's. - Identify requirements for multi-homing of CE's to VPLS PE's. elements. Based on these requirements, define solutions for achieving fast convergence after a switchover to an alternate path, for example through optimized MAC flushing within a VPLS domain. - Identify requirements for Inter-AS VPLS and VPWS services. Define Inter-AS enhancements to VPLS and VPWS based on these requirements. - Include extensions to L2VPN protocols and RFC's necessary to create an MPLS Transport Profile (MPLS-TP). The work on the MPLS TP needs to be coordinated between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) that are chartered to do MPLS TP work. Where necessary, the WG will coordinate its activities with IEEE 802.1 and ITU. Description of Working Group: The L2VPN working group is responsible for defining and specifying a limited number of solutions for supporting provider-provisioned Layer-2 Virtual Private Networks (L2VPNs). Layer-2 VPN's comprise the following: 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that emulates an Ethernet (V)LAN across an IP or an MPLS-enabled IP Packet Switched Network (PSN). 2. Virtual Private Wire Service (VPWS) -- A Layer 2 service that provides point-to-point connectivity for a variety of link layers, including Frame Relay, ATM, Ethernet, PPP, etc., across an IP or MPLS-enabled IP PSN. 3. Virtual Private Multicast Service (VPMS) -- A Layer 2 service that Provides point-to-multipoint connectivity for a variety of link layers, including Frame Relay, ATM, Ethernet, PPP, etc., across an IP or MPLS-enabled IP PSN. 4. IP-only L2VPN -- A point-to-point or point-to-multipoint "IP-only" service over an IP or MPLS-enabled PSN. This service is similar to VPWS because it supports a variety of link-layer protocols on the Attachment Circuits, including Frame Relay, ATM, Ethernet, PPP, etc. IP-only L2VPN's are different from both VPLS and VPWS because unicast Layer-2 frames containing IP data packets, either IPv4 or IPv6, are de- encapsulated leaving only the IP data packet to be transmitted over the PSN. An IP-only L2VPN service also differs from L3VPN service, since no routing protocol operates between the PE and CE; furthermore, connectivity from CE to CE is provided via an emulated Layer-2 service over the PSN, which results in the CE's appearing to be directly attached to each other at Layer-2. The WG will address two specific types of IP-only L2VPN: a) Those with Attachment Circuits (ACs) that use the same Layer 2 framing at all attachment points in the same L2VPN; and, b) Those with ACs that use different Layer 2 framing at various attachment points in the same L2VPN. For (b), inter-working between link-layers is strictly out of scope beyond that which is minimally necessary to ensure that IP packets are transported from an AC of one type, across the IP or MPLS-enabled IP PSN, and to an AC of another type in as transparent a manner as possible to the CEs on both sides of the service. VPLS, VPWS and VPMS operate over Pseudowires (PWs) as defined by the PWE3 WG. As with a single PW, an L2VPN emulates a "native" service over a PSN that is reasonably faithful to, but may not be entirely indistinguishable from, the native service itself. Further, following in the "edge-to-edge" nature of the PWs that it uses, the L2VPN WG will not define any new mechanisms which exert control over the underlying PSN. When necessary it may, however, recommend or require the use of existing PSN QoS and path control mechanisms between PW endpoints which make up the L2VPN. L2VPN's will make use of existing IETF specified mechanisms unless there are technical reasons why the existing mechanisms are insufficient or unnecessary. The L2VPN WG is responsible for specification of the discovery and membership of PE's participating in a VPLS, VPWS or IP-only L2VPN as well as the membership of CE devices to a specific instance of a L2VPN. The L2VPN WG will provide extensions of existing protocols that will be discussed in protocol-specific WG's. In particular, the L2VPN WG may define extensions to pseudowire management mechanisms (including OAM), specifically Pseudowire Virtual Circuit Connectivity Verification (VCCV), for VPLS. Those VCCV extensions will be reviewed by PWE3 to ensure they are inline with the overall design/architecture of VCCV and MPLS. The L2VPN WG will not define new encapsulations, control (set-up, configuration, maintenance or tear-down), or resiliency mechanisms specifically related to pseudowires, because those must be defined by the PWE3 WG. Furthermore, the L2VPN WG will not define protocol inter- working between a VPLS or VPWS and native service-layer control, OAM or or resiliency mechanisms, as those will be defined by the PWE3 WG. On the other hand, the L2VPN WG may define how to operate native service- layer control, IEEE 802.1 OAM or resiliency mechanisms on top of a VPLS or VPWS service. The L2VPN WG scope includes the following: 1. Discovery of PE's participating in a Layer-2 VPN and the associated topology required for connectivity of the VPLS or VPWS service. 2. Signaling of information related to the discovery and membership of PE's within a L2VPN. These procedures must use PWE3 control and management procedures, or define requirements for extensions of PWE3 protocols to suit the needs of an L2VPN. Once those requirements are reviewed by the L2VPN WG, they should be provided to the PWE3 WG to derive solutions. 3. MIB's for Layer-2 VPN solutions. 4. Specification of requirements and framework that will define Operations Administration and Management (OAM) procedures for VPLS and VPWS VPN's, related to the operation of VPLS and VPWS VPN's over IP/MPLS PSN's. In addition, the L2VPN WG will define OAM solutions for VPLS and VPWS VPN's. 5. Mechanisms to permit optimization of multicast data traffic within a VPLS or VPWS VPN over an IP/MPLS PSN. 6. Improved service convergence for multi-homed CE's to VPLS PE's. Specifically, upon failure of a primary path from a CE to VPLS PE, initiate a rapid switch-over to an alternate path. If required, interactions with native service-layer resiliency mechanisms will be provided via solutions from other IETF WG's such as PWE3. 7. Enhancements to increase the scalability of the Control Plane and Data Plane (e.g.: number of PW's and MAC Forwarding Database, respectively) of VPLS PE nodes. 8. Define requirements and solutions for Auto-Discovery and Signaling of Inter-AS VPLS and VPWS L2VPN's, in addition to Inter-AS solutions for multicast-optimized VPLS and VPMS Layer-2 VPN's. The L2VPN WG currently works on the following tasks: - Define MIB's appropriate for each type of Layer-2 VPN. - Specification of Operations Administration and Management (OAM) mechanisms for VPLS, VPWS and IP-only VPN's. - Specification of procedures to permit optimization of L2VPN multicast data traffic within the PSN. - Define enhancements to increase scalability of VPLS PE nodes, to provide aggregation of learned customer MAC addresses at VPLS PE's. - Identify requirements for multi-homing of CE's to VPLS PE's. elements. Based on these requirements, define solutions for achieving fast convergence after a switchover to an alternate path, for example through optimized MAC flushing within a VPLS domain. - Identify requirements for Inter-AS VPLS and VPWS services. Define Inter-AS enhancements to VPLS and VPWS based on these requirements. - Include extensions to L2VPN protocols and RFC's necessary to create an MPLS Transport Profile (MPLS-TP). The work on the MPLS TP needs to be coordinated between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) that are chartered to do MPLS TP work. Where necessary, the WG will coordinate its activities with IEEE 802.1 and ITU. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Sep 2003 May 2006 Provisioning, Autodiscovery, and Signaling in L2VPNs Sep 2004 Jul 2008 L2VPN OAM Requirements and Framework Oct 2004 Jun 2009 ARP Mediation for IP Interworking of Layer 2 VPN Dec 2005 Jul 2009 Multicast in VPLS Jul 2006 Sep 2008 VPLS Interoperability with CE Bridges Jan 2009 Oct 2009 Framework and Requirements for Virtual Private Multicast Service (VPMS) Oct 2009 Oct 2009 VPLS Interoperability with Provider Backbone Bridges Nov 2009 Nov 2009 BGP based Multi-homing in Virtual Private LAN Service Layer 3 Virtual Private Networks (l3vpn) ---------------------------------------- Charter Last Modified: 2009-10-07 Current Status: Active Working Group Chair(s): Marshall Eubanks Danny McPherson Ben Niven-Jenkins Routing Area Director(s): Ross Callon Adrian Farrel Routing Area Advisor: Ross Callon Secretary(ies): Daniel King Mailing Lists: General Discussion:l3vpn@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/l3vpn Archive: http://www.ietf.org/mail-archive/web/l3vpn/current/maillist.html Description of Working Group: This working group is responsible for defining and specifying a limited number of solutions for supporting provider-provisioned Layer-3 (routed) Virtual Private Networks (L3VPNs). The WG is responsible for standardization of the following solutions: 1. BGP/MPLS IP VPNs (based on RFC 2547) 2. IP VPNs using Virtual Routers 3. CE-based VPNs using IPsec The following VPN deployment scenarios will be considered by the WG: 1. Internet-wide: VPN sites attached to arbitrary points in the Internet 2. Single service provider (SP)/single AS: VPN sites attached to the network of a single provider within the scope of a single AS 3. Single SP/multiple AS'es: VPN sites attached to the network of a single provider consisting of multiple AS'es 4. Cooperating SPs: VPN sites attached to networks of different providers that cooperate with each other to provide VPN service The WG will address deployment of the following features in a VPN environment: 1. IP Multicast 2. IPv6 As part of this effort the WG will work on the following tasks (additional work items will require rechartering): 1. Requirements and framework for Layer 3 VPNs 2. Solution documents for each approach listed above (including applicability statements) 3. MIB definitions for each approach 4. Security mechanisms for each approach As a general rule, the WG will not create new protocols, but will provide functional requirements for extensions of the existing protocols that will be discussed in the protocol-specific WGs. L3VPN WG will review proposed protocol extensions for L3VPNs before they are recommended to appropriate protocol-specific WGs. As stated above, the WG will define an IPv6 over BGP / MPLS VPN solution. This will include a forwarding plane component and a control plane component. In the forwarding plane, IPv6 datagrams will be encapsulated within an MPLS header. If any aspect of IPv6 forwarding over MPLS is as yet undefined, the L3VPN WG will defer to the MPLS and appropriate IPv6 WGs. On the control plane, BGP extensions may also need to be defined. In this respect, the L3VPN WG will defer to the IDR and appropriate IPv6 WGs. QoS support is excluded from the charter at this time. It may be considered for inclusion in an updated charter at a later time. Future work items may also include OAM support. Description of Working Group: This working group is responsible for defining and specifying a limited number of solutions for supporting provider-provisioned Layer-3 (routed) Virtual Private Networks (L3VPNs). The WG is responsible for standardization of the following solutions: 1. BGP/MPLS IP VPNs (based on RFC 2547) 2. IP VPNs using Virtual Routers 3. CE-based VPNs using IPsec The following VPN deployment scenarios will be considered by the WG: 1. Internet-wide: VPN sites attached to arbitrary points in the Internet 2. Single service provider (SP)/single AS: VPN sites attached to the network of a single provider within the scope of a single AS 3. Single SP/multiple AS'es: VPN sites attached to the network of a single provider consisting of multiple AS'es 4. Cooperating SPs: VPN sites attached to networks of different providers that cooperate with each other to provide VPN service The WG will address deployment of the following features in a VPN environment: 1. IP Multicast 2. IPv6 As part of this effort the WG will work on the following tasks (additional work items will require rechartering): 1. Requirements and framework for Layer 3 VPNs 2. Solution documents for each approach listed above (including applicability statements) 3. MIB definitions for each approach 4. Security mechanisms for each approach As a general rule, the WG will not create new protocols, but will provide functional requirements for extensions of the existing protocols that will be discussed in the protocol-specific WGs. L3VPN WG will review proposed protocol extensions for L3VPNs before they are recommended to appropriate protocol-specific WGs. As stated above, the WG will define an IPv6 over BGP / MPLS VPN solution. This will include a forwarding plane component and a control plane component. In the forwarding plane, IPv6 datagrams will be encapsulated within an MPLS header. If any aspect of IPv6 forwarding over MPLS is as yet undefined, the L3VPN WG will defer to the MPLS and appropriate IPv6 WGs. On the control plane, BGP extensions may also need to be defined. In this respect, the L3VPN WG will defer to the IDR and appropriate IPv6 WGs. QoS support is excluded from the charter at this time. It may be considered for inclusion in an updated charter at a later time. Future work items may also include OAM support. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jun 2005 Mar 2009 Multicast in MPLS/BGP IP VPNs Aug 2006 Sep 2009 BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs Apr 2008 Aug 2009 Requirements for supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN Sep 2008 Mar 2009 IPv6 Address Specific BGP Extended Communities Attribute Oct 2008 Jun 2009 BGP ACCEPT_OWN Standards Action Community Attribute Oct 2008 Jul 2009 OSPFv3 as a PE-CE routing protocol Nov 2008 Oct 2009 Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution Low Extra Delay Background Transport (ledbat) --------------------------------------------- Charter Last Modified: 2009-08-10 Current Status: Active Working Group Chair(s): Stanislav Shalunov Murari Sridhavan Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Lars Eggert Mailing Lists: General Discussion:ledbat@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ledbat Archive: http://www.ietf.org/mail-archive/web/ledbat Description of Working Group: The LEDBAT WG is chartered to standardize a congestion control mechanism that should saturate the bottleneck, maintain low delay, and yield to standard TCP. Applications that transmit large amounts of data for a long time with congestion-limited TCP, but without AQM, fill the buffer at the head of the bottleneck link. With FIFO queue, this increases the delay experienced by other applications. With buffer of one RTT, the delay doubles. In some cases, the extra delay may be much larger. This is a particularly acute and common case is when P2P applications upload over thin home uplinks: delays in these cases can sometimes be of the order of seconds. The IETF's standard end-to-end transport protocols have not been designed to minimize the extra delay introduced by them into the network. TCP, as a side effect of filling the buffer until it experiences drop-tail loss, effectively maximizes the delay. While this works well for applications that are not delay-sensitive, it harms interactive applications that share the same bottleneck. VoIP and games are particularly affected, but even web browsing may become problematic. LEDBAT is a transport-area WG that will focus on broadly applicable techniques that allow large amounts of data to be consistently transmitted without substantially affecting the delays experienced by other users and applications. The WG will work on the following: (1) An experimental congestion control algorithm for less-than-best-effort "background" transmissions, i.e., an algorithm that attempts to scavenge otherwise idle bandwidth for its transmissions in a way that minimizes interference with regular best-effort traffic. Desired features of such an algorithm are: * saturate the bottleneck * eliminate long standing queues and thus keep delay low when no other traffic is present * quickly yield to traffic sharing the same bottleneck queue that uses standard TCP congestion control * add little to the queueing delays induced by TCP traffic * operate well in networks with FIFO queueing with drop-tail discipline * be deployable for popular applications that currently comprise noticeable fractions of Internet traffic * where available, use explicit congestion notification (ECN), active queue management (AQM), and/or end-to-end differentiated services (DiffServ). Application of this algorithm to existing transport protocols (TCP, SCTP, DCCP) is expected to occur in the working groups that maintain those protocols. Once experience is gained with this congestion control algorithm on the Internet, the WG will consider if it is appropriate to ask the IESG to advance the document as a Proposed Standard. (2) A document that clarifies the current practices of application design and reasons behind them and discusses the tradeoffs surrounding the use of many concurrent TCP connections to one destination and/or to different destinations. Applications routinely open multiple TCP connections. For example, P2P applications maintain connections to a number of different peers while web browsers perform concurrent downloads from the same web server. Application designers pursue different goals when doing so: P2P apps need to maintain a well-connected mesh in the swarm while web browsers mainly use multiple connections to parallelize requests that involve application latency on the web server side. The IETF transport area community is concerned about this practice, because standard Internet congestion control results in different transport connections sharing bottleneck capacity. When an application uses several non-rate-limited transport connections to transfer through a bottleneck, it may obtain a larger fraction of the bottleneck than if it had used fewer connections. Although capacity is the most commonly considered bottleneck resource, middlebox state table entries are also an important resource for an end system communication. Other resource types may exist, and the guidelines are expected to comprehensively discuss them. Applications use a variety of techniques to mitigate these concerns. These techniques have not always been reviewed by the IETF and their interaction with TCP dynamics is poorly understood. The WG will document the known techniques, discussing the consequences and, where appropriate, provide guidance to application designers. Description of Working Group: The LEDBAT WG is chartered to standardize a congestion control mechanism that should saturate the bottleneck, maintain low delay, and yield to standard TCP. Applications that transmit large amounts of data for a long time with congestion-limited TCP, but without AQM, fill the buffer at the head of the bottleneck link. With FIFO queue, this increases the delay experienced by other applications. With buffer of one RTT, the delay doubles. In some cases, the extra delay may be much larger. This is a particularly acute and common case is when P2P applications upload over thin home uplinks: delays in these cases can sometimes be of the order of seconds. The IETF's standard end-to-end transport protocols have not been designed to minimize the extra delay introduced by them into the network. TCP, as a side effect of filling the buffer until it experiences drop-tail loss, effectively maximizes the delay. While this works well for applications that are not delay-sensitive, it harms interactive applications that share the same bottleneck. VoIP and games are particularly affected, but even web browsing may become problematic. LEDBAT is a transport-area WG that will focus on broadly applicable techniques that allow large amounts of data to be consistently transmitted without substantially affecting the delays experienced by other users and applications. The WG will work on the following: (1) An experimental congestion control algorithm for less-than-best-effort "background" transmissions, i.e., an algorithm that attempts to scavenge otherwise idle bandwidth for its transmissions in a way that minimizes interference with regular best-effort traffic. Desired features of such an algorithm are: * saturate the bottleneck * eliminate long standing queues and thus keep delay low when no other traffic is present * quickly yield to traffic sharing the same bottleneck queue that uses standard TCP congestion control * add little to the queueing delays induced by TCP traffic * operate well in networks with FIFO queueing with drop-tail discipline * be deployable for popular applications that currently comprise noticeable fractions of Internet traffic * where available, use explicit congestion notification (ECN), active queue management (AQM), and/or end-to-end differentiated services (DiffServ). Application of this algorithm to existing transport protocols (TCP, SCTP, DCCP) is expected to occur in the working groups that maintain those protocols. Once experience is gained with this congestion control algorithm on the Internet, the WG will consider if it is appropriate to ask the IESG to advance the document as a Proposed Standard. (2) A document that clarifies the current practices of application design and reasons behind them and discusses the tradeoffs surrounding the use of many concurrent TCP connections to one destination and/or to different destinations. Applications routinely open multiple TCP connections. For example, P2P applications maintain connections to a number of different peers while web browsers perform concurrent downloads from the same web server. Application designers pursue different goals when doing so: P2P apps need to maintain a well-connected mesh in the swarm while web browsers mainly use multiple connections to parallelize requests that involve application latency on the web server side. The IETF transport area community is concerned about this practice, because standard Internet congestion control results in different transport connections sharing bottleneck capacity. When an application uses several non-rate-limited transport connections to transfer through a bottleneck, it may obtain a larger fraction of the bottleneck than if it had used fewer connections. Although capacity is the most commonly considered bottleneck resource, middlebox state table entries are also an important resource for an end system communication. Other resource types may exist, and the guidelines are expected to comprehensively discuss them. Applications use a variety of techniques to mitigate these concerns. These techniques have not always been reviewed by the IETF and their interaction with TCP dynamics is poorly understood. The WG will document the known techniques, discussing the consequences and, where appropriate, provide guidance to application designers. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2009 Oct 2009 Low Extra Delay Background Transport (LEDBAT) Enhancements to Internet email to Support Diverse Service Environments (lemonade) --------------------------------------------------------------------------------- Charter Last Modified: 2009-08-20 Current Status: Active Working Group Chair(s): Glenn Parsons Eric Burger Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Alexey Melnikov Secretary(ies): Alexey Melnikov Mailing Lists: General Discussion:lemonade@ietf.org To Subscribe: lemonade-request@ietf.org In Body: in boby 'subscribe' Archive: http://www.ietf.org/mail-archive/web/lemonade/index.html Description of Working Group: Lemonade is tasked to provide a set of enhancements and profiles of Internet email submission, transport, and retrieval protocols to facilitate operation on platforms with constrained resources, or communications links with high latency or limited bandwidth. A primary goal of this work is to ensure that those profiles and enhancements continue to interoperate with the existing Internet email protocols in use on the Internet, so that these environments and more traditional Internet users have access to a seamless service. Lemonade's work is at the crossroads of a body of work related to Internet messaging, in particular work done by the VPIM, FAX, and IMAPEXT IETF working groups. Given the potentially broad scope of activities this group could engage in, the group will focus specifically on the following work items: 0. An informational RFC or RFCs will be produced on LEMONADE architecture and the issues it seeks to address. 1. Enhance the existing IMAP4 message retrieval and message submission (RFC 2476) protocols to satisfy the requirements for handling streaming multimedia content. The existing standards-track CONNEG framework will be used if content negotiation capabilities are needed. The group will employ existing protocols (such as for streaming) with IMAP4 instead of duplicating such functionality within IMAP4. 2. Enhance the existing IMAP4 message retrieval and/or message submission (RFC 2476) protocols to satisfy the requirements for forwarding a message and/or its attachments without downloading the message to the client and subsequently uploading the message to a server. 3. Refine the existing IMAP4 message retrieval protocol to facilitate its use with devices that have limited capabilities such as mobile endpoints. At most one backwards compatible profile of IMAP4 will be produced by this effort. 4. Define a format for message notifications for servers reporting message status information to other servers. Specify the method for delivery of those notifications. 5. Create a specification describing the use of Internet message services in environments where message delivery may take place using either Internet protocols or through an MMS server using WAP to communicate with the receiving user agent. Any protocols defined by this working group will include appopriate security mechanisms, including authentication, privacy, and access control. Mandatory-to-implement security mechanisms will be specified as needed in order to guarantee secure protocol interoperability. The transport area will be consulted to deal with any transport-related issues that arise, especially in regards to items 1-4 above. The IAB is currently working on the specification of general guidelines and requirements for notification services. Once complete this work will be used as input to item 4 above. The working group is aware of several related activities in other groups: - 3GPP TSG T WG2 SWG3 Messaging - W3C Mulitmodal interaction Activity - Open Mobile Alliance - 3GPP2 TSG-X The goal is to coordinate efforts with at least these groups as required. While there is obvious synergy, given the end-of-life of the VPIM and FAX work groups and the similar membership, the working group does not expect to coordinate with these other groups. Description of Working Group: Lemonade is tasked to provide a set of enhancements and profiles of Internet email submission, transport, and retrieval protocols to facilitate operation on platforms with constrained resources, or communications links with high latency or limited bandwidth. A primary goal of this work is to ensure that those profiles and enhancements continue to interoperate with the existing Internet email protocols in use on the Internet, so that these environments and more traditional Internet users have access to a seamless service. Lemonade's work is at the crossroads of a body of work related to Internet messaging, in particular work done by the VPIM, FAX, and IMAPEXT IETF working groups. Given the potentially broad scope of activities this group could engage in, the group will focus specifically on the following work items: 0. An informational RFC or RFCs will be produced on LEMONADE architecture and the issues it seeks to address. 1. Enhance the existing IMAP4 message retrieval and message submission (RFC 2476) protocols to satisfy the requirements for handling streaming multimedia content. The existing standards-track CONNEG framework will be used if content negotiation capabilities are needed. The group will employ existing protocols (such as for streaming) with IMAP4 instead of duplicating such functionality within IMAP4. 2. Enhance the existing IMAP4 message retrieval and/or message submission (RFC 2476) protocols to satisfy the requirements for forwarding a message and/or its attachments without downloading the message to the client and subsequently uploading the message to a server. 3. Refine the existing IMAP4 message retrieval protocol to facilitate its use with devices that have limited capabilities such as mobile endpoints. At most one backwards compatible profile of IMAP4 will be produced by this effort. 4. Define a format for message notifications for servers reporting message status information to other servers. Specify the method for delivery of those notifications. 5. Create a specification describing the use of Internet message services in environments where message delivery may take place using either Internet protocols or through an MMS server using WAP to communicate with the receiving user agent. Any protocols defined by this working group will include appopriate security mechanisms, including authentication, privacy, and access control. Mandatory-to-implement security mechanisms will be specified as needed in order to guarantee secure protocol interoperability. The transport area will be consulted to deal with any transport-related issues that arise, especially in regards to items 1-4 above. The IAB is currently working on the specification of general guidelines and requirements for notification services. Once complete this work will be used as input to item 4 above. The working group is aware of several related activities in other groups: - 3GPP TSG T WG2 SWG3 Messaging - W3C Mulitmodal interaction Activity - Open Mobile Alliance - 3GPP2 TSG-X The goal is to coordinate efforts with at least these groups as required. While there is obvious synergy, given the end-of-life of the VPIM and FAX work groups and the similar membership, the working group does not expect to coordinate with these other groups. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Dec 2005 Jul 2009 Support for Sieve in Internet Message Access Protocol (IMAP4) Locator/ID Separation Protocol (lisp) ------------------------------------- Charter Last Modified: 2009-06-24 Current Status: Active Working Group Chair(s): Sam Hartman Darrel Lewis Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Technical Advisor(s): Joel Halpern Secretary(ies): Terry Manderson Mailing Lists: General Discussion:lisp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lisp Archive: http://www.ietf.org/mail-archive/web/lisp/current/maillist.html Description of Working Group: The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system and the impending exhaustion of the IPv4 address space. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the "locator/identifier separation". The basic idea behind the separation is that the Internet architecture combines two functions, routing locators, (where you are attached to the network) and identifiers (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. LISP supports the separation of the IPv4 and IPv6 address space following a network-based map-and-encapsulate scheme (RFC 1955). In LISP, both identifiers and locators are IP addresses. In LISP, identifiers are composed of two parts: a "global" portion that uniquely identifies a particular site and a "local" portion that identifies an interface within a site. The "local" portion may be subdivided to identify a particular network within the site. For a given identifier, LISP maps the "global" portion of the identifier into a set of locators that can be used by de-capsulation devices to reach the identified interface; as a consequence a host would typically change identifiers when it moves from one site to another or whenever it moves from one subnet to another within an site. Typically, the same IP address will not be used as an identifier and locator in LISP. LISP requires no changes to end-systems or to most routers. LISP aims for an incrementally deployable protocol. A number of approaches are being looked at in parallel in the IRTF and IETF. At this time, these proposals are at an early stage. All proposals (including LISP) have potentially harmful side-effects to Internet traffic carried by the involved routers, have parts where deployment incentives may be lacking, and are NOT RECOMMENDED for deployment beyond experimental situations at this stage. Many of the proposals have components (such as the identifier to locator mapping system) where it is not yet known what kind of design alternative is the best one among many. However, despite these issues it would be valuable to write concrete protocol specifications and develop implementations that can be used to understand the characteristics of these designs. The LISP WG is chartered to work on the LISP base protocol (draft-farinacci-lisp-12.txt), the LISP+ALT mapping system (draft-fuller-lisp-alt-05.txt), LISP Interworking (draft-lewis-lisp-interworking-02.txt), LISP Map Server (draft-fuller-lisp-ms-00.txt), and LISP multicast (draft-farinacci-lisp-multicast-01.txt) for these purposes, with the given drafts as a starting point. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group will also develop security profiles for the ALT and/or other mapping systems. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF (e.g., the Routing Research Group) that attempts to understand which type of a solution is optimal. The LISP WG is NOT chartered to develop the final or standard solution for solving the routing scalability problem. Its specifications are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic. In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic, applications, routers, and security. This analysis will explain what role LISP can play in scalable routing. The analysis should also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on (draft-meyer-loc-id-implications) as well as the manageability and operability of LISP. Description of Working Group: The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system and the impending exhaustion of the IPv4 address space. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the "locator/identifier separation". The basic idea behind the separation is that the Internet architecture combines two functions, routing locators, (where you are attached to the network) and identifiers (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. LISP supports the separation of the IPv4 and IPv6 address space following a network-based map-and-encapsulate scheme (RFC 1955). In LISP, both identifiers and locators are IP addresses. In LISP, identifiers are composed of two parts: a "global" portion that uniquely identifies a particular site and a "local" portion that identifies an interface within a site. The "local" portion may be subdivided to identify a particular network within the site. For a given identifier, LISP maps the "global" portion of the identifier into a set of locators that can be used by de-capsulation devices to reach the identified interface; as a consequence a host would typically change identifiers when it moves from one site to another or whenever it moves from one subnet to another within an site. Typically, the same IP address will not be used as an identifier and locator in LISP. LISP requires no changes to end-systems or to most routers. LISP aims for an incrementally deployable protocol. A number of approaches are being looked at in parallel in the IRTF and IETF. At this time, these proposals are at an early stage. All proposals (including LISP) have potentially harmful side-effects to Internet traffic carried by the involved routers, have parts where deployment incentives may be lacking, and are NOT RECOMMENDED for deployment beyond experimental situations at this stage. Many of the proposals have components (such as the identifier to locator mapping system) where it is not yet known what kind of design alternative is the best one among many. However, despite these issues it would be valuable to write concrete protocol specifications and develop implementations that can be used to understand the characteristics of these designs. The LISP WG is chartered to work on the LISP base protocol (draft-farinacci-lisp-12.txt), the LISP+ALT mapping system (draft-fuller-lisp-alt-05.txt), LISP Interworking (draft-lewis-lisp-interworking-02.txt), LISP Map Server (draft-fuller-lisp-ms-00.txt), and LISP multicast (draft-farinacci-lisp-multicast-01.txt) for these purposes, with the given drafts as a starting point. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group will also develop security profiles for the ALT and/or other mapping systems. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF (e.g., the Routing Research Group) that attempts to understand which type of a solution is optimal. The LISP WG is NOT chartered to develop the final or standard solution for solving the routing scalability problem. Its specifications are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic. In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic, applications, routers, and security. This analysis will explain what role LISP can play in scalable routing. The analysis should also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on (draft-meyer-loc-id-implications) as well as the manageability and operability of LISP. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- May 2009 Sep 2009 LISP for Multicast Environments May 2009 Sep 2009 Locator/ID Separation Protocol (LISP) May 2009 May 2009 Interworking LISP with IPv4 and IPv6 May 2009 May 2009 LISP Alternative Topology (LISP+ALT) May 2009 Oct 2009 LISP Map Server Long-Term Archive and Notary Services (ltans) --------------------------------------------- Charter Last Modified: 2009-09-24 Current Status: Active Working Group Chair(s): Carl Wallace Tobias Gondrom Security Area Director(s): Tim Polk Pasi Eronen Security Area Advisor: Tim Polk Mailing Lists: General Discussion:ltans@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/ltans In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/ltans/current/maillist.html Description of Working Group: In many scenarios, users need to be able to ensure and prove the existence and validity of data, especially digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. Cryptographic means are useful, but they do not provide the whole solution. For example, digital signatures (generated with a particular key size) might become weak over time due to improved computational capabilities, new cryptanalytic attacks might "break" a digital signature algorithm, public key certificates might be revoked or expire, and so on. Complementary methods covering potential weaknesses are necessary. Long-term non-repudiation of digitally signed data is an important aspect of PKI-related standards. Standard mechanisms are needed to handle routine events, such as expiry of signer's public key certificate and expiry of trusted time stamp authority certificate. A single timestamp is not sufficient for this purpose. Additionally, the reliable preservation of content across change of formats, application of electronic notarizations, and subsequent notary services require standard solutions. The objective of the LTANS working group is to define requirements, data structures and protocols for the secure usage of the necessary archive and notary services. First, the requirements for the long-term archive will be collected. Based on that information we will develop a protocol to access archive services supplying long-term non-repudiation for signed documents and define common data structures and formats. Upon completion of the archive-related specifications, we will address 'notary services' in a similar way. The term 'notary services' is not clearly defined. The working group will determine which functions need standards, including transformation of documents from one format to another without losing the value of evidence, electronic notarization, and further verification of legal validity of signed documents. We will determine the needs via the requirements paper and act upon the results accordingly. Work done by the IETF Working Groups PKIX, S/MIME and XMLDSIG will be used as the basis to define those structures and protocols. For example, the Internet-Drafts "Archive Time-Stamps Syntax (ATS)" and "Trusted Archive Protocol (TAP)" and RFC 3029, "Data Validation and Certificate Server Protocols (DVCS)", contain applicable concepts. Description of Working Group: In many scenarios, users need to be able to ensure and prove the existence and validity of data, especially digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. Cryptographic means are useful, but they do not provide the whole solution. For example, digital signatures (generated with a particular key size) might become weak over time due to improved computational capabilities, new cryptanalytic attacks might "break" a digital signature algorithm, public key certificates might be revoked or expire, and so on. Complementary methods covering potential weaknesses are necessary. Long-term non-repudiation of digitally signed data is an important aspect of PKI-related standards. Standard mechanisms are needed to handle routine events, such as expiry of signer's public key certificate and expiry of trusted time stamp authority certificate. A single timestamp is not sufficient for this purpose. Additionally, the reliable preservation of content across change of formats, application of electronic notarizations, and subsequent notary services require standard solutions. The objective of the LTANS working group is to define requirements, data structures and protocols for the secure usage of the necessary archive and notary services. First, the requirements for the long-term archive will be collected. Based on that information we will develop a protocol to access archive services supplying long-term non-repudiation for signed documents and define common data structures and formats. Upon completion of the archive-related specifications, we will address 'notary services' in a similar way. The term 'notary services' is not clearly defined. The working group will determine which functions need standards, including transformation of documents from one format to another without losing the value of evidence, electronic notarization, and further verification of legal validity of signed documents. We will determine the needs via the requirements paper and act upon the results accordingly. Work done by the IETF Working Groups PKIX, S/MIME and XMLDSIG will be used as the basis to define those structures and protocols. For example, the Internet-Drafts "Archive Time-Stamps Syntax (ATS)" and "Trusted Archive Protocol (TAP)" and RFC 3029, "Data Validation and Certificate Server Protocols (DVCS)", contain applicable concepts. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2005 Jul 2009 Long-term Archive Protocol (LTAP) Feb 2007 Aug 2009 Extensible Markup Language Evidence Record Syntax Language Tag Registry Update (ltru) ----------------------------------- Charter Last Modified: 2009-10-19 Current Status: Active Working Group Chair(s): Randy Presuhn Martin Duerst Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Alexey Melnikov Mailing Lists: General Discussion:ltru@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ltru Archive: http://www.ietf.org/mail-archive/web/ltru/current/maillist.html Description of Working Group: The primary language subtags allowed by the current IANA Language Subtag Registry are limited to ISO 639-1 and ISO 639-2 in the same way as they were limited by RFC 3066. This covers approximately 500 possible language subtags. ISO 639-3, scheduled for approval towards the end of 2006, will make available around 7000 more code elements for identifying languages. The working group will prepare an update to the Language Subtag Registry procedures to allow the use of 3-letter code elements from ISO 639-3 as primary language subtags or extended language subtags as appropriate. The working group will also deliver means to update the current IANA Language Subtag Registry with the newly available subtags. The working group will examine, and if necessary clarify or adjust, procedures and guidelines with respect to extended language subtags and variant subtags. Use cases include the identification of signed languages, transliterations, and transcriptions. The working group will also consider how the draft work on ISO 639-6 may relate to the future development of language tags. The working group will clarify text where necessary. It may also make adjustments to the registration process and the form of the registry if this is deemed appropriate based on ongoing registration and operational experience. These adjustments and clarifications are not expected to delay the progress of the work. Work on the drafts is planned to start before ISO 639-3 is fully approved and published. However, the WG will not finalize the drafts before ISO 639-3 is fully approved. Description of Working Group: The primary language subtags allowed by the current IANA Language Subtag Registry are limited to ISO 639-1 and ISO 639-2 in the same way as they were limited by RFC 3066. This covers approximately 500 possible language subtags. ISO 639-3, scheduled for approval towards the end of 2006, will make available around 7000 more code elements for identifying languages. The working group will prepare an update to the Language Subtag Registry procedures to allow the use of 3-letter code elements from ISO 639-3 as primary language subtags or extended language subtags as appropriate. The working group will also deliver means to update the current IANA Language Subtag Registry with the newly available subtags. The working group will examine, and if necessary clarify or adjust, procedures and guidelines with respect to extended language subtags and variant subtags. Use cases include the identification of signed languages, transliterations, and transcriptions. The working group will also consider how the draft work on ISO 639-6 may relate to the future development of language tags. The working group will clarify text where necessary. It may also make adjustments to the registration process and the form of the registry if this is deemed appropriate based on ongoing registration and operational experience. These adjustments and clarifications are not expected to delay the progress of the work. Work on the drafts is planned to start before ISO 639-3 is fully approved and published. However, the WG will not finalize the drafts before ISO 639-3 is fully approved. Internet-Drafts: No Current Internet-Drafts. Mobile Ad-hoc Networks (manet) ------------------------------ Charter Last Modified: 2009-04-22 Current Status: Active Working Group Chair(s): Joseph Macker Ian Chakeres Routing Area Director(s): Ross Callon Adrian Farrel Routing Area Advisor: Ross Callon Mailing Lists: General Discussion:manet@ietf.org To Subscribe: manet-request@ietf.org In Body: subscribe manet Archive: http://www.ietf.org/mail-archive/web/manet/index.html Description of Working Group: The purpose of the MANET working group is to standardize IP routing protocol functionality suitable for wireless routing application within both static and dynamic topologies with increased dynamics due to node motion or other factors. Approaches are intended to be relatively lightweight in nature, suitable for multiple hardware and wireless environments, and address scenarios where MANETs are deployed at the edges of an IP infrastructure. Hybrid mesh infrastructures (e.g., a mixture of fixed and mobile routers) should also be supported by MANET specifications and management features. Using mature components from previous work on experimental reactive and proactive protocols, the WG will develop two Standards track routing protocol specifications: - Reactive MANET Protocol (RMP) - Proactive MANET Protocol (PMP) If significant commonality between RMRP and PMRP protocol modules is observed, the WG may decide to go with a converged approach. Both IPv4 and IPv6 will be supported. Routing security requirements and issues will also be addressed. The MANET WG will also develop a scoped forwarding protocol that can efficiently flood data packets to all participating MANET nodes. The primary purpose of this mechanism is a simplified best effort multicast forwarding function. The use of this protocol is intended to be applied ONLY within MANET routing areas and the WG effort will be limited to routing layer design issues. The MANET WG will pay attention to the OSPF-MANET protocol work within the OSPF WG and IRTF work that is addressing research topics related to MANET environments. Description of Working Group: The purpose of the MANET working group is to standardize IP routing protocol functionality suitable for wireless routing application within both static and dynamic topologies with increased dynamics due to node motion or other factors. Approaches are intended to be relatively lightweight in nature, suitable for multiple hardware and wireless environments, and address scenarios where MANETs are deployed at the edges of an IP infrastructure. Hybrid mesh infrastructures (e.g., a mixture of fixed and mobile routers) should also be supported by MANET specifications and management features. Using mature components from previous work on experimental reactive and proactive protocols, the WG will develop two Standards track routing protocol specifications: - Reactive MANET Protocol (RMP) - Proactive MANET Protocol (PMP) If significant commonality between RMRP and PMRP protocol modules is observed, the WG may decide to go with a converged approach. Both IPv4 and IPv6 will be supported. Routing security requirements and issues will also be addressed. The MANET WG will also develop a scoped forwarding protocol that can efficiently flood data packets to all participating MANET nodes. The primary purpose of this mechanism is a simplified best effort multicast forwarding function. The use of this protocol is intended to be applied ONLY within MANET routing areas and the WG effort will be limited to routing layer design issues. The MANET WG will pay attention to the OSPF-MANET protocol work within the OSPF WG and IRTF work that is addressing research topics related to MANET environments. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2005 Jul 2009 Simplified Multicast Forwarding Oct 2005 Sep 2009 The Optimized Link State Routing Protocol version 2 Jun 2006 Oct 2009 Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) May 2008 Oct 2009 Definition of Managed Objects for the DYMO Manet Routing Protocol Apr 2009 Oct 2009 Definition of Managed Objects for the Manet Simplified Multicast Framework Relay Set Process May 2009 Nov 2009 Definition of Managed Objects for the Neighborhood Discovery Protocol May 2009 Nov 2009 Definition of Managed Objects for the MANET Optimized Link State Routing Protocol version 2 MBONE Deployment (mboned) ------------------------- Charter Last Modified: 2009-01-28 Current Status: Active Working Group Chair(s): Marshall Eubanks Greg Shepherd Leonard Giuliano Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Ronald Bonica Technical Advisor(s): Scott Bradner Mailing Lists: General Discussion:mboned@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mboned Archive: http://www.ietf.org/mail-archive/web/mboned Description of Working Group: The MBONE Deployment Working Group is a forum for coordinating the deployment, engineering, and operation of multicast routing protocols and procedures in the global Internet. This activity will include, but not be limited to: - Documenting deployment of multicast routing in the global Internet. - Receive regular reports on the current state of the deployment of multicast technology. Create "practice and experience" documents that capture the experience of those who have deployed and are deploying various multicast technologies. - Based on reports and other information, provide feedback to other relevant working groups. - Develop mechanisms and procedures for sharing operational information to aid in operation of the multicast backbones and interconnects. - Update RFC 3171/BCP 51 based on experience. - Develop a roadmap informational RFC that describes the current IPv4 and IPv6 IETF multicast architectures, including references to the relevant IETF documents and guidance for implementers and network operators. - Complete the MSDP MIB This is not meant to be a protocol development Working Group. Description of Working Group: The MBONE Deployment Working Group is a forum for coordinating the deployment, engineering, and operation of multicast routing protocols and procedures in the global Internet. This activity will include, but not be limited to: - Documenting deployment of multicast routing in the global Internet. - Receive regular reports on the current state of the deployment of multicast technology. Create "practice and experience" documents that capture the experience of those who have deployed and are deploying various multicast technologies. - Based on reports and other information, provide feedback to other relevant working groups. - Develop mechanisms and procedures for sharing operational information to aid in operation of the multicast backbones and interconnects. - Update RFC 3171/BCP 51 based on experience. - Develop a roadmap informational RFC that describes the current IPv4 and IPv6 IETF multicast architectures, including references to the relevant IETF documents and guidance for implementers and network operators. - Complete the MSDP MIB This is not meant to be a protocol development Working Group. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Nov 2003 Nov 2009 IANA Guidelines for IPv4 Multicast Address Assignments Nov 2004 Aug 2009 Overview of the Internet Multicast Addressing Architecture Apr 2005 Jul 2009 Requirements for Multicast AAA coordinated between Content Provider(s) and Network Service Provider(s) Apr 2006 Aug 2009 AAA and Admission Control Framework for Multicasting Dec 2006 Oct 2009 Lightweight IGMPv3 and MLDv2 Protocols Nov 2007 Oct 2009 Mtrace Version 2: Traceroute Facility for IP Multicast Oct 2008 Oct 2009 Requirements for IP Multicast Session Announcement Media Server Control (mediactrl) -------------------------------- Charter Last Modified: 2009-11-09 Current Status: Active Working Group Chair(s): Spencer Dawkins Eric Burger Real-time Applications and Infrastructure Area Director(s): Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: General Discussion:mediactrl@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mediactrl Archive: http://www.ietf.org/mail-archive/web/mediactrl Description of Working Group: Real-time multi-media applications often need the services of media processing elements. It is true that modern endpoints are capable of media processing. However, the physics of some media processing applications dictate that it is much more efficient for the media processing to occur at a centralized location. By media processing, we mean media mixing, recording and playing media, and interacting with a user in the audio or video domains. The commercial market calls these media processing network elements "media servers." Some services achieve significant efficiencies when a central node performs media processing. Because of these efficiencies, media servers are widely used for conference mixing, multimedia messaging, content rendering, and speech, voice, key press, and other audio and video input and output user interface modalities. Given the wide acceptance of the media server, we need a standard way to control them. Since the media server is a centralized component, the work group will not investigate distributed media processing algorithms or control protocols. A media server contains media processing components that are able to manipulate RTP streams. Typical processing includes mixing multiple streams, transcoding a stream (e.g., from G.711 to MS-GSM), storing or retrieving a stream (e.g., from RTP to HTTP), detecting tones (e.g., DTMF), converting text to speech, and performing speech recognition. Note that an MRCPv2 server may offer the low-level processing for the last two services, where the media server is a client to the MRCPv2 server. Also note it is common to call the package of detecting user input, recording media, and playing media "Interactive Voice Response," or IVR. Media services offered by the media server are addressed using SIP mechanisms, such as described in RFC 4240. Media servers commonly have a built-in VoiceXML interpreter. VoiceXML describes the elements of the user interaction, and is a proven model for separating application logic (which run on the clients of the media server) from the user interface (which the media server renders). Note this is a fundamentally different interaction model from MRCPv2, where media processing engines offer raw, low-level speech services. The work group will examine protocol extensions between media servers and their clients. However, modifying existing standard protocols, such as VoiceXML or SIP towards clients or MRCPv2 towards servers, is not in the work group's charter. The model of interest to this group is where the endpoint solely plays audio or video, transmits audio or video towards the server, and possibly transmits key press information towards the server. Alternate architectures, where the endpoint executes user interface commands, is outside the scope of the work group. For example, WIDEX/BEEP, with its distributed user interface description, is not in scope. The only model of user interface processing the work group will consider is where the media server performs all of the media processing. A caveat here is the media server, in interpreting a VoiceXML page, may make requests to a server for speech services. However, to the media server client and the media end point, the single point of signaling and media interaction is the media server. Any protocol developed by this group will meet the requirements for Internet deployment. This includes addressing Internet security, privacy, congestion control (or at least congestion safe), operational and manageability considerations, and scale. The protocol will not assume a private administrative domain. There is broad market acceptance of the stimulus/markup application design model for the application server - media server protocol interface. Thus this work group will focus on the use of SIP and XML for the protocol suite. The work product of this group includes the following: 1. A requirements document. This document will identify and enumerate requirements for a suite of media server control protocols. Given that one of the common media server clients is a conference application server, we will consider the application server - media server requirements developed by the XCON work group. Likewise, we will consider media server control requirements from other standards groups, such as 3GPP SA2 and CT1. 2. A framework document. This document will describe the different network elements, their interrelationship, and the broad set of message flows between them. 3. A protocol suite describing the embodiment of the framework document. There may be separate protocol PDU's for audio conference control, video conference control, interactive audio (voice) response, and interactive video (multimedia) response. The separation and negotiation of different PDU's is a working group topic. However, there will be one and only one (class) of PDU's defined by the work group. 4. Means for locating, and possibly establishing sessions to, media servers with appropriate resources at the request of clients. By appropriate, we mean the characteristics of a given media server required or desired for handling a given request. The expectation is such a means would build upon existing SIP, SNMP, and other protocol facilities. Such a means may or may not be an integral part of the item 3 deliverables above. This deliverable is an operational protocol that may rely on management protocols such as SNMP. We are neither creating a new management protocol nor a new provisioning protocol. Given the above-mentioned conferencing example, the work of this group is of interest to the XCON work group, as this protocol will describe the "Protocol used between the conference controller and the mixer (s)." Thus we expect to work closely with XCON. The protocol suite also is a possible embodiment of the ISC/Mr interface from the 3GPP IMS architecture. Thus we expect to gather requirements from, 3GPP, notably SA2, CT1, and CT4. ATIS and ETSI TISPAN have considered a functional element known as a media resource broker. The media resource broker provides the functionality described by deliverable #4, above. Thus we expect to gather requirements from ATIS and ETSI TISPAN. The Java Community Process has chartered work on a Java Media Server Control (JMSC) API, known as JSR 309. We expect to gather requirements from JCP, as well. Because of the vast experience with conferencing protocols and payloads, we expect considerable interaction with AVT and MMUSIC. If the work group requires extensions to SIP, the work group will forward those extensions to the SIP work group for consideration and refinement. Description of Working Group: Real-time multi-media applications often need the services of media processing elements. It is true that modern endpoints are capable of media processing. However, the physics of some media processing applications dictate that it is much more efficient for the media processing to occur at a centralized location. By media processing, we mean media mixing, recording and playing media, and interacting with a user in the audio or video domains. The commercial market calls these media processing network elements "media servers." Some services achieve significant efficiencies when a central node performs media processing. Because of these efficiencies, media servers are widely used for conference mixing, multimedia messaging, content rendering, and speech, voice, key press, and other audio and video input and output user interface modalities. Given the wide acceptance of the media server, we need a standard way to control them. Since the media server is a centralized component, the work group will not investigate distributed media processing algorithms or control protocols. A media server contains media processing components that are able to manipulate RTP streams. Typical processing includes mixing multiple streams, transcoding a stream (e.g., from G.711 to MS-GSM), storing or retrieving a stream (e.g., from RTP to HTTP), detecting tones (e.g., DTMF), converting text to speech, and performing speech recognition. Note that an MRCPv2 server may offer the low-level processing for the last two services, where the media server is a client to the MRCPv2 server. Also note it is common to call the package of detecting user input, recording media, and playing media "Interactive Voice Response," or IVR. Media services offered by the media server are addressed using SIP mechanisms, such as described in RFC 4240. Media servers commonly have a built-in VoiceXML interpreter. VoiceXML describes the elements of the user interaction, and is a proven model for separating application logic (which run on the clients of the media server) from the user interface (which the media server renders). Note this is a fundamentally different interaction model from MRCPv2, where media processing engines offer raw, low-level speech services. The work group will examine protocol extensions between media servers and their clients. However, modifying existing standard protocols, such as VoiceXML or SIP towards clients or MRCPv2 towards servers, is not in the work group's charter. The model of interest to this group is where the endpoint solely plays audio or video, transmits audio or video towards the server, and possibly transmits key press information towards the server. Alternate architectures, where the endpoint executes user interface commands, is outside the scope of the work group. For example, WIDEX/BEEP, with its distributed user interface description, is not in scope. The only model of user interface processing the work group will consider is where the media server performs all of the media processing. A caveat here is the media server, in interpreting a VoiceXML page, may make requests to a server for speech services. However, to the media server client and the media end point, the single point of signaling and media interaction is the media server. Any protocol developed by this group will meet the requirements for Internet deployment. This includes addressing Internet security, privacy, congestion control (or at least congestion safe), operational and manageability considerations, and scale. The protocol will not assume a private administrative domain. There is broad market acceptance of the stimulus/markup application design model for the application server - media server protocol interface. Thus this work group will focus on the use of SIP and XML for the protocol suite. The work product of this group includes the following: 1. A requirements document. This document will identify and enumerate requirements for a suite of media server control protocols. Given that one of the common media server clients is a conference application server, we will consider the application server - media server requirements developed by the XCON work group. Likewise, we will consider media server control requirements from other standards groups, such as 3GPP SA2 and CT1. 2. A framework document. This document will describe the different network elements, their interrelationship, and the broad set of message flows between them. 3. A protocol suite describing the embodiment of the framework document. There may be separate protocol PDU's for audio conference control, video conference control, interactive audio (voice) response, and interactive video (multimedia) response. The separation and negotiation of different PDU's is a working group topic. However, there will be one and only one (class) of PDU's defined by the work group. 4. Means for locating, and possibly establishing sessions to, media servers with appropriate resources at the request of clients. By appropriate, we mean the characteristics of a given media server required or desired for handling a given request. The expectation is such a means would build upon existing SIP, SNMP, and other protocol facilities. Such a means may or may not be an integral part of the item 3 deliverables above. This deliverable is an operational protocol that may rely on management protocols such as SNMP. We are neither creating a new management protocol nor a new provisioning protocol. Given the above-mentioned conferencing example, the work of this group is of interest to the XCON work group, as this protocol will describe the "Protocol used between the conference controller and the mixer (s)." Thus we expect to work closely with XCON. The protocol suite also is a possible embodiment of the ISC/Mr interface from the 3GPP IMS architecture. Thus we expect to gather requirements from, 3GPP, notably SA2, CT1, and CT4. ATIS and ETSI TISPAN have considered a functional element known as a media resource broker. The media resource broker provides the functionality described by deliverable #4, above. Thus we expect to gather requirements from ATIS and ETSI TISPAN. The Java Community Process has chartered work on a Java Media Server Control (JMSC) API, known as JSR 309. We expect to gather requirements from JCP, as well. Because of the vast experience with conferencing protocols and payloads, we expect considerable interaction with AVT and MMUSIC. If the work group requires extensions to SIP, the work group will forward those extensions to the SIP work group for consideration and refinement. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Sep 2007 Oct 2009 Media Control Channel Framework Jun 2008 Mar 2009 An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework Jul 2008 May 2009 A Mixer Control Package for the Media Control Channel Framework Mar 2009 Oct 2009 Media Control Channel Framework (CFW) Call Flow Examples May 2009 Sep 2009 Media Resource Brokering Mobility EXTensions for IPv6 (mext) ----------------------------------- Charter Last Modified: 2009-08-06 Current Status: Active Working Group Chair(s): Julien Laganier Marcelo Bagnulo Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:mext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mext Archive: http://www.ietf.org/mail-archive/web/mext Description of Working Group: Mobile IPv6 specifies routing support which permits an IPv6 host to continue using its home address as it moves around the Internet, enabling continuity of sessions. Mobile IPv6 supports transparency above the IP layer, including maintenance of active transport level sessions. In addition, network mobility (NEMO) mechanisms built on top of Mobile IPv6 allow managing the mobility of an entire network, as it changes its point of attachment to the Internet. The base specifications consist of: o RFC 3775 (Mobile IPv6) o RFC 3963 (NEMO) o RFC 4877 (Mobile IPv6 Operation with IKEv2) The MEXT Working Group continues the work of the former MIP6, NEMO, and MONAMI6 Working Groups. The primary goal of MEXT will be to (A) enhance base IPv6 mobility by continuing work on developments that are required for wide-scale deployments and specific deployment scenarios. Additionally, (B) the working group will ensure that any issues identified by implementation and interoperability experience are addressed, and that the base specifications are maintained. (C) The group will also produce informational documentation, such as design rationale documents or description of specific issues within the protocol. Deployment considerations call for (A.1) solutions to enable dual-stack operation, (A.2) mechanisms to support high-availability home agents, (A.3) allowing the use of multiple interfaces in mobile nodes, (A.4) ways to employ Mobile IPv6 in the presence of firewalls, (A.5) address the specific needs of automotive and aviation communities for route optimisation in network mobility, (A.6) support for AAA is needed as a continuation of earlier work on bootstrapping, (A.7) revocation of binding, (A.8) generic notification message format and (A.9) extended DMSIP home network support . Work items related to large scale deployment include: (A.1) A Solution for Mobile IPv6 and NEMO session continuity for dual stack hosts which attach to IPv4 access networks. Additionally provide a mechanism for carrying IPv4 packets via the Home agent for Mobile IPv6 or NEMO capable dual-stack hosts. (A.2) A protocol based solution for enhancing the reliability of home agents and a method to force a host/router to switch home agents. A mechanism to force an MN to switch the HA that is currently serving it. This is required in deployments where the HA needs to be taken offline for maintenance. (A.3) Use of multiple interfaces. Today, the protocols do not provide suppport for simultaneous differentiated use of multiple access technologies. Several proposals exist for such support, and some of them have been implemented and tested. When a mobile host/router uses multiple network interfaces simultaneously, or when multiple prefixes are available on a single network interface, the mobile host/router would end up with multiple Care-of Addresses (CoAs). In addition, the Home Agent might be attached to multiple network interfaces, or to a single network interface with multiple prefixes, hence resulting in the option to use multiple IP addresses for the Home Agent. This could result in the possibility of using a multitude of bi-directional tunnels between pairs of {Home Agent address, CoA} and a number of associated issues: establishment, selection and modification of multiple simultaneous tunnels. The objective of the WG is to produce a clear problem statement and to produce standard track specifications to the problems associated with the simultaneous use of multiple addresses for either mobile hosts using Mobile IPv6 or mobile routers using NEMO Basic Support and their variants (FMIPv6, HMIPv6, etc). Where the effects of having multiple prefixes on a single interface is identical to the effects of having multiple interfaces each with a single prefix, the WG will consider a generalized approach to cater for multiple prefixes available to a mobile host/router. The WG uses existing tunneling mechanisms defined for Mobile IPv6. The involved nodes need to select which tunnel instance to use when multiple ones are available due to multiple addresses on either end. But the WG does not plan to define a new mechanism for this, but rather document how to use existing mechanisms based upon preferences or policies. In particular, the WG will consider that a tunnel is alive as long as packets can be exchanged with the corresponding peer. In addition, local information, such as interface up/down events, or other failure detection mechanisms can be used to quickly detect failure of tunnel(s). Deliverables related to this include - A document explaining the motivations for a node using multiple interfaces and the scenarios where it may end up with multiple global addresses on its interfaces [Informational] - An analysis document explaining what are the limitations for mobile hosts using multiple simultaneous Care-of Addresses and Home Agent addresses using Mobile IPv6, whether issues are specific to Mobile IPv6 or not [Informational]. - A protocol extension to support the registration of multiple Care-of Addresses at a given Home Agent address [Standard Track]. - A "Flow/binding policies exchange" solution for an exchange of policies from the mobile host/router to the Home Agent and from the Home Agent to the mobile host/router influencing the choice of the Care-of Address and Home Agent address. The solution involves two specifications, one for the policy format and another for its transport [both Standard Track]. (A.4) Work on solutions to deal with firewalls and the problems that firewalls cause as identified in RFC 4487. (A.5) Route optimization of network mobility. Three use cases have been identified for this. These are called the Aviation case, the Automotive case, and the Personal Mobile Router (consumer electronics) case, though the actual technical problems are characterized by the type of movements and environments more than by the specific industry using the technology. The group will explore these cases to gather requirements and proceed with solving the open issues. (1) Airline and spacecraft community, who are deploying NEMO for control systems, as well as Internet connectivity and entertainment systems. This use case is characterized by fast (~ 1000 km/h) moving objects over large distances (across continents). The main technical problem is that tunneling-based solutions imply a roundtrip to another continent and that BGP based solutions imply significant churn in the global Internet routing table. (2) Automotive industry who are deploying NEMO for in-car communication, entertainment, and data gathering, possible control systems use, and communication to roadside devices. This use case is characterized by moderately fast (~ 100-300 km/h) moving objects that employ local or cellular networks for connectivity. (3) Personal Mobile Routers, which are consumer devices that allow the user to bring a NEMO network with the user while mobile, and communicate with peer NEMO Basic Support nodes and nodes served by them. After gathering the requirements for these types of deployments, the working group will evaluate what type of route optimization needs to be performed (if any), and formulate a solution to those problems. If no requirements for those scenarios can be collected by the deadline, it will be assumed that the work is premature, and that type of deployment will be dropped from the WG. The group will only consider airline and spacecraft solutions that combine tunneling solutions for small movements with either federated tunnel servers or slowly changing end host prefixes. The group will only consider personal mobile router requirements about optimized routes to another mobile router belonging to the same operator. The group will only consider automotive industry requirements to allow MR-attached hosts to directly access the network where MR has attached to. Work on automotive and personal mobile router solutions requires rechartering. The WG will not consider extensions to routing protocols. The group will not consider general multi-homing problems that are not related to the deployment and maintenance of Mobile IPv6 or NEMO Basic Support protocols. The group will also not consider general route optimization, or other problems that are not related to the deployment and maintenance of NEMO Basic Support protocols. Similarly, the group will not consider or rely on the results of general routing architecture, Internet architecture, or identifier-locator split issues that are discussed in separate, long term efforts elsewhere in the IETF. Finally, the group will not consider solutions that require changes from correspondent nodes in the general Internet (A.6) Bootstrapping mechanisms developed earlier in the MIP6 WG require AAA support for Mobile IPv6. Part of this work is already being done in the DIME WG, but the MEXT WG is chartered to complete a design for RADIUS. (A.7) Binding Revocation for IP Mobility: Define a binding revocation mechanism for Mobile IPv6 and its extensions. This mechanism can be used by any entity involved in the base Mobile IPv6 protocol or one of its extensions to request its corresponding entity to terminate either one, multiple or all binding cache entries. (A.8) Generic Notification Message for Mobile IPv6: A proposal for defining generic notification framework that can be used by the mobility entities for sending and receiving asynchronous notification messages was proposed and the same was adopted by the WG. (A.9) Extended DSMIPv6 Home Network Support: DSMIPv6 assumes the home network to be dual stack providing simultaneous IPv6 and IPv4 network access. It is proposed to extend DSMIPv6 to support home networks which provides IPv4, or IPv6 respectively, direct network access only, but where virtual IPv6 home network connectivity, or virtual IPv4 home network connectivity respectively, may be obtained by tunneling to the HA. The latter shall be obtained by DSMIPv6 operation using the v4HoA address as Care-of-address for the v6HoA address, and vice versa, the v6HoA address as care-of-address for the v4HoA address. Work items related to base specification maintenance include: (B.1) Create and maintain issue lists that are generated on the basis of implementation and interoperability experience. Address specific issues with specific updates or revisions of the base specification. One specific area of concern that should be analyzed and addressed relates to multilink subnets. This work item relates only to corrections and clarifications. The working group shall not revisit design decisions or change the protocol. (B.2) Update the IANA considerations of RFC 3775 to allow extensions for experimental purposes as well passing of optional vendor-specific information. (B.3) Finish working group documents that are currently in process, and submit for RFC. This includes prefix delegation protocol mechanism for network mobility, and a MIB for NEMO Basic Support. Work items related to informational documentation include: (C.1) Produce a design rationale that documents the historical thinking behind the introduction of an alternative security mechanism, the Authentication Protocol (RFC 4285). (C.2) Virtual Home Link configuration for Mobile IPv6: A proposal has been made on Mobile IPv6 home link configuration on virtual links. The proposal does not describe any new protocol, but provides the operational and configuration details and additionally provides implementation guidance for achieving this configuration. The group employs IPsec and IKE as a security mechanism. The group shall refrain, however, from making generic extensions to these protocols. Any proposed extension must be reviewed by the INT and SEC ADs before it can be accepted as a part of a work item. Description of Working Group: Mobile IPv6 specifies routing support which permits an IPv6 host to continue using its home address as it moves around the Internet, enabling continuity of sessions. Mobile IPv6 supports transparency above the IP layer, including maintenance of active transport level sessions. In addition, network mobility (NEMO) mechanisms built on top of Mobile IPv6 allow managing the mobility of an entire network, as it changes its point of attachment to the Internet. The base specifications consist of: o RFC 3775 (Mobile IPv6) o RFC 3963 (NEMO) o RFC 4877 (Mobile IPv6 Operation with IKEv2) The MEXT Working Group continues the work of the former MIP6, NEMO, and MONAMI6 Working Groups. The primary goal of MEXT will be to (A) enhance base IPv6 mobility by continuing work on developments that are required for wide-scale deployments and specific deployment scenarios. Additionally, (B) the working group will ensure that any issues identified by implementation and interoperability experience are addressed, and that the base specifications are maintained. (C) The group will also produce informational documentation, such as design rationale documents or description of specific issues within the protocol. Deployment considerations call for (A.1) solutions to enable dual-stack operation, (A.2) mechanisms to support high-availability home agents, (A.3) allowing the use of multiple interfaces in mobile nodes, (A.4) ways to employ Mobile IPv6 in the presence of firewalls, (A.5) address the specific needs of automotive and aviation communities for route optimisation in network mobility, (A.6) support for AAA is needed as a continuation of earlier work on bootstrapping, (A.7) revocation of binding, (A.8) generic notification message format and (A.9) extended DMSIP home network support . Work items related to large scale deployment include: (A.1) A Solution for Mobile IPv6 and NEMO session continuity for dual stack hosts which attach to IPv4 access networks. Additionally provide a mechanism for carrying IPv4 packets via the Home agent for Mobile IPv6 or NEMO capable dual-stack hosts. (A.2) A protocol based solution for enhancing the reliability of home agents and a method to force a host/router to switch home agents. A mechanism to force an MN to switch the HA that is currently serving it. This is required in deployments where the HA needs to be taken offline for maintenance. (A.3) Use of multiple interfaces. Today, the protocols do not provide suppport for simultaneous differentiated use of multiple access technologies. Several proposals exist for such support, and some of them have been implemented and tested. When a mobile host/router uses multiple network interfaces simultaneously, or when multiple prefixes are available on a single network interface, the mobile host/router would end up with multiple Care-of Addresses (CoAs). In addition, the Home Agent might be attached to multiple network interfaces, or to a single network interface with multiple prefixes, hence resulting in the option to use multiple IP addresses for the Home Agent. This could result in the possibility of using a multitude of bi-directional tunnels between pairs of {Home Agent address, CoA} and a number of associated issues: establishment, selection and modification of multiple simultaneous tunnels. The objective of the WG is to produce a clear problem statement and to produce standard track specifications to the problems associated with the simultaneous use of multiple addresses for either mobile hosts using Mobile IPv6 or mobile routers using NEMO Basic Support and their variants (FMIPv6, HMIPv6, etc). Where the effects of having multiple prefixes on a single interface is identical to the effects of having multiple interfaces each with a single prefix, the WG will consider a generalized approach to cater for multiple prefixes available to a mobile host/router. The WG uses existing tunneling mechanisms defined for Mobile IPv6. The involved nodes need to select which tunnel instance to use when multiple ones are available due to multiple addresses on either end. But the WG does not plan to define a new mechanism for this, but rather document how to use existing mechanisms based upon preferences or policies. In particular, the WG will consider that a tunnel is alive as long as packets can be exchanged with the corresponding peer. In addition, local information, such as interface up/down events, or other failure detection mechanisms can be used to quickly detect failure of tunnel(s). Deliverables related to this include - A document explaining the motivations for a node using multiple interfaces and the scenarios where it may end up with multiple global addresses on its interfaces [Informational] - An analysis document explaining what are the limitations for mobile hosts using multiple simultaneous Care-of Addresses and Home Agent addresses using Mobile IPv6, whether issues are specific to Mobile IPv6 or not [Informational]. - A protocol extension to support the registration of multiple Care-of Addresses at a given Home Agent address [Standard Track]. - A "Flow/binding policies exchange" solution for an exchange of policies from the mobile host/router to the Home Agent and from the Home Agent to the mobile host/router influencing the choice of the Care-of Address and Home Agent address. The solution involves two specifications, one for the policy format and another for its transport [both Standard Track]. (A.4) Work on solutions to deal with firewalls and the problems that firewalls cause as identified in RFC 4487. (A.5) Route optimization of network mobility. Three use cases have been identified for this. These are called the Aviation case, the Automotive case, and the Personal Mobile Router (consumer electronics) case, though the actual technical problems are characterized by the type of movements and environments more than by the specific industry using the technology. The group will explore these cases to gather requirements and proceed with solving the open issues. (1) Airline and spacecraft community, who are deploying NEMO for control systems, as well as Internet connectivity and entertainment systems. This use case is characterized by fast (~ 1000 km/h) moving objects over large distances (across continents). The main technical problem is that tunneling-based solutions imply a roundtrip to another continent and that BGP based solutions imply significant churn in the global Internet routing table. (2) Automotive industry who are deploying NEMO for in-car communication, entertainment, and data gathering, possible control systems use, and communication to roadside devices. This use case is characterized by moderately fast (~ 100-300 km/h) moving objects that employ local or cellular networks for connectivity. (3) Personal Mobile Routers, which are consumer devices that allow the user to bring a NEMO network with the user while mobile, and communicate with peer NEMO Basic Support nodes and nodes served by them. After gathering the requirements for these types of deployments, the working group will evaluate what type of route optimization needs to be performed (if any), and formulate a solution to those problems. If no requirements for those scenarios can be collected by the deadline, it will be assumed that the work is premature, and that type of deployment will be dropped from the WG. The group will only consider airline and spacecraft solutions that combine tunneling solutions for small movements with either federated tunnel servers or slowly changing end host prefixes. The group will only consider personal mobile router requirements about optimized routes to another mobile router belonging to the same operator. The group will only consider automotive industry requirements to allow MR-attached hosts to directly access the network where MR has attached to. Work on automotive and personal mobile router solutions requires rechartering. The WG will not consider extensions to routing protocols. The group will not consider general multi-homing problems that are not related to the deployment and maintenance of Mobile IPv6 or NEMO Basic Support protocols. The group will also not consider general route optimization, or other problems that are not related to the deployment and maintenance of NEMO Basic Support protocols. Similarly, the group will not consider or rely on the results of general routing architecture, Internet architecture, or identifier-locator split issues that are discussed in separate, long term efforts elsewhere in the IETF. Finally, the group will not consider solutions that require changes from correspondent nodes in the general Internet (A.6) Bootstrapping mechanisms developed earlier in the MIP6 WG require AAA support for Mobile IPv6. Part of this work is already being done in the DIME WG, but the MEXT WG is chartered to complete a design for RADIUS. (A.7) Binding Revocation for IP Mobility: Define a binding revocation mechanism for Mobile IPv6 and its extensions. This mechanism can be used by any entity involved in the base Mobile IPv6 protocol or one of its extensions to request its corresponding entity to terminate either one, multiple or all binding cache entries. (A.8) Generic Notification Message for Mobile IPv6: A proposal for defining generic notification framework that can be used by the mobility entities for sending and receiving asynchronous notification messages was proposed and the same was adopted by the WG. (A.9) Extended DSMIPv6 Home Network Support: DSMIPv6 assumes the home network to be dual stack providing simultaneous IPv6 and IPv4 network access. It is proposed to extend DSMIPv6 to support home networks which provides IPv4, or IPv6 respectively, direct network access only, but where virtual IPv6 home network connectivity, or virtual IPv4 home network connectivity respectively, may be obtained by tunneling to the HA. The latter shall be obtained by DSMIPv6 operation using the v4HoA address as Care-of-address for the v6HoA address, and vice versa, the v6HoA address as care-of-address for the v4HoA address. Work items related to base specification maintenance include: (B.1) Create and maintain issue lists that are generated on the basis of implementation and interoperability experience. Address specific issues with specific updates or revisions of the base specification. One specific area of concern that should be analyzed and addressed relates to multilink subnets. This work item relates only to corrections and clarifications. The working group shall not revisit design decisions or change the protocol. (B.2) Update the IANA considerations of RFC 3775 to allow extensions for experimental purposes as well passing of optional vendor-specific information. (B.3) Finish working group documents that are currently in process, and submit for RFC. This includes prefix delegation protocol mechanism for network mobility, and a MIB for NEMO Basic Support. Work items related to informational documentation include: (C.1) Produce a design rationale that documents the historical thinking behind the introduction of an alternative security mechanism, the Authentication Protocol (RFC 4285). (C.2) Virtual Home Link configuration for Mobile IPv6: A proposal has been made on Mobile IPv6 home link configuration on virtual links. The proposal does not describe any new protocol, but provides the operational and configuration details and additionally provides implementation guidance for achieving this configuration. The group employs IPsec and IKE as a security mechanism. The group shall refrain, however, from making generic extensions to these protocols. Any proposed extension must be reviewed by the INT and SEC ADs before it can be accepted as a part of a work item. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jun 2006 Jul 2009 Home Agent Reliability Protocol May 2008 Nov 2009 Flow Bindings in Mobile IPv6 and NEMO Basic Support Jun 2008 Oct 2009 Mobility Support in IPv6 Jun 2008 Oct 2009 DHCPv6 Prefix Delegation for NEMO Jul 2008 Oct 2009 Binding Revocation for IPv6 Mobility Oct 2008 Oct 2009 Guidelines for firewall administrators regarding MIPv6 traffic Oct 2008 Oct 2009 Guidelines for firewall vendors regarding MIPv6 traffic Jul 2009 Nov 2009 Traffic Selectors for Flow Bindings Multiple Interfaces (mif) ------------------------- Charter Last Modified: 2009-10-19 Current Status: Active Working Group Chair(s): Margaret Wasserman Hui Deng Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:mif@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mif Archive: http://www.ietf.org/mail-archive/web/mif Description of Working Group: Many hosts have the ability to attach to multiple networks simultaneously. This can happen over multiple physical network interfaces, a combination of physical and virtual interfaces (VPNs or tunnels), or even indirectly through multiple default routers being on the same link. For instance, current laptops and smartphones typically have multiple access network interfaces. A host attached to multiple networks has to make decisions about default router selection, address selection, DNS server selection, choice of interface for packet transmission, and the treatment of configuration information received from the various networks. Some configuration objects are global to the node, some are local to the interface, and some are related to a particular prefix. Various issues arise when contradictory configuration objects that are global to the node are received on different interfaces. At best, decisions about these matters have an efficiency effect. At worst, they have more significant effects such as security impacts, or even lead to communication not being possible at all. A number of operating systems have implemented various techniques to deal with attachments to multiple networks. Some devices employ only one interface at a time and some allow per-host configuration of preferences between the interfaces but still use just one at a time. Other systems allow per-application preferences or implement sophisticated policy managers that can be configured by users or controlled externally. The purpose of the MIF working group is to describe the issues of attaching to multiple networks on hosts and document existing practice. The group shall also analyze the impacts and effectiveness of these existing mechanisms. The WG shall employ and refer to existing IETF work in this area, including, for instance, strong/weak models (RFC 1122), address selection (RFC 3484), ICE and other mechanisms higher layers can use for address selection, DHCP mechanisms, Router Advertisement mechanisms, and DNS recommendations. The focus of the working group should be on documenting the system level effects to host IP stacks and identification of gaps between the existing IETF recommendations and existing practice. The working group shall address both IPv4 and IPv6 as well as stateless and stateful configuration. Network discovery and selection on lower layers as defined by RFC 5113 is out of scope. Also, the group shall not develop new protocol or policy mechanisms; recommendations and gap analysis from the group are solely based on existing solutions. The group shall not assume any software beyond basic IP protocol support on its peers or in network nodes. No work will be done to enable traffic flows to move from one interface to another. The group recognizes existing work on mechanisms that require peer or network support for moving traffic flows such as RFC 5206, RFC 4980 and the use of multiple care-of addresses in Mobile IPv6. This group does not work on or impact such mechanisms. Once the group has completed its work items, the IETF can make an informed decision about rechartering the working group to define new mechanisms or asking other, specialized working groups (such as DHC or 6MAN) to deal with specific issues. Description of Working Group: Many hosts have the ability to attach to multiple networks simultaneously. This can happen over multiple physical network interfaces, a combination of physical and virtual interfaces (VPNs or tunnels), or even indirectly through multiple default routers being on the same link. For instance, current laptops and smartphones typically have multiple access network interfaces. A host attached to multiple networks has to make decisions about default router selection, address selection, DNS server selection, choice of interface for packet transmission, and the treatment of configuration information received from the various networks. Some configuration objects are global to the node, some are local to the interface, and some are related to a particular prefix. Various issues arise when contradictory configuration objects that are global to the node are received on different interfaces. At best, decisions about these matters have an efficiency effect. At worst, they have more significant effects such as security impacts, or even lead to communication not being possible at all. A number of operating systems have implemented various techniques to deal with attachments to multiple networks. Some devices employ only one interface at a time and some allow per-host configuration of preferences between the interfaces but still use just one at a time. Other systems allow per-application preferences or implement sophisticated policy managers that can be configured by users or controlled externally. The purpose of the MIF working group is to describe the issues of attaching to multiple networks on hosts and document existing practice. The group shall also analyze the impacts and effectiveness of these existing mechanisms. The WG shall employ and refer to existing IETF work in this area, including, for instance, strong/weak models (RFC 1122), address selection (RFC 3484), ICE and other mechanisms higher layers can use for address selection, DHCP mechanisms, Router Advertisement mechanisms, and DNS recommendations. The focus of the working group should be on documenting the system level effects to host IP stacks and identification of gaps between the existing IETF recommendations and existing practice. The working group shall address both IPv4 and IPv6 as well as stateless and stateful configuration. Network discovery and selection on lower layers as defined by RFC 5113 is out of scope. Also, the group shall not develop new protocol or policy mechanisms; recommendations and gap analysis from the group are solely based on existing solutions. The group shall not assume any software beyond basic IP protocol support on its peers or in network nodes. No work will be done to enable traffic flows to move from one interface to another. The group recognizes existing work on mechanisms that require peer or network support for moving traffic flows such as RFC 5206, RFC 4980 and the use of multiple care-of addresses in Mobile IPv6. This group does not work on or impact such mechanisms. Once the group has completed its work items, the IETF can make an informed decision about rechartering the working group to define new mechanisms or asking other, specialized working groups (such as DHC or 6MAN) to deal with specific issues. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2009 Oct 2009 Multiple Interfaces Problem Statement Oct 2009 Oct 2009 Current Practices for Multiple Interface Hosts Mobility for IPv4 (mip4) ------------------------ Charter Last Modified: 2009-08-18 Current Status: Active Working Group Chair(s): Henrik Levkowetz Pete McCann Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:mip4@ietf.org To Subscribe: mip4-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/mip4/index.html Description of Working Group: IP mobility support for IPv4 nodes (hosts and routers) is specified in RFC3344. RFC 3344 mobility allows a node to continue using its "permanent" home address as it moves around the Internet. The Mobile IP protocols support transparency above the IP layer, including maintenance of active TCP connections and UDP port bindings. Besides the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal with concerns such as optimization, security, extensions, AAA support, and deployment issues. MIPv4 is currently being deployed on a wide basis (e.g., in cdma2000 networks). The scope of the deployment is on a fairly large scale and accordingly, the MIP4 WG will focus on deployment issues and on addressing known deficiencies and shortcomings in the protocol that have come up as a result of deployment experience. Specifically, the working group will complete the work items to facilitate interactions with AAA environments, interactions with enterprise environments when MIPv4 is used therein, and updating existing protocol specifications in accordance with deployment needs and advancing those protocols that are on the standards track. Work expected to be done by the MIP4 WG as proposed by this charter is as follows: 1. MIPv4 has been a Proposed Standard for several years. It has been adopted by other standard development organizations and has been deployed commercially. One of the next steps for the WG is to advance the protocol to draft standard status. As part of advancing base Mobile IP specifications to Draft Standard, the MIPv4 NAI RFC (2794) will be revised to reflect implementation experience. 2. The WG will complete the MIB specifications for the Mobile IPv4 base protocol and the UDP tunneling extension. 3. A requirements document for RADIUS MIP4 support was previously completed and published as RFC 5030. Based on these requirements, the WG will complete the specification of MIPv4 RADIUS attributes, solicit feedback from the RADEXT WG, adjust, and submit this for publication. Note that the work may require extensions to the RADIUS attribute space which will be handled outside the MIP4 WG. 4. Like fixed nodes, mobile nodes sometimes need to be dynamically configured with parameters such as DNS server IP addresses. Previous work in the WG proposed to put a generic container for host configuration options into Mobile IPv4 signaling. However, it may be easier for mobile nodes to implement the already existing DHCP specification, and to run DHCP over the tunnel established with an initial registration. The WG will take on a draft describing any modifications to Mobile IPv4 that may be needed to facilitate this mode of operation, and submit for publication as a Proposed Standard or Best Current Practice as appropriate. 5. The proliferation of devices with multiple interface technologies and the desire to use each interface for the type of traffic most appropriate to it (even simultaneously with other interfaces active at the same time) has led to requirements for supporting multiple simultaneous tunnels between the Home Agent and Mobile Node. The WG will adopt and take to publication as an Experimental RFC one draft that describes how to manage such tunnels and how to direct traffic to use the appropriate tunnel when multiple choices are available. This work will be coordinated with similar Mobile IPv6 work ongoing in the mext working group. In particular, we will strive to converge on a consistent set of architectural decisions (such as which entities are responsible for signaling flow-to-tunnel bindings) and we will share protocol definitions wherever practical (such as the layout of packet flow filters). 6. The WG has published a basic Network Mobility (NEMO) specification as RFC 5177. The WG has taken up an extension to NEMO that will allow for dynamic home network prefix allocation to a moving network. The WG will finish work on this draft and publish as a Proposed Standard. 7. Route optimization has been the focus of a large amount of effort in the Mobile IPv6 WG. For Mobile IPv4, however, the usage case is less clear due to a variety of factors, including the inability to modify already deployed correspondent nodes. Recently a specific use case has been proposed involving route optimization for a more closed network where modifications are made to site routers and a centralized Home Agent to enable offloading of traffic from the Home Agent. The WG will take on and publish a draft on this topic as a Experimental RFC. 8. The use of GRE tunneling with Mobile IPv4 enables support for multiple overlapping private address spaces within the same mobility agent. However, to distinguish flows from two different mobile nodes that happen to share the same (private) IP address, the GRE Key field needs to be populated with a unique identifier that will enable the mobility agent to demultiplex the flows. The value used for the Key needs to be signaled at the time of tunnel establishment, which means a new Mobile IPv4 extension is needed for this purpose. The WG will take on an publish a draft on this topic as a Proposed Standard. 9. Support for multicast and broadcast packets in Mobile IPv4 as specified in RFC 3024 currently requires encapsulated delivery style for all packets. This leads to inefficiencies on the MN-to-FA link because even unicast packets must be encapsulated. Eliminating this inefficiency is possible if there is a mechanism to negotiate a mode of operation where only multicast/broadcast packets are encapsulated, while unicast packets can use direct delivery style. The WG will take on a draft to solve this problem and publish as a Proposed Standard. Description of Working Group: IP mobility support for IPv4 nodes (hosts and routers) is specified in RFC3344. RFC 3344 mobility allows a node to continue using its "permanent" home address as it moves around the Internet. The Mobile IP protocols support transparency above the IP layer, including maintenance of active TCP connections and UDP port bindings. Besides the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal with concerns such as optimization, security, extensions, AAA support, and deployment issues. MIPv4 is currently being deployed on a wide basis (e.g., in cdma2000 networks). The scope of the deployment is on a fairly large scale and accordingly, the MIP4 WG will focus on deployment issues and on addressing known deficiencies and shortcomings in the protocol that have come up as a result of deployment experience. Specifically, the working group will complete the work items to facilitate interactions with AAA environments, interactions with enterprise environments when MIPv4 is used therein, and updating existing protocol specifications in accordance with deployment needs and advancing those protocols that are on the standards track. Work expected to be done by the MIP4 WG as proposed by this charter is as follows: 1. MIPv4 has been a Proposed Standard for several years. It has been adopted by other standard development organizations and has been deployed commercially. One of the next steps for the WG is to advance the protocol to draft standard status. As part of advancing base Mobile IP specifications to Draft Standard, the MIPv4 NAI RFC (2794) will be revised to reflect implementation experience. 2. The WG will complete the MIB specifications for the Mobile IPv4 base protocol and the UDP tunneling extension. 3. A requirements document for RADIUS MIP4 support was previously completed and published as RFC 5030. Based on these requirements, the WG will complete the specification of MIPv4 RADIUS attributes, solicit feedback from the RADEXT WG, adjust, and submit this for publication. Note that the work may require extensions to the RADIUS attribute space which will be handled outside the MIP4 WG. 4. Like fixed nodes, mobile nodes sometimes need to be dynamically configured with parameters such as DNS server IP addresses. Previous work in the WG proposed to put a generic container for host configuration options into Mobile IPv4 signaling. However, it may be easier for mobile nodes to implement the already existing DHCP specification, and to run DHCP over the tunnel established with an initial registration. The WG will take on a draft describing any modifications to Mobile IPv4 that may be needed to facilitate this mode of operation, and submit for publication as a Proposed Standard or Best Current Practice as appropriate. 5. The proliferation of devices with multiple interface technologies and the desire to use each interface for the type of traffic most appropriate to it (even simultaneously with other interfaces active at the same time) has led to requirements for supporting multiple simultaneous tunnels between the Home Agent and Mobile Node. The WG will adopt and take to publication as an Experimental RFC one draft that describes how to manage such tunnels and how to direct traffic to use the appropriate tunnel when multiple choices are available. This work will be coordinated with similar Mobile IPv6 work ongoing in the mext working group. In particular, we will strive to converge on a consistent set of architectural decisions (such as which entities are responsible for signaling flow-to-tunnel bindings) and we will share protocol definitions wherever practical (such as the layout of packet flow filters). 6. The WG has published a basic Network Mobility (NEMO) specification as RFC 5177. The WG has taken up an extension to NEMO that will allow for dynamic home network prefix allocation to a moving network. The WG will finish work on this draft and publish as a Proposed Standard. 7. Route optimization has been the focus of a large amount of effort in the Mobile IPv6 WG. For Mobile IPv4, however, the usage case is less clear due to a variety of factors, including the inability to modify already deployed correspondent nodes. Recently a specific use case has been proposed involving route optimization for a more closed network where modifications are made to site routers and a centralized Home Agent to enable offloading of traffic from the Home Agent. The WG will take on and publish a draft on this topic as a Experimental RFC. 8. The use of GRE tunneling with Mobile IPv4 enables support for multiple overlapping private address spaces within the same mobility agent. However, to distinguish flows from two different mobile nodes that happen to share the same (private) IP address, the GRE Key field needs to be populated with a unique identifier that will enable the mobility agent to demultiplex the flows. The value used for the Key needs to be signaled at the time of tunnel establishment, which means a new Mobile IPv4 extension is needed for this purpose. The WG will take on an publish a draft on this topic as a Proposed Standard. 9. Support for multicast and broadcast packets in Mobile IPv4 as specified in RFC 3024 currently requires encapsulated delivery style for all packets. This leads to inefficiencies on the MN-to-FA link because even unicast packets must be encapsulated. Eliminating this inefficiency is possible if there is a mechanism to negotiate a mode of operation where only multicast/broadcast packets are encapsulated, while unicast packets can use direct delivery style. The WG will take on a draft to solve this problem and publish as a Proposed Standard. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2004 Oct 2009 IP Mobility Support for IPv4, revised Mar 2007 Sep 2009 Generic Notification Message for Mobile IPv4 Mar 2007 Nov 2009 Dynamic Prefix Allocation for NEMOv4 Mobility for IP: Performance, Signaling and Handoff Optimization (mipshop) -------------------------------------------------------------------------- Charter Last Modified: 2009-05-22 Current Status: Active Working Group Chair(s): Stefano Faccin Vijay Devarapalli Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:mipshop@ietf.org To Subscribe: mipshop-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/mipshop/index.html Description of Working Group: Mobile IPv6 enables IPv6 mobile nodes to continue a session using a given "home address" in spite of changes in its point of attachment to the network. These changes may cause delay, packet loss, and also represent signaling overhead traffic on the network. The MIPSHOP WG has so far worked on two technologies to address these issues. Hierarchical Mobile IPv6 (HMIPv6) reduces the amount and latency of signaling between a MN, its Home Agent and one or more correspondent nodes. Mobile IPv6 Fast Handovers (FMIPv6) reduces packet loss by providing fast IP connectivity as soon as the mobile node establishes a new point of attachment at a new link. The MIPSHOP WG will continue to work on HMIPv6 and FMIPv6, and the necessary extensions to improve these protocols. The MIPSHOP WG will also identify missing components that are required for deploying these protocols and standardize the necessary extensions. The WG will also address using these protocols to provide fast handovers for network-based mobility management protocols like Proxy Mobile IPv6. The IEEE 802.21 Media Independent Handover (MIH) working group aims at providing services to assist with handoffs between heterogeneous link-layer technologies, and across IP subnet boundaries. MIH services can be delivered through link-layer specific solutions and/or through a "layer 3 or above" protocol. MIPSHOP will define the delivery of information for MIH services for this latter case. A L3 based mechanism to identify a valid information server is also required. The MIPSHOP will work on developing a protocol for transport of MIH services information and mechanisms for discovering the MIH server. Security for the transport of MIH information will also be addressed. The MOBOPTS Research Group in the IRTF is chartered to work on optimizations related to Mobile IPv6 and IP handoffs among other things. The MIPSHOP WG will take mature proposals from the MOBOPTS group and standardize them in the IETF on a case-by-case basis. The MIPSHOP WG will also consider and standardize optimizations for the Mobile IPv6 protocol and IP mobility in general. Scope of MIPSHOP: The working group will work on: 1. FMIPv6 Mobile Node - Access Router security using the AAA infrastructure Currently MIPSHOP has produced a standards track protocol for setting up security between the mobile node and access router for security FMIPv6 signaling messages. However, the protocol depends on SeND (Secure Neighbor Discovery) to be available on the mobile node and the access router. An alternate mechanism that leverages the AAA infrastructure would be useful. Many target systems where FMIPv6 is likely to be used use a AAA infrastructure to authenticate and authorize network access. The working group will work on a Informational document describing how the AAA infrastructure could be used for setting up security associations between the mobile node and the access router. 2. Prefix Management for point-to-point links with FMIPv6 Using FMIPv6 over point-to-points like requires some additional considerations with respect to managing and allocating prefixes for the mobile node on these point-to-point links. Therefore the WG will work on an Informational document to address the issues. 3. Handover optimizations when Proxy Mobile IPv6 is used for handovers Proxy Mobile IPv6 (PMIPv6) is a network-based mobility management protocol where a node in the access network, called the Mobile Access Gateway (MAG) handles mobility on behalf of the mobile node. It has been proposed to use FMIPv6 to optimize the handover in terms of reducing the packet loss and transferring relevant context from the old MAG to the new MAG. The working group will also work on other optimizations like the use of a transient binding cache entry for improving a PMIPv6-based handover. 4. Work on protocols and extensions for transporting information related to IEEE 802.21: The work includes the layer 3 protocol for transporting MIH related information and DHCP and DNS extensions for discovering the information servers. Description of Working Group: Mobile IPv6 enables IPv6 mobile nodes to continue a session using a given "home address" in spite of changes in its point of attachment to the network. These changes may cause delay, packet loss, and also represent signaling overhead traffic on the network. The MIPSHOP WG has so far worked on two technologies to address these issues. Hierarchical Mobile IPv6 (HMIPv6) reduces the amount and latency of signaling between a MN, its Home Agent and one or more correspondent nodes. Mobile IPv6 Fast Handovers (FMIPv6) reduces packet loss by providing fast IP connectivity as soon as the mobile node establishes a new point of attachment at a new link. The MIPSHOP WG will continue to work on HMIPv6 and FMIPv6, and the necessary extensions to improve these protocols. The MIPSHOP WG will also identify missing components that are required for deploying these protocols and standardize the necessary extensions. The WG will also address using these protocols to provide fast handovers for network-based mobility management protocols like Proxy Mobile IPv6. The IEEE 802.21 Media Independent Handover (MIH) working group aims at providing services to assist with handoffs between heterogeneous link-layer technologies, and across IP subnet boundaries. MIH services can be delivered through link-layer specific solutions and/or through a "layer 3 or above" protocol. MIPSHOP will define the delivery of information for MIH services for this latter case. A L3 based mechanism to identify a valid information server is also required. The MIPSHOP will work on developing a protocol for transport of MIH services information and mechanisms for discovering the MIH server. Security for the transport of MIH information will also be addressed. The MOBOPTS Research Group in the IRTF is chartered to work on optimizations related to Mobile IPv6 and IP handoffs among other things. The MIPSHOP WG will take mature proposals from the MOBOPTS group and standardize them in the IETF on a case-by-case basis. The MIPSHOP WG will also consider and standardize optimizations for the Mobile IPv6 protocol and IP mobility in general. Scope of MIPSHOP: The working group will work on: 1. FMIPv6 Mobile Node - Access Router security using the AAA infrastructure Currently MIPSHOP has produced a standards track protocol for setting up security between the mobile node and access router for security FMIPv6 signaling messages. However, the protocol depends on SeND (Secure Neighbor Discovery) to be available on the mobile node and the access router. An alternate mechanism that leverages the AAA infrastructure would be useful. Many target systems where FMIPv6 is likely to be used use a AAA infrastructure to authenticate and authorize network access. The working group will work on a Informational document describing how the AAA infrastructure could be used for setting up security associations between the mobile node and the access router. 2. Prefix Management for point-to-point links with FMIPv6 Using FMIPv6 over point-to-points like requires some additional considerations with respect to managing and allocating prefixes for the mobile node on these point-to-point links. Therefore the WG will work on an Informational document to address the issues. 3. Handover optimizations when Proxy Mobile IPv6 is used for handovers Proxy Mobile IPv6 (PMIPv6) is a network-based mobility management protocol where a node in the access network, called the Mobile Access Gateway (MAG) handles mobility on behalf of the mobile node. It has been proposed to use FMIPv6 to optimize the handover in terms of reducing the packet loss and transferring relevant context from the old MAG to the new MAG. The working group will also work on other optimizations like the use of a transient binding cache entry for improving a PMIPv6-based handover. 4. Work on protocols and extensions for transporting information related to IEEE 802.21: The work includes the layer 3 protocol for transporting MIH related information and DHCP and DNS extensions for discovering the information servers. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Dec 2007 Jan 2009 IEEE 802.21 Mobility Services Framework Design (MSFD) Apr 2008 May 2009 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery Apr 2008 Jul 2009 Locating IEEE 802.21 Mobility Servers using DNS Oct 2008 Nov 2009 Fast Handovers for Proxy Mobile IPv6 Oct 2008 Sep 2009 Transient Binding for Proxy Mobile IPv6 Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- Charter Last Modified: 2009-07-23 Current Status: Active Working Group Chair(s): Joerg Ott Jean-Francois Mule Real-time Applications and Infrastructure Area Director(s): Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Cullen Jennings Mailing Lists: General Discussion:mmusic@ietf.org To Subscribe: mmusic-request@ietf.org In Body: subscribe your_email_address Archive: http://www.ietf.org/mail-archive/web/mmusic/index.html Description of Working Group: The Multiparty MUltimedia SessIon Control (MMUSIC) Working Group was chartered to develop protocols to support Internet teleconferencing and multimedia communications. These protocols are now reasonably mature, and many have received widespread deployments. The group has revised some of these protocols in the light of implementation experience and additional demands that have arisen from other WGs (such as AVT, SIP, and SIPPING). It is focused on using and negotiating mechanisms such STUN and TURN in order to enable media sessions to traverse Network Address Translators NATs, and on new means to exchange SDP capabilities. Multimedia communications protocols use a common platform to express media and session descriptions: the Session Description Protocol, SDP. The many uses of SDP have led to (requests for) numerous extensions and have led to recognition of several flaws in the protocol design, some of which were addressed in the revision of SDP. In spite of these, it is widely deployed. The current aims of the working group include the following: - To support the establishment of multi-party multimedia sessions across NATs, MMUSIC will define an Internet Connectivity Establishment protocol (ICE). This will define several SDP extensions to work with NATs for media sessions carried over both UDP and TCP. - Various extensions to SDP will be pursued to remedy the most urgent of SDP's shortcomings. These will be limited and include adding support for limited but generic capability negotiations in SDP, defining the means to select QoS mechanisms to use for a particular media stream, enabling file transfer via the SDP Offer/Answer model, and support for media loopback. With the exception of these specific items, only extensions within the existing SDP framework will be done (e.g. registering new codecs and defining parameters for them, extending SDP to include new address families). - to maintain and revise the specification of the Real Time Streaming Protocol (RTSP), including fixes and clarifications based on implementation experience. The revised RTSP specification will be re-issued as a Proposed Standard RFC. We will also document how RTSP can be used in the presence of NAT boxes. The MMUSIC work items will be pursued in close coordination with other IETF WGs including AVT, SIP, SIPPING, SIMPLE, XCON, and BEHAVE, as well as others where appropriate such as NSIS. Description of Working Group: The Multiparty MUltimedia SessIon Control (MMUSIC) Working Group was chartered to develop protocols to support Internet teleconferencing and multimedia communications. These protocols are now reasonably mature, and many have received widespread deployments. The group has revised some of these protocols in the light of implementation experience and additional demands that have arisen from other WGs (such as AVT, SIP, and SIPPING). It is focused on using and negotiating mechanisms such STUN and TURN in order to enable media sessions to traverse Network Address Translators NATs, and on new means to exchange SDP capabilities. Multimedia communications protocols use a common platform to express media and session descriptions: the Session Description Protocol, SDP. The many uses of SDP have led to (requests for) numerous extensions and have led to recognition of several flaws in the protocol design, some of which were addressed in the revision of SDP. In spite of these, it is widely deployed. The current aims of the working group include the following: - To support the establishment of multi-party multimedia sessions across NATs, MMUSIC will define an Internet Connectivity Establishment protocol (ICE). This will define several SDP extensions to work with NATs for media sessions carried over both UDP and TCP. - Various extensions to SDP will be pursued to remedy the most urgent of SDP's shortcomings. These will be limited and include adding support for limited but generic capability negotiations in SDP, defining the means to select QoS mechanisms to use for a particular media stream, enabling file transfer via the SDP Offer/Answer model, and support for media loopback. With the exception of these specific items, only extensions within the existing SDP framework will be done (e.g. registering new codecs and defining parameters for them, extending SDP to include new address families). - to maintain and revise the specification of the Real Time Streaming Protocol (RTSP), including fixes and clarifications based on implementation experience. The revised RTSP specification will be re-issued as a Proposed Standard RFC. We will also document how RTSP can be used in the presence of NAT boxes. The MMUSIC work items will be pursued in close coordination with other IETF WGs including AVT, SIP, SIPPING, SIMPLE, XCON, and BEHAVE, as well as others where appropriate such as NSIS. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2002 Jul 2009 Real Time Streaming Protocol 2.0 (RTSP) Feb 2003 Jul 2009 A Network Address Translator (NAT) Traversal mechanism for media controlled by Real-Time Streaming Protocol (RTSP) Oct 2003 Oct 2007 Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols Dec 2004 Oct 2009 An Extension to the Session Description Protocol (SDP) for Media Loopback May 2005 Mar 2009 Connectivity Preconditions for Session Description Protocol Media Streams Mar 2006 Oct 2009 TCP Candidates with Interactive Connectivity Establishment (ICE) Jan 2007 May 2009 SDP Capability Negotiation Feb 2007 Jul 2009 SDP media capabilities Negotiation Jun 2008 Nov 2009 The SDP (Session Description Protocol) Grouping Framework Jan 2009 Oct 2009 Forward Error Correction Grouping Semantics in Session Description Protocol Feb 2009 Oct 2009 Negotiation of Generic Image Attributes in SDP Feb 2009 Oct 2009 Session Description Protocol (SDP) Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN) Message Organization (morg) --------------------------- Charter Last Modified: 2009-04-03 Current Status: Active Working Group Chair(s): Randall Gellens Timo Sirainen Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Alexey Melnikov Secretary(ies): Barry Leiba Mailing Lists: General Discussion:morg@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/morg Archive: http://www.ietf.org/mail-archive/web/morg/current/maillist.html Description of Working Group: The IETF Message Organization extensions Working Group will work on IMAP extensions that improve clients' ability to find messages or groups of messages in an IMAP mailstore. As a secondary goal, the WG will design its extensions so as to minimize client/server round trips and bandwidth overhead. In particular the Working Group is chartered to finalize and publish the following IMAP extensions as proposed standards: (a) A SORT extension specifying new sort criteria for header fields containing email addresses. This extension will be based on draft-karp-morg-sortdisplay-00.txt. (b) A SEARCH extension specifying new search criteria for header fields containing email addresses. (c) A LIST extension for returning STATUS information in LIST responses. This extension will be based on draft-melnikov-imapext-status-in-list-00.txt. (d) An extension that formalizes a way to return message counters by message context using STATUS and SEARCH commands. (e) An extension that specifies Internet-search-engine-like searching. Such searches would be more flexible (and less formally defined) than substring-based searches, and may return their results in a significant order. They may include "relevance" scores or similar information that could be useful to the user. (f) New collation algorithms such as "ignore whitespace" and "numeric, ignoring punctuation". The WG group will determine which collations are needed, taking into consideration the needs of the protocols that use the collation framework. (g) An extension that allows searching for messages within a message thread. This extension will be based on draft-gulbrandsen-imap-inthread-03.txt. (h) An extension that allows searching of multiple mailboxes at the same time (based on draft-melnikov-imapext-multimailbox-search-03.txt), or of multiple mailbox views. The WG will determine which approach (mailboxes or views) is more suitable as part of its work. Additional documents may be added this list, but only via a charter revision. There must also be demonstrable willingness in the IMAP development community to actually implement a given extension before it can be added to this charter. Revising or replacing the base IMAP4rev1 specification (RFC 3501) is out of the scope of this WG. This WG will ensure that all extensions it proposes take into account any existing problems in the base specification of IMAP, and do not make them worse nor make the problems harder to address in the future. Description of Working Group: The IETF Message Organization extensions Working Group will work on IMAP extensions that improve clients' ability to find messages or groups of messages in an IMAP mailstore. As a secondary goal, the WG will design its extensions so as to minimize client/server round trips and bandwidth overhead. In particular the Working Group is chartered to finalize and publish the following IMAP extensions as proposed standards: (a) A SORT extension specifying new sort criteria for header fields containing email addresses. This extension will be based on draft-karp-morg-sortdisplay-00.txt. (b) A SEARCH extension specifying new search criteria for header fields containing email addresses. (c) A LIST extension for returning STATUS information in LIST responses. This extension will be based on draft-melnikov-imapext-status-in-list-00.txt. (d) An extension that formalizes a way to return message counters by message context using STATUS and SEARCH commands. (e) An extension that specifies Internet-search-engine-like searching. Such searches would be more flexible (and less formally defined) than substring-based searches, and may return their results in a significant order. They may include "relevance" scores or similar information that could be useful to the user. (f) New collation algorithms such as "ignore whitespace" and "numeric, ignoring punctuation". The WG group will determine which collations are needed, taking into consideration the needs of the protocols that use the collation framework. (g) An extension that allows searching for messages within a message thread. This extension will be based on draft-gulbrandsen-imap-inthread-03.txt. (h) An extension that allows searching of multiple mailboxes at the same time (based on draft-melnikov-imapext-multimailbox-search-03.txt), or of multiple mailbox views. The WG will determine which approach (mailboxes or views) is more suitable as part of its work. Additional documents may be added this list, but only via a charter revision. There must also be demonstrable willingness in the IMAP development community to actually implement a given extension before it can be added to this charter. Revising or replacing the base IMAP4rev1 specification (RFC 3501) is out of the scope of this WG. This WG will ensure that all extensions it proposes take into account any existing problems in the base specification of IMAP, and do not make them worse nor make the problems harder to address in the future. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jan 2009 Jul 2009 IMAP4 Multimailbox SEARCH Extension Jan 2009 Oct 2009 Display-based Address Sorting for the IMAP4 SORT Extension Feb 2009 May 2009 IMAP4 Extension for returning STATUS information in extended LIST Apr 2009 May 2009 IMAP4 Extension for Fuzzy Search Multiprotocol Label Switching (mpls) ------------------------------------ Charter Last Modified: 2009-06-29 Current Status: Active Working Group Chair(s): George Swallow Loa Andersson Routing Area Director(s): Ross Callon Adrian Farrel Routing Area Advisor: Adrian Farrel Secretary(ies): Martin Vigoureux Martin Vigoureux Mailing Lists: General Discussion:mpls@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mpls Archive: http://www.ietf.org/mail-archive/web/mpls/current/maillist.html Description of Working Group: The MPLS working group is responsible for standardizing a base technology for using label switching and for the implementation of label-switched paths over various packet based link-level technologies, such as Packet-over-Sonet, Frame Relay, ATM, and LAN technologies (e.g. all forms of Ethernet, Token Ring, etc.). This includes procedures and protocols for the distribution of labels between routers and encapsulation. The working group is also responsible for specifying the necessary management objects (e.g. as part of MIB modules) and OAM techniques for the functionality specified in the base MPLS technology. The first generation of the MPLS standards are largely complete, and the current WG work items are: - Define requirements, mechanisms and protocol extensions for point-to-multipoint (P2MP) MPLS - Define requirements, mechanisms and protocol extensions for traffic engineered point-to-multipoint (P2MP) MPLS, including soft preemption - Define requirements and mechanisms for MPLS OAM - Define an overall OAM framework for MPLS applications - MPLS-specific aspects of traffic engineering for multi-areas/multi-AS in cooperation with the CCAMP WG - Determine (with CCAMP) what procedures are appropriate for evaluating proposals to extend the MPLS and GMPLS protocols, and document these - Document current implementation practices for MPLS load sharing - Include extensions to the MPLS WG protocols and RFCs necessary to create an MPLS Transport Profile (MPLS TP). The work on the MPLS TP will be coordinated between the working groups (eg, MPLS, CCAMP, PWE3, and L2PVN) that are chartered to do MPLS TP work. The Working Group chairs tracking of the working group documents can be viewed at http://www.tla-group.com/~mpls/mpls-wg-docs.htm Description of Working Group: The MPLS working group is responsible for standardizing a base technology for using label switching and for the implementation of label-switched paths over various packet based link-level technologies, such as Packet-over-Sonet, Frame Relay, ATM, and LAN technologies (e.g. all forms of Ethernet, Token Ring, etc.). This includes procedures and protocols for the distribution of labels between routers and encapsulation. The working group is also responsible for specifying the necessary management objects (e.g. as part of MIB modules) and OAM techniques for the functionality specified in the base MPLS technology. The first generation of the MPLS standards are largely complete, and the current WG work items are: - Define requirements, mechanisms and protocol extensions for point-to-multipoint (P2MP) MPLS - Define requirements, mechanisms and protocol extensions for traffic engineered point-to-multipoint (P2MP) MPLS, including soft preemption - Define requirements and mechanisms for MPLS OAM - Define an overall OAM framework for MPLS applications - MPLS-specific aspects of traffic engineering for multi-areas/multi-AS in cooperation with the CCAMP WG - Determine (with CCAMP) what procedures are appropriate for evaluating proposals to extend the MPLS and GMPLS protocols, and document these - Document current implementation practices for MPLS load sharing - Include extensions to the MPLS WG protocols and RFCs necessary to create an MPLS Transport Profile (MPLS TP). The work on the MPLS TP will be coordinated between the working groups (eg, MPLS, CCAMP, PWE3, and L2PVN) that are chartered to do MPLS TP work. The Working Group chairs tracking of the working group documents can be viewed at http://www.tla-group.com/~mpls/mpls-wg-docs.htm Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2002 Jul 2009 Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute Apr 2003 Jul 2009 MPLS Traffic Engineering Soft Preemption Sep 2005 Aug 2009 Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping Sep 2005 Nov 2009 Component Link Recording and Resource Control for TE Link Bundles Mar 2006 Oct 2009 Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths Mar 2006 Jul 2009 MPLS Upstream Label Assignment for RSVP-TE Apr 2006 Jul 2009 MPLS Upstream Label Assignment for LDP Sep 2006 Apr 2009 Point-to-Multipoint Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) module Jan 2007 Sep 2009 LDP Typed Wildcard FEC May 2007 Sep 2009 Node behavior upon originating and receiving Resource ReserVation Protocol (RSVP) Path Error message Sep 2007 Oct 2009 Security Framework for MPLS and GMPLS Networks Sep 2007 Oct 2009 Non PHP Behavior and out-of-band mapping for RSVP-TE LSPs Jun 2008 Oct 2009 Mechanism for performing LSP-Ping over MPLS tunnels Jul 2008 Aug 2009 Signaling LDP Label Advertisement Completion Aug 2008 Sep 2009 PathErr Message Triggered MPLS and GMPLS LSP Reroute Nov 2008 Oct 2009 A Framework for MPLS in Transport Networks Dec 2008 Aug 2009 Requirements for OAM in MPLS Transport Networks Dec 2008 Jul 2009 Requirements for Label Edge Router Forwarding of IPv4 Option Packets Feb 2009 Oct 2009 MPLS TP Network Management Requirements Mar 2009 Sep 2009 An Inband Data Communication Network For the MPLS Transport Profile Mar 2009 Oct 2009 MPLS-TP OAM Framework Apr 2009 Nov 2009 Multiprotocol Label Switching Transport Profile Survivability Framework Jun 2009 Jun 2009 Definition of ACH TLV Structure Jun 2009 Nov 2009 MPLS-TP Network Management Framework Jun 2009 Oct 2009 A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations Sep 2009 Oct 2009 IETF Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) Document Process Nov 2009 Nov 2009 MPLS-TP OAM Analysis Nov 2009 Nov 2009 MPLS-TP Identifiers Nov 2009 Nov 2009 LDP IGP Synchronization for broadcast networks Multipath TCP (mptcp) --------------------- Charter Last Modified: 2009-10-29 Current Status: Active Working Group Chair(s): Philip Eardley Yoshifumi Nishida Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Magnus Westerlund Mailing Lists: General Discussion:multipathtcp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/multipathtcp Archive: http://www.ietf.org/mail-archive/web/multipathtcp/ Description of Working Group: The Multipath TCP (MPTCP) working group develops 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. Initially the WG will only produce documents that are experimental or informational. Key goals for MPTCP are: to be deployable and usable without significant changes to existing Internet infrastructure; to be usable by unmodified applications; and to be stable and congestion-safe over the wide range of existing Internet paths. That will include handling MTU discovery on a per path basis and NAT interactions. The design's success in meeting the goals should be determined through experiments. However, it is expected that some results from large scale experiments can only be achievable after the publication of the initial design. The working group will provide a modular architecture that is designed to be easily extensible and adaptable. In particular, the congestion control mechanism is separated from the mechanisms for identifying and using multiple paths. The working group will focus on a solution requiring modification of both peers. One or both peers are expected to have multiple addresses, which often results in different network paths that are at least partially divergent. However, multiple addresses, even on different network interfaces, are no guarantee that the paths are divergent at all. The design needs to address the issues associated with fully or partially joint paths and shared bottlenecks. The design should allow for future extensions to handle cases where path diversity is attempted through other means than using different addresses. The design must also consider what happens when an end-point pair becomes unavailable during an ongoing session, especially a pair that has been used to establish an additional path (for this connection) between another end-point pair. Whilst MPTCP will require modifications to the TCP stack at both the peers, all existing applications should be able to use the new MPTCP stack without modification and gain benefits from multipath usage. The impact on different classes of applications will be considered and documented. An extended API will be defined to allow applications to express particular preferences for how MPTCP operates, and to get additional information about MPTCP-specific run-time events. The WG will carefully analyze and address in the appropriate protocol documents all new security threats introduced by MPTCP. The following items will be worked on: a. An architectural framework for congestion-dependent multipath transport protocols. This is an overview document which tracks the technical documents, describing how the modular components fit together, and will describe the motivations and the general approach that should be followed to enable congestion-dependent multipath transport. It will also analyze how MPTCP interacts with existing infrastructure elements and other address agility mechanisms, such as Mobile IP, HIP and SHIM6. The results of any experiment performed during the development should also be included or referenced in this document. b. A security threat analysis for multipath TCP. The ability to change the addresses used during a TCP session opens up new types of vulnerabilities and attacks. These and their mitigations will be documented. c. A coupled multipath-aware congestion control algorithm. This algorithm is the multipath equivalent of SACK/NewReno congestion control. As experience is gathered from implementations of various congestion control algorithms, it is expected that the working group will be rechartered to pursue additional work in these areas. d. Extensions to current TCP to support multi-addressed multipath TCP. This covers all on-the-wire changes required to create a two-ended MPTCP solution using multiple addresses at one or both ends. It will be designed in a modular fashion to allow alternative address management schemes to be explored in future. This document will also include a basic security model. e. An extended API describing how applications can exploit additional features of multipath transport. While MPTCP needs to be usable without any application changes, this API should be an optional extension that provides access to multipath information and enables control over the usage of multipath. f. An application considerations document, presenting the impacts that MPTCP may have on applications, such as performance changes. It should also discuss issues it create for applications, such as its effects on the usage of IPsec. Where appropriate, this group is expected to coordinate with, and will use input from, the MIF working group to support the use of multiple interfaces. Description of Working Group: The Multipath TCP (MPTCP) working group develops 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. Initially the WG will only produce documents that are experimental or informational. Key goals for MPTCP are: to be deployable and usable without significant changes to existing Internet infrastructure; to be usable by unmodified applications; and to be stable and congestion-safe over the wide range of existing Internet paths. That will include handling MTU discovery on a per path basis and NAT interactions. The design's success in meeting the goals should be determined through experiments. However, it is expected that some results from large scale experiments can only be achievable after the publication of the initial design. The working group will provide a modular architecture that is designed to be easily extensible and adaptable. In particular, the congestion control mechanism is separated from the mechanisms for identifying and using multiple paths. The working group will focus on a solution requiring modification of both peers. One or both peers are expected to have multiple addresses, which often results in different network paths that are at least partially divergent. However, multiple addresses, even on different network interfaces, are no guarantee that the paths are divergent at all. The design needs to address the issues associated with fully or partially joint paths and shared bottlenecks. The design should allow for future extensions to handle cases where path diversity is attempted through other means than using different addresses. The design must also consider what happens when an end-point pair becomes unavailable during an ongoing session, especially a pair that has been used to establish an additional path (for this connection) between another end-point pair. Whilst MPTCP will require modifications to the TCP stack at both the peers, all existing applications should be able to use the new MPTCP stack without modification and gain benefits from multipath usage. The impact on different classes of applications will be considered and documented. An extended API will be defined to allow applications to express particular preferences for how MPTCP operates, and to get additional information about MPTCP-specific run-time events. The WG will carefully analyze and address in the appropriate protocol documents all new security threats introduced by MPTCP. The following items will be worked on: a. An architectural framework for congestion-dependent multipath transport protocols. This is an overview document which tracks the technical documents, describing how the modular components fit together, and will describe the motivations and the general approach that should be followed to enable congestion-dependent multipath transport. It will also analyze how MPTCP interacts with existing infrastructure elements and other address agility mechanisms, such as Mobile IP, HIP and SHIM6. The results of any experiment performed during the development should also be included or referenced in this document. b. A security threat analysis for multipath TCP. The ability to change the addresses used during a TCP session opens up new types of vulnerabilities and attacks. These and their mitigations will be documented. c. A coupled multipath-aware congestion control algorithm. This algorithm is the multipath equivalent of SACK/NewReno congestion control. As experience is gathered from implementations of various congestion control algorithms, it is expected that the working group will be rechartered to pursue additional work in these areas. d. Extensions to current TCP to support multi-addressed multipath TCP. This covers all on-the-wire changes required to create a two-ended MPTCP solution using multiple addresses at one or both ends. It will be designed in a modular fashion to allow alternative address management schemes to be explored in future. This document will also include a basic security model. e. An extended API describing how applications can exploit additional features of multipath transport. While MPTCP needs to be usable without any application changes, this API should be an optional extension that provides access to multipath information and enables control over the usage of multipath. f. An application considerations document, presenting the impacts that MPTCP may have on applications, such as performance changes. It should also discuss issues it create for applications, such as its effects on the usage of IPsec. Where appropriate, this group is expected to coordinate with, and will use input from, the MIF working group to support the use of multiple interfaces. Internet-Drafts: No Current Internet-Drafts. Multicast Security (msec) ------------------------- Charter Last Modified: 2009-07-27 Current Status: Active Working Group Chair(s): Brian Weis Security Area Director(s): Tim Polk Pasi Eronen Security Area Advisor: Tim Polk Mailing Lists: General Discussion:msec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/msec Archive: http://www.ietf.org/mail-archive/web/msec/current/maillist.html Description of Working Group: The purpose of the MSEC WG is to standardize protocols for securing group communication over internets, and in particular over the global Internet. Initial efforts will focus on scalable solutions for groups with a single source and a very large number of recipients. Additional emphasis will be put on groups where the data is transmitted via IP-layer multicast routing protocols (with or without guaranteed reliability). The developed standard will assume that each group has a single trusted entity (the Group Controller) that sets the security policy and controls the group membership. The standard will strive to provide at least the following basic security guarantees: + Only legitimate group members will have access to current group communication. This includes groups with highly dynamic membership. + Legitimate group members will be able to authenticate the source and contents of the group communication. This includes cases where group members do not trust each other. An additional goal of the standard will be to protect against denial-of-service attacks, whenever possible. Due to the large number of one-to-many multicast applications and the sometimes conflicting requirements these applications exhibit, it is believed that a single protocol will be unable to meet the requirements of all applications. Therefore, the WG will first specify a general Reference Framework that includes a number of functional building blocks. Each such building block will be instantiated by one or more protocols that will be interchanable. The Reference Framework will not only describe one-to-many multicast, but also many-to-many multicast. In addition, as a secondary goal the MSEC WG will also focus on distributed architectures for group key management and group policy management, where for scalability purposes multiple trusted entities (such as Key Distributors) are deployed in a distributed fashion. For this purpose, the Reference Framework will not only describe one-to-many multicast, but also many-to-many multicast. MSEC will generate at least the following documents, which could be considered as base documents: 1. An RFC describing the security requirements of multicast security and an RFC describing the MSEC Architecture. 2. An RFC describing the Group Key Management Architecture and an RFC describing Group Policy Management Architecture in MSEC. 3. Several RFCs describing specifications for protocols that implement source authentication, group key management and group policy management. As multicast security covers a broad range of issues, and therefore touches other Working Groups in the IETF, the MSEC WG will work closely with othersecurity-related Working Groups (e.g. IPsec, IPSP), as well as other Working Groups which maybe considered a 'consumer' of the technologies produced in the MSEC WG (e.g. AVT, MMUSIC) or which may have a multicast focus (e.g. PIM, RMT, IDRM, MAGMA). With this in mind, the MSEC WG is open to receiving new work items, whenever it is considered appropriate to be homed in the MSEC WG. Such drafts will be matured in conjunction with the MSEC base documents. Description of Working Group: The purpose of the MSEC WG is to standardize protocols for securing group communication over internets, and in particular over the global Internet. Initial efforts will focus on scalable solutions for groups with a single source and a very large number of recipients. Additional emphasis will be put on groups where the data is transmitted via IP-layer multicast routing protocols (with or without guaranteed reliability). The developed standard will assume that each group has a single trusted entity (the Group Controller) that sets the security policy and controls the group membership. The standard will strive to provide at least the following basic security guarantees: + Only legitimate group members will have access to current group communication. This includes groups with highly dynamic membership. + Legitimate group members will be able to authenticate the source and contents of the group communication. This includes cases where group members do not trust each other. An additional goal of the standard will be to protect against denial-of-service attacks, whenever possible. Due to the large number of one-to-many multicast applications and the sometimes conflicting requirements these applications exhibit, it is believed that a single protocol will be unable to meet the requirements of all applications. Therefore, the WG will first specify a general Reference Framework that includes a number of functional building blocks. Each such building block will be instantiated by one or more protocols that will be interchanable. The Reference Framework will not only describe one-to-many multicast, but also many-to-many multicast. In addition, as a secondary goal the MSEC WG will also focus on distributed architectures for group key management and group policy management, where for scalability purposes multiple trusted entities (such as Key Distributors) are deployed in a distributed fashion. For this purpose, the Reference Framework will not only describe one-to-many multicast, but also many-to-many multicast. MSEC will generate at least the following documents, which could be considered as base documents: 1. An RFC describing the security requirements of multicast security and an RFC describing the MSEC Architecture. 2. An RFC describing the Group Key Management Architecture and an RFC describing Group Policy Management Architecture in MSEC. 3. Several RFCs describing specifications for protocols that implement source authentication, group key management and group policy management. As multicast security covers a broad range of issues, and therefore touches other Working Groups in the IETF, the MSEC WG will work closely with othersecurity-related Working Groups (e.g. IPsec, IPSP), as well as other Working Groups which maybe considered a 'consumer' of the technologies produced in the MSEC WG (e.g. AVT, MMUSIC) or which may have a multicast focus (e.g. PIM, RMT, IDRM, MAGMA). With this in mind, the MSEC WG is open to receiving new work items, whenever it is considered appropriate to be homed in the MSEC WG. Such drafts will be matured in conjunction with the MSEC base documents. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jun 2006 Oct 2009 Use of TESLA in the ALC and NORM Protocols Multicast Mobility (multimob) ----------------------------- Charter Last Modified: 2009-09-09 Current Status: Active Working Group Chair(s): Stig Venaas Behcet Sarikaya Behcet Sarikaya Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:multimob@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/multimob Archive: http://www.ietf.org/mail-archive/web/multimob/current/maillist.html Description of Working Group: The Multicast mobility (multimob) working group provides guidance for supporting multicast in a mobile environment. The scope of work will be limited to Proxy Mobile IPv6, IGMPv3/MLDv2 protocols and listener mobility. Work requiring modifications to mobility protocols and IGMPv3/MLDv2 is out of scope in this first stage of this working group. Modifications to multicast routing protocols are out of scope. Specific goals for the group are: - Document how multicast can be supported in a Proxy Mobile IPv6 environment - Document the configuration of IGMPv3/MLDv2 in mobile environments The Proxy Mobile IPv6 (PMIPv6) specification as defined in RFC 5213 does not describe how to support multicast. Some forms of multicast support can, however, be built in the involved nodes by using existing capabilities of multicast protocols and the underlying mobility protocols. The first task of the working group is to document such solutions for PMIPv6. This work will not require any additions or changes to message types and parameters specified in RFC 5213, and must assume an unmodified mobile host. The work will employ the remote subscription model. This is a mechanism by which a mobile node joins a multicast group and receives multicast data forwarded via the local mobility anchor. IGMPv3/MLDv2 has been specified for wired networks with shared links. Mobile nodes have needs that are specific to wireless networks and mobility (e.g. entering a dormant mode to conserve battery power, minimizing the latency for joining and leaving a group in support of movement). The second task of the WG is to assess existing solutions for group management, and determine to what extent these methods are sufficient in a mobile environment. This will include recommending appropriate selection of timer values and protocol parameters. In performing its work, the working group will work closely with both the mobility community (NETLMM and NETEXT WGs) and the multicast community (MBONED WG). The group will consider both source specific multicast and any source multicast multicast models. Future work, subject to rechartering, may study/evaluate extensions to support PMIPv6 optimizations to address the avalanche problem and fast handover and extensions to IGMPv3/MLDv2 to support better operation in mobile environments. Description of Working Group: The Multicast mobility (multimob) working group provides guidance for supporting multicast in a mobile environment. The scope of work will be limited to Proxy Mobile IPv6, IGMPv3/MLDv2 protocols and listener mobility. Work requiring modifications to mobility protocols and IGMPv3/MLDv2 is out of scope in this first stage of this working group. Modifications to multicast routing protocols are out of scope. Specific goals for the group are: - Document how multicast can be supported in a Proxy Mobile IPv6 environment - Document the configuration of IGMPv3/MLDv2 in mobile environments The Proxy Mobile IPv6 (PMIPv6) specification as defined in RFC 5213 does not describe how to support multicast. Some forms of multicast support can, however, be built in the involved nodes by using existing capabilities of multicast protocols and the underlying mobility protocols. The first task of the working group is to document such solutions for PMIPv6. This work will not require any additions or changes to message types and parameters specified in RFC 5213, and must assume an unmodified mobile host. The work will employ the remote subscription model. This is a mechanism by which a mobile node joins a multicast group and receives multicast data forwarded via the local mobility anchor. IGMPv3/MLDv2 has been specified for wired networks with shared links. Mobile nodes have needs that are specific to wireless networks and mobility (e.g. entering a dormant mode to conserve battery power, minimizing the latency for joining and leaving a group in support of movement). The second task of the WG is to assess existing solutions for group management, and determine to what extent these methods are sufficient in a mobile environment. This will include recommending appropriate selection of timer values and protocol parameters. In performing its work, the working group will work closely with both the mobility community (NETLMM and NETEXT WGs) and the multicast community (MBONED WG). The group will consider both source specific multicast and any source multicast multicast models. Future work, subject to rechartering, may study/evaluate extensions to support PMIPv6 optimizations to address the avalanche problem and fast handover and extensions to IGMPv3/MLDv2 to support better operation in mobile environments. Internet-Drafts: No Current Internet-Drafts. Network Endpoint Assessment (nea) --------------------------------- Charter Last Modified: 2009-09-29 Current Status: Active Working Group Chair(s): Stephen Hanna Susan Thomson Security Area Director(s): Tim Polk Pasi Eronen Security Area Advisor: Tim Polk Mailing Lists: General Discussion:nea@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/nea Archive: http://www.ietf.org/mail-archive/web/nea Description of Working Group: Network Endpoint Assessment (NEA) architectures have been implemented in the industry to assess the "posture" of endpoint devices for the purposes of monitoring compliance to an organization's posture policy and optionally restricting access until the endpoint has been updated to satisfy the posture requirements. An endpoint that does not comply with posture policy may be vulnerable to a number of known threats that may exist on the network. The intent of NEA is to facilitate corrective actions to address these known vulnerabilities before a host is exposed to potential attack. Note that an endpoint that is deemed compliant may still be vulnerable to threats that may exist on the network. The network may thus continue to be exposed to such threats as well as the range of other threats not addressed by maintaining endpoint compliance. Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security policy. Posture may include knowledge that software installed to protect the machine (e.g. patch management software, anti-virus software, host firewall software, host intrusion protection software or any custom software) is enabled and up-to-date. An endpoint supporting NEA protocols can be queried for posture information. An organization may make a range of policy decisions based on the posture of an endpoint. NEA is not intended to be prescriptive in this regard. Supported deployment scenarios will include, but are not limited to, providing normal access regardless of compliance result along with any recommendations for remediation ("advisory mode"), as well as providing restricted access sufficient for remediation purposes and any essential services until an endpoint is in compliance ("mandatory mode"). Specifying mechanisms for providing restricted access is outside the scope of the NEA WG. Since NEA involves many different components from different vendors, interoperability is important. The NEA working group will develop standard protocols at the following three layers in the architecture: the Posture Attribute protocol (PA), the Posture Broker protocol (PB), and the Posture Transport protocol (PT). PA and PB will be designed to support a variety of PT protocols. Together, PA, PB and the mandatory to implement PT protocols will allow interoperability between an NEA Client from one vendor and an NEA Server from another. Since there are already several non-standard protocols at these layers, the NEA working group will consider these existing protocols as candidates for the standard protocols. A requirements document will be written and used as a basis for evaluating the candidate protocols. The working group may decide to standardize one of the candidate protocols, use one of them as a basis for a new or revised protocol, or decide that a new protocol is needed. The NEA Requirements document will include a problem statement, definition of terms, requirements for the PA and PB protocols, and an overall security analysis. It will also include generic requirements for the protocol transporting PA, PB: the Posture Transport protocol (PT). The PA (Posture Attribute) protocol consists of posture attributes that are carried between a particular Posture Collector in a NEA client and a particular Posture Validator in a NEA Server. The PA protocol is carried inside the PB protocol. A base set of standard posture attributes will be specified that are expected to address many common posture policies. Vendor-specific attributes will also be supported; vendor-specific attributes will be identified by a private enterprise number and a vendor assigned value. Vendors are strongly encouraged to document vendor-specific attributes in an RFC. The NEA WG will investigate the use of a standard syntax for all attributes. The PB (Posture Broker) protocol aggregates posture attributes from one or more Posture Collectors in an NEA client and sends them to the NEA server for assessment by one or more Posture Validators. The PT (Posture Transport) protocol carries the PB protocol. The expectation is that the PT protocol is a shim protocol that defines an encapsulation of PB within an existing standard transport protocol. Existing standard transport protocols will be leveraged to the extent possible. The NEA WG may specify more than one PT to meet the requirements of different deployment scenarios. The NEA WG will specify at least one mandatory to implement PT protocol. PT protocol specifications must describe any limitations that they impose on PB and PA (e.g. half duplex). One commonly discussed issue with NEA systems is how to handle compromised endpoints, whose reports of their own posture may not be accurate. Detecting or handling such endpoints is out of scope of the NEA WG. Work on PA will focus on attributes useful for assessing posture of those endpoints reporting accurate information. However, the protocols developed by the NEA WG must be designed to accommodate emerging technologies for identifying and dealing with lying endpoints. Note that NEA is not chartered to develop standard protocols for remediation. NEA is intended to be used with new or existing tools that can be used in the absence of NEA. NEA is applicable to computing enterprise environments, where endpoints accessing the enterprise's network are owned and/or expected to conform to the policies set forth by the organization that owns and operates the network. All other cases are outside the scope of the NEA charter, since we do not know that NEA would be useful in such cases. NEA applicability and security considerations will be described in the appropriate NEA documents. Further work in the NEA WG will be considered via the rechartering process after the completion of these milestones. Description of Working Group: Network Endpoint Assessment (NEA) architectures have been implemented in the industry to assess the "posture" of endpoint devices for the purposes of monitoring compliance to an organization's posture policy and optionally restricting access until the endpoint has been updated to satisfy the posture requirements. An endpoint that does not comply with posture policy may be vulnerable to a number of known threats that may exist on the network. The intent of NEA is to facilitate corrective actions to address these known vulnerabilities before a host is exposed to potential attack. Note that an endpoint that is deemed compliant may still be vulnerable to threats that may exist on the network. The network may thus continue to be exposed to such threats as well as the range of other threats not addressed by maintaining endpoint compliance. Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security policy. Posture may include knowledge that software installed to protect the machine (e.g. patch management software, anti-virus software, host firewall software, host intrusion protection software or any custom software) is enabled and up-to-date. An endpoint supporting NEA protocols can be queried for posture information. An organization may make a range of policy decisions based on the posture of an endpoint. NEA is not intended to be prescriptive in this regard. Supported deployment scenarios will include, but are not limited to, providing normal access regardless of compliance result along with any recommendations for remediation ("advisory mode"), as well as providing restricted access sufficient for remediation purposes and any essential services until an endpoint is in compliance ("mandatory mode"). Specifying mechanisms for providing restricted access is outside the scope of the NEA WG. Since NEA involves many different components from different vendors, interoperability is important. The NEA working group will develop standard protocols at the following three layers in the architecture: the Posture Attribute protocol (PA), the Posture Broker protocol (PB), and the Posture Transport protocol (PT). PA and PB will be designed to support a variety of PT protocols. Together, PA, PB and the mandatory to implement PT protocols will allow interoperability between an NEA Client from one vendor and an NEA Server from another. Since there are already several non-standard protocols at these layers, the NEA working group will consider these existing protocols as candidates for the standard protocols. A requirements document will be written and used as a basis for evaluating the candidate protocols. The working group may decide to standardize one of the candidate protocols, use one of them as a basis for a new or revised protocol, or decide that a new protocol is needed. The NEA Requirements document will include a problem statement, definition of terms, requirements for the PA and PB protocols, and an overall security analysis. It will also include generic requirements for the protocol transporting PA, PB: the Posture Transport protocol (PT). The PA (Posture Attribute) protocol consists of posture attributes that are carried between a particular Posture Collector in a NEA client and a particular Posture Validator in a NEA Server. The PA protocol is carried inside the PB protocol. A base set of standard posture attributes will be specified that are expected to address many common posture policies. Vendor-specific attributes will also be supported; vendor-specific attributes will be identified by a private enterprise number and a vendor assigned value. Vendors are strongly encouraged to document vendor-specific attributes in an RFC. The NEA WG will investigate the use of a standard syntax for all attributes. The PB (Posture Broker) protocol aggregates posture attributes from one or more Posture Collectors in an NEA client and sends them to the NEA server for assessment by one or more Posture Validators. The PT (Posture Transport) protocol carries the PB protocol. The expectation is that the PT protocol is a shim protocol that defines an encapsulation of PB within an existing standard transport protocol. Existing standard transport protocols will be leveraged to the extent possible. The NEA WG may specify more than one PT to meet the requirements of different deployment scenarios. The NEA WG will specify at least one mandatory to implement PT protocol. PT protocol specifications must describe any limitations that they impose on PB and PA (e.g. half duplex). One commonly discussed issue with NEA systems is how to handle compromised endpoints, whose reports of their own posture may not be accurate. Detecting or handling such endpoints is out of scope of the NEA WG. Work on PA will focus on attributes useful for assessing posture of those endpoints reporting accurate information. However, the protocols developed by the NEA WG must be designed to accommodate emerging technologies for identifying and dealing with lying endpoints. Note that NEA is not chartered to develop standard protocols for remediation. NEA is intended to be used with new or existing tools that can be used in the absence of NEA. NEA is applicable to computing enterprise environments, where endpoints accessing the enterprise's network are owned and/or expected to conform to the policies set forth by the organization that owns and operates the network. All other cases are outside the scope of the NEA charter, since we do not know that NEA would be useful in such cases. NEA applicability and security considerations will be described in the appropriate NEA documents. Further work in the NEA WG will be considered via the rechartering process after the completion of these milestones. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Apr 2008 Oct 2009 PB-TNC: A Posture Broker Protocol (PB) Compatible with TNC Apr 2008 Oct 2009 PA-TNC: A Posture Attribute Protocol (PA) Compatible with TNC Network Configuration (netconf) ------------------------------- Charter Last Modified: 2009-02-03 Current Status: Active Working Group Chair(s): Bert Wijnen Mehmet Ersue Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Technical Advisor(s): Charlie Kaufman Mailing Lists: General Discussion:netconf@ietf.org To Subscribe: netconf-request@ietf.org In Body: in msg body: subscribe Archive: http://www.ietf.org/mail-archive/web/netconf/ Description of Working Group: Charlie Kaufman is Technical Advisor for Security Matters Configuration of networks of devices has become a critical requirement for operators in today's highly interoperable networks. Operators from large to small have developed their own mechanisms or used vendor specific mechanisms to transfer configuration data to and from a device, and for examining device state information which may impact the configuration. Each of these mechanisms may be different in various aspects, such as session establishment, user authentication, configuration data exchange, and error responses. The NETCONF Working Group is chartered to produce a protocol suitable for network configuration, with the following characteristics: - Provides retrieval mechanisms which can differentiate between configuration data and non-configuration data - Is extensible enough so that vendors will provide access to all configuration data on the device using a single protocol - Has a programmatic interface (avoids screen scraping and formatting-related changes between releases) - Uses a textual data representation, that can be easily manipulated using non-specialized text manipulation tools. - Supports integration with existing user authentication methods - Supports integration with existing configuration database systems - Supports network wide configuration transactions (with features such as locking and rollback capability) - Is as transport-independent as possible - Provides support for asynchronous notifications. The NETCONF protocol is using XML for data encoding purposes, because XML is a widely deployed standard which is supported by a large number of applications. The NETCONF protocol should be independent of the data definition language and data models used to describe configuration and state data. However, the authorization model used in the protocol is dependent on the data model. Although these issues must be fully addressed to develop standard data models, only a small part of this work will be initially addressed. This group will specify requirements for standard data models in order to fully support the NETCONF protocol, such as: - identification of principals, such as user names or distinguished names - mechanism to distinguish configuration from non-configuration data - XML namespace conventions - XML usage guidelines The initial work started in 2003 and has already been completed and was restricted to following items: a) NETCONF Protocol Specification, which defines the operational model, protocol operations, transaction model, data model requirements, security requirements, and transport layer requirements. b) NETCONF over SSH Specification: Implementation Mandatory, c) NETCONF over BEEP Specification: Implementation Optional, d) NETCONF over SOAP Specification: Implementation Optional. These documents define how the NETCONF protocol is used with each transport protocol selected by the working group, and how it meets the security and transport layer requirements of the NETCONF Protocol Specification. e) NETCONF Notification Specification, which defines mechanisms that provide an asynchronous message notification delivery service for the NETCONF protocol. NETCONF Notification is an optional capability built on top of the base NETCONF definition and provides the capabilities and operations necessary to support this service. The NETCONF notification specification has been finished now as well. In the current phase of the incremental development of NETCONF the workgroup will focus on following items: 1. Fine-grain locking: The base NETCONF protocol only provides a lock for the entire configuration datastore, which is not deemed to meet important operational and security requirements. The NETCONF working group will produce a standards-track RFC specifying a mechanism for fine-grain locking of the NETCONF configuration datastore. 2. NETCONF monitoring: It is considered best practice for IETF working groups to include management of their protocols within the scope of the solution they are providing. The NETCONF working group will produce a standards-track RFC with mechanisms allowing NETCONF itself to be used to monitor some aspects of NETCONF operation. 3. Schema advertisement: Currently the NETCONF protocol is able to advertise which protocol features are supported on a particular netconf-capable device. However, there is currently no way to discover which XML Schema are supported on the device. The NETCONF working group will produce a standards-track RFC with mechanisms making this discovery possible (this item may be merged with "NETCONF monitoring" into a single document). Note: The schema-advertisement material has been merged into the NETCONF monitoring document based on WG consensus. 4. NETCONF over TLS: Based on implementation experience there is a need for a standards track document to define NETCONF over TLS as an optional transport for the NETCONF protocol. 5. NETCONF default handling: NETCONF today does not define whether default values should be returned by the server in replies to requests for reading configuration and state data. Different clients have different needs to receive or not to receive default data. The NETCONF working group will produce a standards-track RFC defining a mechanism that allows NETCONF clients to control whether default data is returned by the netconf server. 6. NETCONF implementations have shown that the specification in RFC4741 is not 100% clear and has lead to different interpretations and implementations. Also some errors have been uncovered. So the WG will do an rfc4741bis with following constraints: - bug fixes are to be done - clarifications can be done - extensions can be done only when needed to fix bugs or inconsistencies (i.e. we are not doing a NETCONF V2) - The work can be started based on the discussion in IETF #73 (see http://www.ietf.org/proceedings/08nov/slides/netconf-3.pdf). Note: A technical errata has been posted on rfc4742. If the work on rfc4741bis uncovers any additional fixes/clarifications that need to be made to rfc4742, the WG may consider to also do a rfc4742bis as part of this work-item. The following items have been identified as important but are currently not considered in scope for re-chartering and may be candidates for work when there is community consensus to take them on: - NETCONF Notification content - Access Control requirements - NETCONF access to SMI-based MIB data Description of Working Group: Charlie Kaufman is Technical Advisor for Security Matters Configuration of networks of devices has become a critical requirement for operators in today's highly interoperable networks. Operators from large to small have developed their own mechanisms or used vendor specific mechanisms to transfer configuration data to and from a device, and for examining device state information which may impact the configuration. Each of these mechanisms may be different in various aspects, such as session establishment, user authentication, configuration data exchange, and error responses. The NETCONF Working Group is chartered to produce a protocol suitable for network configuration, with the following characteristics: - Provides retrieval mechanisms which can differentiate between configuration data and non-configuration data - Is extensible enough so that vendors will provide access to all configuration data on the device using a single protocol - Has a programmatic interface (avoids screen scraping and formatting-related changes between releases) - Uses a textual data representation, that can be easily manipulated using non-specialized text manipulation tools. - Supports integration with existing user authentication methods - Supports integration with existing configuration database systems - Supports network wide configuration transactions (with features such as locking and rollback capability) - Is as transport-independent as possible - Provides support for asynchronous notifications. The NETCONF protocol is using XML for data encoding purposes, because XML is a widely deployed standard which is supported by a large number of applications. The NETCONF protocol should be independent of the data definition language and data models used to describe configuration and state data. However, the authorization model used in the protocol is dependent on the data model. Although these issues must be fully addressed to develop standard data models, only a small part of this work will be initially addressed. This group will specify requirements for standard data models in order to fully support the NETCONF protocol, such as: - identification of principals, such as user names or distinguished names - mechanism to distinguish configuration from non-configuration data - XML namespace conventions - XML usage guidelines The initial work started in 2003 and has already been completed and was restricted to following items: a) NETCONF Protocol Specification, which defines the operational model, protocol operations, transaction model, data model requirements, security requirements, and transport layer requirements. b) NETCONF over SSH Specification: Implementation Mandatory, c) NETCONF over BEEP Specification: Implementation Optional, d) NETCONF over SOAP Specification: Implementation Optional. These documents define how the NETCONF protocol is used with each transport protocol selected by the working group, and how it meets the security and transport layer requirements of the NETCONF Protocol Specification. e) NETCONF Notification Specification, which defines mechanisms that provide an asynchronous message notification delivery service for the NETCONF protocol. NETCONF Notification is an optional capability built on top of the base NETCONF definition and provides the capabilities and operations necessary to support this service. The NETCONF notification specification has been finished now as well. In the current phase of the incremental development of NETCONF the workgroup will focus on following items: 1. Fine-grain locking: The base NETCONF protocol only provides a lock for the entire configuration datastore, which is not deemed to meet important operational and security requirements. The NETCONF working group will produce a standards-track RFC specifying a mechanism for fine-grain locking of the NETCONF configuration datastore. 2. NETCONF monitoring: It is considered best practice for IETF working groups to include management of their protocols within the scope of the solution they are providing. The NETCONF working group will produce a standards-track RFC with mechanisms allowing NETCONF itself to be used to monitor some aspects of NETCONF operation. 3. Schema advertisement: Currently the NETCONF protocol is able to advertise which protocol features are supported on a particular netconf-capable device. However, there is currently no way to discover which XML Schema are supported on the device. The NETCONF working group will produce a standards-track RFC with mechanisms making this discovery possible (this item may be merged with "NETCONF monitoring" into a single document). Note: The schema-advertisement material has been merged into the NETCONF monitoring document based on WG consensus. 4. NETCONF over TLS: Based on implementation experience there is a need for a standards track document to define NETCONF over TLS as an optional transport for the NETCONF protocol. 5. NETCONF default handling: NETCONF today does not define whether default values should be returned by the server in replies to requests for reading configuration and state data. Different clients have different needs to receive or not to receive default data. The NETCONF working group will produce a standards-track RFC defining a mechanism that allows NETCONF clients to control whether default data is returned by the netconf server. 6. NETCONF implementations have shown that the specification in RFC4741 is not 100% clear and has lead to different interpretations and implementations. Also some errors have been uncovered. So the WG will do an rfc4741bis with following constraints: - bug fixes are to be done - clarifications can be done - extensions can be done only when needed to fix bugs or inconsistencies (i.e. we are not doing a NETCONF V2) - The work can be started based on the discussion in IETF #73 (see http://www.ietf.org/proceedings/08nov/slides/netconf-3.pdf). Note: A technical errata has been posted on rfc4742. If the work on rfc4741bis uncovers any additional fixes/clarifications that need to be made to rfc4742, the WG may consider to also do a rfc4742bis as part of this work-item. The following items have been identified as important but are currently not considered in scope for re-chartering and may be candidates for work when there is community consensus to take them on: - NETCONF Notification content - Access Control requirements - NETCONF access to SMI-based MIB data Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jan 2008 Oct 2009 Partial Lock RPC for NETCONF Jan 2008 Oct 2009 NETCONF Monitoring Schema Feb 2009 Oct 2009 With-defaults capability for NETCONF Mar 2009 Jul 2009 NETCONF Configuration Protocol Network-Based Mobility Extensions (netext) ------------------------------------------ Charter Last Modified: 2009-06-18 Current Status: Active Working Group Chair(s): Rajeev Koodli Basavaraj Patil Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:netext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netext Archive: http://www.ietf.org/mail-archive/web/netext/current/maillist.html Description of Working Group: Proxy Mobile IPv6, specified in RFC 5213, is a network-based mobility protocol. It uses a Mobile Access Gateway (MAG) and a Local Mobility Anchor (LMA) to allow hosts to move around within a domain while keeping their address or address prefix stable. Proxy Mobile IPv6 has been incorporated into a number of products and deployments are starting. Certain deployment considerations, including localized routing and bulk refresh of lifetime are already emerging. The working group will focus on the following topics relevant for network-based mobility: Localized Routing: a specification for routing traffic between the MAG(s) without involving the LMA. That is, allow the MAGs to route traffic between hosts from one MAG to another, without being tunneled all the way to the LMA. This reduces latency and backhaul load. Applications such as voice can benefit from the reduced latency. Bulk Refresh: a specification of improving the signaling load for binding lifetime refresh. The current specifications call for the handling of each mobility session independent of each other. When a large number of hosts are served by a single MAG, a periodic refresh of the binding lifetimes can lead to a signaling storm. The purpose of the Bulk Refresh feature is to construct a protocol feature that allows such refreshes to occur on a per-MAG basis. LMA Redirection: a specification for allowing an LMA to redirect a MAG to another LMA. This is primarily needed as a way to perform load balancing. This functionality is complementary to implementation techniques that allow distributed MAG implementations to move tasks around without a visible impact at the protocol level, and the initial LMA discovery work in the NETLMM WG. An applicability statement describing the situations where the new functionality is or is not applicable has to be included in the specification. The work in this charter is entirely internal to the network and does not affect hosts in any way (except perhaps through impacting packet forwarding capacity visible to the hosts). The proposed activity will be complementary to the existing IETF Working Groups, notably the NETLMM and MEXT WGs. The NETEXT working group will also act as the primary forum where new extensions on top of the Proxy Mobile IPv6 protocol can be developed. The addition of such new extensions to the working group involves addition of the extension to this charter through the normal rechartering process. This initial charter excludes a number of possible work items that were discussed in the March 2009 BOF. The working group should continue the discussion about a possible update of its charter and principles under which the new work items must operate under. The completion of the work items in the initial charter is not a requirement for the rechartering to become possible. Description of Working Group: Proxy Mobile IPv6, specified in RFC 5213, is a network-based mobility protocol. It uses a Mobile Access Gateway (MAG) and a Local Mobility Anchor (LMA) to allow hosts to move around within a domain while keeping their address or address prefix stable. Proxy Mobile IPv6 has been incorporated into a number of products and deployments are starting. Certain deployment considerations, including localized routing and bulk refresh of lifetime are already emerging. The working group will focus on the following topics relevant for network-based mobility: Localized Routing: a specification for routing traffic between the MAG(s) without involving the LMA. That is, allow the MAGs to route traffic between hosts from one MAG to another, without being tunneled all the way to the LMA. This reduces latency and backhaul load. Applications such as voice can benefit from the reduced latency. Bulk Refresh: a specification of improving the signaling load for binding lifetime refresh. The current specifications call for the handling of each mobility session independent of each other. When a large number of hosts are served by a single MAG, a periodic refresh of the binding lifetimes can lead to a signaling storm. The purpose of the Bulk Refresh feature is to construct a protocol feature that allows such refreshes to occur on a per-MAG basis. LMA Redirection: a specification for allowing an LMA to redirect a MAG to another LMA. This is primarily needed as a way to perform load balancing. This functionality is complementary to implementation techniques that allow distributed MAG implementations to move tasks around without a visible impact at the protocol level, and the initial LMA discovery work in the NETLMM WG. An applicability statement describing the situations where the new functionality is or is not applicable has to be included in the specification. The work in this charter is entirely internal to the network and does not affect hosts in any way (except perhaps through impacting packet forwarding capacity visible to the hosts). The proposed activity will be complementary to the existing IETF Working Groups, notably the NETLMM and MEXT WGs. The NETEXT working group will also act as the primary forum where new extensions on top of the Proxy Mobile IPv6 protocol can be developed. The addition of such new extensions to the working group involves addition of the extension to this charter through the normal rechartering process. This initial charter excludes a number of possible work items that were discussed in the March 2009 BOF. The working group should continue the discussion about a possible update of its charter and principles under which the new work items must operate under. The completion of the work items in the initial charter is not a requirement for the rechartering to become possible. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Sep 2009 Oct 2009 PMIPv6 Localized Routing Problem Statement Oct 2009 Oct 2009 Runtime LMA Assignment Support for Proxy Mobile IPv6 Network-based Localized Mobility Management (netlmm) ---------------------------------------------------- Charter Last Modified: 2008-12-16 Current Status: Active Working Group Chair(s): Vidya Narayanan Jonne Soininen Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:netlmm@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/netlmm In Body: to subscribe Archive: http://www.ietf.org/mail-archive/web/netlmm Description of Working Group: The IETF has defined both local and global mobility management protocols that are intended to handle IP mobility for nodes. All IP mobility management protocols defined thus far require the involvement of the mobile node in order to accomplish mobility. This working group is tasked with defining a network-based local mobility management protocol, where local IP mobility is handled without involvement from the mobile node. The idea is that the mobile node may move across multiple access routers without encountering a change in its IP address, thereby hiding the mobility from the IP layer and above. As part of the first phase of efforts in this working group, a protocol for such network-based local mobility has been developed. This protocol, Proxy Mobile IPv6 (PMIPv6), has been developed based on Mobile IPv6, after considering other alternative approaches. With this protocol, unmodified IP nodes may change access routers without having to change the IP address on an interface, within a given administrative domain. This is accomplished by having Mobile Access Gateways (MAGs), often part of the access routers in a network, send binding updates on behalf of mobile nodes attached to them, to a Local Mobility Anchor (LMA). The LMA manages the mobility of the mobile nodes across the MAGs within a given PMIPv6 domain. The PMIPv6 protocol is being adopted as part of several wide-area wireless network (e.g., 3GPP, 3GPP2, WiMAX) and local area network environments. The current charter of this working group involves specification of some necessary features that make the deployment of this protocol feasible in these various environments. As part of this effort, it is essential to support mobility for IPv4 end nodes. Some means of dealing with overlapping private IPv4 addresses of mobile nodes and supporting separation of flows between the MAG and LMA is also required. Further, given that local and global mobility management protocols are likely to be deployed in some combination in various environments, it is necessary to clearly define the interactions between PMIPv6 and MIPv6. Interactions with AAA protocols such as RADIUS and Diameter may be required for authorization or provisioning purposes. When multiple LMAs are present, an automated LMA discovery mechanism may be needed to facilitate deployment. The above items are in scope of the current charter. The MAG and LMA are considered to be IPv6 capable for all efforts of this protocol. Also, all features defined must work with unmodified IP nodes. Specifying any changes to mobile nodes is out of scope of the current charter. Handoff and route optimizations are also out of scope. There is, however, considerable interest in optimization work, for instance, and a future recharter of this working group is likely to address this in some manner. NETLMM WG Deliverables ---------------------- 1) Interface between a PMIPv6 MAG and MN: This interface will define the interaction between a regular IP node and a MAG that will be used to trigger various mobility management actions on the MAG. This is necessary for the MAG to properly trigger binding updates to the LMA and create appropriate mobility management state. 2) IPv4 Support for PMIPv6: This will define the support for IPv4 nodes in PMIPv6. This will also define the protocol operation over an IPv4 transport between the MAG and LMA, by employing protocol extensions already developed in the MEXT WG. 3) Interactions between Mobile IPv6 and Proxy Mobile IPv6: This will highlight the interactions required between these protocols in various methods of co-existence of these in a system, with a view to documenting the best practices to be used. The scenarios considered will include a hierarchical model of local and global mobility management using PMIPv6 and MIPv6 respectively, a mixed mode of the two with some nodes supporting MIPv6 and others not, and the use of MIPv6 upon movement of nodes outside a PMIPv6 domain. 4) GRE Keying option for PMIPv6: This will define a mechanism using GRE keys to support separation of flows between a MAG and LMA. 5) RADIUS support for PMIPv6: This will define the interactions between RADIUS and PMIPv6 to support policy provisioning and authorization. 6) Automatic LMA discovery: This will define the ability for MAGs to automatically discover and use an LMA within a PMIPv6 domain. The scope of this effort may include specifying the use of DNS or DHCP based LMA discovery or LMA discovery using policy information retrieved via AAA protocols. 7) MIB for PMIPv6: This will define the MIB for the protocol for interoperability purposes. 8) PMIPv6 path management and failure detection: This will define an extension to the PMIPv6 protocol allowing PMIPv6 peers to verify bidirectional reachability with their peer, detect failure of their peer, and signal their own failure to their peer. Description of Working Group: The IETF has defined both local and global mobility management protocols that are intended to handle IP mobility for nodes. All IP mobility management protocols defined thus far require the involvement of the mobile node in order to accomplish mobility. This working group is tasked with defining a network-based local mobility management protocol, where local IP mobility is handled without involvement from the mobile node. The idea is that the mobile node may move across multiple access routers without encountering a change in its IP address, thereby hiding the mobility from the IP layer and above. As part of the first phase of efforts in this working group, a protocol for such network-based local mobility has been developed. This protocol, Proxy Mobile IPv6 (PMIPv6), has been developed based on Mobile IPv6, after considering other alternative approaches. With this protocol, unmodified IP nodes may change access routers without having to change the IP address on an interface, within a given administrative domain. This is accomplished by having Mobile Access Gateways (MAGs), often part of the access routers in a network, send binding updates on behalf of mobile nodes attached to them, to a Local Mobility Anchor (LMA). The LMA manages the mobility of the mobile nodes across the MAGs within a given PMIPv6 domain. The PMIPv6 protocol is being adopted as part of several wide-area wireless network (e.g., 3GPP, 3GPP2, WiMAX) and local area network environments. The current charter of this working group involves specification of some necessary features that make the deployment of this protocol feasible in these various environments. As part of this effort, it is essential to support mobility for IPv4 end nodes. Some means of dealing with overlapping private IPv4 addresses of mobile nodes and supporting separation of flows between the MAG and LMA is also required. Further, given that local and global mobility management protocols are likely to be deployed in some combination in various environments, it is necessary to clearly define the interactions between PMIPv6 and MIPv6. Interactions with AAA protocols such as RADIUS and Diameter may be required for authorization or provisioning purposes. When multiple LMAs are present, an automated LMA discovery mechanism may be needed to facilitate deployment. The above items are in scope of the current charter. The MAG and LMA are considered to be IPv6 capable for all efforts of this protocol. Also, all features defined must work with unmodified IP nodes. Specifying any changes to mobile nodes is out of scope of the current charter. Handoff and route optimizations are also out of scope. There is, however, considerable interest in optimization work, for instance, and a future recharter of this working group is likely to address this in some manner. NETLMM WG Deliverables ---------------------- 1) Interface between a PMIPv6 MAG and MN: This interface will define the interaction between a regular IP node and a MAG that will be used to trigger various mobility management actions on the MAG. This is necessary for the MAG to properly trigger binding updates to the LMA and create appropriate mobility management state. 2) IPv4 Support for PMIPv6: This will define the support for IPv4 nodes in PMIPv6. This will also define the protocol operation over an IPv4 transport between the MAG and LMA, by employing protocol extensions already developed in the MEXT WG. 3) Interactions between Mobile IPv6 and Proxy Mobile IPv6: This will highlight the interactions required between these protocols in various methods of co-existence of these in a system, with a view to documenting the best practices to be used. The scenarios considered will include a hierarchical model of local and global mobility management using PMIPv6 and MIPv6 respectively, a mixed mode of the two with some nodes supporting MIPv6 and others not, and the use of MIPv6 upon movement of nodes outside a PMIPv6 domain. 4) GRE Keying option for PMIPv6: This will define a mechanism using GRE keys to support separation of flows between a MAG and LMA. 5) RADIUS support for PMIPv6: This will define the interactions between RADIUS and PMIPv6 to support policy provisioning and authorization. 6) Automatic LMA discovery: This will define the ability for MAGs to automatically discover and use an LMA within a PMIPv6 domain. The scope of this effort may include specifying the use of DNS or DHCP based LMA discovery or LMA discovery using policy information retrieved via AAA protocols. 7) MIB for PMIPv6: This will define the MIB for the protocol for interoperability purposes. 8) PMIPv6 path management and failure detection: This will define an extension to the PMIPv6 protocol allowing PMIPv6 peers to verify bidirectional reachability with their peer, detect failure of their peer, and signal their own failure to their peer. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Apr 2007 Sep 2009 IPv4 Support for Proxy Mobile IPv6 Aug 2008 May 2009 GRE Key Option for Proxy Mobile IPv6 Sep 2008 Apr 2009 Heartbeat Mechanism for Proxy Mobile IPv6 Oct 2008 Jun 2009 Interactions between PMIPv6 and MIPv6: scenarios and related issues May 2009 Sep 2009 LMA Discovery for Proxy Mobile IPv6 Jul 2009 Sep 2009 Proxy Mobile IPv6 Management Information Base NETCONF Data Modeling Language (netmod) --------------------------------------- Charter Last Modified: 2009-05-06 Current Status: Active Working Group Chair(s): David Partain David Kessens Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion:netmod@ietf.org To Subscribe: netmod-request@ietf.org In Body: In msg body: subscribe Archive: http://www.ietf.org/mail-archive/web/netmod/ Description of Working Group: The NETCONF Working Group has completed a base protocol to be used for configuration management. However, the NETCONF protocol does not include a standard content layer. The specifications do not include a modeling language or accompanying rules that can be used to model the management information that is to be configured using NETCONF. This has resulted in inconsistent syntax and interoperability problems. The purpose of NETMOD is to support the ongoing development of IETF and vendor-defined data models for NETCONF. NETMOD's requirements are drawn from the RCDML requirements draft (draft-presuhn-rcdml) and documents referenced therein. The WG will define a "human-friendly" modeling language defining the semantics of operational data, configuration data, notifications, and operations. This language will focus on readability and ease of use. This language must be able to serve as the normative description of NETCONF data models. The WG will use YANG (draft-bjorklund-yang) as its starting point for this language. Language abstractions that facilitate model extensibility and reuse have been identified as a work area and will be considered as a work item or may be integrated into the YANG document based on WG consensus. The WG will define a canonical mapping of this language to NETCONF XML instance documents, the on-the-wire format of YANG-defined XML content. Only data models defined in YANG will have to adhere to this on-the-wire format. In order to leverage existing XML tools for validating NETCONF data in various contexts and also facilitate exchange of data models and schemas with other IETF working groups, the WG will define standard mapping rules from YANG to the DSDL data modeling framework (ISO/IEC 19757) with additional annotations to preserve semantics. The initial YANG mapping rules specifications are expressly defined for NETCONF modeling. However, there may be future areas of applicability beyond NETCONF, and the WG must provide suitable language extensibility mechanisms to allow for such future work. The NETMOD WG will only address modeling NETCONF devices and the language extensibility mechanisms. Any application of YANG to other protocols is future work. The WG will consult with the NETCONF WG to ensure that NETMOD's decision do not conflict with planned work in NETCONF (e.g., locking, notifications). While it is desirable to provide a migration path from existing MIB modules to YANG data models (modules), it is not a requirement to provide full compatibility between SMIv2 and YANG. The Working Group will determine which constructs (e.g., conformance statements) are not relevant for translation from SMIv2 to YANG. YANG is also permitted to introduce constructs that cannot be expressed in SMIv2. However, all basic types that can be represented in SMIv2 must be expressible in YANG. Initial deliverables are below. The working group may choose to combine multiple deliverables into a single document where deemed appropriate. 1. An architecture document explaining the relationship between YANG and its inputs and outputs. (informational) 2. The YANG data modeling language and semantics (proposed standard) 3. Mapping rules of YANG to XML instance data in NETCONF (proposed standard) 4. YIN, a semantically equivalent fully reversible mapping to an XML-based syntax for YANG. YIN is simply the data model in an XML syntax that can be manipulated using existing XML tools (e.g., XSLT) (proposed standard) 5. Mapping rules of YANG to DSDL data modeling framework (ISO/IEC 19757), including annotations for DSDL to preserve top-level semantics during translation (proposed standard). 6. A standard type library for use by YANG (proposed standard) Description of Working Group: The NETCONF Working Group has completed a base protocol to be used for configuration management. However, the NETCONF protocol does not include a standard content layer. The specifications do not include a modeling language or accompanying rules that can be used to model the management information that is to be configured using NETCONF. This has resulted in inconsistent syntax and interoperability problems. The purpose of NETMOD is to support the ongoing development of IETF and vendor-defined data models for NETCONF. NETMOD's requirements are drawn from the RCDML requirements draft (draft-presuhn-rcdml) and documents referenced therein. The WG will define a "human-friendly" modeling language defining the semantics of operational data, configuration data, notifications, and operations. This language will focus on readability and ease of use. This language must be able to serve as the normative description of NETCONF data models. The WG will use YANG (draft-bjorklund-yang) as its starting point for this language. Language abstractions that facilitate model extensibility and reuse have been identified as a work area and will be considered as a work item or may be integrated into the YANG document based on WG consensus. The WG will define a canonical mapping of this language to NETCONF XML instance documents, the on-the-wire format of YANG-defined XML content. Only data models defined in YANG will have to adhere to this on-the-wire format. In order to leverage existing XML tools for validating NETCONF data in various contexts and also facilitate exchange of data models and schemas with other IETF working groups, the WG will define standard mapping rules from YANG to the DSDL data modeling framework (ISO/IEC 19757) with additional annotations to preserve semantics. The initial YANG mapping rules specifications are expressly defined for NETCONF modeling. However, there may be future areas of applicability beyond NETCONF, and the WG must provide suitable language extensibility mechanisms to allow for such future work. The NETMOD WG will only address modeling NETCONF devices and the language extensibility mechanisms. Any application of YANG to other protocols is future work. The WG will consult with the NETCONF WG to ensure that NETMOD's decision do not conflict with planned work in NETCONF (e.g., locking, notifications). While it is desirable to provide a migration path from existing MIB modules to YANG data models (modules), it is not a requirement to provide full compatibility between SMIv2 and YANG. The Working Group will determine which constructs (e.g., conformance statements) are not relevant for translation from SMIv2 to YANG. YANG is also permitted to introduce constructs that cannot be expressed in SMIv2. However, all basic types that can be represented in SMIv2 must be expressible in YANG. Initial deliverables are below. The working group may choose to combine multiple deliverables into a single document where deemed appropriate. 1. An architecture document explaining the relationship between YANG and its inputs and outputs. (informational) 2. The YANG data modeling language and semantics (proposed standard) 3. Mapping rules of YANG to XML instance data in NETCONF (proposed standard) 4. YIN, a semantically equivalent fully reversible mapping to an XML-based syntax for YANG. YIN is simply the data model in an XML syntax that can be manipulated using existing XML tools (e.g., XSLT) (proposed standard) 5. Mapping rules of YANG to DSDL data modeling framework (ISO/IEC 19757), including annotations for DSDL to preserve top-level semantics during translation (proposed standard). 6. A standard type library for use by YANG (proposed standard) Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- May 2008 Oct 2009 YANG - A data modeling language for NETCONF Sep 2008 Oct 2009 Common YANG Data Types Feb 2009 Oct 2009 Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content Mar 2009 May 2009 An NETCONF- and NETMOD-based Architecture for Network Management May 2009 Oct 2009 Guidelines for Authors and Reviewers of YANG Data Model Documents Network File System Version 4 (nfsv4) ------------------------------------- Charter Last Modified: 2009-03-18 Current Status: Active Working Group Chair(s): Brian Pawlowski Spencer Shepler Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Lars Eggert Technical Advisor(s): Leif Johansson Mailing Lists: General Discussion:nfsv4@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/nfsv4 Archive: http://www.ietf.org/mail-archive/web/nfsv4/current/maillist.html Description of Working Group: NFS Version 4 is the IETF standard for file sharing. To maintain NFS Version 4's utility and currency, the working group is chartered to (1) maintain the existing NFSv4, NFSv4.1 and related specifications, such as RPC and XDR, (2) progress these specifications along the standards track, (3) develop a protocol to create a federated namespace using NFSv4's existing referral mechanisms. (1) NFS version 4.0 maintenance Under this charter item, the WG correct errors and ambiguities in the protocol currently specified in RFC 3530 and advances it along the standards track. Extensions of any other kind are out of scope under this charter item. (2) NFS Version 4.1 Maintenance As with NFSv4.0, the WG will address errors or ambiguities in the NFSv4.1 protocol and related specifications in support of progressing implementations. (3) RPC and XDR protocol maintenance The NFSv4 protocol depends on two related specifications: ONC RPC and XDR. Similar to charter item (1), the WG may correct errors and ambiguities in the ONC RPC and XDR protocols currently specified by RFCs 1831, 1833 and 2203. In conjunction with the advancement of the NFSv4 specification along the standards track, the WG will also work on the advancements of its ONC RPC and XDR dependencies. The WG will also update the ONC RPC specification for compatibility with IPv6. Additionally, it will create an IANA registry for RPC program numbers and seed it with a registry Sun has been maintaining. (4) Federated Namespace The NFSv4 protocol provides a referral mechanism that allows a server to redirect a client to another server. The working group will produce documents describing a mechanism for creating a federated namespace (single global name space for a set of NFSv4 servers) using the NFSv4 protocol's referral capabilities. The file system federation protocol will enable file access and namespace traversal across collections of independently administered fileservers. No modifications will be made to the NFS client to server protocol. Description of Working Group: NFS Version 4 is the IETF standard for file sharing. To maintain NFS Version 4's utility and currency, the working group is chartered to (1) maintain the existing NFSv4, NFSv4.1 and related specifications, such as RPC and XDR, (2) progress these specifications along the standards track, (3) develop a protocol to create a federated namespace using NFSv4's existing referral mechanisms. (1) NFS version 4.0 maintenance Under this charter item, the WG correct errors and ambiguities in the protocol currently specified in RFC 3530 and advances it along the standards track. Extensions of any other kind are out of scope under this charter item. (2) NFS Version 4.1 Maintenance As with NFSv4.0, the WG will address errors or ambiguities in the NFSv4.1 protocol and related specifications in support of progressing implementations. (3) RPC and XDR protocol maintenance The NFSv4 protocol depends on two related specifications: ONC RPC and XDR. Similar to charter item (1), the WG may correct errors and ambiguities in the ONC RPC and XDR protocols currently specified by RFCs 1831, 1833 and 2203. In conjunction with the advancement of the NFSv4 specification along the standards track, the WG will also work on the advancements of its ONC RPC and XDR dependencies. The WG will also update the ONC RPC specification for compatibility with IPv6. Additionally, it will create an IANA registry for RPC program numbers and seed it with a registry Sun has been maintaining. (4) Federated Namespace The NFSv4 protocol provides a referral mechanism that allows a server to redirect a client to another server. The working group will produce documents describing a mechanism for creating a federated namespace (single global name space for a set of NFSv4 servers) using the NFSv4 protocol's referral capabilities. The file system federation protocol will enable file access and namespace traversal across collections of independently administered fileservers. No modifications will be made to the NFS client to server protocol. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2004 Dec 2008 Remote Direct Memory Access Transport for Remote Procedure Call Jul 2004 Apr 2008 NFS Direct Data Placement Oct 2005 Dec 2008 NFS Version 4 Minor Version 1 Jan 2006 Dec 2008 pNFS Block/Volume Layout Jan 2006 Dec 2008 Object-based pNFS Operations Nov 2007 Dec 2008 NFSv4 Minor Version 1 XDR Description Aug 2008 Jan 2009 IANA Considerations for RPC Net Identifiers and Universal Address Formats Sep 2008 Oct 2009 Using DNS SRV to Specify a Global File Name Space with NFS version 4 Sep 2008 Oct 2009 Administration Protocol for Federated Filesystems Sep 2008 Oct 2009 Requirements for Federated File Systems Sep 2008 Oct 2009 NSDB Protocol for Federated Filesystems Next Steps in Signaling (nsis) ------------------------------ Charter Last Modified: 2009-09-22 Current Status: Active Working Group Chair(s): Martin Stiemerling Jukka Manner Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Magnus Westerlund Secretary(ies): Hannes Tschofenig Mailing Lists: General Discussion:nsis@ietf.org To Subscribe: nsis-request@ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/nsis/index.html Description of Working Group: The Next Steps in Signaling Working Group is responsible for standardizing an IP signaling protocol with QoS signaling as the first use case. This working group will concentrate on a two-layer signaling paradigm. The intention is to re-use, where appropriate, the protocol mechanisms of RSVP, while at the same time simplifying it and applying a more general signaling model. The existing work on the requirements, the framework and analysis of existing protocols will be completed and used as input for the protocol work. NSIS will develop a transport layer signaling protocol for the transport of upper layer signaling. In order to support a toolbox or building block approach, the two-layer model will be used to separate the transport of the signaling from the application signaling. This allows for a more general signaling protocol to be developed to support signaling for different services or resources, such as NAT & firewall traversal and QoS resources. The initial NSIS application will be an optimized RSVP QoS signaling protocol. The second application will be a middle box traversal protocol. An informational document detailing how Differentiated Services can be signaled with the QoS Signaling protocol will be made. Security is a very important concern for NSIS. The working group will study and analyze the threats and security requirements for signaling. Compatibility with authentication and authorization mechanisms such as those of Diameter, COPS for RSVP (RFC 2749) and RSVP Session Authorization (RFC 3250), will be addressed. It is a non-goal of the working group to develop new resource allocation protocols. Traffic engineering is out of scope of this WG. Additionally, third party signaling is out of scope of this WG. New mobility and AAA protocols are out of scope of the WG. However, the work produced in this Working Group should work with existing IETF mobility and AAA protocols, including (but not limited to) Mobile IP, Seanoby Context Transfer, etc. An applicability statement will be written to discuss the applicability of NSIS protocols in mobile environments. NSIS also welcomes participation and expression of requirements requirements from non-IETF standards organization members, for instance 3GPP, 3GPP2 and ITU-T. Description of Working Group: The Next Steps in Signaling Working Group is responsible for standardizing an IP signaling protocol with QoS signaling as the first use case. This working group will concentrate on a two-layer signaling paradigm. The intention is to re-use, where appropriate, the protocol mechanisms of RSVP, while at the same time simplifying it and applying a more general signaling model. The existing work on the requirements, the framework and analysis of existing protocols will be completed and used as input for the protocol work. NSIS will develop a transport layer signaling protocol for the transport of upper layer signaling. In order to support a toolbox or building block approach, the two-layer model will be used to separate the transport of the signaling from the application signaling. This allows for a more general signaling protocol to be developed to support signaling for different services or resources, such as NAT & firewall traversal and QoS resources. The initial NSIS application will be an optimized RSVP QoS signaling protocol. The second application will be a middle box traversal protocol. An informational document detailing how Differentiated Services can be signaled with the QoS Signaling protocol will be made. Security is a very important concern for NSIS. The working group will study and analyze the threats and security requirements for signaling. Compatibility with authentication and authorization mechanisms such as those of Diameter, COPS for RSVP (RFC 2749) and RSVP Session Authorization (RFC 3250), will be addressed. It is a non-goal of the working group to develop new resource allocation protocols. Traffic engineering is out of scope of this WG. Additionally, third party signaling is out of scope of this WG. New mobility and AAA protocols are out of scope of the WG. However, the work produced in this Working Group should work with existing IETF mobility and AAA protocols, including (but not limited to) Mobile IP, Seanoby Context Transfer, etc. An applicability statement will be written to discuss the applicability of NSIS protocols in mobile environments. NSIS also welcomes participation and expression of requirements requirements from non-IETF standards organization members, for instance 3GPP, 3GPP2 and ITU-T. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Sep 2003 Oct 2009 NSLP for Quality-of-Service Signaling Oct 2003 Nov 2008 NAT/Firewall NSIS Signaling Layer Protocol (NSLP) Oct 2003 Jun 2009 GIST: General Internet Signalling Transport Sep 2004 Nov 2009 QoS NSLP QSPEC Template Oct 2004 Jul 2009 Applicability Statement of NSIS Protocols in Mobile Environments Nov 2004 Jul 2009 RMD-QOSM - The Resource Management in Diffserv QOS Model Jul 2005 Jul 2009 GIST State Machine Aug 2005 Oct 2008 Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes Jun 2006 Jun 2009 NSIS Operation Over IP Tunnels Feb 2009 Aug 2009 Using and Extending the NSIS Protocol Family Network Time Protocol (ntp) --------------------------- Charter Last Modified: 2009-08-04 Current Status: Active Working Group Chair(s): Brian Haberman Karen O'Donoghue Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion:ntpwg@lists.ntp.isc.org To Subscribe: https://lists.ntp.isc.org/mailman/listinfo/ntpwg Archive: http://lists.ntp.isc.org/pipermail/ntpwg Description of Working Group: The Network Time Protocol (NTP) is widely deployed and used in the Internet. However, the standardization status of this protocol has lagged in the IETF. RFC 1305 (NTP version 3) was published in March 1992 and remains unchanged and at Draft Standard status. RFC 1305 represents the majority of full NTP implementations deployed today. RFC 2030 (SNTP version 4) was published as an Informational RFC in October 1996 as a lightweight version of NTP for deployments not requiring the full functionality of NTP. SNTP now represents the majority of both NTP traffic and NTP implementation issues on the Internet. A good deal of work has been produced in the NTP community updating both NTPv3 and SNTPv4. This work is ongoing and available through the collaborative development effort in the NTP community, but it has not been reflected back into the NTP specifications. The goal of this working group is to document NTPv4 based on the extensive work of the NTP community and to advance the standardization status of NTP. It is an explicit goal of this effort to have NTPv4 interoperate with the deployed base avoiding any backwards-incompatible changes. A number of topics have been raised as potential work items for an update to NTP including support for IPv6, security considerations including authentication, automatic configuration including possible requirements for DHCP, and algorithm improvements. This working group will focus first on delivering NTPv4 and will defer additional development efforts until after the delivery of NTPv4. Support for IPv6 and defining mechanisms for securing NTP transactions is considered part of the core NTPv4 functionality. Potential further modifications and additions to the NTP protocol will be documented for possible further work beyond the initial NTPv4 effort. The working group will initially focus on the following deliverables: 1. NTPv4 Scope and Requirements Document (documenting the scope of the NTPv4 update and identifying issues deferred for future work). 2. NTPv4 Protocol Specification (documenting the protocol on the wire) 3. NTPv4 Architecture and Algorithms Specification (documenting the architecture, mathematical algorithms, and behavior of NTP servers and clients) 4. NTPv4 MIB (provision for management and monitoring of NTP via SNMP) Description of Working Group: The Network Time Protocol (NTP) is widely deployed and used in the Internet. However, the standardization status of this protocol has lagged in the IETF. RFC 1305 (NTP version 3) was published in March 1992 and remains unchanged and at Draft Standard status. RFC 1305 represents the majority of full NTP implementations deployed today. RFC 2030 (SNTP version 4) was published as an Informational RFC in October 1996 as a lightweight version of NTP for deployments not requiring the full functionality of NTP. SNTP now represents the majority of both NTP traffic and NTP implementation issues on the Internet. A good deal of work has been produced in the NTP community updating both NTPv3 and SNTPv4. This work is ongoing and available through the collaborative development effort in the NTP community, but it has not been reflected back into the NTP specifications. The goal of this working group is to document NTPv4 based on the extensive work of the NTP community and to advance the standardization status of NTP. It is an explicit goal of this effort to have NTPv4 interoperate with the deployed base avoiding any backwards-incompatible changes. A number of topics have been raised as potential work items for an update to NTP including support for IPv6, security considerations including authentication, automatic configuration including possible requirements for DHCP, and algorithm improvements. This working group will focus first on delivering NTPv4 and will defer additional development efforts until after the delivery of NTPv4. Support for IPv6 and defining mechanisms for securing NTP transactions is considered part of the core NTPv4 functionality. Potential further modifications and additions to the NTP protocol will be documented for possible further work beyond the initial NTPv4 effort. The working group will initially focus on the following deliverables: 1. NTPv4 Scope and Requirements Document (documenting the scope of the NTPv4 update and identifying issues deferred for future work). 2. NTPv4 Protocol Specification (documenting the protocol on the wire) 3. NTPv4 Architecture and Algorithms Specification (documenting the architecture, mathematical algorithms, and behavior of NTP servers and clients) 4. NTPv4 MIB (provision for management and monitoring of NTP via SNMP) Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2005 Oct 2009 Network Time Protocol Version 4 Protocol And Algorithms Specification Jun 2006 Oct 2009 Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4) Sep 2007 Nov 2009 Network Time Protocol Version 4 Autokey Specification May 2008 Oct 2009 Network Time Protocol (NTP) Server Option for DHCPv6 Open Authentication Protocol (oauth) ------------------------------------ Charter Last Modified: 2009-05-15 Current Status: Active Working Group Chair(s): Blaine Cook Peter Saint-Andre Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Lisa Dusseault Technical Advisor(s): Hannes Tschofenig Mailing Lists: General Discussion:oauth@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/oauth Archive: http://www.ietf.org/mail-archive/web/oauth/current/maillist.html Description of Working Group: 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. For example, a photo-sharing site that supports OAuth would allow its users to use a third-party printing Web site to access their private pictures, without gaining full control of the user account. OAuth consists of: * A mechanism for a user to authorize issuance of credentials which a third party can use to access resources on their behalf. * Mechanism for using the issued credential to authenticate HTTP requests (called "signatures" in current OAuth). The Working Group will produce one or more documents suitable for consideration as Proposed Standard that will: * Improve the terminology used. * Embody good security practice, or document gaps in its capabilities, and propose a path forward for addressing the gap. * Promote interoperability. * Provide guidelines for extensibility. This specifically means that as a starting point for the working group OAuth 1.0 (i.e., draft-hammer-oauth), which is a copy of the original OAuth specification in IETF draft format, is used and the available extension points are going to be utilized. In completing its work to update OAuth 1.0 to become OAuth 1.1, the group will strive to retain backwards compatibility with the OAuth 1.0 specification. However, changes that are not backwards compatible might be accepted if the group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. Furthermore, OAuth 1.0 defines three "signature" methods used to protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA- SHA1. The group will work on new authentication ("signature") methods and will describe the environments where new security requirements justify their usage. Existing signature methods will not be modified but may be dropped as part of the backwards compatible profiling activity. The applicability of existing and new authentication methods to protocols other than HTTP will be investigated. The Working Group should consider: * Implementer experience. * The end-user experience, including internationalization. * Existing uses of OAuth. * Ability to achieve broad implementation. * Ability to address broader use cases than may be contemplated by the original authors. After delivering OAuth 1.1, the Working Group may consider defining additional functions and/or extensions, for example (but not limited to): * Discovery of OAuth configuration, e.g., http://oauth.net/discovery/1.0. * Comprehensive message integrity, e.g., http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/draf ts/1/spec.html. * Recommendations regarding the structure of the token. * Localization, e.g., http://oauth.googlecode.com/svn/spec/ext/language_preferenc e/1.0/drafts/2/spec.html. * Session-oriented tokens, e.g., http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts /1/spec.html. * Alternate token exchange profiles, e.g., draft-dehora- farrell-oauth-accesstoken-creds-00. The work on extensions is within the scope of the working group charter and requires consensus within the group to add new milestones. The Working Group will also define a generally applicable HTTP authentication mechanism (i.e., browser-based "2-leg" scenerio). Description of Working Group: 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. For example, a photo-sharing site that supports OAuth would allow its users to use a third-party printing Web site to access their private pictures, without gaining full control of the user account. OAuth consists of: * A mechanism for a user to authorize issuance of credentials which a third party can use to access resources on their behalf. * Mechanism for using the issued credential to authenticate HTTP requests (called "signatures" in current OAuth). The Working Group will produce one or more documents suitable for consideration as Proposed Standard that will: * Improve the terminology used. * Embody good security practice, or document gaps in its capabilities, and propose a path forward for addressing the gap. * Promote interoperability. * Provide guidelines for extensibility. This specifically means that as a starting point for the working group OAuth 1.0 (i.e., draft-hammer-oauth), which is a copy of the original OAuth specification in IETF draft format, is used and the available extension points are going to be utilized. In completing its work to update OAuth 1.0 to become OAuth 1.1, the group will strive to retain backwards compatibility with the OAuth 1.0 specification. However, changes that are not backwards compatible might be accepted if the group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. Furthermore, OAuth 1.0 defines three "signature" methods used to protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA- SHA1. The group will work on new authentication ("signature") methods and will describe the environments where new security requirements justify their usage. Existing signature methods will not be modified but may be dropped as part of the backwards compatible profiling activity. The applicability of existing and new authentication methods to protocols other than HTTP will be investigated. The Working Group should consider: * Implementer experience. * The end-user experience, including internationalization. * Existing uses of OAuth. * Ability to achieve broad implementation. * Ability to address broader use cases than may be contemplated by the original authors. After delivering OAuth 1.1, the Working Group may consider defining additional functions and/or extensions, for example (but not limited to): * Discovery of OAuth configuration, e.g., http://oauth.net/discovery/1.0. * Comprehensive message integrity, e.g., http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/draf ts/1/spec.html. * Recommendations regarding the structure of the token. * Localization, e.g., http://oauth.googlecode.com/svn/spec/ext/language_preferenc e/1.0/drafts/2/spec.html. * Session-oriented tokens, e.g., http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts /1/spec.html. * Alternate token exchange profiles, e.g., draft-dehora- farrell-oauth-accesstoken-creds-00. The work on extensions is within the scope of the working group charter and requires consensus within the group to add new milestones. The Working Group will also define a generally applicable HTTP authentication mechanism (i.e., browser-based "2-leg" scenerio). Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2009 Jul 2009 The OAuth Protocol: Authentication Jul 2009 Jul 2009 The OAuth Protocol: Web Delegation Operations and Management Area Working Group (opsawg) ----------------------------------------------------- Charter Last Modified: 2009-11-17 Current Status: Active Working Group Chair(s): Scott Bradner Chris Liljenstolpe Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion:opsawg@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/opsawg Archive: http://www.ietf.org/mail-archive/web/opsawg Description of Working Group: The Operations and Management Area receives occasional proposals for the development and publication of RFCs dealing with operational and management topics that are not in scope of an existing working group and do not justify the formation of a new working group. The OPSAWG will serve as the forum for developing such work items in the IETF. The OPSAWG mailing list is an open discussion forum for such work items, when they arise. The working group meets if there are active proposals that require discussion. The working group milestones are updated as needed to reflect the current work items and their associated milestones. All new work items and rechartering proposals will be brought for approval with the IESG. The focus of the work will be on topics that govern the behavior or WGs in the O&M area (e.g., manageability requirements) and on small, highly focused projects that don't merit a WG of their own or belong to WGs that have already concluded (e.g. advancement of documents on the standards track, application statements, extensions of MIB modules). The OPSAWG will undertake only work items that are proved to have at least a reasonable level of interest from the operators and users community and have a committed number of editors and reviewers. It is not within the scope of the OPSAWG to pick up failed WG work or parts of a WG charter items that could not come to convergence on what they were chartered to do. The currently active OPSAWG work items mostly fall under the following topics: (A) Development of a BCP document that will provide guidelines for authors and a reference for reviewers of IETF documents that specify new protocols or protocol extensions about the information about operational and manageability requirements that needs to be covered in these documents (B) Templates and tools for Operations and Management Area Documents (C) Maintenance and small scale extensions of documents that were developed in working groups that have concluded (e.g. MIB modules). Description of Working Group: The Operations and Management Area receives occasional proposals for the development and publication of RFCs dealing with operational and management topics that are not in scope of an existing working group and do not justify the formation of a new working group. The OPSAWG will serve as the forum for developing such work items in the IETF. The OPSAWG mailing list is an open discussion forum for such work items, when they arise. The working group meets if there are active proposals that require discussion. The working group milestones are updated as needed to reflect the current work items and their associated milestones. All new work items and rechartering proposals will be brought for approval with the IESG. The focus of the work will be on topics that govern the behavior or WGs in the O&M area (e.g., manageability requirements) and on small, highly focused projects that don't merit a WG of their own or belong to WGs that have already concluded (e.g. advancement of documents on the standards track, application statements, extensions of MIB modules). The OPSAWG will undertake only work items that are proved to have at least a reasonable level of interest from the operators and users community and have a committed number of editors and reviewers. It is not within the scope of the OPSAWG to pick up failed WG work or parts of a WG charter items that could not come to convergence on what they were chartered to do. The currently active OPSAWG work items mostly fall under the following topics: (A) Development of a BCP document that will provide guidelines for authors and a reference for reviewers of IETF documents that specify new protocols or protocol extensions about the information about operational and manageability requirements that needs to be covered in these documents (B) Templates and tools for Operations and Management Area Documents (C) Maintenance and small scale extensions of documents that were developed in working groups that have concluded (e.g. MIB modules). Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2008 Mar 2009 Expressing SNMP SMI Datatypes in XML Schema Definition Language Sep 2009 Sep 2009 "The OAM Acronym Soup" Operational Security Capabilities for IP Network Infrastructure (opsec) ----------------------------------------------------------------------- Charter Last Modified: 2009-04-20 Current Status: Active Working Group Chair(s): Joe Abley Joel Jaeggli Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Ronald Bonica Mailing Lists: General Discussion:opsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/opsec In Body: In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/opsec/current/maillist.html Description of Working Group: Goals: The OPSEC WG will document best current practices with regard to network security. In particular an effort will be made to clarify the rationale supporting current operational practice, address gaps in currently understood best practices for forwarding, control plane, and management plane security and make clear the liabilities inherent in security practices where they exist. Scope: The scope of the OPSEC WG is intended to include the protection and secure operation of the forwarding, control and management planes. Documentation of best common practices, revision of existing operational security practices documents and proposals for new approaches to operational challenges are in scope. Method: It is expected that the work product of the working group will fall into the category of best current practices documents. Taxonomy or problem statement documents may provide a basis for best current practices documents. Best Current Practices Document For each topic addressed, a document will be produced that attempts to capture current practices related to secure operation. This will be primarily based on operational experience. Each entry will list: * threats addressed, * current practices for addressing the threat, * protocols, tools and technologies extant at the time of writing that are used to address the threat, * the possibility that a solution does not exist within existing tools or technologies. Taxonomy and Problem Statement Documents A document which attempts to describe the scope of particular operational security challenge or problem space without necessarily coming to a conclusion or proposing a solution. Such a document might be a precursor to a best common practices document. While the principal input of the Working Group are operational experience and needs, the output should be directed both to provide guidance to the operators community as well as to Working Groups that develop protocols or the community of protocol developers at large, as well as to the implementers of these protocols. Non-Goals: The Operations security working group is not the place to do new protocols. New protocol work should be addressed in a working group chartered in the appropriate area or as individual submissions. The OPSEC WG may take on documents related to the practices of using such work. Description of Working Group: Goals: The OPSEC WG will document best current practices with regard to network security. In particular an effort will be made to clarify the rationale supporting current operational practice, address gaps in currently understood best practices for forwarding, control plane, and management plane security and make clear the liabilities inherent in security practices where they exist. Scope: The scope of the OPSEC WG is intended to include the protection and secure operation of the forwarding, control and management planes. Documentation of best common practices, revision of existing operational security practices documents and proposals for new approaches to operational challenges are in scope. Method: It is expected that the work product of the working group will fall into the category of best current practices documents. Taxonomy or problem statement documents may provide a basis for best current practices documents. Best Current Practices Document For each topic addressed, a document will be produced that attempts to capture current practices related to secure operation. This will be primarily based on operational experience. Each entry will list: * threats addressed, * current practices for addressing the threat, * protocols, tools and technologies extant at the time of writing that are used to address the threat, * the possibility that a solution does not exist within existing tools or technologies. Taxonomy and Problem Statement Documents A document which attempts to describe the scope of particular operational security challenge or problem space without necessarily coming to a conclusion or proposing a solution. Such a document might be a precursor to a best common practices document. While the principal input of the Working Group are operational experience and needs, the output should be directed both to provide guidance to the operators community as well as to Working Groups that develop protocols or the community of protocol developers at large, as well as to the implementers of these protocols. Non-Goals: The Operations security working group is not the place to do new protocols. New protocol work should be addressed in a working group chartered in the appropriate area or as individual submissions. The OPSEC WG may take on documents related to the practices of using such work. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jan 2005 Nov 2009 Security Best Practices Efforts and Documents Sep 2008 Oct 2009 Recommendations for filtering ICMP messages Oct 2008 Nov 2009 Issues with existing Cryptographic Protection Methods for Routing Protocols Jan 2009 Aug 2009 Security Assessment of the Internet Protocol version 4 Open Shortest Path First IGP (ospf) ----------------------------------- Charter Last Modified: 2009-04-02 Current Status: Active Working Group Chair(s): Acee Lindem Abhay Roy Routing Area Director(s): Ross Callon Adrian Farrel Routing Area Advisor: Ross Callon Mailing Lists: General Discussion:ospf@ietf.org To Subscribe: ospf-request@ietf.org In Body: In Body: With a subject line: subscribe Archive: http://www.ietf.org/mail-archive/web/ospf/current/maillist.html Description of Working Group: The OSPF Working develops and documents extensions and bug fixes to the OSPF protocol, as well as documenting OSPF usage scenarios. The specific protocol work items area listed in the Goals and Milestones section below. Additional work items will require rechartering. Description of Working Group: The OSPF Working develops and documents extensions and bug fixes to the OSPF protocol, as well as documenting OSPF usage scenarios. The specific protocol work items area listed in the Goals and Milestones section below. Additional work items will require rechartering. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Apr 2004 Nov 2009 Support of address families in OSPFv3 Apr 2004 May 2009 Advertising a Router's Local Addresses in OSPF TE Extensions Feb 2008 Jul 2009 Extensions to OSPF to Support Mobile Ad Hoc Networking Feb 2009 Oct 2009 OSPF Transport Instance Extensions Feb 2009 Oct 2009 OSPF Multi-Instance Extensions Peer-to-Peer Session Initiation Protocol (p2psip) ------------------------------------------------- Charter Last Modified: 2009-03-30 Current Status: Active Working Group Chair(s): Brian Rosen David Bryan Real-time Applications and Infrastructure Area Director(s): Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: General Discussion:p2psip@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/p2psip Archive: http://www.ietf.org/mail-archive/web/p2psip Description of Working Group: The Peer-to-Peer (P2P) Session Initiation Protocol working group (P2PSIP WG) is chartered to develop protocols and mechanisms for the use of the Session Initiation Protocol (SIP) in settings where the service of establishing and managing sessions is principally handled by a collection of intelligent endpoints, rather than centralized servers as in SIP as currently deployed. A number of cases where such an architecture is desirable have been documented. The work focuses on collections of nodes called "P2PSIP peers" and "P2PSIP clients". P2PSIP peers manifest a distributed namespace in which overlay users are identified and provides mechanisms for locating users or resources within the P2PSIP overlay. P2PSIP clients differ from P2PSIP peers primarily in that they do not store information in the overlay, but only use it to locate users and resources. P2PSIP clients and peers use the resolution services of the peers as an alternative to the SIP discovery process of RFC 3263. In this way, P2PSIP offers an alternative mechanism for determining the correct destination for SIP requests. The working group's initial charter scope will be to produce protocols to enable this alternate mechanism for RFC 3263 functionality. Session management, messaging, and presence functions are performed using conventional SIP. This group's primary tasks are to produce: 1. An overview document explaining concepts, terminology, rationale, and illustrative use cases for the remaining work. 2. A proposed standard defining a P2PSIP Peer Protocol. This protocol is used between P2PSIP overlay peers, some of which may be behind NATs. This protocol will define how the P2PSIP peers collectively provide for user and resource location in a SIP environment with no or minimal centralized servers. This protocol may or may not be syntactically based on SIP, a decision to be made by the WG. The group will identify and require one base P2P algorithm (likely a particular Distributed Hash Table (DHT) algorithm), while allowing for additional optional algorithms in the future. 3. Optionally, a proposed standard defining a P2PSIP Client Protocol for use by P2PSIP clients, some of which may be behind NATs. This protocol will define how the P2PSIP clients query and/or modify, the resource location information of the overlay. While clearly a logical subset of the P2PSIP Protocol, the WG will determine if the P2PSIP Client Protocol is a syntactic subset of the P2PSIP Peer Protocol, and whether the P2PSIP Client Protocol builds on the SIP protocol. 4. A usage document. This document will address how the protocols defined above, along with existing IETF protocols, can be used to produce systems to locate a P2PSIP peer or client, identify appropriate resources to facilitate communications (for example media relays), and establish communications between the users of these P2PSIP peers or clients, without relying on centralized servers. Additionally, the document will explain how P2PSIP and conventional SIP entities can interoperate. The initial work will assume the existence of some enrollment process that provides a unique user name, credentials, and an initial set of bootstrap nodes if that is required by the protocols. Developing a non-centralized enrollment process is not in scope. The work planned for the P2PSIP working group is distinct from, but requires close participation with other IETF WGs, particularly SIP, SIPPING, SIMPLE, BEHAVE and MMUSIC. The group cannot modify the baseline SIP behavior, define a new version of SIP, or attempt to produce a parallel protocol for session establishment. If the group determines that any capabilities requiring an extension to SIP are needed, the group will seek to define such extensions within the SIP working group using the SIP change process (RFC 3427). Similarly, existing tools developed in the BEHAVE and MMUSIC groups will be used for NAT traversal, with extensions or changes desired to support P2PSIP presented to the BEHAVE or MMUSIC working groups. The working group will assume that NATs and firewalls exist in the Internet, and will ensure that the protocols produced work in their presence as much as possible. Similarly, the WG will avoid making protocol design decisions that would preclude the creation of anonymous communications systems using techniques such as onion routing to conceal the IP addresses of P2PSIP peers. P2P networks pose unique security and privacy problems because an adversarial relationship may exist between nodes. Attackers can mount both integrity attacks on the stored data and denial of service attacks on the system as a whole. The WG will not attempt a solution to these issues for P2P networks in general. In order to simplify this problem, the WG will assume that all participants in the system are issued unique identities and credentials through some mechanism not in the scope of this working group, such as a centralized server, and that the data stored in the network will be authenticated by the storing entity in order to address the integrity issue and to some extent alleviate the DoS issue. Because signaling dialogs may be routed through intermediate P2PSIP peers which may be untrusted by the originating SIP UA, the WG will address the issue of establishing authenticated signaling dialogs through such untrusted relays. P2P systems also have privacy issues because the nodes that store data objects and route requests are unrelated to the clients which want to communicate. In the design of the P2PSIP protocol, the WG will assess these privacy issues and determine to what extent they need to be alleviated. The protocol document will contain a complete description of the privacy properties of P2PSIP. The following topics are excluded from the Working Group's scope: 1. Issues specific to applications other than locating users and resources for SIP-based communications and presence. 2. Solving "research" type questions related to P2PSIP or P2P in general. The WG will instead forward such work to the IRTF P2PRG or other RG as appropriate. Examples include fully distributed schemes for assuring unique user identities and the development of P2P-based replacements for DNS. 3. Locating resources based on something other than URIs. In other words, arbitrary search of attributes is out of scope, but locating resources based on their URIs is in scope. Using URIs need not imply using the DNS or having a record in the DNS for the URI. 4. Multicast and dynamic DNS based approaches as the core lookup mechanism for locating users and resources. Approaches based on these technologies may be reasonable ways to solve similar problems but that is not the focus of this WG. These techniques may be in-scope for locating bootstrap peers/servers or for interoperation with conventional SIP. Description of Working Group: The Peer-to-Peer (P2P) Session Initiation Protocol working group (P2PSIP WG) is chartered to develop protocols and mechanisms for the use of the Session Initiation Protocol (SIP) in settings where the service of establishing and managing sessions is principally handled by a collection of intelligent endpoints, rather than centralized servers as in SIP as currently deployed. A number of cases where such an architecture is desirable have been documented. The work focuses on collections of nodes called "P2PSIP peers" and "P2PSIP clients". P2PSIP peers manifest a distributed namespace in which overlay users are identified and provides mechanisms for locating users or resources within the P2PSIP overlay. P2PSIP clients differ from P2PSIP peers primarily in that they do not store information in the overlay, but only use it to locate users and resources. P2PSIP clients and peers use the resolution services of the peers as an alternative to the SIP discovery process of RFC 3263. In this way, P2PSIP offers an alternative mechanism for determining the correct destination for SIP requests. The working group's initial charter scope will be to produce protocols to enable this alternate mechanism for RFC 3263 functionality. Session management, messaging, and presence functions are performed using conventional SIP. This group's primary tasks are to produce: 1. An overview document explaining concepts, terminology, rationale, and illustrative use cases for the remaining work. 2. A proposed standard defining a P2PSIP Peer Protocol. This protocol is used between P2PSIP overlay peers, some of which may be behind NATs. This protocol will define how the P2PSIP peers collectively provide for user and resource location in a SIP environment with no or minimal centralized servers. This protocol may or may not be syntactically based on SIP, a decision to be made by the WG. The group will identify and require one base P2P algorithm (likely a particular Distributed Hash Table (DHT) algorithm), while allowing for additional optional algorithms in the future. 3. Optionally, a proposed standard defining a P2PSIP Client Protocol for use by P2PSIP clients, some of which may be behind NATs. This protocol will define how the P2PSIP clients query and/or modify, the resource location information of the overlay. While clearly a logical subset of the P2PSIP Protocol, the WG will determine if the P2PSIP Client Protocol is a syntactic subset of the P2PSIP Peer Protocol, and whether the P2PSIP Client Protocol builds on the SIP protocol. 4. A usage document. This document will address how the protocols defined above, along with existing IETF protocols, can be used to produce systems to locate a P2PSIP peer or client, identify appropriate resources to facilitate communications (for example media relays), and establish communications between the users of these P2PSIP peers or clients, without relying on centralized servers. Additionally, the document will explain how P2PSIP and conventional SIP entities can interoperate. The initial work will assume the existence of some enrollment process that provides a unique user name, credentials, and an initial set of bootstrap nodes if that is required by the protocols. Developing a non-centralized enrollment process is not in scope. The work planned for the P2PSIP working group is distinct from, but requires close participation with other IETF WGs, particularly SIP, SIPPING, SIMPLE, BEHAVE and MMUSIC. The group cannot modify the baseline SIP behavior, define a new version of SIP, or attempt to produce a parallel protocol for session establishment. If the group determines that any capabilities requiring an extension to SIP are needed, the group will seek to define such extensions within the SIP working group using the SIP change process (RFC 3427). Similarly, existing tools developed in the BEHAVE and MMUSIC groups will be used for NAT traversal, with extensions or changes desired to support P2PSIP presented to the BEHAVE or MMUSIC working groups. The working group will assume that NATs and firewalls exist in the Internet, and will ensure that the protocols produced work in their presence as much as possible. Similarly, the WG will avoid making protocol design decisions that would preclude the creation of anonymous communications systems using techniques such as onion routing to conceal the IP addresses of P2PSIP peers. P2P networks pose unique security and privacy problems because an adversarial relationship may exist between nodes. Attackers can mount both integrity attacks on the stored data and denial of service attacks on the system as a whole. The WG will not attempt a solution to these issues for P2P networks in general. In order to simplify this problem, the WG will assume that all participants in the system are issued unique identities and credentials through some mechanism not in the scope of this working group, such as a centralized server, and that the data stored in the network will be authenticated by the storing entity in order to address the integrity issue and to some extent alleviate the DoS issue. Because signaling dialogs may be routed through intermediate P2PSIP peers which may be untrusted by the originating SIP UA, the WG will address the issue of establishing authenticated signaling dialogs through such untrusted relays. P2P systems also have privacy issues because the nodes that store data objects and route requests are unrelated to the clients which want to communicate. In the design of the P2PSIP protocol, the WG will assess these privacy issues and determine to what extent they need to be alleviated. The protocol document will contain a complete description of the privacy properties of P2PSIP. The following topics are excluded from the Working Group's scope: 1. Issues specific to applications other than locating users and resources for SIP-based communications and presence. 2. Solving "research" type questions related to P2PSIP or P2P in general. The WG will instead forward such work to the IRTF P2PRG or other RG as appropriate. Examples include fully distributed schemes for assuring unique user identities and the development of P2P-based replacements for DNS. 3. Locating resources based on something other than URIs. In other words, arbitrary search of attributes is out of scope, but locating resources based on their URIs is in scope. Using URIs need not imply using the DNS or having a record in the DNS for the URI. 4. Multicast and dynamic DNS based approaches as the core lookup mechanism for locating users and resources. Approaches based on these technologies may be reasonable ways to solve similar problems but that is not the focus of this WG. These techniques may be in-scope for locating bootstrap peers/servers or for interoperation with conventional SIP. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2008 Oct 2009 A SIP Usage for RELOAD Oct 2008 Nov 2009 REsource LOcation And Discovery (RELOAD) Base Protocol Jan 2009 Jun 2009 P2PSIP Overlay Diagnostics Protocol for carrying Authentication for Network Access (pana) -------------------------------------------------------------- Charter Last Modified: 2008-08-21 Current Status: Active Working Group Chair(s): Basavaraj Patil Alper Yegin Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Technical Advisor(s): Jari Arkko Mailing Lists: General Discussion:pana@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/pana In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/pana/index.html Description of Working Group: In some scenarios, an IP-based device is required to authenticate itself to the network prior to being authorized to use it. This authentication usually requires a protocol that can support various authentication methods, dynamic service provider selection, and roaming clients. In the absence of such an authentication protocol on most of the link-layers, architectures have resorted to filling the gap by using a number of inadequate methods. For example, inserting an additional layer between link-layer and network-layer mostly for client authentication purpose (e.g., PPPoE), overloading another network-layer protocol to achieve this goal (e.g., Mobile IPv4 with Registration- required flag), and even defining application-layer ad-hoc authentication mechanisms (e.g., http redirects with web-based login). In these and other cases, a network-layer authentication protocol may provide a cleaner solution to the authentication problem. The goal of PANA is to define a protocol that allows clients to authenticate themselves to the access network using IP protocols. Such a protocol would allow a client to interact with a site's back-end AAA infrastructure to gain access without needing to understand the particular AAA infrastructure protocols that are in use at the site. It would also allow such interactions to take place without a link-layer specific mechanism. PANA would be applicable to both multi-access and point-to-point links. It would provide support for various authentication methods, dynamic service provider selection, and roaming clients. Mobile IPv4 developed its own protocols for performing PANA-like functions (e.g., MN-FA interaction). Mobile IPv6 does not have the equivalent of a Foreign Agent (FA) that would allow the access/visited network to authenticate the MN before allowing access. The PANA authentication agent (PAA) can perform the authentication function attributed to the FA in Mobile IPv4, in Mobile IPv6 networks. The WG will work with the assumption that a PANA client (PaC) is already configured with an IP address before using PANA. This IP address will provide limited reachability to the PaC until it is authenticated with the PAA. Upon successful authentication, PaC is granted broader network access possibly by either a new IP address assignment, or by enforcement points changing filtering rules for the same IP address. PANA will neither define any new authentication protocol nor define key distribution, key agreement or key derivation protocols. It is believed that PANA will be able to meet its goals if it is able to carry EAP payloads. Note, however, that EAP may need to be extended in order for PANA to meet the need for all of its intended usages. Such extensions are outside the scope of the PANA WG. PANA will develop an IP-based protocol that allows a device to authenticate itself with the network (and to a PAA in particular) in order to be granted network access. The PAA itself may interface with other AAA backend infrastructures for authenticating and authorizing the service being requested by the host, but such interactions are transparent to the PaC. Network access authentication enables the client to be authorized for packet data service. However it is possible that the underlying link itself is insecure, i.e the packets being transmitted between the client (PaC) and the enforcement point (EP) in the network are not protected by any physical or cryptographic means. In such cases, PANA will enable the establishment of an IPsec SA between the PaC and the EP (a router) to enable access control. In networks that have physical security or ciphering as a link-layer feature, no such SA is required. Hence the establishment of the IPsec SA is optional. The WG will deliver a document that explains how such an IPsec SA is established by using IKE after successful PANA authentication. No enhancements to either IKE or IPsec are expected. The PAA does not necessarily act as an enforcement point (EP) to prevent unauthorized access or usage of the network. When a PaC succesfully authenticates itself to the PAA, EP(s) (e.g., access routers) will need to be suitably notified. SNMP will be used by the PAA to deliver the authorization information to one or more EPs when the PAA is separated from EPs. The WG will document the solution based on SNMP for carrying the authorization information between the PAA and the EP. The WG will also propose a solution of how the PaC discovers the IP address of PAA for sending the authentication request. The PANA WG will deliver - A mechanism for the PAC to discover the PAA on the link. - The PANA protocol itself, capable of carrying multiple authentication methods (e.g. using EAP) - A document that describes how SNMP is used to deliver authorization information from the PAA to the EP in the scenarios where the PAA and EP are separated. - A document that explains the establishment of an IPsec SA between the client and a router (EP) subsequent to authentication for securing the data packets. Description of Working Group: In some scenarios, an IP-based device is required to authenticate itself to the network prior to being authorized to use it. This authentication usually requires a protocol that can support various authentication methods, dynamic service provider selection, and roaming clients. In the absence of such an authentication protocol on most of the link-layers, architectures have resorted to filling the gap by using a number of inadequate methods. For example, inserting an additional layer between link-layer and network-layer mostly for client authentication purpose (e.g., PPPoE), overloading another network-layer protocol to achieve this goal (e.g., Mobile IPv4 with Registration- required flag), and even defining application-layer ad-hoc authentication mechanisms (e.g., http redirects with web-based login). In these and other cases, a network-layer authentication protocol may provide a cleaner solution to the authentication problem. The goal of PANA is to define a protocol that allows clients to authenticate themselves to the access network using IP protocols. Such a protocol would allow a client to interact with a site's back-end AAA infrastructure to gain access without needing to understand the particular AAA infrastructure protocols that are in use at the site. It would also allow such interactions to take place without a link-layer specific mechanism. PANA would be applicable to both multi-access and point-to-point links. It would provide support for various authentication methods, dynamic service provider selection, and roaming clients. Mobile IPv4 developed its own protocols for performing PANA-like functions (e.g., MN-FA interaction). Mobile IPv6 does not have the equivalent of a Foreign Agent (FA) that would allow the access/visited network to authenticate the MN before allowing access. The PANA authentication agent (PAA) can perform the authentication function attributed to the FA in Mobile IPv4, in Mobile IPv6 networks. The WG will work with the assumption that a PANA client (PaC) is already configured with an IP address before using PANA. This IP address will provide limited reachability to the PaC until it is authenticated with the PAA. Upon successful authentication, PaC is granted broader network access possibly by either a new IP address assignment, or by enforcement points changing filtering rules for the same IP address. PANA will neither define any new authentication protocol nor define key distribution, key agreement or key derivation protocols. It is believed that PANA will be able to meet its goals if it is able to carry EAP payloads. Note, however, that EAP may need to be extended in order for PANA to meet the need for all of its intended usages. Such extensions are outside the scope of the PANA WG. PANA will develop an IP-based protocol that allows a device to authenticate itself with the network (and to a PAA in particular) in order to be granted network access. The PAA itself may interface with other AAA backend infrastructures for authenticating and authorizing the service being requested by the host, but such interactions are transparent to the PaC. Network access authentication enables the client to be authorized for packet data service. However it is possible that the underlying link itself is insecure, i.e the packets being transmitted between the client (PaC) and the enforcement point (EP) in the network are not protected by any physical or cryptographic means. In such cases, PANA will enable the establishment of an IPsec SA between the PaC and the EP (a router) to enable access control. In networks that have physical security or ciphering as a link-layer feature, no such SA is required. Hence the establishment of the IPsec SA is optional. The WG will deliver a document that explains how such an IPsec SA is established by using IKE after successful PANA authentication. No enhancements to either IKE or IPsec are expected. The PAA does not necessarily act as an enforcement point (EP) to prevent unauthorized access or usage of the network. When a PaC succesfully authenticates itself to the PAA, EP(s) (e.g., access routers) will need to be suitably notified. SNMP will be used by the PAA to deliver the authorization information to one or more EPs when the PAA is separated from EPs. The WG will document the solution based on SNMP for carrying the authorization information between the PAA and the EP. The WG will also propose a solution of how the PaC discovers the IP address of PAA for sending the authentication request. The PANA WG will deliver - A mechanism for the PAC to discover the PAA on the link. - The PANA protocol itself, capable of carrying multiple authentication methods (e.g. using EAP) - A document that describes how SNMP is used to deliver authorization information from the PAA to the EP in the scenarios where the PAA and EP are separated. - A document that explains the establishment of an IPsec SA between the client and a router (EP) subsequent to authentication for securing the data packets. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2003 Jul 2005 PANA Enabling IPsec based Access Control Oct 2005 Oct 2009 Pre-authentication Support for PANA Path Computation Element (pce) ------------------------------ Charter Last Modified: 2009-11-05 Current Status: Active Working Group Chair(s): JP Vasseur Julien Meuric Routing Area Director(s): Ross Callon Adrian Farrel Routing Area Advisor: Adrian Farrel Secretary(ies): Daniel King Mailing Lists: General Discussion:pce@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/pce Archive: http://www.ietf.org/mail-archive/web/pce/ Description of Working Group: The PCE Working Group is chartered to specify a Path Computation Element (PCE) based architecture for the computation of paths for MPLS and GMPLS Point to Point and Point to Multi-point Traffic Engineering LSPs. In this architecture path computation does not occur on the head-end (ingress) LSR, but on some other path computation entity that may physically not be located on the head-end LSR. The PCE WG will work on application of this model within a single Domain or within a small group of domains (where a domain is a layer, IGP area or Autonomous System with limited visibility from the head-end LSR). At this time, applying this model to large groups of domains such as the Internet is not thought to be possible, and the PCE WG will not spend energy on that topic. The WG will specify a protocol for communication between LSRs (termed Path Computation Clients - PCCs) and PCEs, and between cooperating PCEs. This protocol will be capable of representing requests for path computation including a full set of constraints, will be able to return multiple paths, and will include security mechanisms such as authentication and confidentiality. The WG will determine requirements for extensions to existing routing and signaling protocols in support of PCE discovery and signaling of inter-domain paths. Candidate protocols for extensions are RSVP-TE, OSPF-TE, ISIS-TE and BGP. Any necessary extensions will be produced in collaboration with the Working Groups responsible for the protocols. The Working Group will also work on the definition of metrics to evaluate path quality, scalability, responsiveness and robustness of path computation models. Work Items: - Functional specification of MPLS and GMPLS Traffic Engineered LSP path computation models involving Path Computation Element(s). This includes the case of computing the paths of intra and inter-domain TE LSPs. Such path computation includes the generation of primary, protection and recovery paths, as well as computations for (local/global) reoptimization and load balancing. The WG will address the inter-area (single IGP domain) scenario first. WG progress will be evaluated before inter-AS related work is started. - Specification of the PCE-based architecture. - Specification of requirements and protocol extensions related to the policy, and security aspects of PCE-based path computation involving PCEs of multiple administrative entities. - In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP signaling (RSVP-TE) extensions required to support PCE-based path computation models. - Specification of techniques in support of PCE discovery within and across domains. Where such techniques result in the extensions of existing protocols (e.g., OSPF, ISIS or BGP), this work will be done in conjunction with the appropriate WGs. - Specification of a new communication protocol for use between a PCC and a PCE, and between PCEs. A single protocol will be selected from among candidates that include the existing protocols defined in other WGs. - Definition of objective metrics to evaluate various criteria such as the measurement of path quality, response time, robustness and scalability of path computation models. Review of the document "Requirements for path computation element in GMPLS inter-domain networks" produced by the CCAMP WG. Description of Working Group: The PCE Working Group is chartered to specify a Path Computation Element (PCE) based architecture for the computation of paths for MPLS and GMPLS Point to Point and Point to Multi-point Traffic Engineering LSPs. In this architecture path computation does not occur on the head-end (ingress) LSR, but on some other path computation entity that may physically not be located on the head-end LSR. The PCE WG will work on application of this model within a single Domain or within a small group of domains (where a domain is a layer, IGP area or Autonomous System with limited visibility from the head-end LSR). At this time, applying this model to large groups of domains such as the Internet is not thought to be possible, and the PCE WG will not spend energy on that topic. The WG will specify a protocol for communication between LSRs (termed Path Computation Clients - PCCs) and PCEs, and between cooperating PCEs. This protocol will be capable of representing requests for path computation including a full set of constraints, will be able to return multiple paths, and will include security mechanisms such as authentication and confidentiality. The WG will determine requirements for extensions to existing routing and signaling protocols in support of PCE discovery and signaling of inter-domain paths. Candidate protocols for extensions are RSVP-TE, OSPF-TE, ISIS-TE and BGP. Any necessary extensions will be produced in collaboration with the Working Groups responsible for the protocols. The Working Group will also work on the definition of metrics to evaluate path quality, scalability, responsiveness and robustness of path computation models. Work Items: - Functional specification of MPLS and GMPLS Traffic Engineered LSP path computation models involving Path Computation Element(s). This includes the case of computing the paths of intra and inter-domain TE LSPs. Such path computation includes the generation of primary, protection and recovery paths, as well as computations for (local/global) reoptimization and load balancing. The WG will address the inter-area (single IGP domain) scenario first. WG progress will be evaluated before inter-AS related work is started. - Specification of the PCE-based architecture. - Specification of requirements and protocol extensions related to the policy, and security aspects of PCE-based path computation involving PCEs of multiple administrative entities. - In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP signaling (RSVP-TE) extensions required to support PCE-based path computation models. - Specification of techniques in support of PCE discovery within and across domains. Where such techniques result in the extensions of existing protocols (e.g., OSPF, ISIS or BGP), this work will be done in conjunction with the appropriate WGs. - Specification of a new communication protocol for use between a PCC and a PCE, and between PCEs. A single protocol will be selected from among candidates that include the existing protocols defined in other WGs. - Definition of objective metrics to evaluate various criteria such as the measurement of path quality, response time, robustness and scalability of path computation models. Review of the document "Requirements for path computation element in GMPLS inter-domain networks" produced by the CCAMP WG. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Nov 2005 Aug 2009 PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering Dec 2006 Oct 2009 Definitions of Managed Objects for Path Computation Element Discovery Dec 2006 Oct 2009 Definitions of Textual Conventions for Path Computation Element Jan 2007 Jul 2009 Inclusion of Manageability Sections in PCE Working Group Drafts Sep 2007 Jun 2009 A set of monitoring tools for Path Computation Element based Architecture Feb 2008 Sep 2009 Extensions to the Path Computation Element communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering Aug 2008 Oct 2009 PCC-PCE Communication Requirements for Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE) Sep 2008 Oct 2009 Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths Sep 2008 Jul 2009 Document: draft-ietf-pce-gmpls-aps-req-01.txt Sep 2008 Sep 2009 The use of SVEC (Synchronization VECtor) list for Synchronized dependent path computations Mar 2009 Oct 2009 PCC-PCE Communication Requirements for VPNs Jul 2009 Jul 2009 Conveying Vendor-Specific Constraints in the Path Computation Element Protocol Sep 2009 Sep 2009 PCEP Requirements for WSON Routing and Wavelength Assignment Congestion and Pre-Congestion Notification (pcn) ------------------------------------------------ Charter Last Modified: 2009-03-27 Current Status: Active Working Group Chair(s): Scott Bradner Steven Blake Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Lars Eggert Mailing Lists: General Discussion:pcn@ietf.org To Subscribe: pcn-request@ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/pcn/index.html Description of Working Group: The Congestion and Pre-Congestion Notification (PCN) working group develops mechanisms to protect the quality-of-service of established inelastic flows within a DiffServ domain when congestion is imminent or existing. These mechanisms operate at the domain boundary, based on aggregated congestion and pre-congestion information from within the domain. The focus of the WG is on developing standards for the marking behavior of the interior nodes and the encoding and transport of the congestion information. To allow for future extensions to the mechanisms and their application to new deployment scenarios, they are logically separated into several components, namely, encoding and transport along forward path from marker to egress, metering of congestion information at the egress, and transport of congestion information back to the controlling ingress. Reaction mechanisms at the boundary consist of flow admission and flow termination. Although designed to work together, flow admission and flow termination are independent mechanisms, and the use of one does not require or prevent the use of the other. The WG may produce a small number of informational documents that describe how specific quality-of-service policies for a domain can be implemented using these two mechanisms. The PCN WG will specify the following components to protect the quality-of-service of flows within a DiffServ domain: (1) a general architecture for flow admission and termination based on aggregated (pre-)congestion information (2) a specification of conditions under which interior nodes generate (pre-)congestion information (3) encoding and transport of (pre-)congestion information between the interior and domain egress (4) metering of (pre-)congestion information at the domain egress (5) encoding and transport of (pre-)congestion information between the egress and the controlling domain ingress (6) ingress node control mechanisms for flow admission or termination, based on aggregated (pre-)congestion information The WG focuses on the marking behavior and encoding and transport mechanisms needed to realize the overall PCN architecture. Standards- track protocols and mechanisms are only developed where necessary for interoperability. For other components of the architecture, the WG may document examples or provide recommended solutions in informational documents. The architecture document will be comprehensive, and include security, manageability and operational considerations. All PCN mechanisms, including transport and encoding of (pre-congestion) information, are required to cleanly integrate with existing architectures and protocols such as DiffServ and ECN. If the PCN WG requires extensions or modifications to protocols that are products of other WGs, it may motivate their need and describe requirements in informational documents; design of such extensions and modifications will take place in the appropriate WGs. The initial scope of the PCN WG is restricted by the following assumptions: (A) these components are deployed in a single DiffServ domain, where all boundary and interior nodes are PCN-enabled and trust each other for correct PCN marking, encoding, transport and aggregation (B) all flows handled by these mechanisms are inelastic and constrained to a known maximum rate through policing or shaping (C) the number of flows across any potential aggregation bottleneck is sufficiently large for stateless, statistical mechanisms to be effective (D) flows may have different precedence, but the applicability of the PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc.) is out of scope After completion of the initial phase, the PCN WG may re-charter to develop solutions for scenarios where some of these restrictions are not in place. It may also re-charter to consider applying the PCN mechanisms to additional deployment scenarios (operation over concatenated DiffServ domains, PCN-aware application mechanisms, etc.). The WG may also consider to investigate additional response mechanisms that act on (pre-)congestion information. One example could be flow-rate adaptation (rather than flow admission/ termination) during times of congestion. The details of these work items are outside the scope of the initial phase; but the WG may consider their requirements to design components that are sufficiently general to support such extensions in the future. Description of Working Group: The Congestion and Pre-Congestion Notification (PCN) working group develops mechanisms to protect the quality-of-service of established inelastic flows within a DiffServ domain when congestion is imminent or existing. These mechanisms operate at the domain boundary, based on aggregated congestion and pre-congestion information from within the domain. The focus of the WG is on developing standards for the marking behavior of the interior nodes and the encoding and transport of the congestion information. To allow for future extensions to the mechanisms and their application to new deployment scenarios, they are logically separated into several components, namely, encoding and transport along forward path from marker to egress, metering of congestion information at the egress, and transport of congestion information back to the controlling ingress. Reaction mechanisms at the boundary consist of flow admission and flow termination. Although designed to work together, flow admission and flow termination are independent mechanisms, and the use of one does not require or prevent the use of the other. The WG may produce a small number of informational documents that describe how specific quality-of-service policies for a domain can be implemented using these two mechanisms. The PCN WG will specify the following components to protect the quality-of-service of flows within a DiffServ domain: (1) a general architecture for flow admission and termination based on aggregated (pre-)congestion information (2) a specification of conditions under which interior nodes generate (pre-)congestion information (3) encoding and transport of (pre-)congestion information between the interior and domain egress (4) metering of (pre-)congestion information at the domain egress (5) encoding and transport of (pre-)congestion information between the egress and the controlling domain ingress (6) ingress node control mechanisms for flow admission or termination, based on aggregated (pre-)congestion information The WG focuses on the marking behavior and encoding and transport mechanisms needed to realize the overall PCN architecture. Standards- track protocols and mechanisms are only developed where necessary for interoperability. For other components of the architecture, the WG may document examples or provide recommended solutions in informational documents. The architecture document will be comprehensive, and include security, manageability and operational considerations. All PCN mechanisms, including transport and encoding of (pre-congestion) information, are required to cleanly integrate with existing architectures and protocols such as DiffServ and ECN. If the PCN WG requires extensions or modifications to protocols that are products of other WGs, it may motivate their need and describe requirements in informational documents; design of such extensions and modifications will take place in the appropriate WGs. The initial scope of the PCN WG is restricted by the following assumptions: (A) these components are deployed in a single DiffServ domain, where all boundary and interior nodes are PCN-enabled and trust each other for correct PCN marking, encoding, transport and aggregation (B) all flows handled by these mechanisms are inelastic and constrained to a known maximum rate through policing or shaping (C) the number of flows across any potential aggregation bottleneck is sufficiently large for stateless, statistical mechanisms to be effective (D) flows may have different precedence, but the applicability of the PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc.) is out of scope After completion of the initial phase, the PCN WG may re-charter to develop solutions for scenarios where some of these restrictions are not in place. It may also re-charter to consider applying the PCN mechanisms to additional deployment scenarios (operation over concatenated DiffServ domains, PCN-aware application mechanisms, etc.). The WG may also consider to investigate additional response mechanisms that act on (pre-)congestion information. One example could be flow-rate adaptation (rather than flow admission/ termination) during times of congestion. The details of these work items are outside the scope of the initial phase; but the WG may consider their requirements to design components that are sufficiently general to support such extensions in the future. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Sep 2008 Sep 2009 Baseline Encoding and Transport of Pre-Congestion Information Oct 2008 Aug 2009 Metering and marking behaviour of PCN-nodes Jul 2009 Jul 2009 PCN 3-State Encoding Extension in a single DSCP Jul 2009 Jun 2009 PCN Encoding for Packet-Specific Dual Marking (PSDM) Jul 2009 Oct 2009 Pre-Congestion Notification Encoding Comparison Jul 2009 Oct 2009 PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation Jul 2009 Oct 2009 PCN Boundary Node Behaviour for the Single Marking (SM) Mode of Operation Protocol Independent Multicast (pim) ------------------------------------ Charter Last Modified: 2009-04-02 Current Status: Active Working Group Chair(s): Mike McBride Stig Venaas Routing Area Director(s): Ross Callon Adrian Farrel Routing Area Advisor: Adrian Farrel Mailing Lists: General Discussion:pim@ietf.org To Subscribe: http://www1.ietf.org/mailman/listinfo/pim/ Archive: http://www.ietf.org/mail-archive/web/pim/index.html Description of Working Group: The Protocol Independent Multicast (PIM) Working Group has completed the standardization of PIM with RFC 4601. The WG has determined there is additional work to be accomplished and is chartered to standardize extensions to RFC 4601 - Protocol Independent Multicast Version 2 - Sparse Mode. These PIM extensions will involve reliability, resiliency, scalability, management, and security. The PIM WG will consider implications of VPN service on PIM when it's a component of that service or when PIM interfaces with that service at a VPN edge. If L2VPN or L3VPN WGs determine that support for multicast in L2VPNs and/or L3VPNs requires extensions to PIM, then such extensions could be developed within the PIM WG. Additional work on the PIM-BIDIR and BSR drafts may also be necessary by the WG as these drafts progress through Standards Track. The working group will continue to specify the MIB modules required for PIM and its enhancements. The PIM WG will further enhance RFC4601 as an even more scalable, efficient and robust multicast routing protocol, which is capable of supporting thousands of groups, different types of multicast applications, and all major underlying layer-2 subnetwork technologies. We will accomplish these enhancements by submitting drafts, to the IESG, involving reliable pim, pim join attributes and pim authentication. The working group will initiate a new re-chartering effort if it is determined that a Version 3 of PIM is required. Description of Working Group: The Protocol Independent Multicast (PIM) Working Group has completed the standardization of PIM with RFC 4601. The WG has determined there is additional work to be accomplished and is chartered to standardize extensions to RFC 4601 - Protocol Independent Multicast Version 2 - Sparse Mode. These PIM extensions will involve reliability, resiliency, scalability, management, and security. The PIM WG will consider implications of VPN service on PIM when it's a component of that service or when PIM interfaces with that service at a VPN edge. If L2VPN or L3VPN WGs determine that support for multicast in L2VPNs and/or L3VPNs requires extensions to PIM, then such extensions could be developed within the PIM WG. Additional work on the PIM-BIDIR and BSR drafts may also be necessary by the WG as these drafts progress through Standards Track. The working group will continue to specify the MIB modules required for PIM and its enhancements. The PIM WG will further enhance RFC4601 as an even more scalable, efficient and robust multicast routing protocol, which is capable of supporting thousands of groups, different types of multicast applications, and all major underlying layer-2 subnetwork technologies. We will accomplish these enhancements by submitting drafts, to the IESG, involving reliable pim, pim join attributes and pim authentication. The working group will initiate a new re-chartering effort if it is determined that a Version 3 of PIM is required. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2006 Oct 2009 Authentication and Confidentiality in PIM-SM Link-local Messages Jul 2008 Jul 2009 Population Count Extensions to PIM Aug 2008 Oct 2009 A Reliable Transport Mechanism for PIM Oct 2008 Sep 2009 PIM Group-to-RP Mapping Jan 2009 Oct 2009 PIM Multi-Topology ID (MT-ID) Join-Attribute Public-Key Infrastructure (X.509) (pkix) ---------------------------------------- Charter Last Modified: 2009-09-09 Current Status: Active Working Group Chair(s): Stephen Kent Stefan Santesson Security Area Director(s): Tim Polk Pasi Eronen Security Area Advisor: Tim Polk Mailing Lists: General Discussion:pkix@ietf.org To Subscribe: pkix-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/pkix/current/maillist.html Description of Working Group: The PKIX Working Group was established in the fall of 1995 with the goal of developing Internet standards to support X.509-based Public Key Infrastructures (PKIs). Initially PKIX pursued this goal by profiling X.509 standards developed by the CCITT (later the ITU-T). Later, PKIX initiated the development of standards that are not profiles of ITU-T work, but rather are independent initiatives designed to address X.509-based PKI needs in the Internet. Over time this latter category of work has become the major focus of PKIX work, i.e., most PKIX-generated RFCs are no longer profiles of ITU-T X.509 documents. PKIX has produced a number of standards track and informational RFCs. RFC 3280 (Certificate and CRL Profile), and RCF 3281 (Attribute Certificate Profile) are recent examples of standards track RFCs that profile ITU-T documents. RFC 2560 (Online Certificate Status Profile), RFC 3779 (IP Address and AS Number Extensions), and RFC 3161 (Time Stamp Authority) are examples of standards track RFCs that are IETF-initiated. RFC 4055 (RSA) and RFC 3874 (SHA2) are examples of informational RFCs that describe how to use public key and hash algorithms in PKIs. PKIX Work Plan PKIX will continue to track the evolution of ITU-T X.509 documents, and will maintain compatibility between these documents and IETF PKI standards, since the profiling of X.509 standards for use in the Internet remains an important topic for the working group. PKIX does not endorse the use of specific cryptographic algorithms with its protocols. However, PKIX does publish standards track RFCs that describe how to identify algorithms and represent associated parameters in these protocols, and how to use these algorithms with these protocols. We anticipate efforts in this arena will continue to be required over time. PKIX will pursue new work items in the PKI arena if working group members express sufficient interest, and if approved by the cognizant Security Area director. For example, certificate validation under X. 509 and PKIX standards calls for a relying party to use a trust anchor as the start of a certificate path. Neither X.509 nor extant PKIX standards define protocols for the management of trust anchors. Existing mechanisms for managing trust anchors, e.g., in browsers, are limited in functionality and non-standard. There is considerable interest in the PKI community to define a standard model for trust anchor management, and standard protocols to allow remote management. Thus a future work item for PKIX is the definition of such protocols and associated data models. Description of Working Group: The PKIX Working Group was established in the fall of 1995 with the goal of developing Internet standards to support X.509-based Public Key Infrastructures (PKIs). Initially PKIX pursued this goal by profiling X.509 standards developed by the CCITT (later the ITU-T). Later, PKIX initiated the development of standards that are not profiles of ITU-T work, but rather are independent initiatives designed to address X.509-based PKI needs in the Internet. Over time this latter category of work has become the major focus of PKIX work, i.e., most PKIX-generated RFCs are no longer profiles of ITU-T X.509 documents. PKIX has produced a number of standards track and informational RFCs. RFC 3280 (Certificate and CRL Profile), and RCF 3281 (Attribute Certificate Profile) are recent examples of standards track RFCs that profile ITU-T documents. RFC 2560 (Online Certificate Status Profile), RFC 3779 (IP Address and AS Number Extensions), and RFC 3161 (Time Stamp Authority) are examples of standards track RFCs that are IETF-initiated. RFC 4055 (RSA) and RFC 3874 (SHA2) are examples of informational RFCs that describe how to use public key and hash algorithms in PKIs. PKIX Work Plan PKIX will continue to track the evolution of ITU-T X.509 documents, and will maintain compatibility between these documents and IETF PKI standards, since the profiling of X.509 standards for use in the Internet remains an important topic for the working group. PKIX does not endorse the use of specific cryptographic algorithms with its protocols. However, PKIX does publish standards track RFCs that describe how to identify algorithms and represent associated parameters in these protocols, and how to use these algorithms with these protocols. We anticipate efforts in this arena will continue to be required over time. PKIX will pursue new work items in the PKI arena if working group members express sufficient interest, and if approved by the cognizant Security Area director. For example, certificate validation under X. 509 and PKIX standards calls for a relying party to use a trust anchor as the start of a certificate path. Neither X.509 nor extant PKIX standards define protocols for the management of trust anchors. Existing mechanisms for managing trust anchors, e.g., in browsers, are limited in functionality and non-standard. There is considerable interest in the PKI community to define a standard model for trust anchor management, and standard protocols to allow remote management. Thus a future work item for PKIX is the definition of such protocols and associated data models. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jun 2000 Oct 2009 Internet X.509 Public Key Infrastructure -- Transport Protocols for CMP Jun 2006 Oct 2009 Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA Dec 2007 Aug 2009 New ASN.1 Modules for PKIX Jan 2008 Mar 2009 Update for RSAES-OAEP Algorithm Parameters Jun 2008 Sep 2009 Trust Anchor Management Requirements Jul 2008 Nov 2009 PKI Resource Query Protocol (PRQP) Oct 2008 Oct 2009 Trust Anchor Management Protocol (TAMP) Oct 2008 Oct 2009 Trust Anchor Format Oct 2008 Apr 2009 An Internet Attribute Certificate Profile for Authorization Oct 2008 Oct 2009 Clearance Attribute and Authority Clearance Constraints Certificate Extension Mar 2009 Aug 2009 OCSP Algorithm Agility May 2009 Nov 2009 Internet X.509 Public Key Infrastructure - Certificate Image May 2009 Nov 2009 ASN.1 Translation Aug 2009 Oct 2009 The application/pkix-attr-cert Content Type for Attribute Certificates Aug 2009 Oct 2009 ESSCertIDv2 update for RFC 3161 Performance Metrics for Other Layers (pmol) ------------------------------------------- Charter Last Modified: 2008-08-21 Current Status: Active Working Group Chair(s): Al Morton Alan Clark Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion:pmol@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/pmol Archive: http://www.ietf.org/mail-archive/web/pmol/index.html Description of Working Group: The successful implementation and operation of IP based applications often depends on some underlying performance measurement infrastructure that helps service operators or network managers to recognize when performance is unsatisfactory and identify problems affecting service quality. Standardized performance metrics add the desirable features of consistent implementation, interpretation, no comparison. The IETF has two Working Groups dedicated to the development of performance metrics however each has strict limitations in their charters: - The Benchmarking Methodology WG has addressed a range of networking technologies and protocols in their long history (such as IEEE 802.3, ATM, Frame Relay, and Routing Protocols), but the charter strictly limits their Performance characterizations to the laboratory environment. - The IP Performance Metrics WG has the mandate to develop metrics applicable to the performance of Internet data delivery, but it is specifically prohibited from developing metrics that characterize traffic (such as a VoIP stream). The IETF also has current and completed activities related to the reporting of application performance metrics (e.g. RAQMON and RTCP XR) and is also actively involved in the development of reliable transport protocols which would affect the relationship between IP performance and application performance. Thus there is a gap in the currently chartered coverage of IETF WGs: development of performance metrics for IP-based protocols and applications that operate over UDP, TCP, SCTP, DCCP, Forward Error Correction (FEC) and other robust transport protocols, and that can be used to characterize traffic on live networks. The working group will focus on the completion of two RFCs: 1. A PMOL framework and guidelines memo that will describe the necessary elements of performance metrics of protocols and applications transported over IETF-specified protocols (such as the formal definition, purpose, and units of measure) and the various types of metrics that characterize traffic on live networks (such as metrics derived from other metrics, possibly on lower layers). The framework will also address the need to specify the intended audience and the motivation for the performance metrics. There will also be guidelines for a performance metric development process that includes entry criteria for new proposals (how a proposal might be evaluated for possible endorsement by a protocol development working group), and how an successful proposal will be developed. Also, it is recognized that there are applications and protocols that do not need to use this framework and can make use of simpler specific methods for determining performance. 2. A proof-of-concept RFC defining performance metrics for SIP, based on draft-malas-performance-metrics. This memo would serve as an example of the framework and the PMOL development process in the IETF. Discussion of new work proposals is strongly discouraged under the initial charter of the PMOL WG, except to advise a protocol development WG when they are evaluating a new work proposal for related performance metrics. The Working Group will work closely with the RAI and APPS areas, performing early review of the documents with the two areas and inviting their particpation in the WGLC. The PMOL WG will also be guided by a document describing how memos defining performance metrics are intended to advance along the IETF Standards track (draft-bradner-metricstest). PMOL WG will take advantage of expertise and seek to avoid overlap with other standards development organizations, such as ETSI STQ, ITU- T SG 12, ATIS IIF, ATIS PRQC, and others. Description of Working Group: The successful implementation and operation of IP based applications often depends on some underlying performance measurement infrastructure that helps service operators or network managers to recognize when performance is unsatisfactory and identify problems affecting service quality. Standardized performance metrics add the desirable features of consistent implementation, interpretation, no comparison. The IETF has two Working Groups dedicated to the development of performance metrics however each has strict limitations in their charters: - The Benchmarking Methodology WG has addressed a range of networking technologies and protocols in their long history (such as IEEE 802.3, ATM, Frame Relay, and Routing Protocols), but the charter strictly limits their Performance characterizations to the laboratory environment. - The IP Performance Metrics WG has the mandate to develop metrics applicable to the performance of Internet data delivery, but it is specifically prohibited from developing metrics that characterize traffic (such as a VoIP stream). The IETF also has current and completed activities related to the reporting of application performance metrics (e.g. RAQMON and RTCP XR) and is also actively involved in the development of reliable transport protocols which would affect the relationship between IP performance and application performance. Thus there is a gap in the currently chartered coverage of IETF WGs: development of performance metrics for IP-based protocols and applications that operate over UDP, TCP, SCTP, DCCP, Forward Error Correction (FEC) and other robust transport protocols, and that can be used to characterize traffic on live networks. The working group will focus on the completion of two RFCs: 1. A PMOL framework and guidelines memo that will describe the necessary elements of performance metrics of protocols and applications transported over IETF-specified protocols (such as the formal definition, purpose, and units of measure) and the various types of metrics that characterize traffic on live networks (such as metrics derived from other metrics, possibly on lower layers). The framework will also address the need to specify the intended audience and the motivation for the performance metrics. There will also be guidelines for a performance metric development process that includes entry criteria for new proposals (how a proposal might be evaluated for possible endorsement by a protocol development working group), and how an successful proposal will be developed. Also, it is recognized that there are applications and protocols that do not need to use this framework and can make use of simpler specific methods for determining performance. 2. A proof-of-concept RFC defining performance metrics for SIP, based on draft-malas-performance-metrics. This memo would serve as an example of the framework and the PMOL development process in the IETF. Discussion of new work proposals is strongly discouraged under the initial charter of the PMOL WG, except to advise a protocol development WG when they are evaluating a new work proposal for related performance metrics. The Working Group will work closely with the RAI and APPS areas, performing early review of the documents with the two areas and inviting their particpation in the WGLC. The PMOL WG will also be guided by a document describing how memos defining performance metrics are intended to advance along the IETF Standards track (draft-bradner-metricstest). PMOL WG will take advantage of expertise and seek to avoid overlap with other standards development organizations, such as ETSI STQ, ITU- T SG 12, ATIS IIF, ATIS PRQC, and others. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2008 Sep 2009 SIP End-to-End Performance Metrics Jul 2008 Oct 2009 Framework for Performance Metric Development Point-to-Point Protocol Extensions (pppext) ------------------------------------------- Charter Last Modified: 2009-06-09 Current Status: Active Working Group Chair(s): James Carlson Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:pppext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/pppext In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/pppext/index.html Description of Working Group: The Point-to-Point Protocol (PPP, RFC 1661) is a mature protocol with a large number of subprotocols, encapsulations and other extensions. The PPPEXT working group exists to provide a forum for asking clarifications about the existing specifications and to defend against enhancements of questionable value. The group is not expected to create new specifications, and if a need for such work comes up, a recharter is required. The group may, however, advance existing specifications to the next level in the standards track, if a need for that comes up. Similarly, the group may classify existing specifications as Historic where this is appropriate. Description of Working Group: The Point-to-Point Protocol (PPP, RFC 1661) is a mature protocol with a large number of subprotocols, encapsulations and other extensions. The PPPEXT working group exists to provide a forum for asking clarifications about the existing specifications and to defend against enhancements of questionable value. The group is not expected to create new specifications, and if a need for such work comes up, a recharter is required. The group may, however, advance existing specifications to the next level in the standards track, if a need for that comes up. Similarly, the group may classify existing specifications as Historic where this is appropriate. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2009 Oct 2009 PPP TRILL Protocol Control Protocol Pseudowire Emulation Edge to Edge (pwe3) ---------------------------------------- Charter Last Modified: 2009-04-13 Current Status: Active Working Group Chair(s): Stewart Bryant Matthew Bocci Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Technical Advisor(s): David Black Secretary(ies): David Sinicrope Mailing Lists: General Discussion:pwe3@ietf.org To Subscribe: pwe3-request@ietf.org In Body: subscribe your_email_address Archive: http://www.ietf.org/mail-archive/web/pwe3/index.html Description of Working Group: Network transport service providers and their users are seeking to rationalize their networks by migrating their existing services and platforms onto IP or MPLS enabled IP packet switched networks (PSN). This migration requires communications services that can emulate the essential properties of traditional communications links over a PSN. Some service providers wish to use MPLS technology to replace existing transport network infrastructure, relying upon pseudowire technology is an integral component of these network convergence architectures. Pseudowire Emulation Edge to Edge (PWE3) will specify the encapsulation, transport, control, management, interworking and security of services emulated over IETF-specified PSNs. A pseudowire emulates a point-to-point or point-to-multipoint link, and provides a single service which is perceived by its user as an unshared link or circuit of the chosen service. It is not intended that an emulated service will be indistinguishable from the service that is being emulated. The emulation need only be sufficient for the satisfactory operation of the service. Emulation necessarily involves a degree of cost-performance trade-off. In some cases it may be necessary to design more than one emulation mechanism in order to resolve these design conflicts. All emulated service definitions must include an applicability statement describing the faithfulness of the emulation. Switching, multiplexing, modification or other operation on the traditional service, unless required as part of the emulation, is out of the scope of the PWE3 WG. PWE3 will make use of existing IETF-specified mechanisms unless there are technical reasons why the existing mechanisms are insufficient or unnecessary. PWE3 operates "edge to edge" and will not exert control on the underlying PSN, other than to use any existing QoS or path control mechanism to provide the required connectivity between the endpoints of the PW. PWE3 will co-ordinate this with the AVT and TICTOC WGs. Where AVT or TICTOC require extensions to PWs to support time or frequency transfer this work will be undertaken by the PWE3 WG in co-ordination with the these WGs. A PW operating over a shared PSN does not necessarily have the same intrinsic security as a dedicated, purpose built, network. In some cases this is satisfactory, while in other cases it will be necessary to enhance the security of the PW to emulate the intrinsic security of the emulated service. PW specifications MUST include a description of how they are to be operated over a shared PSN with adequate security. PWE3 will work with the MPLS, L2VPN and other relevant WGs for definitions of common solutions for the secure operation of pseudowires. Whilst a service provider may traffic engineer their network in such a way that PW traffic will not cause significant congestion, a PW deployed by an end-user may cause congestion of the underlying PSN. Suitable congestion avoidance mechanisms are therefore needed to protect the Internet from the unconstrained deployment of PWs. Congestion avoidance may be more difficult with P2MP pseudowires than P2P pseudowires. The WG will consider both cases. PWE3 will work closely with the L2VPN WG to ensure a clear demarcation is defined for where PWE3 stops and L2VPN starts, in particular in defining point-multipoint (P2MP) PWs. PWE3 will work with MPLS and L2VPN to enhance the OAM suite for transport applications. PWE3 will coordinate very closely with any WG that is responsible for protocols which PWE3 intends to extend (e.g., the MPLS WG for LDP), as well as foster interaction with WGs that intend to extend PWE3 protocols. The IETF PWE3 WG is the design authority for pseudo-wire over IP/MPLS PSN technology. An entity or individual that wishes to propose extensions or changes to this technology must bring the corresponding proposals to the PWE3 WG that would treat them via a process similar to one described in RFC 4929 for the MPLS/GMPLS change process. WG Objectives: Specify the following PW types: Most of the initial specific PW types have been specified (e.g., Frame Realy, Ethernet, ATM). Investigation into and specification of a "generic PW" type and/or MPLS PW should be undertaken. PWE3 will specify a PW type for the special case where the access service payloads at both ends are known to consist entirely of IP packets. PWE3 will not specify mechanisms by which a PW connects two different access services unless the Network Layer protocol is IP or MPLS. Specify the control and management functions of chartered PW types, to include PW setup, configuration, maintenance and tear-down. The PWE3 WG will do this in its entirety for MPLS PSNs, and the L2TPEXT WG will develop the L2TP specifics for L2TPv3-based PWs. Specify Operations and Management (OAM) mechanisms for all PW types, suitable for operation over both IP/L2TPv3 and MPLS PSNs, and capable of providing the necessary interworking with the OAM mechanisms of the emulated service. Define requirements for and mechanisms to provide interconnection of PWs (to include inter-domain PWs). Define requirements for and mechanisms to provide protection and restoration of PWs. Publish document outlining PW-specific congestion avoidance and response guidelines. Publish document outlining PW-specific security considerations. Specify requirements and mechanisms for P2MP functionality for PWs. This work will be coordinated with the L2VPN and MPLS working groups. Publish requirements and specification for PW to take advantage of multiple PSN paths that exist between PEs. Publish requirements and specification for enhanced OAM. Include extensions to the PWE3 protocols and RFCs necessary to create an MPLS Transport Profile (MPLS-TP). The work on the MPLS TP needs to be coordinated between three primary working groups (MPLS, PWE3, L2VPN and CCAMP) that are chartered to do MPLS TP work. Description of Working Group: Network transport service providers and their users are seeking to rationalize their networks by migrating their existing services and platforms onto IP or MPLS enabled IP packet switched networks (PSN). This migration requires communications services that can emulate the essential properties of traditional communications links over a PSN. Some service providers wish to use MPLS technology to replace existing transport network infrastructure, relying upon pseudowire technology is an integral component of these network convergence architectures. Pseudowire Emulation Edge to Edge (PWE3) will specify the encapsulation, transport, control, management, interworking and security of services emulated over IETF-specified PSNs. A pseudowire emulates a point-to-point or point-to-multipoint link, and provides a single service which is perceived by its user as an unshared link or circuit of the chosen service. It is not intended that an emulated service will be indistinguishable from the service that is being emulated. The emulation need only be sufficient for the satisfactory operation of the service. Emulation necessarily involves a degree of cost-performance trade-off. In some cases it may be necessary to design more than one emulation mechanism in order to resolve these design conflicts. All emulated service definitions must include an applicability statement describing the faithfulness of the emulation. Switching, multiplexing, modification or other operation on the traditional service, unless required as part of the emulation, is out of the scope of the PWE3 WG. PWE3 will make use of existing IETF-specified mechanisms unless there are technical reasons why the existing mechanisms are insufficient or unnecessary. PWE3 operates "edge to edge" and will not exert control on the underlying PSN, other than to use any existing QoS or path control mechanism to provide the required connectivity between the endpoints of the PW. PWE3 will co-ordinate this with the AVT and TICTOC WGs. Where AVT or TICTOC require extensions to PWs to support time or frequency transfer this work will be undertaken by the PWE3 WG in co-ordination with the these WGs. A PW operating over a shared PSN does not necessarily have the same intrinsic security as a dedicated, purpose built, network. In some cases this is satisfactory, while in other cases it will be necessary to enhance the security of the PW to emulate the intrinsic security of the emulated service. PW specifications MUST include a description of how they are to be operated over a shared PSN with adequate security. PWE3 will work with the MPLS, L2VPN and other relevant WGs for definitions of common solutions for the secure operation of pseudowires. Whilst a service provider may traffic engineer their network in such a way that PW traffic will not cause significant congestion, a PW deployed by an end-user may cause congestion of the underlying PSN. Suitable congestion avoidance mechanisms are therefore needed to protect the Internet from the unconstrained deployment of PWs. Congestion avoidance may be more difficult with P2MP pseudowires than P2P pseudowires. The WG will consider both cases. PWE3 will work closely with the L2VPN WG to ensure a clear demarcation is defined for where PWE3 stops and L2VPN starts, in particular in defining point-multipoint (P2MP) PWs. PWE3 will work with MPLS and L2VPN to enhance the OAM suite for transport applications. PWE3 will coordinate very closely with any WG that is responsible for protocols which PWE3 intends to extend (e.g., the MPLS WG for LDP), as well as foster interaction with WGs that intend to extend PWE3 protocols. The IETF PWE3 WG is the design authority for pseudo-wire over IP/MPLS PSN technology. An entity or individual that wishes to propose extensions or changes to this technology must bring the corresponding proposals to the PWE3 WG that would treat them via a process similar to one described in RFC 4929 for the MPLS/GMPLS change process. WG Objectives: Specify the following PW types: Most of the initial specific PW types have been specified (e.g., Frame Realy, Ethernet, ATM). Investigation into and specification of a "generic PW" type and/or MPLS PW should be undertaken. PWE3 will specify a PW type for the special case where the access service payloads at both ends are known to consist entirely of IP packets. PWE3 will not specify mechanisms by which a PW connects two different access services unless the Network Layer protocol is IP or MPLS. Specify the control and management functions of chartered PW types, to include PW setup, configuration, maintenance and tear-down. The PWE3 WG will do this in its entirety for MPLS PSNs, and the L2TPEXT WG will develop the L2TP specifics for L2TPv3-based PWs. Specify Operations and Management (OAM) mechanisms for all PW types, suitable for operation over both IP/L2TPv3 and MPLS PSNs, and capable of providing the necessary interworking with the OAM mechanisms of the emulated service. Define requirements for and mechanisms to provide interconnection of PWs (to include inter-domain PWs). Define requirements for and mechanisms to provide protection and restoration of PWs. Publish document outlining PW-specific congestion avoidance and response guidelines. Publish document outlining PW-specific security considerations. Specify requirements and mechanisms for P2MP functionality for PWs. This work will be coordinated with the L2VPN and MPLS working groups. Publish requirements and specification for PW to take advantage of multiple PSN paths that exist between PEs. Publish requirements and specification for enhanced OAM. Include extensions to the PWE3 protocols and RFCs necessary to create an MPLS Transport Profile (MPLS-TP). The work on the MPLS TP needs to be coordinated between three primary working groups (MPLS, PWE3, L2VPN and CCAMP) that are chartered to do MPLS TP work. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Aug 2002 Jan 2008 SONET/SDH Circuit Emulation Service Over Packet (CEP) Management Information Base (MIB) Using SMIv2 Sep 2004 Jun 2009 Pseudo Wire (PW) OAM Message Mapping Jul 2005 Aug 2009 Segmented Pseudowire Jan 2006 Oct 2009 Dynamic Placement of Multi Segment Pseudo Wires Feb 2007 Jun 2009 Pseudowire Congestion Control Framework May 2007 Jun 2009 Application of Ethernet Pseudowires to MPLS Transport Networks Nov 2007 Jul 2009 Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV) Feb 2008 Oct 2009 Preferential Forwarding Status bit definition Mar 2008 Oct 2009 Pseudowire (PW) Redundancy Sep 2008 Jul 2009 Requirements for Point-to-Multipoint Pseudowire Dec 2008 May 2009 LDP extensions for AII reachability Feb 2009 Oct 2009 MPLS and Ethernet OAM Interworking Jun 2009 Oct 2009 Inter-Chassis Communication Protocol for L2VPN PE Redundancy Jul 2009 Oct 2009 Flow Aware Transport of Pseudowires over an MPLS PSN RADIUS EXTensions (radext) -------------------------- Charter Last Modified: 2009-06-03 Current Status: Active Working Group Chair(s): Bernard Aboba David Nelson Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Technical Advisor(s): Paul Congdon Mailing Lists: General Discussion:radiusext@ops.ietf.org To Subscribe: radiusext-request@ops.ietf.org In Body: In Body: subscribe Archive: https://ops.ietf.org/lists/radiusext Description of Working Group: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to define extensions to the standard attribute space as well as to address cryptographic algorithm agility and use over new transports. In addition, RADEXT will work on RADIUS Design Guidelines and define new attributes for particular applications of authentication, authorization and accounting such as NAS management and local area network (LAN) usage. In order to enable interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: - All documents produced MUST specify means of interoperation with legacy RADIUS and, if possible, be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090 and 5176. Transport profiles should, if possible, be compatible with RFC 3539. - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. Work Items The immediate goals of the RADEXT working group are to address the following issues: - RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes. It will specifically consider how complex data types may be introduced in a robust manner, maintaining backwards compatibility with existing RADIUS RFCs, across all the classes of attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it will review RADIUS data types and associated backwards compatibility issues. - RADIUS Management authorization. This document will define the use of RADIUS for NAS management over IP. -RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes. -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally relied on MD5 for both per-packet integrity and authentication as well as attribute confidentiality. Given the increasingly successful attacks being mounted against MD5, the ability to support alternative algorithms is required. This work item will include documentation of RADIUS crypto-agility requirements, as well as development of one or more Experimental RFCs providing support for negotiation of alternative cryptographic algorithms to protect RADIUS. - IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. - New RADIUS transports. A reliable transport profile for RADIUS will be developed, as well as specifications for Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS. - Documentation of Status-Server usage. A document describing usage of the Status-Server facility will be developed. Description of Working Group: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to define extensions to the standard attribute space as well as to address cryptographic algorithm agility and use over new transports. In addition, RADEXT will work on RADIUS Design Guidelines and define new attributes for particular applications of authentication, authorization and accounting such as NAS management and local area network (LAN) usage. In order to enable interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: - All documents produced MUST specify means of interoperation with legacy RADIUS and, if possible, be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090 and 5176. Transport profiles should, if possible, be compatible with RFC 3539. - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. Work Items The immediate goals of the RADEXT working group are to address the following issues: - RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes. It will specifically consider how complex data types may be introduced in a robust manner, maintaining backwards compatibility with existing RADIUS RFCs, across all the classes of attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it will review RADIUS data types and associated backwards compatibility issues. - RADIUS Management authorization. This document will define the use of RADIUS for NAS management over IP. -RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes. -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally relied on MD5 for both per-packet integrity and authentication as well as attribute confidentiality. Given the increasingly successful attacks being mounted against MD5, the ability to support alternative algorithms is required. This work item will include documentation of RADIUS crypto-agility requirements, as well as development of one or more Experimental RFCs providing support for negotiation of alternative cryptographic algorithms to protect RADIUS. - IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. - New RADIUS transports. A reliable transport profile for RADIUS will be developed, as well as specifications for Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS. - Documentation of Status-Server usage. A document describing usage of the Status-Server facility will be developed. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Sep 2007 Oct 2009 RADIUS Design Guidelines Jun 2008 Jul 2009 TLS encryption for RADIUS over TCP (RadSec) Jun 2008 Oct 2009 Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol Dec 2008 Oct 2009 RADIUS Over TCP Jul 2009 Jul 2009 NAI-based Dynamic Peer Discovery for RADIUS over TLS and DTLS Reliable Multicast Transport (rmt) ---------------------------------- Charter Last Modified: 2008-08-21 Current Status: Active Working Group Chair(s): Lorenzo Vicisano Brian Adamson Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Magnus Westerlund Mailing Lists: General Discussion:rmt@ietf.org To Subscribe: rmt-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/rmt/index.html Description of Working Group: The purpose of this WG is to standardize reliable multicast transport. Initial efforts have focused solely on the standardization of the one-to-many transport of large amounts of data. Due to the large number of applications that fall into this category, and the sometimes orthogonal requirements these applications exhibit, it is believed that a "one size fits all" protocol will be unable to meet the requirements of all applications. In recognition of this observation, this working group will standardize two protocol instantiations, initially as Experimental protocols, and then as warranted, in the standards track, from the following families: 1) A NACK-based protocol. 2) An "Asynchronous Layered Coding protocol that uses Forward Error Correction. The WG will carry out protocol standardization in general by composing a a set of RFCs that specify - building blocks: A set of easily-separable coarse-grained modular components that are common to multiple protocols along with abstract APIs that define a building block's access methods and their arguments. - protocol instantiations: Specifications that define the necessary gluing logic and minimal additional functionality required to realize a working protocol from one or more building blocks. These specifications will also include an abstract API that defines the interface between the protocol implementation and an application. The WG has previously completed work on three documents to assist in the standardization process. RFC2887 describes the design-space in which the one-to-many transport protocols will be developed. RFC3048 explains the concepts of building-blocks and protocol instantiations. RFC3269 provides guidelines to authors of drafts that specify building-blocks and protocol instantiations. The WG will generate and submit for standardization drafts of the following building-blocks for use in the construction of the two protocols: congestion control, negative acknowledgments, forward error correction, and to address the RFC 2357 security requirements. Generic mechanisms for router assist are also considered for an additional building block. Initial work on the framework for router-assist has already been performed, the WG will evaluate whether to complete this task basing on available resource and interest. The WG will also standardize and generate RFCs for the following two protocol instantiations: A NACK-based protocol, and an Asynchronous Layered Coding (ALC) protocol that uses Forward Error Correction. RFC 3450 is the Experimental RFC of the ALC protocol instantiation. If new requirements are identified that cannot be satisfied with the building-blocks and protocol instantiations described above, the Area Directors in consultation with the IESG may add additional building-blocks and protocol instantiations to the working group deliverables. This working group will work closely with the Internet Research Task Force (IRTF) groups on Reliable Multicast (RMRG) and Secure Multicast (SMUG), especially for meeting the congestion control and security requirements mandated by RFC 2357. This working group may work with the Area Directors to recharter to standardize reliable multicast for additional scenarios beyond the one-to-many transport of bulk data once they are sufficiently well understood. Description of Working Group: The purpose of this WG is to standardize reliable multicast transport. Initial efforts have focused solely on the standardization of the one-to-many transport of large amounts of data. Due to the large number of applications that fall into this category, and the sometimes orthogonal requirements these applications exhibit, it is believed that a "one size fits all" protocol will be unable to meet the requirements of all applications. In recognition of this observation, this working group will standardize two protocol instantiations, initially as Experimental protocols, and then as warranted, in the standards track, from the following families: 1) A NACK-based protocol. 2) An "Asynchronous Layered Coding protocol that uses Forward Error Correction. The WG will carry out protocol standardization in general by composing a a set of RFCs that specify - building blocks: A set of easily-separable coarse-grained modular components that are common to multiple protocols along with abstract APIs that define a building block's access methods and their arguments. - protocol instantiations: Specifications that define the necessary gluing logic and minimal additional functionality required to realize a working protocol from one or more building blocks. These specifications will also include an abstract API that defines the interface between the protocol implementation and an application. The WG has previously completed work on three documents to assist in the standardization process. RFC2887 describes the design-space in which the one-to-many transport protocols will be developed. RFC3048 explains the concepts of building-blocks and protocol instantiations. RFC3269 provides guidelines to authors of drafts that specify building-blocks and protocol instantiations. The WG will generate and submit for standardization drafts of the following building-blocks for use in the construction of the two protocols: congestion control, negative acknowledgments, forward error correction, and to address the RFC 2357 security requirements. Generic mechanisms for router assist are also considered for an additional building block. Initial work on the framework for router-assist has already been performed, the WG will evaluate whether to complete this task basing on available resource and interest. The WG will also standardize and generate RFCs for the following two protocol instantiations: A NACK-based protocol, and an Asynchronous Layered Coding (ALC) protocol that uses Forward Error Correction. RFC 3450 is the Experimental RFC of the ALC protocol instantiation. If new requirements are identified that cannot be satisfied with the building-blocks and protocol instantiations described above, the Area Directors in consultation with the IESG may add additional building-blocks and protocol instantiations to the working group deliverables. This working group will work closely with the Internet Research Task Force (IRTF) groups on Reliable Multicast (RMRG) and Secure Multicast (SMUG), especially for meeting the congestion control and security requirements mandated by RFC 2357. This working group may work with the Area Directors to recharter to standardize reliable multicast for additional scenarios beyond the one-to-many transport of bulk data once they are sufficiently well understood. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2005 Nov 2009 Asynchronous Layered Coding (ALC) Protocol Instantiation Oct 2005 Aug 2009 FLUTE - File Delivery over Unidirectional Transport Oct 2005 Sep 2009 NACK-Oriented Reliable Multicast Transport Protocol Jul 2007 Oct 2009 Security and Reliable Multicast Transport Protocols: Discussions and Guidelines Oct 2008 Oct 2009 Simple Authentication Schemes for the ALC and NORM Protocols Robust Header Compression (rohc) -------------------------------- Charter Last Modified: 2007-09-28 Current Status: Active Working Group Chair(s): Carl Knutsson Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Magnus Westerlund Technical Advisor(s): Erik Nordmark Carsten Bormann Mailing Lists: General Discussion:rohc@ietf.org To Subscribe: rohc-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/rohc/index.html Description of Working Group: The Robust Header Compression (ROHC) Working Group was formed to develop new header compression protocols, designed to suit today's and future target link technologies. Most specifically, the ROHC protocols were to take into account typical needs presented by various wireless link technologies, and perform well for cellular links built using technologies such as WCDMA, EDGE, and CDMA-2000. Protocol development has thus focused on coping with issues such as high loss rates and long round trip times. The WG has specified a common compression protocol platform, the ROHC framework, along with a number of compression protocols (profiles). Most focus has been on compression of the Real-time Transport Protocol (RTP) headers, but profiles have also been specified for compression of UDP, ESP, IP-only, UDP-Lite, and TCP headers. The WG has further produced a ROHC link integration specification for PPP, an optimized RTP compression scheme for "0-byte compression", a ROHC MIB, as well as various informational documents related to ROHC header compression and/or header compression in general. In addition to the work on header compression, the ROHC WG has also developed the SigComp (Signaling Compression) protocol for end-to-end compression of text-based signaling protocol messages. The working group maintains connections with other standardization organizations developing cellular technology for IP, such as 3GPP and 3GPP-2, to ensure that its output fulfills their requirements and will be put to good use. The current aims of the working group are: - to carry out a re-work of the ROHC framework and profiles specifications, hereafter referred to as the ROHCv2 project. The purpose of the ROHCv2 project is to generate a separate framework specification, not changing the framework part of the ROHC protocol, as well as a set of revised compression profiles. The most specific goals with the ROHCv2 profiles are to improve tolerance to packet reordering between compressor and decompressor, and to reduce the overall complexity of the protocol. It should be noted that the v2 profiles will thus not be compatible with the original (ROHCv1) profiles, which means less complex ROHC implementations can be realized by not providing support for ROHCv1 (over links not yet supporting ROHC, or by shifting out support for ROHCv1 in the long run). Profile support is agreed through the ROHC channel negotiation, which is part of the ROHC framework and thus not changed by ROHCv2. - to update and correct the original profile specifications through publication of the "Corrections and Clarifications to RFC 3095"- document. - to finalize the ROHC profile work for TCP header compression. - to develop and/or document proper protocol solutions to apply ROHC over IPsec tunnels. - to finalize the "SigComp implementer's guide" and "SigComp for SIP" documents. The longer term goal of the working group is to advance all its specifications to Draft Standard status (with an exception for the original profiles being revised as part of the ROHCv2 activity). Description of Working Group: The Robust Header Compression (ROHC) Working Group was formed to develop new header compression protocols, designed to suit today's and future target link technologies. Most specifically, the ROHC protocols were to take into account typical needs presented by various wireless link technologies, and perform well for cellular links built using technologies such as WCDMA, EDGE, and CDMA-2000. Protocol development has thus focused on coping with issues such as high loss rates and long round trip times. The WG has specified a common compression protocol platform, the ROHC framework, along with a number of compression protocols (profiles). Most focus has been on compression of the Real-time Transport Protocol (RTP) headers, but profiles have also been specified for compression of UDP, ESP, IP-only, UDP-Lite, and TCP headers. The WG has further produced a ROHC link integration specification for PPP, an optimized RTP compression scheme for "0-byte compression", a ROHC MIB, as well as various informational documents related to ROHC header compression and/or header compression in general. In addition to the work on header compression, the ROHC WG has also developed the SigComp (Signaling Compression) protocol for end-to-end compression of text-based signaling protocol messages. The working group maintains connections with other standardization organizations developing cellular technology for IP, such as 3GPP and 3GPP-2, to ensure that its output fulfills their requirements and will be put to good use. The current aims of the working group are: - to carry out a re-work of the ROHC framework and profiles specifications, hereafter referred to as the ROHCv2 project. The purpose of the ROHCv2 project is to generate a separate framework specification, not changing the framework part of the ROHC protocol, as well as a set of revised compression profiles. The most specific goals with the ROHCv2 profiles are to improve tolerance to packet reordering between compressor and decompressor, and to reduce the overall complexity of the protocol. It should be noted that the v2 profiles will thus not be compatible with the original (ROHCv1) profiles, which means less complex ROHC implementations can be realized by not providing support for ROHCv1 (over links not yet supporting ROHC, or by shifting out support for ROHCv1 in the long run). Profile support is agreed through the ROHC channel negotiation, which is part of the ROHC framework and thus not changed by ROHCv2. - to update and correct the original profile specifications through publication of the "Corrections and Clarifications to RFC 3095"- document. - to finalize the ROHC profile work for TCP header compression. - to develop and/or document proper protocol solutions to apply ROHC over IPsec tunnels. - to finalize the "SigComp implementer's guide" and "SigComp for SIP" documents. The longer term goal of the working group is to advance all its specifications to Draft Standard status (with an exception for the original profiles being revised as part of the ROHCv2 activity). Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Nov 2005 Aug 2009 Integration of Robust Header Compression (ROHC) over IPsec Security Associations Sep 2006 Aug 2009 IKEv2 Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec) Aug 2007 Aug 2009 IPsec Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec) Aug 2008 Jul 2009 The RObust Header Compression (ROHC) Framework Routing Over Low power and Lossy networks (roll) ------------------------------------------------ Charter Last Modified: 2009-06-22 Current Status: Active Working Group Chair(s): JP Vasseur David Culler Routing Area Director(s): Ross Callon Adrian Farrel Routing Area Advisor: Adrian Farrel Technical Advisor(s): Rene Struik Mailing Lists: General Discussion:roll@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/roll Archive: http://www.ietf.org/mail-archive/web/roll/ Description of Working Group: Low power and Lossy networks (LLNs) are made up of many embedded devices with limited power, memory, and processing resources. They are interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline Communication) links. LLNs are transitioning to an end-to-end IP-based solution to avoid the problem of non-interoperable networks interconnected by protocol translation gateways and proxies. Generally speaking, LLNs have at least five distinguishing characteristics: - LLNs operate with a hard, very small bound on state. - In most cases, LLN optimize for saving energy. - Typical traffic patterns are not simply unicast flows (e.g. in some cases most if not all traffic can be point to multipoint). - In most cases, LLNs will be employed over link layers with restricted frame-sizes, thus a routing protocol for LLNs should be specifically adapted for such link layers. - LLN routing protocols have to be very careful when trading off efficiency for generality; many LLN nodes do not have resources to waste. These specific properties cause LLNs to have specific routing requirements. Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have been evaluated by the working group and have in their current form been found to not satisfy all of these specific routing requirements. The Working Group is focused on routing issues for LLN. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (HVAC, lighting, access control, fire), connected homes, healthcare, environmental monitoring, urban sensor networks (e.g. Smart Grid), asset tracking. The Working Group focuses on routing solutions for a subset of these: industrial, connected home, building and urban sensor networks for which routing requirements have been specified. These application-specific routing requirement documents will be used for protocol design. The Working Group focuses only on IPv6 routing architectural framework for these application scenarios. The Framework will take into consideration various aspects including high reliability in the presence of time varying loss characteristics and connectivity while permitting low-power operation with very modest memory and CPU pressure in networks potentially comprising a very large number (several thousands) of nodes. The Working Group will pay particular attention to routing security and manageability (e.g., self routing configuration) issues. It will also need to consider the transport characteristic the routing protocol messages will experience. Mechanisms that protect an LLN from congestion collapse or that establish some degree of fairness between concurrent communication sessions are out of scope of the Working Group. It is expected that upper-layer applications utilizing LLNs define appropriate mechanisms. The solution must include unicast and multicast considerations. Work Items: - Specification of routing metrics used in path calculation. This includes static and dynamic link/node attributes required for routing in LLNs. - Provide an architectural framework for routing and path selection at Layer 3 (Routing for LLN Architecture) that addresses such issues as whether LLN routing require a distributed and/or centralized path computation models, whether additional hierarchy is necessary and how it is applied. Manageability will be considered with each approach, along with various trade-offs for maintaining low power operation, including the presence of non-trivial loss and networks with a very large number of nodes. - Produce a routing security framework for routing in LLNs. - Protocol work: The Working Group will consider specific routing requirements from the four application documents collectively, and specify either a new protocol or extend an existing routing protocol in cooperation with the relevant Working Group. If requirements from the four target application areas cannot be met with a single protocol, the WG may choose to specify or extend more than one protocol (this will require a recharter of the WG). - Documentation of applicability statement of ROLL routing protocols. Description of Working Group: Low power and Lossy networks (LLNs) are made up of many embedded devices with limited power, memory, and processing resources. They are interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline Communication) links. LLNs are transitioning to an end-to-end IP-based solution to avoid the problem of non-interoperable networks interconnected by protocol translation gateways and proxies. Generally speaking, LLNs have at least five distinguishing characteristics: - LLNs operate with a hard, very small bound on state. - In most cases, LLN optimize for saving energy. - Typical traffic patterns are not simply unicast flows (e.g. in some cases most if not all traffic can be point to multipoint). - In most cases, LLNs will be employed over link layers with restricted frame-sizes, thus a routing protocol for LLNs should be specifically adapted for such link layers. - LLN routing protocols have to be very careful when trading off efficiency for generality; many LLN nodes do not have resources to waste. These specific properties cause LLNs to have specific routing requirements. Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have been evaluated by the working group and have in their current form been found to not satisfy all of these specific routing requirements. The Working Group is focused on routing issues for LLN. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (HVAC, lighting, access control, fire), connected homes, healthcare, environmental monitoring, urban sensor networks (e.g. Smart Grid), asset tracking. The Working Group focuses on routing solutions for a subset of these: industrial, connected home, building and urban sensor networks for which routing requirements have been specified. These application-specific routing requirement documents will be used for protocol design. The Working Group focuses only on IPv6 routing architectural framework for these application scenarios. The Framework will take into consideration various aspects including high reliability in the presence of time varying loss characteristics and connectivity while permitting low-power operation with very modest memory and CPU pressure in networks potentially comprising a very large number (several thousands) of nodes. The Working Group will pay particular attention to routing security and manageability (e.g., self routing configuration) issues. It will also need to consider the transport characteristic the routing protocol messages will experience. Mechanisms that protect an LLN from congestion collapse or that establish some degree of fairness between concurrent communication sessions are out of scope of the Working Group. It is expected that upper-layer applications utilizing LLNs define appropriate mechanisms. The solution must include unicast and multicast considerations. Work Items: - Specification of routing metrics used in path calculation. This includes static and dynamic link/node attributes required for routing in LLNs. - Provide an architectural framework for routing and path selection at Layer 3 (Routing for LLN Architecture) that addresses such issues as whether LLN routing require a distributed and/or centralized path computation models, whether additional hierarchy is necessary and how it is applied. Manageability will be considered with each approach, along with various trade-offs for maintaining low power operation, including the presence of non-trivial loss and networks with a very large number of nodes. - Produce a routing security framework for routing in LLNs. - Protocol work: The Working Group will consider specific routing requirements from the four application documents collectively, and specify either a new protocol or extend an existing routing protocol in cooperation with the relevant Working Group. If requirements from the four target application areas cannot be met with a single protocol, the WG may choose to specify or extend more than one protocol (this will require a recharter of the WG). - Documentation of applicability statement of ROLL routing protocols. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- May 2008 Sep 2009 Home Automation Routing Requirements in Low Power and Lossy Networks Oct 2008 Oct 2009 Terminology in Low power And Lossy Networks Oct 2008 Sep 2009 Building Automation Routing Requirements in Low Power and Lossy Networks May 2009 Oct 2009 Routing Metrics used for Path Calculation in Low Power and Lossy Networks Aug 2009 Oct 2009 RPL: IPv6 Routing Protocol for Low power and Lossy Networks Routing Area Working Group (rtgwg) ---------------------------------- Charter Last Modified: 2009-10-21 Current Status: Active Working Group Chair(s): Alex Zinin John Scudder Alia Atlas Routing Area Director(s): Ross Callon Adrian Farrel Routing Area Advisor: Ross Callon Mailing Lists: General Discussion:rtgwg@ietf.org To Subscribe: rtgwg-request@ietf.org In Body: subscribe email_address Archive: http://www.ietf.org/mail-archive/web/rtgwg/index.html Description of Working Group: The Routing area receives occasional proposals for the development and publication of RFCs dealing with routing topics, but for which the required work does not rise to the level where a new working group is justified, yet the topic does not fit with an existing working group, and a single BOF would not provide the time to ensure a mature proposal. The rtgwg will serve as the forum for developing these types of proposals. The rtgwg mailing list will be used to discuss the proposals as they arise. The working group will meet if there are one or more active proposals that require discussion. The working group milestones will be updated as needed to reflect the proposals currently being worked on and the target dates for their completion. New milestones will be first reviewed by the IESG. The working group will be on-going as long as the ADs believe it serves a useful purpose. Description of Working Group: The Routing area receives occasional proposals for the development and publication of RFCs dealing with routing topics, but for which the required work does not rise to the level where a new working group is justified, yet the topic does not fit with an existing working group, and a single BOF would not provide the time to ensure a mature proposal. The rtgwg will serve as the forum for developing these types of proposals. The rtgwg mailing list will be used to discuss the proposals as they arise. The working group will meet if there are one or more active proposals that require discussion. The working group milestones will be updated as needed to reflect the proposals currently being worked on and the target dates for their completion. New milestones will be first reviewed by the IESG. The working group will be on-going as long as the ADs believe it serves a useful purpose. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jun 2004 Oct 2009 IP Fast Reroute Framework Dec 2006 Jul 2009 IP Fast Reroute Using Not-via Addresses Dec 2006 Oct 2009 A Framework for Loop-free Convergence Simple Authentication and Security Layer (sasl) ----------------------------------------------- Charter Last Modified: 2009-08-24 Current Status: Active Working Group Chair(s): Kurt Zeilenga Tom Yu Security Area Director(s): Tim Polk Pasi Eronen Security Area Advisor: Pasi Eronen Mailing Lists: General Discussion:sasl@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sasl Archive: http://www.ietf.org/mail-archive/web/sasl/current/maillist.html Description of Working Group: The Simple Authentication and Security Layer [RFC4422] provides key security services to a number of application protocols including BEEP, IMAP, LDAP, POP, and SMTP. The purpose of this working group is to shepherd SASL, including select SASL mechanisms, through the Internet Standards process. This group will work to progress the SASL Technical Specification toward Draft Standard. The group has determined that DIGEST-MD5 [RFC2831] is not suitable for progression on the Standards Track due to interoperability, internationalization, and security concerns. The group will deliver a technical specification for a suitable password-based challenge/ response replacement mechanism for Standard Track consideration. The replacement mechanism is expected to be "better than" DIGEST-MD5 from a number of perspectives including interoperability, internationalization, and security. The replacement mechanism is not expected to (but may) provide a security layer itself, instead relying on security services provided at a lower layer (e.g., TLS) and channel bindings. The WG is expected to strike a consensus-supported balance between the many qualities desired in the replacement. Desired qualities include (but are not limited to) negotiated key hardening iteration count, downgrade attack protection, and mutual authentication. The group intends to consider a number of approaches, including draft-newman-auth-scram and draft-josefsson-password-auth, as input. Additionally, the WG will deliver a document summarizing its DIGEST-MD5 concerns and requesting RFC 2831 be moved to Historic status. This document will be based upon draft-ietf-sasl-digest-to- historic. This group will deliver a revised Technical Specification suitable for publication as Proposed Standard for the GSS-API family of SASL mechanisms. This work will be based upon draft-ietf-sasl-gs2. The group will produce a successor document for the CRAM-MD5 specification, RFC 2195. The outcome can be a Standards Track specification replacing RFC 2195, an Informational document moving RFC 2195 to Historic, or an Informational document that documents existing implementation practice. The following areas are not within the scope of work of this WG: - new features, - SASL Mechanisms not specifically mentioned above, and - SASL "profiles". However, the SASL WG is an acceptable forum for review of SASL-related submissions produced by others as long as such review does not impede progress on the WG objectives listed above. Description of Working Group: The Simple Authentication and Security Layer [RFC4422] provides key security services to a number of application protocols including BEEP, IMAP, LDAP, POP, and SMTP. The purpose of this working group is to shepherd SASL, including select SASL mechanisms, through the Internet Standards process. This group will work to progress the SASL Technical Specification toward Draft Standard. The group has determined that DIGEST-MD5 [RFC2831] is not suitable for progression on the Standards Track due to interoperability, internationalization, and security concerns. The group will deliver a technical specification for a suitable password-based challenge/ response replacement mechanism for Standard Track consideration. The replacement mechanism is expected to be "better than" DIGEST-MD5 from a number of perspectives including interoperability, internationalization, and security. The replacement mechanism is not expected to (but may) provide a security layer itself, instead relying on security services provided at a lower layer (e.g., TLS) and channel bindings. The WG is expected to strike a consensus-supported balance between the many qualities desired in the replacement. Desired qualities include (but are not limited to) negotiated key hardening iteration count, downgrade attack protection, and mutual authentication. The group intends to consider a number of approaches, including draft-newman-auth-scram and draft-josefsson-password-auth, as input. Additionally, the WG will deliver a document summarizing its DIGEST-MD5 concerns and requesting RFC 2831 be moved to Historic status. This document will be based upon draft-ietf-sasl-digest-to- historic. This group will deliver a revised Technical Specification suitable for publication as Proposed Standard for the GSS-API family of SASL mechanisms. This work will be based upon draft-ietf-sasl-gs2. The group will produce a successor document for the CRAM-MD5 specification, RFC 2195. The outcome can be a Standards Track specification replacing RFC 2195, an Informational document moving RFC 2195 to Historic, or an Informational document that documents existing implementation practice. The following areas are not within the scope of work of this WG: - new features, - SASL Mechanisms not specifically mentioned above, and - SASL "profiles". However, the SASL WG is an acceptable forum for review of SASL-related submissions produced by others as long as such review does not impede progress on the WG objectives listed above. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2006 Nov 2009 Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family May 2009 Oct 2009 Salted Challenge Response (SCRAM) SASL and GSS-API Mechanism Source Address Validation Improvements (savi) --------------------------------------------- Charter Last Modified: 2008-11-05 Current Status: Active Working Group Chair(s): Christian Vogt Bill Fenner Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Technical Advisor(s): Jianping Wu Secretary(ies): Jun Bi Mailing Lists: General Discussion:savi@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/savi Archive: http://www.ietf.org/mail-archive/web/savi/current/maillist.html Description of Working Group: While ingress filtering [RFC 2827, BCP 38] provides a way to validate IP source addresses at an aggregated level, there is not yet a standardized mechanism for IP source address validation at a finer granularity. Having a finer granularity would be helpful in a number of situations, including filtering traffic from customer interfaces implemented as ports in a layer 3 aware bridge or a router, general improvements in filtering accuracy in enterprise networks, etc. Depending on the situation, there may be a requirement for blocking spoofed packets or merely logging packets that appear to be spoofed. Partial solutions exist to prevent nodes from spoofing the IP source address of another node in the same IP link (e.g., the "IP source guard"), but are proprietary. The purpose of the proposed "Source Address Validation Improvements" working group is to standardize mechanisms that prevent nodes attached to the same IP link from spoofing each other's IP addresses. The scope of the WG is as follows: - The working group considers only solutions implemented on systems located on the same IP link as a to-be-verified node. The goal of the working group is the LAN environment and solutions running in routers or layer 3 aware Ethernet bridges. - Both IPv4 and IPv6 need to be covered. - The first goal of the working group is on unicast traffic, but using the same mechanisms to police multicast traffic is also within the scope. - All address assignment mechanisms need to be supported, including stateless, stateful, and manual configuration; as well as privacy and cryptographically generated addresses. - Solutions are preferably based on observing user traffic, or on observing or using existing signaling protocols. Examples of protocols that can be useful to observe/use are ARP, Neighbor Discovery, DHCP, and DHCP Prefix Delegation protocols. Observing addresses in IP headers can also be useful. The gathered information is used to determine what IP source addresses in packets are appropriate. Where automatic operation is impossible or would lead to sub-optimal validation results, solutions may require manual configuration. - Interdomain scenarios (across Autonomous Systems) that require information from routing protocols like BGP are out of scope. Nevertheless, solution may observe routing protocol signaling to detect that a device is a router. - Tracking other protocols is not within the scope of the WG. - No changes to hosts are allowed. - The WG is prohibited from creating its own protocols or extensions/modifications of current protocols. These limitations in the scope may be relaxed through later rechartering. For instance, solutions tailored for PPP links and specific environments may be added later, or solutions involving co-operation of the nodes on the link may be developed once the baseline solutions have been completed. However, the WG is already chartered to work also on a solution for Ethernet-based broadband access networks that are used in DSL environments. This work is a specialization of the working group's primary LAN-based solution. In order to reach a result that is widely usable and unlikely to disturb existing network practices, the working group needs to take into account - nodes that use static addresses, - nodes with multiple IP addresses on the same interface, - nodes that use multiple link-layer addresses on the same interface, - nodes that have multiple interfaces to the same link, - attachment of another bridge at a bridge port, - presence of routers, NATs, and other similar devices on the same link, including their distinction from hosts with multiple interfaces or hosts with multiple IP addresses on a single interface, - use of SEcure Neighbor Discovery in some networks, - nodes that move to another port on the same link, and - hosts with anycast addresses. However, should such wide applicability turn out to be impossible, the working group will document the limitations of the solutions in due manner. In particular, it is likely that anycast addressing and nodes that employ multiple interfaces for load balancing at link layer are indistinguishable from an actual spoofing attack. There may also be a difference in the applicability between blocking and merely logging spoofed packets. In any case, the solutions may require to be explicitly turned on for each network or interface where they are applicable. For background information, the working group will also develop a threats analysis document that describes what threats the solutions from the WG protect against. This document also contrasts SAVI to existing solutions. Description of Working Group: While ingress filtering [RFC 2827, BCP 38] provides a way to validate IP source addresses at an aggregated level, there is not yet a standardized mechanism for IP source address validation at a finer granularity. Having a finer granularity would be helpful in a number of situations, including filtering traffic from customer interfaces implemented as ports in a layer 3 aware bridge or a router, general improvements in filtering accuracy in enterprise networks, etc. Depending on the situation, there may be a requirement for blocking spoofed packets or merely logging packets that appear to be spoofed. Partial solutions exist to prevent nodes from spoofing the IP source address of another node in the same IP link (e.g., the "IP source guard"), but are proprietary. The purpose of the proposed "Source Address Validation Improvements" working group is to standardize mechanisms that prevent nodes attached to the same IP link from spoofing each other's IP addresses. The scope of the WG is as follows: - The working group considers only solutions implemented on systems located on the same IP link as a to-be-verified node. The goal of the working group is the LAN environment and solutions running in routers or layer 3 aware Ethernet bridges. - Both IPv4 and IPv6 need to be covered. - The first goal of the working group is on unicast traffic, but using the same mechanisms to police multicast traffic is also within the scope. - All address assignment mechanisms need to be supported, including stateless, stateful, and manual configuration; as well as privacy and cryptographically generated addresses. - Solutions are preferably based on observing user traffic, or on observing or using existing signaling protocols. Examples of protocols that can be useful to observe/use are ARP, Neighbor Discovery, DHCP, and DHCP Prefix Delegation protocols. Observing addresses in IP headers can also be useful. The gathered information is used to determine what IP source addresses in packets are appropriate. Where automatic operation is impossible or would lead to sub-optimal validation results, solutions may require manual configuration. - Interdomain scenarios (across Autonomous Systems) that require information from routing protocols like BGP are out of scope. Nevertheless, solution may observe routing protocol signaling to detect that a device is a router. - Tracking other protocols is not within the scope of the WG. - No changes to hosts are allowed. - The WG is prohibited from creating its own protocols or extensions/modifications of current protocols. These limitations in the scope may be relaxed through later rechartering. For instance, solutions tailored for PPP links and specific environments may be added later, or solutions involving co-operation of the nodes on the link may be developed once the baseline solutions have been completed. However, the WG is already chartered to work also on a solution for Ethernet-based broadband access networks that are used in DSL environments. This work is a specialization of the working group's primary LAN-based solution. In order to reach a result that is widely usable and unlikely to disturb existing network practices, the working group needs to take into account - nodes that use static addresses, - nodes with multiple IP addresses on the same interface, - nodes that use multiple link-layer addresses on the same interface, - nodes that have multiple interfaces to the same link, - attachment of another bridge at a bridge port, - presence of routers, NATs, and other similar devices on the same link, including their distinction from hosts with multiple interfaces or hosts with multiple IP addresses on a single interface, - use of SEcure Neighbor Discovery in some networks, - nodes that move to another port on the same link, and - hosts with anycast addresses. However, should such wide applicability turn out to be impossible, the working group will document the limitations of the solutions in due manner. In particular, it is likely that anycast addressing and nodes that employ multiple interfaces for load balancing at link layer are indistinguishable from an actual spoofing attack. There may also be a difference in the applicability between blocking and merely logging spoofed packets. In any case, the solutions may require to be explicitly turned on for each network or interface where they are applicable. For background information, the working group will also develop a threats analysis document that describes what threats the solutions from the WG protect against. This document also contrasts SAVI to existing solutions. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jan 2009 Jul 2009 SAVI Threat Scope Jan 2009 Oct 2009 FCFS-SAVI: First-Come First-Serve Source-Address Validation for Locally Assigned Addresses Jan 2009 Oct 2009 SEND-based Source-Address Validation Implementation Site Multihoming by IPv6 Intermediation (shim6) ----------------------------------------------- Charter Last Modified: 2009-07-07 Current Status: Active Working Group Chair(s): Kurt Lindqvist Geoff Huston Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Technical Advisor(s): Thomas Narten Mailing Lists: General Discussion:shim6@psg.com To Subscribe: shim6-request@psg.com Archive: http://ops.ietf.org/lists/shim6/ Description of Working Group: Earlier efforts in this working group completed the Shim6 protocol specification, documented in RFCs 5533 through 5535. This protocol is a layer 3 shim for providing locator agility with failover capabilities for IPv6 nodes. Hosts that employ Shim6 use multiple IPv6 address prefixes and setup state with peer hosts. This state can later be used to failover to a different set of locators, should the original locators stop working. The Shim6 approach has a number of advantages, such as enabling small sites to be multihomed without requiring a provider independent IPv6 address prefix for the site. But the approach has also been criticized, e.g., for the operational impacts that the use of multiple prefixes causes. At this time there is no clear view on how well Shim6 works in practice. Implementation and deployment in select networks is needed to determine its true characteristics. The Shim6 working group is chartered to track the implementation and testing or deployment efforts. The group is also expected to shepherd to completion a few remaining informational documents that complement the existing protocol specifications. The specific work items of the group are: o Write an implementation and/or deployment experience report. o Specify socket API extensions. This API enables interactions between applications and the Shim6 layer for advanced locator management, and access to information about failure detection and path exploration. It also enables some applications to turn Shim6 off. o Complete the work on the applicability draft. This draft explains in detail in which types of networks Shim6 is applicable, and what its advantages and disadvantages are. The draft will also explain how firewalls are impacted by the use of Shim6. Finally, the draft will also explain how Shim6 can be used in situations where native IPv6 connectivity is not available, such as using Shim6 over 6to4. The group will also work in co-operation with the 6MAN working group as they continue their efforts in improving IPv6 address selection mechanisms. The group shall not work on extensions to the Shim6 protocol itself at this time. However, new work items can be added through rechartering as others get completed. Description of Working Group: Earlier efforts in this working group completed the Shim6 protocol specification, documented in RFCs 5533 through 5535. This protocol is a layer 3 shim for providing locator agility with failover capabilities for IPv6 nodes. Hosts that employ Shim6 use multiple IPv6 address prefixes and setup state with peer hosts. This state can later be used to failover to a different set of locators, should the original locators stop working. The Shim6 approach has a number of advantages, such as enabling small sites to be multihomed without requiring a provider independent IPv6 address prefix for the site. But the approach has also been criticized, e.g., for the operational impacts that the use of multiple prefixes causes. At this time there is no clear view on how well Shim6 works in practice. Implementation and deployment in select networks is needed to determine its true characteristics. The Shim6 working group is chartered to track the implementation and testing or deployment efforts. The group is also expected to shepherd to completion a few remaining informational documents that complement the existing protocol specifications. The specific work items of the group are: o Write an implementation and/or deployment experience report. o Specify socket API extensions. This API enables interactions between applications and the Shim6 layer for advanced locator management, and access to information about failure detection and path exploration. It also enables some applications to turn Shim6 off. o Complete the work on the applicability draft. This draft explains in detail in which types of networks Shim6 is applicable, and what its advantages and disadvantages are. The draft will also explain how firewalls are impacted by the use of Shim6. Finally, the draft will also explain how Shim6 can be used in situations where native IPv6 connectivity is not available, such as using Shim6 over 6to4. The group will also work in co-operation with the 6MAN working group as they continue their efforts in improving IPv6 address selection mechanisms. The group shall not work on extensions to the Shim6 protocol itself at this time. However, new work items can be added through rechartering as others get completed. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2006 Oct 2009 Socket Application Program Interface (API) for Multihoming Shim Secure Inter-Domain Routing (sidr) ---------------------------------- Charter Last Modified: 2009-04-02 Current Status: Active Working Group Chair(s): Geoff Huston Sandra Murphy Routing Area Director(s): Ross Callon Adrian Farrel Routing Area Advisor: Ross Callon Technical Advisor(s): Steven Bellovin Mailing Lists: General Discussion:sidr@ietf.org To Subscribe: sidr-request@ietf.org In Body: In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/sidr/index.html Description of Working Group: One of the areas of vulnerability for large scale Internet environments lies in the area of inter-domain routing. The basic security questions that can be posed regarding routing information are whether the originating Autonomous System is authorized to advertise an address prefix by the holder of that prefix, whether the originating AS is accurately identified by the originating Autonomous System Number in the advertisement, and the validity of both the address prefix and the Autonomous System Number. A related question concerns the level of trust than can be ascribed to attributes of a route object in terms of their authenticity, including consideration of the AS Path attribute. The Routing Protocol Security Group (RPSEC) has been chartered to document the security requirements for routing systems, and, in particular, to produce a document on BGP security requirements. The scope of work in the SIDR working group is to formulate an extensible architecture for an interdomain routing security framework. This framework must be capable of supporting incremental additions of functional components. The SIDR working group will develop security mechanisms which fulfill those requirements which have been agreed on by the RPSEC working group. In developing these mechanisms, the SIDR working group will take practical deployability into consideration. The scope of work will include describing the use of certification objects for supporting the distribution of authorization and authentication information. Both hierarchic and distributed non- hierarchic trust systems are intended to be supported within this framework. The intended support of both forms of trust models is to allow for the use of this framework for routing security in diverse routing environments that have different underlying trust characteristics. The scope of work is limited to inter-domain router-to-router protocols only, for both unicast and multicast systems. The SIDR working group is charged with the following tasks: - Document an extensible interdomain routing security architecture - Document the use of certification objects within this secure routing architecture - Document specific routing functionality modules within this architecture that are designed to address specific secure routing requirements as they are determined by the RPSEC Working Group Description of Working Group: One of the areas of vulnerability for large scale Internet environments lies in the area of inter-domain routing. The basic security questions that can be posed regarding routing information are whether the originating Autonomous System is authorized to advertise an address prefix by the holder of that prefix, whether the originating AS is accurately identified by the originating Autonomous System Number in the advertisement, and the validity of both the address prefix and the Autonomous System Number. A related question concerns the level of trust than can be ascribed to attributes of a route object in terms of their authenticity, including consideration of the AS Path attribute. The Routing Protocol Security Group (RPSEC) has been chartered to document the security requirements for routing systems, and, in particular, to produce a document on BGP security requirements. The scope of work in the SIDR working group is to formulate an extensible architecture for an interdomain routing security framework. This framework must be capable of supporting incremental additions of functional components. The SIDR working group will develop security mechanisms which fulfill those requirements which have been agreed on by the RPSEC working group. In developing these mechanisms, the SIDR working group will take practical deployability into consideration. The scope of work will include describing the use of certification objects for supporting the distribution of authorization and authentication information. Both hierarchic and distributed non- hierarchic trust systems are intended to be supported within this framework. The intended support of both forms of trust models is to allow for the use of this framework for routing security in diverse routing environments that have different underlying trust characteristics. The scope of work is limited to inter-domain router-to-router protocols only, for both unicast and multicast systems. The SIDR working group is charged with the following tasks: - Document an extensible interdomain routing security architecture - Document the use of certification objects within this secure routing architecture - Document specific routing functionality modules within this architecture that are designed to address specific secure routing requirements as they are determined by the RPSEC Working Group Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jun 2006 Sep 2009 A Profile for X.509 PKIX Resource Certificates Oct 2006 Oct 2009 Certificate Policy (CP) for the Resource PKI (RPKI) Feb 2007 Oct 2009 A Profile for Route Origin Authorizations (ROAs) Feb 2007 Oct 2009 An Infrastructure to Support Secure Internet Routing Jan 2008 Aug 2009 A Protocol for Provisioning Resource Certificates Jan 2008 Aug 2009 Manifests for the Resource Public Key Infrastructure Aug 2008 May 2009 A Profile for Bogon Origin Attestations (BOAs) Aug 2008 Aug 2009 Validation of Route Origination in BGP using the Resource Certificate PKI and ROAs Aug 2008 Aug 2009 A Profile for Resource Certificate Repository Structure Dec 2008 Jul 2009 Securing RPSL Objects with RPKI Signatures Feb 2009 Sep 2009 A Profile for Trust Anchor Material for the Resource Certificate PKI Aug 2009 Aug 2009 A Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure Sieve Mail Filtering Language (sieve) ------------------------------------- Charter Last Modified: 2009-08-21 Current Status: Active Working Group Chair(s): Cyrus Daboo Aaron Stone Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion:sieve@ietf.org To Subscribe: sieve-request@ietf.org In Body: 'subscribe' Archive: http://www.ietf.org/mail-archive/web/sieve/current/maillist.html Description of Working Group: The SIEVE email filtering language is specified in RFC 5228, together with a number of extensions. The SIEVE working group is being re-chartered to: (1) Finish work on existing in-progress Working Group documents: (a) Notify mailto (draft-ietf-sieve-notify-mailto) (c) Mime loops (draft-ietf-sieve-mime-loop) (d) Refuse/reject (draft-ietf-sieve-refuse-reject) (2) Finalize and publish the following SIEVE extensions as proposed standards: (a) iHave (draft-freed-sieve-ihave) (b) Notary (draft-freed-sieve-notary) (c) SIEVE in XML (draft-freed-sieve-in-xml) (d) Notify-sip (draft-melnikov-sieve-notify-sip-message) (e) ManageSIEVE (draft-martin-managesieve) (f) RegEx (draft-ietf-sieve-regex) (g) Meta-data (draft-melnikov-sieve-imapext-metadata) (h) Include/multi-script (draft-daboo-sieve-include) (i) Address data (draft-melnikov-sieve-external-lists) (j) Support for Sieve in IMAP (draft-ietf-lemonade-imap-sieve) Additional drafts may be added to this list, but only via a charter revision. There must also be demonstrable willingness in the SIEVE development community to actually implement a given extension before it can be added to this charter. (3) Work on a specification to describe how EAI/IDN issues should be handled in SIEVE. (4) Work on a "Benefits of SIEVE" guide for client and server vendors that: (a) Describes the SIEVE protocol and its suite of extensions. (b) Explains the benefits of server-side filtering in practical terms. (c) Shows how client-side filtering can be migrated to SIEVE. (5) Produce one or more informational RFCs containing a set of test scripts and test email messages that are to be filtered by the scripts, and the expected results of that filtering. This will serve as the basis of a interoperability test suite to help determine the suitability of moving the base specification and selected extensions to Draft status. Description of Working Group: The SIEVE email filtering language is specified in RFC 5228, together with a number of extensions. The SIEVE working group is being re-chartered to: (1) Finish work on existing in-progress Working Group documents: (a) Notify mailto (draft-ietf-sieve-notify-mailto) (c) Mime loops (draft-ietf-sieve-mime-loop) (d) Refuse/reject (draft-ietf-sieve-refuse-reject) (2) Finalize and publish the following SIEVE extensions as proposed standards: (a) iHave (draft-freed-sieve-ihave) (b) Notary (draft-freed-sieve-notary) (c) SIEVE in XML (draft-freed-sieve-in-xml) (d) Notify-sip (draft-melnikov-sieve-notify-sip-message) (e) ManageSIEVE (draft-martin-managesieve) (f) RegEx (draft-ietf-sieve-regex) (g) Meta-data (draft-melnikov-sieve-imapext-metadata) (h) Include/multi-script (draft-daboo-sieve-include) (i) Address data (draft-melnikov-sieve-external-lists) (j) Support for Sieve in IMAP (draft-ietf-lemonade-imap-sieve) Additional drafts may be added to this list, but only via a charter revision. There must also be demonstrable willingness in the SIEVE development community to actually implement a given extension before it can be added to this charter. (3) Work on a specification to describe how EAI/IDN issues should be handled in SIEVE. (4) Work on a "Benefits of SIEVE" guide for client and server vendors that: (a) Describes the SIEVE protocol and its suite of extensions. (b) Explains the benefits of server-side filtering in practical terms. (c) Shows how client-side filtering can be migrated to SIEVE. (5) Produce one or more informational RFCs containing a set of test scripts and test email messages that are to be filtered by the scripts, and the expected results of that filtering. This will serve as the basis of a interoperability test suite to help determine the suitability of moving the base specification and selected extensions to Draft status. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2007 Oct 2009 Sieve Email Filtering: Sieves and display directives in XML Oct 2008 Jan 2009 A Protocol for Remotely Managing Sieve Scripts Mar 2009 Jul 2009 Sieve Email Filtering: Include Extension Jul 2009 Aug 2009 Sieve Extension: Externally Stored Lists SIP for Instant Messaging and Presence Leveraging Extensions (simple) --------------------------------------------------------------------- Charter Last Modified: 2009-03-30 Current Status: Active Working Group Chair(s): Hisham Khartabil Ben Campbell Real-time Applications and Infrastructure Area Director(s): Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Robert Sparks Technical Advisor(s): Jon Peterson Mailing Lists: General Discussion:simple@ietf.org To Subscribe: simple-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/simple/index.html Description of Working Group: This working group focuses on the application of the Session Initiation Protocol (SIP, RFC 3261) to the suite of services collectively known as instant messaging and presence (IMP). The IETF has committed to producing an interoperable standard for these services compliant to the requirements for IM outlined in RFC 2779 (including the security and privacy requirements there) and in the Common Profile for Instant Messaging (CPIM) specification, developed within the IMPP working group. As the most common services for which SIP is used share quite a bit in common with IMP, the adaptation of SIP to IMP seems a natural choice given the widespread support for (and relative maturity of) the SIP standard. This group has completed the majority of its primary goals and will focus on the remaining tasks documented here and concluding. Any proposed new work will require a recharter. The primary remaining work of this group will be to complete: 1. The MSRP proposed standard mechanism for transporting sessions of messages initiated using the SIP, compliant to the requirments of RFC 2779, CPIM and BCP 41. 2. The XCAP framework for representing and carrying configuration and policy information in SIMPLE systems. 3. A mechanism for representing partial changes (patches) to XML documents and extensions to the SIMPLE publication and notification mechanisms to convey these partial changes. 4. A mechanism for initiating and managing Instant Message group chat. 5. An annotated overview of the SIMPLE protocol definition documents. Any SIP extensions proposed in the course of this development will, after a last call process, be transferred to the SIP WG for consideration as formal SIP extensions. Any mechanisms created for managing Instant Message group chat are intended to provide a bridge to the conferencing protocols that will be defined in XCON. They will be limited in scope to address only simple Instant Message chat with nicknames and will not attempt to address complex conferencing concepts such as sidebars. Their design must anticipate operating in conjunction with the conferencing protocols XCON is working towards. The working group will work within the framework for presence and IM described in RFC 2778. The extensions it defines must also be compliant with the SIP processes for extensions. The group cannot modify baseline SIP behavior or define a new version of SIP for IM and presence. If the group determines that any capabilities requiring an extension to SIP are needed, the group will seek to define such extensions within the SIP working group, and then use them here. Description of Working Group: This working group focuses on the application of the Session Initiation Protocol (SIP, RFC 3261) to the suite of services collectively known as instant messaging and presence (IMP). The IETF has committed to producing an interoperable standard for these services compliant to the requirements for IM outlined in RFC 2779 (including the security and privacy requirements there) and in the Common Profile for Instant Messaging (CPIM) specification, developed within the IMPP working group. As the most common services for which SIP is used share quite a bit in common with IMP, the adaptation of SIP to IMP seems a natural choice given the widespread support for (and relative maturity of) the SIP standard. This group has completed the majority of its primary goals and will focus on the remaining tasks documented here and concluding. Any proposed new work will require a recharter. The primary remaining work of this group will be to complete: 1. The MSRP proposed standard mechanism for transporting sessions of messages initiated using the SIP, compliant to the requirments of RFC 2779, CPIM and BCP 41. 2. The XCAP framework for representing and carrying configuration and policy information in SIMPLE systems. 3. A mechanism for representing partial changes (patches) to XML documents and extensions to the SIMPLE publication and notification mechanisms to convey these partial changes. 4. A mechanism for initiating and managing Instant Message group chat. 5. An annotated overview of the SIMPLE protocol definition documents. Any SIP extensions proposed in the course of this development will, after a last call process, be transferred to the SIP WG for consideration as formal SIP extensions. Any mechanisms created for managing Instant Message group chat are intended to provide a bridge to the conferencing protocols that will be defined in XCON. They will be limited in scope to address only simple Instant Message chat with nicknames and will not attempt to address complex conferencing concepts such as sidebars. Their design must anticipate operating in conjunction with the conferencing protocols XCON is working towards. The working group will work within the framework for presence and IM described in RFC 2778. The extensions it defines must also be compliant with the SIP processes for extensions. The group cannot modify baseline SIP behavior or define a new version of SIP for IM and presence. If the group determines that any capabilities requiring an extension to SIP are needed, the group will seek to define such extensions within the SIP working group, and then use them here. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2005 Jun 2009 An Extensible Markup Language (XML) Document Format for Indicating A Change in XML Configuration Access Protocol (XCAP) Resources Feb 2007 Aug 2009 Presence Interdomain Scaling Analysis for SIP/SIMPLE Jun 2007 Oct 2009 Multi-party Chat Using the Message Session Relay Protocol (MSRP) Feb 2008 Jul 2009 Models for Intra-Domain Presence and Instant Messaging (IM) Bridging Feb 2009 Nov 2009 An Alternative Connection Model for the Message Session Relay Protocol (MSRP) SIP Common Log Format (sipclf) ------------------------------ Charter Last Modified: 2009-09-15 Current Status: Active Working Group Chair(s): Spencer Dawkins Theo Zourzouvillys Real-time Applications and Infrastructure Area Director(s): Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Robert Sparks Technical Advisor(s): David Harrington Mailing Lists: General Discussion:sip-clf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sip-clf Archive: http://www.ietf.org/mail-archive/web/sip-clf/current/maillist.html Description of Working Group: The SIP Common Log Format (SIPCLF) working group is chartered to define a standard logging format for systems processing SIP messages. Well-known web servers such as Apache and web proxies like Squid support event logging using a common log format. The logs produced using these de-facto standard formats are invaluable to system administrators for trouble-shooting a server and tool writers to craft tools that mine the log files to produce reports and trends and to search for a certain message or messages, a transaction or a related set of transactions. Furthermore, these log records can also be used to train anomaly detection systems and feed events into a security event management system. The Session Initiation Protocol does not have a common log format. Diverse elements provide distinct log formats making it complex to produce tools to analyze them. The SIPCLF working group will produce a format suitable for logging from any SIP element. The working group will take into account * the need to search, merge, and summarize the log records from one or more possibly diverse elements. * the need to correlate messages from multiple elements related to a given request (that may fork) or a given dialog. The format will take SIP's extensibility into consideration, providing a way to represent SIP message components that are defined in the future. The format will anticipate being used both for off-line analysis and on-line real-time processing applications. The working group will consider the need for efficient creation of records and the need for efficient processing of the records. The working group will identify the fields to appear in a log record and provide one or more formats for encoding those fields. The working group is not pre-constrained to producing either a bit-field oriented or text-oriented format, and may choose to provide both. If the group chooses to specify both, it must be possible to mechanically translate between the formats without loss of information. Specifying the mechanics of exchanging, transporting, and storing SIP Common Log Format records is explicitly out of scope. However, the working group will document as part of the definition of the log record format: * operational guidance considering log file management addressing size, rollover, aggregation and filtering. * guidance for correlating SIP CLF records with events reported via other log mechanisms such as syslog or SNMP notifications. * security guidance for storage, access, and transporting SIP CLF log records, addressing information privacy The group will generate: - A problem statement enunciating the motivation, and use cases for a SIP Common Log Format. This analysis will identify the required minimal information that must appear in any record. - A specification of the SIP Common Log Format record Description of Working Group: The SIP Common Log Format (SIPCLF) working group is chartered to define a standard logging format for systems processing SIP messages. Well-known web servers such as Apache and web proxies like Squid support event logging using a common log format. The logs produced using these de-facto standard formats are invaluable to system administrators for trouble-shooting a server and tool writers to craft tools that mine the log files to produce reports and trends and to search for a certain message or messages, a transaction or a related set of transactions. Furthermore, these log records can also be used to train anomaly detection systems and feed events into a security event management system. The Session Initiation Protocol does not have a common log format. Diverse elements provide distinct log formats making it complex to produce tools to analyze them. The SIPCLF working group will produce a format suitable for logging from any SIP element. The working group will take into account * the need to search, merge, and summarize the log records from one or more possibly diverse elements. * the need to correlate messages from multiple elements related to a given request (that may fork) or a given dialog. The format will take SIP's extensibility into consideration, providing a way to represent SIP message components that are defined in the future. The format will anticipate being used both for off-line analysis and on-line real-time processing applications. The working group will consider the need for efficient creation of records and the need for efficient processing of the records. The working group will identify the fields to appear in a log record and provide one or more formats for encoding those fields. The working group is not pre-constrained to producing either a bit-field oriented or text-oriented format, and may choose to provide both. If the group chooses to specify both, it must be possible to mechanically translate between the formats without loss of information. Specifying the mechanics of exchanging, transporting, and storing SIP Common Log Format records is explicitly out of scope. However, the working group will document as part of the definition of the log record format: * operational guidance considering log file management addressing size, rollover, aggregation and filtering. * guidance for correlating SIP CLF records with events reported via other log mechanisms such as syslog or SNMP notifications. * security guidance for storage, access, and transporting SIP CLF log records, addressing information privacy The group will generate: - A problem statement enunciating the motivation, and use cases for a SIP Common Log Format. This analysis will identify the required minimal information that must appear in any record. - A specification of the SIP Common Log Format record Internet-Drafts: No Current Internet-Drafts. Session Initiation Protocol Core (sipcore) ------------------------------------------ Charter Last Modified: 2009-09-09 Current Status: Active Working Group Chair(s): Gonzalo Camarillo Adam Roach Real-time Applications and Infrastructure Area Director(s): Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Robert Sparks Secretary(ies): Oscar Novo Mailing Lists: General Discussion:sipcore@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sipcore Archive: http://www.ietf.org/mail-archive/web/sipcore/ Description of Working Group: The Session Initiation Protocol Core (SIPCore) working group is chartered to maintain and continue the development of the core SIP specifications, currently defined as proposed standard RFCs 3261, 3262, 3263, 3264, and 3265. The SIPCore working group will concentrate on specifications that update or replace the core SIP specifications. In this context, "update" means replacing or modifying protocol elements in the above listed RFCs in ways that would affect most or all implementations of those RFCs alone. Extensions to SIP that add new functionality that would not be required of all implementations will be done outside of this WG. The process and requirements for such extensions are documented in RFC 3427bis, "Change Process for the Session Initiation Protocol". Throughout its work, the group will strive to maintain the basic model and architecture defined by SIP. In particular: 1. Services and features are provided end-to-end whenever possible. 2. Reuse of existing Internet protocols and architectures and integrating with other Internet applications is crucial. The primary source of change requirements will be a) interoperability problems that stem from ambiguous, or under-defined specification, and b) requirements from other working groups in the RAI Area. Although in general the WG will not work on extensions to SIP, it may take on some previous work items from the SIP working group to allow for a smooth transition. The adoption of new items requires explicit agreement from the AD or rechartering. Description of Working Group: The Session Initiation Protocol Core (SIPCore) working group is chartered to maintain and continue the development of the core SIP specifications, currently defined as proposed standard RFCs 3261, 3262, 3263, 3264, and 3265. The SIPCore working group will concentrate on specifications that update or replace the core SIP specifications. In this context, "update" means replacing or modifying protocol elements in the above listed RFCs in ways that would affect most or all implementations of those RFCs alone. Extensions to SIP that add new functionality that would not be required of all implementations will be done outside of this WG. The process and requirements for such extensions are documented in RFC 3427bis, "Change Process for the Session Initiation Protocol". Throughout its work, the group will strive to maintain the basic model and architecture defined by SIP. In particular: 1. Services and features are provided end-to-end whenever possible. 2. Reuse of existing Internet protocols and architectures and integrating with other Internet applications is crucial. The primary source of change requirements will be a) interoperability problems that stem from ambiguous, or under-defined specification, and b) requirements from other working groups in the RAI Area. Although in general the WG will not work on extensions to SIP, it may take on some previous work items from the SIP working group to allow for a smooth transition. The adoption of new items requires explicit agreement from the AD or rechartering. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Apr 2009 Sep 2009 Scaling Requirements for Presence in SIP/SIMPLE Apr 2009 Apr 2009 An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification Apr 2009 Apr 2009 Response Code for Indication of Terminated Dialog May 2009 Nov 2009 Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control Jun 2009 Jul 2009 Location Conveyance for the Session Initiation Protocol Jul 2009 Oct 2009 Session Initiation Protocol (SIP) INFO Method and Package Framework Jul 2009 Jul 2009 SIP-Specific Event Notification Sep 2009 Sep 2009 Correct transaction handling for 200 responses to Session Initiation Protocol INVITE requests S/MIME Mail Security (smime) ---------------------------- Charter Last Modified: 2009-09-23 Current Status: Active Working Group Chair(s): Sean Turner Blake Ramsdell Security Area Director(s): Tim Polk Pasi Eronen Security Area Advisor: Tim Polk Mailing Lists: General Discussion:smime@ietf.org To Subscribe: smime-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/smime/current/maillist.html Description of Working Group: The S/MIME Working Group has completed a series of Proposed Standards that comprise the S/MIME version 3.1 specification. As part of the specification update, a new suite of "mandatory to implement" algorithms was be selected. Current efforts update and build upon these base specifications. The Cryptographic Message Syntax (CMS) (RFC 3852) is cryptographic algorithm independent, yet there is always more than one way to use any algorithm. To ensure interoperability, each algorithm should have a specification that describes its use with CMS. Specifications for the use of additional cryptographic algorithms will be developed. CMS, as well as S/MIME version 3 and later, permit the use of previously distributed symmetric key-encryption keys. Specifications for the distribution of symmetric key-encryption keys to multiple message recipients will be developed. Mail List Agents (MLAs) are one use of symmetric key-encryption keys. The specification will be algorithm independent. To aid initial determination of recipient's cryptographic capabilities a specification will be developed allowing S/MIME capabilities to be stored and asserted in X.509 certificates based on the X.509 certificate and CRL profile developed by the PKIX Working Group. The working group will perform necessary interoperability testing to progress the CMS and S/MIME specifications to Draft Standard. The CMS specification depends on the RFC 3280, which was developed by the PKIX working group. This profile must progress to Draft Standard before CMS and the other S/MIME specifications can progress to Draft Standard. Assuming timely progress by the PKIX Working Group, the S/MIME specification can start progressing to Draft Standard in 2005. Description of Working Group: The S/MIME Working Group has completed a series of Proposed Standards that comprise the S/MIME version 3.1 specification. As part of the specification update, a new suite of "mandatory to implement" algorithms was be selected. Current efforts update and build upon these base specifications. The Cryptographic Message Syntax (CMS) (RFC 3852) is cryptographic algorithm independent, yet there is always more than one way to use any algorithm. To ensure interoperability, each algorithm should have a specification that describes its use with CMS. Specifications for the use of additional cryptographic algorithms will be developed. CMS, as well as S/MIME version 3 and later, permit the use of previously distributed symmetric key-encryption keys. Specifications for the distribution of symmetric key-encryption keys to multiple message recipients will be developed. Mail List Agents (MLAs) are one use of symmetric key-encryption keys. The specification will be algorithm independent. To aid initial determination of recipient's cryptographic capabilities a specification will be developed allowing S/MIME capabilities to be stored and asserted in X.509 certificates based on the X.509 certificate and CRL profile developed by the PKIX Working Group. The working group will perform necessary interoperability testing to progress the CMS and S/MIME specifications to Draft Standard. The CMS specification depends on the RFC 3280, which was developed by the PKIX working group. This profile must progress to Draft Standard before CMS and the other S/MIME specifications can progress to Draft Standard. Assuming timely progress by the PKIX Working Group, the S/MIME specification can start progressing to Draft Standard in 2005. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- May 2003 Jul 2009 Use of the RSA-KEM Key Transport Algorithm in CMS Dec 2006 Mar 2008 Multiple Signatures in S/MIME May 2007 Jan 2009 Using SHA2 Algorithms with Cryptographic Message Syntax Nov 2007 May 2009 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling Nov 2007 May 2009 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification Dec 2007 Aug 2009 New ASN.1 Modules for CMS and S/MIME Jun 2008 Jun 2009 Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) Softwires (softwire) -------------------- Charter Last Modified: 2009-04-13 Current Status: Active Working Group Chair(s): Alain Durand David Ward Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Technical Advisor(s): Xing Li Mailing Lists: General Discussion:softwires@ietf.org To Subscribe: softwires-request@ietf.org In Body: With a subject line: subscribe Archive: http://www.ietf.org/mail-archive/web/softwires/current/maillist.html Description of Working Group: The Softwires Working Group is specifying the standardization of discovery, control and encapsulation methods for connecting IPv4 networks across IPv6 networks and IPv6 networks across IPv4 networks in a way that will encourage multiple, inter-operable implementations. For various reasons, native IPv4 and/or IPv6 transport may not be available in all cases, and there is a need to tunnel IPv4 in IPv6 or IPv6 in IPv4 to cross a part of the network which is not IPv4 or IPv6 capable. The Softwire Problem Statement, RFC 4925, identifies two distinct topological scenarios that the WG will provide solutions for, "Hubs and Spokes" and "Mesh." In the former case, hosts or "stub" networks are attached via individual, point-to-point, IPv4 over IPv6 or IPv6 over IPv4 softwires to a centralized Softwire Concentrator. In the latter case (Mesh), network islands of one Address Family (IPv4 or IPv6) are connected over a network of another Address Family via point to multi-point softwires among Address family Border Routers (AFBRs). The focus of this WG is to: Document the softwire encapsulation and control protocol usage for one Address Family (IPv6 or IPv4) over another within the defined problem spaces set out in RFC 4925. Define "Dual-Stack Lite" which uses softwires and IPv4 NAT functions to reduce the amount of Global and RFC 1918 Local IPv4 addressing necessary for a Service Provider with an IPv6-enabled network to continue delivering IPv4 reachability to its customers. The WG will reuse existing technologies as much as possible and only when necessary, create additional protocol building blocks. For generality, all base SOFTWIRE encapsulation mechanisms should support all combinations of IP versions over one other (IPv4 over IPv6, IPv6 over IPv4, IPv4 over IPv4, IPv6 over IPv6). IPv4 to IPv6 translation mechanisms (NAT-PT), new addressing schemes, and block address assignments are out of scope. DHCP options developed in this group will be reviewed jointly with the DHC WG. BGP and other routing and signaling protocols developed in this group will be reviewed jointly with the proper working groups and other workings that may take interest (e.g. IDR, L3VPN, PIM, LDP, SAAG, etc). Description of Working Group: The Softwires Working Group is specifying the standardization of discovery, control and encapsulation methods for connecting IPv4 networks across IPv6 networks and IPv6 networks across IPv4 networks in a way that will encourage multiple, inter-operable implementations. For various reasons, native IPv4 and/or IPv6 transport may not be available in all cases, and there is a need to tunnel IPv4 in IPv6 or IPv6 in IPv4 to cross a part of the network which is not IPv4 or IPv6 capable. The Softwire Problem Statement, RFC 4925, identifies two distinct topological scenarios that the WG will provide solutions for, "Hubs and Spokes" and "Mesh." In the former case, hosts or "stub" networks are attached via individual, point-to-point, IPv4 over IPv6 or IPv6 over IPv4 softwires to a centralized Softwire Concentrator. In the latter case (Mesh), network islands of one Address Family (IPv4 or IPv6) are connected over a network of another Address Family via point to multi-point softwires among Address family Border Routers (AFBRs). The focus of this WG is to: Document the softwire encapsulation and control protocol usage for one Address Family (IPv6 or IPv4) over another within the defined problem spaces set out in RFC 4925. Define "Dual-Stack Lite" which uses softwires and IPv4 NAT functions to reduce the amount of Global and RFC 1918 Local IPv4 addressing necessary for a Service Provider with an IPv6-enabled network to continue delivering IPv4 reachability to its customers. The WG will reuse existing technologies as much as possible and only when necessary, create additional protocol building blocks. For generality, all base SOFTWIRE encapsulation mechanisms should support all combinations of IP versions over one other (IPv4 over IPv6, IPv6 over IPv4, IPv4 over IPv4, IPv6 over IPv6). IPv4 to IPv6 translation mechanisms (NAT-PT), new addressing schemes, and block address assignments are out of scope. DHCP options developed in this group will be reviewed jointly with the DHC WG. BGP and other routing and signaling protocols developed in this group will be reviewed jointly with the proper working groups and other workings that may take interest (e.g. IDR, L3VPN, PIM, LDP, SAAG, etc). Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Mar 2009 Oct 2009 Dual-stack lite broadband deployments post IPv4 exhaustion Aug 2009 Oct 2009 IPv6 via IPv4 Service Provider Networks Speech Services Control (speechsc) ---------------------------------- Charter Last Modified: 2009-03-30 Current Status: Active Working Group Chair(s): David Oran Eric Burger Real-time Applications and Infrastructure Area Director(s): Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: General Discussion:speechsc@ietf.org To Subscribe: speechsc-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/speechsc/index.html Description of Working Group: Many multimedia applications can benefit from having Automated Speech Recognition (ASR), Text to Speech (TTS), and Speaker Verification (SV) processing available as a distributed, network resource. To date, there are a number of proprietary ASR, TTS, and SV API's, as well as two IETF drafts, that address this problem. However, there are serious deficiencies to the existing drafts relating to this problem. In particular, they mix the semantics of existing protocols yet are close enough to other protocols as to be confusing to the implementer. The speechsc Work Group will develop protocols to support distributed media processing of audio streams. The focus of this working group is to develop protocols to support ASR, TTS, and SV. The working group will only focus on the secure distributed control of these servers. The working group will develop an informational RFC detailing the architecture and requirements for distributed speechsc control. In addition, the requirements document will describe the use cases driving these requirements. The working group will then examine existing media-related protocols, especially RTSP, for suitability as a protocol for carriage of speechsc server control. The working group will then propose extensions to existing protocols or the development of new protocols, as appropriate, to meet the requirements specified in the informational RFC. The protocol will assume RTP carriage of media. Assuming session-oriented media transport, the protocol will use SDP to describe the session. The working group will not be investigating distributed speech recognition (DSR), as exemplified by the ETSI Aurora project. The working group will not be recreating functionality available in other protocols, such as SIP or SDP. The working group will offer changes to existing protocols, with the possible exception of RTSP, to the appropriate IETF work group for consideration. This working group will explore modifications to RTSP, if required. It is expected that we will coordinate our work in the IETF with the W3C Mutlimodal Interaction Work Group; the ITU-T Study Group 16 Working Party 3/16 on SG 16 Question 15/16; the 3GPP TSG SA WG1; and the ETSI Aurora STQ. Once the current set of milestones is completed, the speechsc charter may be expanded, with IESG approval, to cover additional uses of the technology, such as the orchestration of multiple ASR/TTS/SV servers, the accommodation of additional types of servers such as simultaneous translation servers, etc. Description of Working Group: Many multimedia applications can benefit from having Automated Speech Recognition (ASR), Text to Speech (TTS), and Speaker Verification (SV) processing available as a distributed, network resource. To date, there are a number of proprietary ASR, TTS, and SV API's, as well as two IETF drafts, that address this problem. However, there are serious deficiencies to the existing drafts relating to this problem. In particular, they mix the semantics of existing protocols yet are close enough to other protocols as to be confusing to the implementer. The speechsc Work Group will develop protocols to support distributed media processing of audio streams. The focus of this working group is to develop protocols to support ASR, TTS, and SV. The working group will only focus on the secure distributed control of these servers. The working group will develop an informational RFC detailing the architecture and requirements for distributed speechsc control. In addition, the requirements document will describe the use cases driving these requirements. The working group will then examine existing media-related protocols, especially RTSP, for suitability as a protocol for carriage of speechsc server control. The working group will then propose extensions to existing protocols or the development of new protocols, as appropriate, to meet the requirements specified in the informational RFC. The protocol will assume RTP carriage of media. Assuming session-oriented media transport, the protocol will use SDP to describe the session. The working group will not be investigating distributed speech recognition (DSR), as exemplified by the ETSI Aurora project. The working group will not be recreating functionality available in other protocols, such as SIP or SDP. The working group will offer changes to existing protocols, with the possible exception of RTSP, to the appropriate IETF work group for consideration. This working group will explore modifications to RTSP, if required. It is expected that we will coordinate our work in the IETF with the W3C Mutlimodal Interaction Work Group; the ITU-T Study Group 16 Working Party 3/16 on SG 16 Question 15/16; the 3GPP TSG SA WG1; and the ETSI Aurora STQ. Once the current set of milestones is completed, the speechsc charter may be expanded, with IESG approval, to cover additional uses of the technology, such as the orchestration of multiple ASR/TTS/SV servers, the accommodation of additional types of servers such as simultaneous translation servers, etc. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Sep 2003 Aug 2009 Media Resource Control Protocol Version 2 (MRCPv2) Session PEERing for Multimedia INTerconnect (speermint) ------------------------------------------------------- Charter Last Modified: 2009-03-30 Current Status: Active Working Group Chair(s): Jason Livingood Daryl Malas Real-time Applications and Infrastructure Area Director(s): Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Cullen Jennings Secretary(ies): Alexander Mayrhofer Mailing Lists: General Discussion:speermint@ietf.org To Subscribe: speermint-request@ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/speermint/index.html Description of Working Group: The term "VoIP Peering" has historically been used to describe inter-provider network interconnect and the delivery of voice calls over interconnection points. While voice calls are the primary motivation for this today, other forms of real-time communications are and will continue to evolve as natural additions to such peering. Therefore, the focus of this working group is best generalized to describe calls as sessions, and to note that that such communications are inherently real-time in nature. SPEERMINT focuses architectures to identify, signal, and route delay-sensitive (real-time) communication sessions. These sessions use the SIP signaling protocol to enable peering between two or more administrative domains over IP networks. Where these domains peer, or meet, the establishment of trust, security, and a resistance to abuse and attack are all important considerations. Note that the term "peering" is used here to refer to the interconnection between application layer entities such as SIP servers, as opposed to interconnection at the IP network layer. However, in order to achieve real-time Session PEERing, both signaling and media flows must be taken into consideration. In addition, the working group recognizes that there will be use cases that require SPEERMINT to focus on the interaction between the application layer and lower network layers, or the dependence of specific application layer use cases on lower layers, so SPEERMINT will have to be prepared to solve these problems as they arise. More specifically, SPEERMINT focuses on real-time session routing architectures and their associated use cases. Deliverables here include the specification of the various types of application flows, such as signaling and media flows, in such networks, and includes both trunking and peer-to-peer flows. In addition, SPEERMINT considers and documents requirements for the feedback of operational conditions (e.g., congestion control) that enables the application of dynamic policy and recognizes that various mechanisms for achieving this should be studied as a potential part of any architecture. In future, as its initial work completes and the requirements become known, SPEERMINT may seek rechartering to consider various mechanism to support applying Quality of Service and/or traffic engineering mechanisms in an architecturally sound way in support of real-time Session PEERing. A charter discussion would consider how to work with with mechanisms developed by other working groups, selecting and integrating those, but as stated, first the initial milestones must be completed. The most focused deliverables of SPEERMINT are best current practices regarding exchange of real-time sessions among VoIP and other real-time application service providers and, in particular, how such calls are routed. SPEERMINT will recognize that some of these providers also control underlying access networks (facilities-based), while others do not (not facilities-based), and this fact may present various additional requirements or use cases for consideration. The working group will develop one or more use case documents to record the varieties of the practices, as well as use this recognition as a guide to maintaining the greatest possible separation of the application layer from lower layers. The SPEERMINT work plan is related to and distinct from the work plans of the ENUM and SIPPING working groups. While the the ENUM Working Group is primarily concerned with the structure and lookup of data for the translation of E.164 numbers into URIs (RFC3761), SPEERMINT is concerned with the use of the resulting URI data, as well as non-ENUM-derived URI data, for use in signaling and routing of real-time sessions. The SIPPING WG produced the original document in this area (RFC 3824). The future work in this area will be produced by SPEERMINT, but RFC 3427, the SIP change process will be followed as needed. Issues that are out of scope for SPEERMINT include: o Interoperability, and NITS/profiling of existing protocols such as SIP, RTP, and SRTP, o SPIT prevention. Note, however, that other working groups may release relevant specifications that become required or are referenced by various SPEERMINT uses cases and BCPs, o Routing of sessions which are not signaled using SIP. In particular, SPEERMINT is constrained to consider only those scenarios in which call routing is signaled using the SIP protocol and addressed by SIP or SIPS URIs. E.164 numbers and other national or private formats may only be used as defined within the SIP protocols, and o H.323 In the goals and milestones, "submit" means to submit the document to the IESG for publication. Description of Working Group: The term "VoIP Peering" has historically been used to describe inter-provider network interconnect and the delivery of voice calls over interconnection points. While voice calls are the primary motivation for this today, other forms of real-time communications are and will continue to evolve as natural additions to such peering. Therefore, the focus of this working group is best generalized to describe calls as sessions, and to note that that such communications are inherently real-time in nature. SPEERMINT focuses architectures to identify, signal, and route delay-sensitive (real-time) communication sessions. These sessions use the SIP signaling protocol to enable peering between two or more administrative domains over IP networks. Where these domains peer, or meet, the establishment of trust, security, and a resistance to abuse and attack are all important considerations. Note that the term "peering" is used here to refer to the interconnection between application layer entities such as SIP servers, as opposed to interconnection at the IP network layer. However, in order to achieve real-time Session PEERing, both signaling and media flows must be taken into consideration. In addition, the working group recognizes that there will be use cases that require SPEERMINT to focus on the interaction between the application layer and lower network layers, or the dependence of specific application layer use cases on lower layers, so SPEERMINT will have to be prepared to solve these problems as they arise. More specifically, SPEERMINT focuses on real-time session routing architectures and their associated use cases. Deliverables here include the specification of the various types of application flows, such as signaling and media flows, in such networks, and includes both trunking and peer-to-peer flows. In addition, SPEERMINT considers and documents requirements for the feedback of operational conditions (e.g., congestion control) that enables the application of dynamic policy and recognizes that various mechanisms for achieving this should be studied as a potential part of any architecture. In future, as its initial work completes and the requirements become known, SPEERMINT may seek rechartering to consider various mechanism to support applying Quality of Service and/or traffic engineering mechanisms in an architecturally sound way in support of real-time Session PEERing. A charter discussion would consider how to work with with mechanisms developed by other working groups, selecting and integrating those, but as stated, first the initial milestones must be completed. The most focused deliverables of SPEERMINT are best current practices regarding exchange of real-time sessions among VoIP and other real-time application service providers and, in particular, how such calls are routed. SPEERMINT will recognize that some of these providers also control underlying access networks (facilities-based), while others do not (not facilities-based), and this fact may present various additional requirements or use cases for consideration. The working group will develop one or more use case documents to record the varieties of the practices, as well as use this recognition as a guide to maintaining the greatest possible separation of the application layer from lower layers. The SPEERMINT work plan is related to and distinct from the work plans of the ENUM and SIPPING working groups. While the the ENUM Working Group is primarily concerned with the structure and lookup of data for the translation of E.164 numbers into URIs (RFC3761), SPEERMINT is concerned with the use of the resulting URI data, as well as non-ENUM-derived URI data, for use in signaling and routing of real-time sessions. The SIPPING WG produced the original document in this area (RFC 3824). The future work in this area will be produced by SPEERMINT, but RFC 3427, the SIP change process will be followed as needed. Issues that are out of scope for SPEERMINT include: o Interoperability, and NITS/profiling of existing protocols such as SIP, RTP, and SRTP, o SPIT prevention. Note, however, that other working groups may release relevant specifications that become required or are referenced by various SPEERMINT uses cases and BCPs, o Routing of sessions which are not signaled using SIP. In particular, SPEERMINT is constrained to consider only those scenarios in which call routing is signaled using the SIP protocol and addressed by SIP or SIPS URIs. E.164 numbers and other national or private formats may only be used as defined within the SIP protocols, and o H.323 In the goals and milestones, "submit" means to submit the document to the IESG for publication. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jun 2006 Oct 2009 SPEERMINT Requirements for SIP-based Session Peering Aug 2006 Nov 2009 SPEERMINT Peering Architecture Sep 2006 Nov 2009 SPEERMINT Routing Architecture Message Flows Oct 2006 Sep 2009 Use of DNS SRV and NAPTR Records for SPEERMINT Mar 2007 Aug 2009 VoIP SIP Peering Use Cases Nov 2008 Jul 2009 SPEERMINT Security Threats and Suggested Countermeasures STORage Maintenance (storm) --------------------------- Charter Last Modified: 2009-10-16 Current Status: Active Working Group Chair(s): David Black Tom Talpey Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Lars Eggert Mailing Lists: General Discussion:storm@ietf.org To Subscribe: storm-request@ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/storm/index.html Description of Working Group: The IETF IPS (IP Storage) and RDDP (Remote Direct Data Placement) working groups have produced a significant number of storage protocols (e.g., iSCSI, iSER and FCIP) for which there is significant usage. The time has come to reflect feedback from implementation and usage into updated RFCs; this work may include: - Implementation-driven revisions and updates to existing protocols (i.e., updated RFCs that match the "running code"). - Interoperability reports as needed for the resulting revised protocols that are appropriate for Draft Standard RFC status. - Minor protocol changes or additions. Backwards compatibility is required. Significant changes to the existing protocol standards are out of scope, including any work on version 2 of any of these protocols. Security for these protocols is based on the functionality specified in RFC 3723 (Securing Block Storage Protocols over IP); the working group does not intend to make major changes or updates to that RFC. Stability is critical to the usage of these protocols, so backwards compatibility with existing implementations will be a requirement imposed on for all protocol changes and additions. Note that this is a requirement for implementation compatibility - if it is the case that all implementations of a protocol have done something different than what the RFC specifies, it is appropriate for a new RFC to document what the "running code" actually does and deprecate the unused original behavior. Initial list of work items: (1) iSCSI: Combine RFCs 3720 (iSCSI), 3980 (NAA names), 4850 (node architecture key) and 5048 (corrections/clarifications) into one draft (3720bis), removing features that are not implemented in practice. This draft should be prepared so that it could become a Draft Standard RFC, but it is up to the Working Group to decide whether to advance it to Draft Standard. (2) iSCSI: Add features to support at least SAM-4 (4th version of the SCSI architecture) in a backwards-compatible fashion, as iSCSI is currently based on SAM-2. This will be a separate draft from the iSCSI update in the previous item. The Working Group may add additional minor useful iSCSI features to this draft, including features from draft versions of SAM-5. The iSCSI MIB (RFC 4544) should be updated to provide SNMP support for new features as appropriate. (3) FCIP: IP Protocol number 133 was allocated to a precursor of the FCIP protocol in 2000, but this allocated number is not used by FCIP. The Working Group will consider whether this allocated number should be returned to IANA for future reallocation. (4) iFCP: The Address Translation mode of iFCP needs to be deprecated (SHOULD NOT implement or use), as there are significant technical problems with its specification, and moreover, only the Address Transparent mode of iFCP is in use. This will be done via a short draft that updates RFC 4172, and not via a complete rewrite of RFC 4172. A combined draft is expected that encompasses items (3) and (4); this draft should also update the iFCP MIB (RFC 4369) to deprecate support for iFCP Address Translation mode. (5) RDDP MPA: Good support for MPI applications requires a small update to the startup functionality to allow either end of the connection to initiate. In addition, a couple of minor changes to RDDP connection setup are needed based on implementation experience. (6) iSER: Experience with Infiniband implementations suggest a few minor updates to reflect what has been done in practice. The Working Group is expected to maintain good working relationships with INCITS Technical Committee T10 (SCSI standards) and INCITS Technical Committee T11 (Fibre Channel standards) via overlaps in membership as opposed to appointment of formal liaisons. The liaison process (including IAB appointment of a liaison or liaisons) remains available for use if needed. Recent changes in INCITS rules have removed public access to some T10 and T11 standards documents that are expected to be needed for the WG's program of work. Arrangements have been made with T10 and T11 for IETF participants to obtain copies of specific standards their personal use in IETF work as needed; contact the WG chair(s) for details. Description of Working Group: The IETF IPS (IP Storage) and RDDP (Remote Direct Data Placement) working groups have produced a significant number of storage protocols (e.g., iSCSI, iSER and FCIP) for which there is significant usage. The time has come to reflect feedback from implementation and usage into updated RFCs; this work may include: - Implementation-driven revisions and updates to existing protocols (i.e., updated RFCs that match the "running code"). - Interoperability reports as needed for the resulting revised protocols that are appropriate for Draft Standard RFC status. - Minor protocol changes or additions. Backwards compatibility is required. Significant changes to the existing protocol standards are out of scope, including any work on version 2 of any of these protocols. Security for these protocols is based on the functionality specified in RFC 3723 (Securing Block Storage Protocols over IP); the working group does not intend to make major changes or updates to that RFC. Stability is critical to the usage of these protocols, so backwards compatibility with existing implementations will be a requirement imposed on for all protocol changes and additions. Note that this is a requirement for implementation compatibility - if it is the case that all implementations of a protocol have done something different than what the RFC specifies, it is appropriate for a new RFC to document what the "running code" actually does and deprecate the unused original behavior. Initial list of work items: (1) iSCSI: Combine RFCs 3720 (iSCSI), 3980 (NAA names), 4850 (node architecture key) and 5048 (corrections/clarifications) into one draft (3720bis), removing features that are not implemented in practice. This draft should be prepared so that it could become a Draft Standard RFC, but it is up to the Working Group to decide whether to advance it to Draft Standard. (2) iSCSI: Add features to support at least SAM-4 (4th version of the SCSI architecture) in a backwards-compatible fashion, as iSCSI is currently based on SAM-2. This will be a separate draft from the iSCSI update in the previous item. The Working Group may add additional minor useful iSCSI features to this draft, including features from draft versions of SAM-5. The iSCSI MIB (RFC 4544) should be updated to provide SNMP support for new features as appropriate. (3) FCIP: IP Protocol number 133 was allocated to a precursor of the FCIP protocol in 2000, but this allocated number is not used by FCIP. The Working Group will consider whether this allocated number should be returned to IANA for future reallocation. (4) iFCP: The Address Translation mode of iFCP needs to be deprecated (SHOULD NOT implement or use), as there are significant technical problems with its specification, and moreover, only the Address Transparent mode of iFCP is in use. This will be done via a short draft that updates RFC 4172, and not via a complete rewrite of RFC 4172. A combined draft is expected that encompasses items (3) and (4); this draft should also update the iFCP MIB (RFC 4369) to deprecate support for iFCP Address Translation mode. (5) RDDP MPA: Good support for MPI applications requires a small update to the startup functionality to allow either end of the connection to initiate. In addition, a couple of minor changes to RDDP connection setup are needed based on implementation experience. (6) iSER: Experience with Infiniband implementations suggest a few minor updates to reflect what has been done in practice. The Working Group is expected to maintain good working relationships with INCITS Technical Committee T10 (SCSI standards) and INCITS Technical Committee T11 (Fibre Channel standards) via overlaps in membership as opposed to appointment of formal liaisons. The liaison process (including IAB appointment of a liaison or liaisons) remains available for use if needed. Recent changes in INCITS rules have removed public access to some T10 and T11 standards documents that are expected to be needed for the WG's program of work. Arrangements have been made with T10 and T11 for IETF participants to obtain copies of specific standards their personal use in IETF work as needed; contact the WG chair(s) for details. Internet-Drafts: No Current Internet-Drafts. Security Issues in Network Event Logging (syslog) ------------------------------------------------- Charter Last Modified: 2009-09-15 Current Status: Active Working Group Chair(s): Chris Lonvick David Harrington Security Area Director(s): Tim Polk Pasi Eronen Security Area Advisor: Pasi Eronen Mailing Lists: General Discussion:syslog@ietf.org To Subscribe: syslog-request@ietf.org In Body: in body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/syslog Description of Working Group: Syslog has been a de-facto standard for logging system events for long time. The syslog WG recently completed standardization of the syslog protocol (RFC 5424), secure transport of the syslog protocol over TLS (RFC 5425), and non-secure transport over UDP (RFC 5426). The WG under this charter will standardize a DTLS transport for syslog, providing a secure transport for syslog messages in cases where a connection-less transport is desired. The threats that this WG will primarily address are modification, disclosure, and masquerade. A secondary threat is message stream modification. These are consistent with those addressed in RFC 5425. Draft-feng-syslog-transport-dtls is already similar to RFC 5425 in this respect, so this draft will become the starting point for the WG document, which the WG will adjust as needed, and merge desired features from other sources, such as draft-petch-gerhards-syslog-transport-dtls, draft-hardaker-isms-dtls-tm, and draft-seggelmann-tls-dtls-heartbeat. The WG will also complete the ongoing work to specify a standardized mechanism for signing syslog messages (draft-ietf-syslog-sign). Description of Working Group: Syslog has been a de-facto standard for logging system events for long time. The syslog WG recently completed standardization of the syslog protocol (RFC 5424), secure transport of the syslog protocol over TLS (RFC 5425), and non-secure transport over UDP (RFC 5426). The WG under this charter will standardize a DTLS transport for syslog, providing a secure transport for syslog messages in cases where a connection-less transport is desired. The threats that this WG will primarily address are modification, disclosure, and masquerade. A secondary threat is message stream modification. These are consistent with those addressed in RFC 5425. Draft-feng-syslog-transport-dtls is already similar to RFC 5425 in this respect, so this draft will become the starting point for the WG document, which the WG will adjust as needed, and merge desired features from other sources, such as draft-petch-gerhards-syslog-transport-dtls, draft-hardaker-isms-dtls-tm, and draft-seggelmann-tls-dtls-heartbeat. The WG will also complete the ongoing work to specify a standardized mechanism for signing syslog messages (draft-ietf-syslog-sign). Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jan 2001 Oct 2009 Signed syslog Messages Oct 2009 Oct 2009 Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog TCP Maintenance and Minor Extensions (tcpm) ------------------------------------------- Charter Last Modified: 2009-10-13 Current Status: Active Working Group Chair(s): Wesley Eddy David Borman Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Lars Eggert Mailing Lists: General Discussion:tcpm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tcpm Archive: http://www.ietf.org/mail-archive/web/tcpm/index.html Description of Working Group: TCP is currently the Internet's predominant transport protocol. To maintain TCP's utility the IETF has regularly updated both the protocol itself and the congestion control algorithms implemented by the protocol that are crucial for the stability of the Internet. These changes reflect our evolving understanding of transport protocols, congestion control and new needs presented by an ever-changing network. The TCPM WG will provide a venue within the IETF to work on these issues. The WG will serve several purposes: * The WG will mostly focus on maintenance issues (e.g., bug fixes) and modest changes to the protocol and algorithms that maintain TCP's utility. * The WG will be a venue for moving current TCP specifications along the standards track (as community energy is available for such efforts). * The WG will write a document that outlines "what is TCP". This document will be a roadmap of sorts to the various TCP specifications in the RFC series. TCPM will take a subset of the work which has been conducted in the Transport Area WG over the past several years. Specifically, some of the WG's initial work will be moved from the Transport Area WG (tsvwg). TCPM is expected to be the working group within the IETF to handle TCP changes. Proposals for additional TCP work items should be brought up within the working group. While fundamental changes to TCP or its congestion control algorithms (e.g., departure from loss-based congestion control) should be brought through TCPM, it is expected that such large changes will ultimately be handled by the Transport Area WG (tsvwg). All additional work items for TCPM will, naturally, require the approval of the Transport Services Area Area Directors and the IESG. TCP's congestion control algorithms are the model followed by alternate transports (e.g., SCTP and (in some cases) DCCP). In addition, the IETF has recently worked on several documents about algorithms that are specified for multiple protocols (e.g., TCP and SCTP) in the same document. Which WG shepherds such documents in the future will determined on a case-by-case basis. In any case, the TCPM WG will remain in close contact with other relevant WGs working on these protocols to ensure openness and stringent review from all angles. Specific Goals: * A document specifying a way to share the local "User TimeOut" value with the peer such that TCP connections can withstand long periods of disconnection. * The WG is coming to grips with how to deal with spoofed segments that can tear down connections, cause data corruption or performance problems. To this end the WG is generating an overview document as well as a scheme that mitigates some of the issues brought on by spoofed TCP segments using a challenge-response scheme to reduce the probabilities of a connection being impacted. Finally, the WG will produce a document outlining the potential impact of using ICMP messages to attack TCP streams. * The WG is writing an informational document about the ways in which TCPs can handle ICMP "soft errors". * The WG is updating the specification for Explicit Congestion Notification to allow for the use of ECN during part of TCP's three-way handshake to aid performance for short transfers. * The WG is writing an informational document that discusses commonly used, but not documented ways to combat SYN flooding attacks. * The WG is updating RFC 2581 to fix some minor specification problems and move it along the standards track. Description of Working Group: TCP is currently the Internet's predominant transport protocol. To maintain TCP's utility the IETF has regularly updated both the protocol itself and the congestion control algorithms implemented by the protocol that are crucial for the stability of the Internet. These changes reflect our evolving understanding of transport protocols, congestion control and new needs presented by an ever-changing network. The TCPM WG will provide a venue within the IETF to work on these issues. The WG will serve several purposes: * The WG will mostly focus on maintenance issues (e.g., bug fixes) and modest changes to the protocol and algorithms that maintain TCP's utility. * The WG will be a venue for moving current TCP specifications along the standards track (as community energy is available for such efforts). * The WG will write a document that outlines "what is TCP". This document will be a roadmap of sorts to the various TCP specifications in the RFC series. TCPM will take a subset of the work which has been conducted in the Transport Area WG over the past several years. Specifically, some of the WG's initial work will be moved from the Transport Area WG (tsvwg). TCPM is expected to be the working group within the IETF to handle TCP changes. Proposals for additional TCP work items should be brought up within the working group. While fundamental changes to TCP or its congestion control algorithms (e.g., departure from loss-based congestion control) should be brought through TCPM, it is expected that such large changes will ultimately be handled by the Transport Area WG (tsvwg). All additional work items for TCPM will, naturally, require the approval of the Transport Services Area Area Directors and the IESG. TCP's congestion control algorithms are the model followed by alternate transports (e.g., SCTP and (in some cases) DCCP). In addition, the IETF has recently worked on several documents about algorithms that are specified for multiple protocols (e.g., TCP and SCTP) in the same document. Which WG shepherds such documents in the future will determined on a case-by-case basis. In any case, the TCPM WG will remain in close contact with other relevant WGs working on these protocols to ensure openness and stringent review from all angles. Specific Goals: * A document specifying a way to share the local "User TimeOut" value with the peer such that TCP connections can withstand long periods of disconnection. * The WG is coming to grips with how to deal with spoofed segments that can tear down connections, cause data corruption or performance problems. To this end the WG is generating an overview document as well as a scheme that mitigates some of the issues brought on by spoofed TCP segments using a challenge-response scheme to reduce the probabilities of a connection being impacted. Finally, the WG will produce a document outlining the potential impact of using ICMP messages to attack TCP streams. * The WG is writing an informational document about the ways in which TCPs can handle ICMP "soft errors". * The WG is updating the specification for Explicit Congestion Notification to allow for the use of ECN during part of TCP's three-way handshake to aid performance for short transfers. * The WG is writing an informational document that discusses commonly used, but not documented ways to combat SYN flooding attacks. * The WG is updating RFC 2581 to fix some minor specification problems and move it along the standards track. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Apr 2004 Sep 2009 Improving TCP's Robustness to Blind In-Window Attacks Feb 2006 Aug 2009 ICMP attacks against TCP Nov 2007 Oct 2009 The TCP Authentication Option Aug 2008 Nov 2009 Early Retransmit for TCP and SCTP Mar 2009 Jul 2009 TCP Options and MSS May 2009 Nov 2009 On the implementation of the TCP urgent mechanism Aug 2009 Aug 2009 Security Assessment of the Transmission Control Protocol (TCP) Sep 2009 Oct 2009 Cryptographic Algorithms for TCP's Authentication Option, TCP-AO Oct 2009 Oct 2009 Using TCP Selective Acknowledgement (SACK) Information to Determine Duplicate Acknowledgements for Loss Recovery Initiation Nov 2009 Nov 2009 Making TCP more Robust to Long Connectivity Disruptions (TCP-LCD) Timing over IP Connection and Transfer of Clock (tictoc) -------------------------------------------------------- Charter Last Modified: 2009-04-13 Current Status: Active Working Group Chair(s): Yaakov Stein Stewart Bryant Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion:tictoc@ietf.org To Subscribe: TICTOC-request@ietf.org In Body: In Body: subscribe your_email_address Archive: http://www.ietf.org/mail-archive/web/tictoc Description of Working Group: The Timing over IP Connections and Transfer Of Clock (TICTOC) WG is concerned with highly accurate time and frequency distribution over native IP and MPLS-enabled IP Packet Switched Networks (PSNs). While this need arises from a variety of sources (see draft-bryant-tictoc-probstat-01.txt), the application areas of focus for this WG are: (1) Network infrastructures with the need for highly accurate time and frequency distribution within well-engineered service provider or enterprise campus networks. On-path support with specialized hardware may be expected to be available at one or more hops on a given path. (2) Individual hosts and devices on the public Internet requiring functionality or performance not currently available in NTP. On-path support may be utilized if available, but is not expected. This application brings additional requirements beyond improved accuracy, for example, the traceable and authenticated distribution of UTC time, including correct handling of leap seconds. The NTP Working Group is currently standardizing the fourth version of NTP for time distribution over IP networks. The NTP WG has focused its deliverables largely on standardizing the currently deployed NTPv4, while collecting requirements for future extensions. These requirements will transition to the tictoc WG for further development. Meeting those requirements may include revision of the protocol to a new version level. However, in all cases backwards compatibility and coexistence with currently deployed NTPv4 is a paramount concern. An applicability statement will describe the use cases for which any extension of NTP is targeted. The IEEE Test and Measurement Society is in the closing stages of standardizing a second version of IEEE1588. This is unofficially known as IEEE1588v2 and is expected to be published as IEEE1588-2008. IEEE1588v2 is emerging as a viable solution for time transfer over service provider and campus Ethernet networks, and for which on-path hardware support is becoming available. IEEE1588v2 specifically encourages other standards organizations to adapt it to their requirements, and provides guidelines for doing so. TICTOC will determine whether a profile for IEEE1588v2 over IP or MPLS-enabled IP networks would be suitable for (1), and if so will produce a profile within the guidelines provided in the IEEE1588v2 specification. An applicability statement will describe the use cases for which any profile of IEEE1588v2 is targeted. Time and Frequency distribution is considered by many to be a complex and often esoteric subject area. The WG will develop a modular framework in order to map out components within the solution space, define terminology, and identify common areas of protocol work that can be capitalized upon. TICTOC will also consider the co-existence of IEEE1588v2 and NTP in the same network. In doing so, TICTOC will first verify that the data model of NTP can be accommodated by IEEE1588v2 protocol operation and document any deficiencies compared to NTP. If there is a need to map the data models, it will produce a specification for how to utilize IEEE 1588 in a localized region as one portion of an NTP-based system. TICTOC protocols will be applicable to a variety of link layer technologies. To get the highest quality time and frequency transfer the user should take advantage of two types of on-path service where they are available: Link based frequency transfer, and hop-by-hop delay correction (for time). Examples of link based frequency support are SONET/SDH, TDM, Synchronous Ethernet and DSL with timing reference support. The main types of support that can be provided by a network element are boundary clock (where the clock is regenerated at the node in a multistage master slave relationship) and transparent clock where corrections are applied to time transfer packets as they pass through to compensate for the queuing delay, and where known for asymmetry in the link delay. Transparent clock (queue delay correction) requires routers to identify a time transfer packet, record the queuing delay, and either apply an on the fly correction to the packet, or to generate a follow-up packet with the necessary time correction information. TICTOC will ensure that any transparent clock design is acceptable in an Internet environment. On-path support is not a given, and TICTOC will investigate methods for automatically discovering when this support is available and when it is not. TICTOC will transfer time and frequency over both IP and IP enabled MPLS PSNs. One of the major users of TICTOC technology is the service provider community, where MPLS enabled IP networks are common. If necessary, TICTOC may take advantage of the path control properties of MPLS and the ability to signal modifications to per packet forwarding behavior. The security of time transfer, including the authentication of the time reference is an important consideration and must be designed in from the beginning. The ultimate system-level accuracy of time and frequency transfer depends on a number of factors outside the scope of the protocols themselves. Thus, even if it is possible for TICTOC to make a number of improvements at the protocol level to facilitate more accurate time and frequency transfer, it is impossible for the WG to provide system-level accuracy guarantees on its own. The TICTOC WG will co-ordinate with the PWE3 and NTP WGs in the IETF, as well as IEEE1588, IEEE 802.1AS and ITU-T SG15 Q13. It is also expected that active individuals in the TICTOC WG will propose the formation of an IRTF RG to study more advanced aspects of time and frequency distribution. First phase Objectives: - To develop a time and frequency distribution requirements document for the two cases listed above, including coexistence of the two as appropriate. - To develop a document defining the modular breakdown of functionality within the solution space. - To determine the extent to which these requirements can be satisfied using IEEE1588v2 and NTPv4 within each use case, along with an associated gap analysis for what requirements are not met without adaptation or extension of these protocols. - To develop an IEEE1588v2 profile as necessary for time and frequency distribution, with primary focus on (1). This profile will include a MIB module for IEEE1588v2. - To develop extensions to NTPv4 as necessary for time and frequency distribution, with primary focus on (2). - If required, to develop mechanisms for coexistence of IEEE1588v2 and NTP. - To document threat analyses and security mechanisms for all protocols developed by the WG. - To document media mappings for link layer technologies of interest. Second phase Objectives (requiring re-charter of the WG): To propose and document algorithms, protocols and mechanisms for transport, frequency acquisition, ranging, and packet selection/discard, master clock selection, path selection, OAM, synchronization status messaging, performance monitoring, security, and network management. Description of Working Group: The Timing over IP Connections and Transfer Of Clock (TICTOC) WG is concerned with highly accurate time and frequency distribution over native IP and MPLS-enabled IP Packet Switched Networks (PSNs). While this need arises from a variety of sources (see draft-bryant-tictoc-probstat-01.txt), the application areas of focus for this WG are: (1) Network infrastructures with the need for highly accurate time and frequency distribution within well-engineered service provider or enterprise campus networks. On-path support with specialized hardware may be expected to be available at one or more hops on a given path. (2) Individual hosts and devices on the public Internet requiring functionality or performance not currently available in NTP. On-path support may be utilized if available, but is not expected. This application brings additional requirements beyond improved accuracy, for example, the traceable and authenticated distribution of UTC time, including correct handling of leap seconds. The NTP Working Group is currently standardizing the fourth version of NTP for time distribution over IP networks. The NTP WG has focused its deliverables largely on standardizing the currently deployed NTPv4, while collecting requirements for future extensions. These requirements will transition to the tictoc WG for further development. Meeting those requirements may include revision of the protocol to a new version level. However, in all cases backwards compatibility and coexistence with currently deployed NTPv4 is a paramount concern. An applicability statement will describe the use cases for which any extension of NTP is targeted. The IEEE Test and Measurement Society is in the closing stages of standardizing a second version of IEEE1588. This is unofficially known as IEEE1588v2 and is expected to be published as IEEE1588-2008. IEEE1588v2 is emerging as a viable solution for time transfer over service provider and campus Ethernet networks, and for which on-path hardware support is becoming available. IEEE1588v2 specifically encourages other standards organizations to adapt it to their requirements, and provides guidelines for doing so. TICTOC will determine whether a profile for IEEE1588v2 over IP or MPLS-enabled IP networks would be suitable for (1), and if so will produce a profile within the guidelines provided in the IEEE1588v2 specification. An applicability statement will describe the use cases for which any profile of IEEE1588v2 is targeted. Time and Frequency distribution is considered by many to be a complex and often esoteric subject area. The WG will develop a modular framework in order to map out components within the solution space, define terminology, and identify common areas of protocol work that can be capitalized upon. TICTOC will also consider the co-existence of IEEE1588v2 and NTP in the same network. In doing so, TICTOC will first verify that the data model of NTP can be accommodated by IEEE1588v2 protocol operation and document any deficiencies compared to NTP. If there is a need to map the data models, it will produce a specification for how to utilize IEEE 1588 in a localized region as one portion of an NTP-based system. TICTOC protocols will be applicable to a variety of link layer technologies. To get the highest quality time and frequency transfer the user should take advantage of two types of on-path service where they are available: Link based frequency transfer, and hop-by-hop delay correction (for time). Examples of link based frequency support are SONET/SDH, TDM, Synchronous Ethernet and DSL with timing reference support. The main types of support that can be provided by a network element are boundary clock (where the clock is regenerated at the node in a multistage master slave relationship) and transparent clock where corrections are applied to time transfer packets as they pass through to compensate for the queuing delay, and where known for asymmetry in the link delay. Transparent clock (queue delay correction) requires routers to identify a time transfer packet, record the queuing delay, and either apply an on the fly correction to the packet, or to generate a follow-up packet with the necessary time correction information. TICTOC will ensure that any transparent clock design is acceptable in an Internet environment. On-path support is not a given, and TICTOC will investigate methods for automatically discovering when this support is available and when it is not. TICTOC will transfer time and frequency over both IP and IP enabled MPLS PSNs. One of the major users of TICTOC technology is the service provider community, where MPLS enabled IP networks are common. If necessary, TICTOC may take advantage of the path control properties of MPLS and the ability to signal modifications to per packet forwarding behavior. The security of time transfer, including the authentication of the time reference is an important consideration and must be designed in from the beginning. The ultimate system-level accuracy of time and frequency transfer depends on a number of factors outside the scope of the protocols themselves. Thus, even if it is possible for TICTOC to make a number of improvements at the protocol level to facilitate more accurate time and frequency transfer, it is impossible for the WG to provide system-level accuracy guarantees on its own. The TICTOC WG will co-ordinate with the PWE3 and NTP WGs in the IETF, as well as IEEE1588, IEEE 802.1AS and ITU-T SG15 Q13. It is also expected that active individuals in the TICTOC WG will propose the formation of an IRTF RG to study more advanced aspects of time and frequency distribution. First phase Objectives: - To develop a time and frequency distribution requirements document for the two cases listed above, including coexistence of the two as appropriate. - To develop a document defining the modular breakdown of functionality within the solution space. - To determine the extent to which these requirements can be satisfied using IEEE1588v2 and NTPv4 within each use case, along with an associated gap analysis for what requirements are not met without adaptation or extension of these protocols. - To develop an IEEE1588v2 profile as necessary for time and frequency distribution, with primary focus on (1). This profile will include a MIB module for IEEE1588v2. - To develop extensions to NTPv4 as necessary for time and frequency distribution, with primary focus on (2). - If required, to develop mechanisms for coexistence of IEEE1588v2 and NTP. - To document threat analyses and security mechanisms for all protocols developed by the WG. - To document media mappings for link layer technologies of interest. Second phase Objectives (requiring re-charter of the WG): To propose and document algorithms, protocols and mechanisms for transport, frequency acquisition, ranging, and packet selection/discard, master clock selection, path selection, OAM, synchronization status messaging, performance monitoring, security, and network management. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2009 Jul 2009 TICTOC Requirement Transport Layer Security (tls) ------------------------------ Charter Last Modified: 2009-02-04 Current Status: Active Working Group Chair(s): Eric Rescorla Joseph Salowey Eric Rescorla Security Area Director(s): Tim Polk Pasi Eronen Security Area Advisor: Pasi Eronen Technical Advisor(s): Allison Mankin Mailing Lists: General Discussion:tls@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tls Archive: http://www.ietf.org/mail-archive/web/tls/current/maillist.html Description of Working Group: The TLS Working Group was established in 1996 to standardize a 'transport layer' security protocol. The working group began with SSL version 3.0. The TLS Working Group has completed a series of specifications that describe the Transport Layer Security protocol versions 1.0 and 1.1, extensions to the protocol, and new ciphersuites to be used with TLS. The primary goal of the WG is to publish a revision of TLS, version 1.2, that removes the protocol's dependency on the MD5 and SHA-1 digest algorithms, which have been either wholly or partially compromised by recent research. The TLS WG will also work on new authenticated encryption modes for TLS, including modes based on counter mode encryption (CTR) and combined encryption/authentication modes, and may define major new cipher suites for TLS for this purpose. In the preparation of TLS 1.2, the WG will attempt to avoid gratuitous changes to TLS 1.1. Description of Working Group: The TLS Working Group was established in 1996 to standardize a 'transport layer' security protocol. The working group began with SSL version 3.0. The TLS Working Group has completed a series of specifications that describe the Transport Layer Security protocol versions 1.0 and 1.1, extensions to the protocol, and new ciphersuites to be used with TLS. The primary goal of the WG is to publish a revision of TLS, version 1.2, that removes the protocol's dependency on the MD5 and SHA-1 digest algorithms, which have been either wholly or partially compromised by recent research. The TLS WG will also work on new authenticated encryption modes for TLS, including modes based on counter mode encryption (CTR) and combined encryption/authentication modes, and may define major new cipher suites for TLS for this purpose. In the preparation of TLS 1.2, the WG will attempt to avoid gratuitous changes to TLS 1.1. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2007 Oct 2009 Transport Layer Security (TLS) Extensions: Extension Definitions Dec 2007 Sep 2009 Keying Material Exporters for Transport Layer Security (TLS) Jun 2008 Oct 2009 Datagram Transport Layer Security version 1.2 Jun 2009 Sep 2009 Transport Layer Security (TLS) Cached Information Extension Nov 2009 Nov 2009 Transport Layer Security (TLS) Renegotiation Indication Extension Transparent Interconnection of Lots of Links (trill) ---------------------------------------------------- Charter Last Modified: 2009-05-07 Current Status: Active Working Group Chair(s): Erik Nordmark Donald Eastlake 3rd Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion:rbridge@postel.org To Subscribe: http://www.postel.org/mailman/listinfo/rbridge Archive: http://www.postel.org/pipermail/rbridge Description of Working Group: The TRILL WG will design a solution for shortest-path frame routing in multi-hop IEEE 802.1-compliant Ethernet networks with arbitrary topologies, using an existing link-state routing protocol technology. This work will initially be based on draft-perlman-rbridge-03.txt. The design should have the following properties: - Minimal or no configuration required - Load-splitting among multiple paths - Routing loop mitigation (possibly through a TTL field) - Support of multiple points of attachment - Support for broadcast and multicast - No significant service delay after attachment - No less secure than existing bridged solutions Any changes introduced to the Ethernet service model should be analyzed and clearly documented. To ensure compatibility with IEEE VLANs and the Ethernet service model, the WG will request an IEEE liaison relationship with IEEE 802.1, and IEEE 802.1 will be asked to review the architecture document and specification(s) before they are submitted to the IESG. It is not an explicit requirement that the solution should be able to run on existing IP routers or IEEE 802 switches as a software upgrade. However, the working group should take deployment considerations into account, to ensure that the solution can interwork with bridges in a flexible manner (e.g., to allow incremental deployment into LANs that currently use 802.1D bridges). The TRILL working will work with the L2VPN WG to develop interworking between TRILL and 802.1D bridges at the edge, such that a bridged sub-cloud could be attached to TRILL devices in more than one place for redundancy. The solution must not interfere with the end-to-end transparency of the Internet architecture or with end-to-end congestion control and QOS mechanisms. The WG will work on the following items: (1) Develop a problem statement and architecture document that describes the high-level TRILL architecture, discusses the scalability of that architecture, describes the threat model and security impacts of the TRILL solution, and describes the expected impacts (if any) of the TRILL solution on the Ethernet service model. (2) Define the requirements for a TRILL-capable routing protocol, and select one or more existing routing protocols that could meet those requirements. (3) Work with the appropriate Routing area working group to extend an existing routing protocol to meet the TRILL working group requirements. Note: The TRILL working group is not chartered to develop a new routing protocol or to make substantial modifications to an existing routing protocol. If, during the requirements definition and selection phase, the TRILL working group discovers that no existing routing protocol will meet their needs, we will need to re-assess the TRILL WG charter to determine how/if this work should proceed. (4) Produce a (set of) TRILL specification(s) for standards track publication that define(s) what information must be carried in an encapsulation header for data packets. Although this work will initially be undertaken only for 802.1-compliant links, it may later be expanded to non-802.1 links, so the design should be link-layer agnostic to whatever extent possible. The TRILL working group is chartered to undertake all of the above tasks and may begin work on more than one of these tasks in parallel. However, the problem statement and architecture document should be completed before the details of the base protocol are finalized, while there is still time to consider changes to the architecture without major impacts on established specifications. Description of Working Group: The TRILL WG will design a solution for shortest-path frame routing in multi-hop IEEE 802.1-compliant Ethernet networks with arbitrary topologies, using an existing link-state routing protocol technology. This work will initially be based on draft-perlman-rbridge-03.txt. The design should have the following properties: - Minimal or no configuration required - Load-splitting among multiple paths - Routing loop mitigation (possibly through a TTL field) - Support of multiple points of attachment - Support for broadcast and multicast - No significant service delay after attachment - No less secure than existing bridged solutions Any changes introduced to the Ethernet service model should be analyzed and clearly documented. To ensure compatibility with IEEE VLANs and the Ethernet service model, the WG will request an IEEE liaison relationship with IEEE 802.1, and IEEE 802.1 will be asked to review the architecture document and specification(s) before they are submitted to the IESG. It is not an explicit requirement that the solution should be able to run on existing IP routers or IEEE 802 switches as a software upgrade. However, the working group should take deployment considerations into account, to ensure that the solution can interwork with bridges in a flexible manner (e.g., to allow incremental deployment into LANs that currently use 802.1D bridges). The TRILL working will work with the L2VPN WG to develop interworking between TRILL and 802.1D bridges at the edge, such that a bridged sub-cloud could be attached to TRILL devices in more than one place for redundancy. The solution must not interfere with the end-to-end transparency of the Internet architecture or with end-to-end congestion control and QOS mechanisms. The WG will work on the following items: (1) Develop a problem statement and architecture document that describes the high-level TRILL architecture, discusses the scalability of that architecture, describes the threat model and security impacts of the TRILL solution, and describes the expected impacts (if any) of the TRILL solution on the Ethernet service model. (2) Define the requirements for a TRILL-capable routing protocol, and select one or more existing routing protocols that could meet those requirements. (3) Work with the appropriate Routing area working group to extend an existing routing protocol to meet the TRILL working group requirements. Note: The TRILL working group is not chartered to develop a new routing protocol or to make substantial modifications to an existing routing protocol. If, during the requirements definition and selection phase, the TRILL working group discovers that no existing routing protocol will meet their needs, we will need to re-assess the TRILL WG charter to determine how/if this work should proceed. (4) Produce a (set of) TRILL specification(s) for standards track publication that define(s) what information must be carried in an encapsulation header for data packets. Although this work will initially be undertaken only for 802.1-compliant links, it may later be expanded to non-802.1 links, so the design should be link-layer agnostic to whatever extent possible. The TRILL working group is chartered to undertake all of the above tasks and may begin work on more than one of these tasks in parallel. However, the problem statement and architecture document should be completed before the details of the base protocol are finalized, while there is still time to consider changes to the architecture without major impacts on established specifications. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- May 2006 Oct 2009 Rbridges: Base Protocol Specification Transport Area Working Group (tsvwg) ------------------------------------ Charter Last Modified: 2009-09-22 Current Status: Active Working Group Chair(s): James Polk Gorry Fairhurst Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Lars Eggert Mailing Lists: General Discussion:tsvwg@ietf.org To Subscribe: tsvwg-request@ietf.org In Body: subscribe email_address Archive: http://www.ietf.org/mail-archive/web/tsvwg/index.html Description of Working Group: The Transport Area receives occasional proposals for the development and publication of RFCs dealing with transport topics that are not in scope of an existing working group or do not justify the formation of a new working group. TSVWG will serve as the forum for developing such work items in the IETF. The TSVWG mailing list is an open discussion forum for such work items, when they arise. The working group meets if there are active proposals that require discussion. The working group milestones are updated as needed to reflect the current work items and their associated milestones. The currently active TSVWG work items mostly fall under the following topics: (A) Maintenance of the Stream Control Transmission Protocol (SCTP), which involves bug fixes to the SCTP specifications and their progression along the standards track. This work item also includes a small number of modular extensions to SCTP. Currently, these include SCTP-ADDIP, SCTP-AUTH and SCTP-PADDING, as well as socket API and threat analysis documents. In order to maintain stable specifications, additional work on SCTP in TSVWG requires Area Director approval. (B) Maintenance of the Resource Reservation Protocol (RSVP), which involves bug fixes to the RSVP specifications and their progression along the standards track. This work item may also include a small number of extensions to RSVP or advisory documents to address specific application scenarios. In order to maintain stable specifications, additional work on RSVP in TSVWG requires Area Director approval. (C) Maintenance of IP Differentiated Services (DiffServ) mechanisms, which involves mostly advisory documents on the use of DiffServ in specific application scenarios. Other work items related to DiffServ require Area Director approval. (D) Selected other work items, which are mostly in TSVWG for historic reasons. These include an extended statistics MIB for TCP and the quick-start mechanism for TCP and IP. Additional work that does not fall under one of the above topics in TSVWG must satisfy four conditions: (1) WG consensus on the suitability and projected quality of the proposed work item. (2) A core group of WG participants with sufficient energy and expertise to advance the work item according to the proposed schedule. (3) Commitment from the WG as a whole to provide sufficient and timely review of the proposed work item. (4) Agreement by the ADs, who, depending on the scope of the proposed work item, may decide that an IESG review is needed first. Description of Working Group: The Transport Area receives occasional proposals for the development and publication of RFCs dealing with transport topics that are not in scope of an existing working group or do not justify the formation of a new working group. TSVWG will serve as the forum for developing such work items in the IETF. The TSVWG mailing list is an open discussion forum for such work items, when they arise. The working group meets if there are active proposals that require discussion. The working group milestones are updated as needed to reflect the current work items and their associated milestones. The currently active TSVWG work items mostly fall under the following topics: (A) Maintenance of the Stream Control Transmission Protocol (SCTP), which involves bug fixes to the SCTP specifications and their progression along the standards track. This work item also includes a small number of modular extensions to SCTP. Currently, these include SCTP-ADDIP, SCTP-AUTH and SCTP-PADDING, as well as socket API and threat analysis documents. In order to maintain stable specifications, additional work on SCTP in TSVWG requires Area Director approval. (B) Maintenance of the Resource Reservation Protocol (RSVP), which involves bug fixes to the RSVP specifications and their progression along the standards track. This work item may also include a small number of extensions to RSVP or advisory documents to address specific application scenarios. In order to maintain stable specifications, additional work on RSVP in TSVWG requires Area Director approval. (C) Maintenance of IP Differentiated Services (DiffServ) mechanisms, which involves mostly advisory documents on the use of DiffServ in specific application scenarios. Other work items related to DiffServ require Area Director approval. (D) Selected other work items, which are mostly in TSVWG for historic reasons. These include an extended statistics MIB for TCP and the quick-start mechanism for TCP and IP. Additional work that does not fall under one of the above topics in TSVWG must satisfy four conditions: (1) WG consensus on the suitability and projected quality of the proposed work item. (2) A core group of WG participants with sufficient energy and expertise to advance the work item according to the proposed schedule. (3) Commitment from the WG as a whole to provide sufficient and timely review of the proposed work item. (4) Agreement by the ADs, who, depending on the scope of the proposed work item, may decide that an IESG review is needed first. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2006 Nov 2009 Resource ReSerVation Protocol (RSVP) Extensions for Admission Priority Dec 2006 Nov 2008 DSCP for Capacity-Admitted Traffic Feb 2007 Oct 2009 RSVP Extensions for Path-Triggered RSVP Receiver Proxy Feb 2007 Oct 2009 RSVP Proxy Approaches Dec 2007 Jul 2009 Port Randomization Feb 2008 Jun 2009 Applicability of Keying Methods for RSVP Security Jul 2008 Nov 2009 Support for RSVP in Layer 3 VPNs Jul 2008 Oct 2009 Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Transport Protocol Port Number and Service Name Registry Aug 2008 Oct 2009 Byte and Packet Congestion Notification Oct 2008 Oct 2009 Tunnelling of Explicit Congestion Notification Oct 2008 Oct 2009 Datagram Transport Layer Security for Stream Control Transmission Protocol Jul 2009 Oct 2009 Stream Control Transmission Protocol (SCTP) Stream Reconfiguration IPv6 Operations (v6ops) ----------------------- Charter Last Modified: 2008-08-21 Current Status: Active Working Group Chair(s): Fred Baker Kurt Lindqvist Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Ronald Bonica Mailing Lists: General Discussion:v6ops@ops.ietf.org To Subscribe: majordomo@ops.ietf.org In Body: subscribe v6ops Archive: http://ops.ietf.org/lists/v6ops/ Description of Working Group: The global deployment of IPv6 is underway, creating an IPv4/IPv6 Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and nodes. This deployment must be properly handled to avoid the division of the Internet into separate IPv4 and IPv6 networks while ensuring addressing and connectivity for all IPv4 and IPv6 nodes. 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. The main focus of the v6ops WG is to look at the immediate deployment issues; more advanced stages of deployment and transition are a lower priority. The goals of the v6ops working group are: 1. Solicit input from network operators and users to identify operational issues with the IPv4/IPv6 Internet, and determine solutions or workarounds to those issues. These issues will be documented in Informational or BCP RFCs, or in Internet-Drafts. This work should primarily be conducted by those areas and WGs which are responsible and best fit to analyze these problems, but v6ops may also cooperate in focusing such work. 2. Publish Informational or BCP RFCs that identify potential security risks in the operation of shared IPv4/IPv6 networks, and document operational practices to eliminate or mitigate those risks. This work will be done in cooperation with the Security area and other relevant areas or working groups. 3. As a particular instance of (1) and (2), provide feedback to the IPv6 WG regarding portions of the IPv6 specifications that cause, or are likely to cause, operational or security concerns, and work with the IPv6 WG to resolve those concerns. This feedback will be published in Internet-Drafts or RFCs. 4. Publish Informational or BCP RFCs that identify and analyze solutions for deploying IPv6 within common network environments, such as ISP Networks, Enterprise Networks, Unmanaged Networks (Home/Small Office), and Cellular Networks. These documents should serve as useful guides to network operators and users on possible ways how to deploy IPv6 within their existing IPv4 networks, as well as in new network installations. These documents should not be normative guides for IPv6 deployment, and the primary intent is not capture the needs for new solutions, but rather describe which approaches work and which do not. IPv6 operational and deployment issues with specific protocols or technologies (such as Applications, Transport Protocols, Routing Protocols, DNS or Sub-IP Protocols) are the primary responsibility of the groups or areas responsible for those protocols or technologies. However, the v6ops WG may provide input to those areas/groups, as needed, and cooperate with those areas/groups in reviewing solutions to IPv6 operational and deployment problems. Future work items within this scope will be adopted by the WG only if there is a substantial expression of interest from the community and if the work clearly does not fit elsewhere in the IETF. There must be a continuous expression of interest for the WG to work on a particular work item. If there is no longer sufficient interest in the WG in a work item, the item may be removed from the list of WG items. Specifying any protocols or transition mechanisms is out of scope of the WG. Description of Working Group: The global deployment of IPv6 is underway, creating an IPv4/IPv6 Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and nodes. This deployment must be properly handled to avoid the division of the Internet into separate IPv4 and IPv6 networks while ensuring addressing and connectivity for all IPv4 and IPv6 nodes. 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. The main focus of the v6ops WG is to look at the immediate deployment issues; more advanced stages of deployment and transition are a lower priority. The goals of the v6ops working group are: 1. Solicit input from network operators and users to identify operational issues with the IPv4/IPv6 Internet, and determine solutions or workarounds to those issues. These issues will be documented in Informational or BCP RFCs, or in Internet-Drafts. This work should primarily be conducted by those areas and WGs which are responsible and best fit to analyze these problems, but v6ops may also cooperate in focusing such work. 2. Publish Informational or BCP RFCs that identify potential security risks in the operation of shared IPv4/IPv6 networks, and document operational practices to eliminate or mitigate those risks. This work will be done in cooperation with the Security area and other relevant areas or working groups. 3. As a particular instance of (1) and (2), provide feedback to the IPv6 WG regarding portions of the IPv6 specifications that cause, or are likely to cause, operational or security concerns, and work with the IPv6 WG to resolve those concerns. This feedback will be published in Internet-Drafts or RFCs. 4. Publish Informational or BCP RFCs that identify and analyze solutions for deploying IPv6 within common network environments, such as ISP Networks, Enterprise Networks, Unmanaged Networks (Home/Small Office), and Cellular Networks. These documents should serve as useful guides to network operators and users on possible ways how to deploy IPv6 within their existing IPv4 networks, as well as in new network installations. These documents should not be normative guides for IPv6 deployment, and the primary intent is not capture the needs for new solutions, but rather describe which approaches work and which do not. IPv6 operational and deployment issues with specific protocols or technologies (such as Applications, Transport Protocols, Routing Protocols, DNS or Sub-IP Protocols) are the primary responsibility of the groups or areas responsible for those protocols or technologies. However, the v6ops WG may provide input to those areas/groups, as needed, and cooperate with those areas/groups in reviewing solutions to IPv6 operational and deployment problems. Future work items within this scope will be adopted by the WG only if there is a substantial expression of interest from the community and if the work clearly does not fit elsewhere in the IETF. There must be a continuous expression of interest for the WG to work on a particular work item. If there is no longer sufficient interest in the WG in a work item, the item may be removed from the list of WG items. Specifying any protocols or transition mechanisms is out of scope of the WG. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jun 2007 Oct 2009 Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service Jun 2008 May 2009 IPv6 RA-Guard Mar 2009 Oct 2009 Requirements for IPv6 Customer Edge Routers May 2009 May 2009 Rogue IPv6 Router Advertisement Problem Statement Jun 2009 Oct 2009 IPv6 Deployment in Internet Exchange Points (IXPs) Nov 2009 Nov 2009 An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition vCard and CardDAV (vcarddav) ---------------------------- Charter Last Modified: 2009-04-03 Current Status: Active Working Group Chair(s): Kurt Zeilenga Marc Blanchet Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Alexey Melnikov Mailing Lists: General Discussion:vcarddav@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/vcarddav Archive: http://www.ietf.org/mail-archive/web/vcarddav Description of Working Group: A personal address book (PAB) contains a read/write copy of attributes describing a user's interpersonal contacts. This is distinct from a directory which contains a primarily read-only copy of users within an organization. While these two data objects share a large number of common attributes, their use and access patterns are fundamentally different. The IETF has a standards-track data format (vCard) which has been successfully used to interchange both personal-address-book and user directory entry data objects. However, due to the lack of a standard access control model for LDAP, the lack of a standard LDAP schema and DIT-model for vCard PAB objects, and the different access patterns for PAB data (as opposed to directory data), the use of LDAP as an access protocol for PABs has had mixed results in practice. Moreover, the vCard format has been extended by many parties and the current specification is ambiguous for some objects. If the deployed protocols related to interpersonal communication are viewed as a component-based system, there are a number of points in the system that would benefit from a standards track access protocol for personal address book data. This includes: * Mail User Agents use PAB data to assist outgoing email addressing and may use vCard attachments to transport PAB data between users. * Calendar User Agents use PAB data to invite attendees to events * Instant Messaging User Agents can provide additional information about a user's buddies if they can be associated with a user's PAB entry. * A server-side Sieve engine with the spamtest/virustest extension would benefit from access to a user's PAB to provide per-user white list capabilities. * Various deployed challenge-response mechanisms for email present in Mail Transfer Agents, such as TMDA, would be improved by a PAB-based white list. * Mobile device synchronization software might be simplified by a single cross-platform PAB access protocol. * A voice conference or IP telephony system could access a user's PAB to provide name-based or nickname-based dialing. This WG will produce the following outputs: (1) A revision of the vCard specification (RFC2426) at proposed standard status. This revision shall include other vCard standardized extensions (RFC 2739, 4770) and extensions assisting synchronization technologies (for example, a per-entry UUID or per-attribute sequence number). Other extensions shall be considered either in the base specification or in additional documents. (2) An address book access protocol leveraging the vCard data format. The Internet-draft draft-daboo-carddav will be the starting point. The WG is explicitly cautioned to keep the base specification feature set small with an adequate extension mechanism, as failure to do so was a problem for previous PAB efforts (ACAP). The WG will consider arguments of the form "feature X must be in the base feature set because ..." with great skepticism. These documents will consider security implications carefully. The WG will consider developing a mechanism that provides the ability to check if an email address (or im address, etc) is in the user's PAB without providing unrestricted access to all of the user's PAB data. The WG should also consider developing a mechanism that allows the user to grant this limited permission to a third-party service (such as a server-based Sieve engine) for white-list purposes. Once the primary outputs are complete, the WG will consider the following secondary outputs: (3) An XML schema which is semantically identical to vCard in all ways and can be mechanically translated to and from vCard format without loss of data. While vCard has deployed successfully and will remain the preferred interchange format, a standard XML schema which preserves vCard semantics might make vCard data more accessible to XML- centric technologies such as AJAX and XSLT. Such a standard format would be preferable to multiple proprietary XML schemas, particularly if vCard semantics were lost by some of them and a lossy gateway problem resulted. (4) Identifying useful deployed vCard vendor extensions and creating standards track versions of those extensions. (5) Cooperate with the Sieve WG to produce a Sieve extension for address book Sieve tests. (6) LDAP mapping to the new vCard format without loss of data. Description of Working Group: A personal address book (PAB) contains a read/write copy of attributes describing a user's interpersonal contacts. This is distinct from a directory which contains a primarily read-only copy of users within an organization. While these two data objects share a large number of common attributes, their use and access patterns are fundamentally different. The IETF has a standards-track data format (vCard) which has been successfully used to interchange both personal-address-book and user directory entry data objects. However, due to the lack of a standard access control model for LDAP, the lack of a standard LDAP schema and DIT-model for vCard PAB objects, and the different access patterns for PAB data (as opposed to directory data), the use of LDAP as an access protocol for PABs has had mixed results in practice. Moreover, the vCard format has been extended by many parties and the current specification is ambiguous for some objects. If the deployed protocols related to interpersonal communication are viewed as a component-based system, there are a number of points in the system that would benefit from a standards track access protocol for personal address book data. This includes: * Mail User Agents use PAB data to assist outgoing email addressing and may use vCard attachments to transport PAB data between users. * Calendar User Agents use PAB data to invite attendees to events * Instant Messaging User Agents can provide additional information about a user's buddies if they can be associated with a user's PAB entry. * A server-side Sieve engine with the spamtest/virustest extension would benefit from access to a user's PAB to provide per-user white list capabilities. * Various deployed challenge-response mechanisms for email present in Mail Transfer Agents, such as TMDA, would be improved by a PAB-based white list. * Mobile device synchronization software might be simplified by a single cross-platform PAB access protocol. * A voice conference or IP telephony system could access a user's PAB to provide name-based or nickname-based dialing. This WG will produce the following outputs: (1) A revision of the vCard specification (RFC2426) at proposed standard status. This revision shall include other vCard standardized extensions (RFC 2739, 4770) and extensions assisting synchronization technologies (for example, a per-entry UUID or per-attribute sequence number). Other extensions shall be considered either in the base specification or in additional documents. (2) An address book access protocol leveraging the vCard data format. The Internet-draft draft-daboo-carddav will be the starting point. The WG is explicitly cautioned to keep the base specification feature set small with an adequate extension mechanism, as failure to do so was a problem for previous PAB efforts (ACAP). The WG will consider arguments of the form "feature X must be in the base feature set because ..." with great skepticism. These documents will consider security implications carefully. The WG will consider developing a mechanism that provides the ability to check if an email address (or im address, etc) is in the user's PAB without providing unrestricted access to all of the user's PAB data. The WG should also consider developing a mechanism that allows the user to grant this limited permission to a third-party service (such as a server-based Sieve engine) for white-list purposes. Once the primary outputs are complete, the WG will consider the following secondary outputs: (3) An XML schema which is semantically identical to vCard in all ways and can be mechanically translated to and from vCard format without loss of data. While vCard has deployed successfully and will remain the preferred interchange format, a standard XML schema which preserves vCard semantics might make vCard data more accessible to XML- centric technologies such as AJAX and XSLT. Such a standard format would be preferable to multiple proprietary XML schemas, particularly if vCard semantics were lost by some of them and a lossy gateway problem resulted. (4) Identifying useful deployed vCard vendor extensions and creating standards track versions of those extensions. (5) Cooperate with the Sieve WG to produce a Sieve extension for address book Sieve tests. (6) LDAP mapping to the new vCard format without loss of data. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Mar 2008 Oct 2009 vCard Format Specification May 2008 Nov 2009 vCard Extensions to WebDAV (CardDAV) Oct 2009 Oct 2009 vCard XML Schema Virtual Router Redundancy Protocol (vrrp) ----------------------------------------- Charter Last Modified: 2009-04-02 Current Status: Active Working Group Chair(s): Mukesh Gupta Radia Perlman Routing Area Director(s): Ross Callon Adrian Farrel Routing Area Advisor: Adrian Farrel Mailing Lists: General Discussion:vrrp@ietf.org To Subscribe: vrrp-request@ietf.org In Body: subscribe vrrp Archive: http://www.ietf.org/mail-archive/web/vrrp/index.html Description of Working Group: The purpose of this working group is to define and develop a standard virtual router redundancy protocol for IPv4 and IPv6. A virtual router redundancy protocol is a protocol which allows several routers on a multiaccess link to utilize the same virtual IP address. One router will be elected as a master with the other routers acting as backups in case of the failure of the master router. The primary motivation to using a virtual router redundancy protocol is that host systems may be configured (manually or via DHCP) with a single default gateway, rather than running an active routing protocol. The protocol should also support the ability to load share traffic when both routers are up. The goals of this working group are: 1. Define and develop a standard virtual router redundancy protocol for IPv4 and IPv6. 2. Develop VRRP MIB(s). 3. Separate specifications will be developed for IPv4 and IPv6. 4. Determine whether static (configuration based) load sharing is adequate or if some amount of dynamic load sharing is required. 5. Working group will examine security issues to determine what security threats it is appropriate for the VRRP protocol to handle and include the appropriate mechanisms in the VRRP protocol. 6. The internet draft "Virtual Router Redundancy Protocol" (draft-hinden-vrrp-00.txt) will be use as the basis of virtual router redundancy protocol. The working group will also consider other Internet-Drafts related to this topic allowing for issues regarding change control, security, running code, etc. 7. Intellectual property issues regarding the technology to develop a virtual router redundancy protocol will be identified and addressed. Description of Working Group: The purpose of this working group is to define and develop a standard virtual router redundancy protocol for IPv4 and IPv6. A virtual router redundancy protocol is a protocol which allows several routers on a multiaccess link to utilize the same virtual IP address. One router will be elected as a master with the other routers acting as backups in case of the failure of the master router. The primary motivation to using a virtual router redundancy protocol is that host systems may be configured (manually or via DHCP) with a single default gateway, rather than running an active routing protocol. The protocol should also support the ability to load share traffic when both routers are up. The goals of this working group are: 1. Define and develop a standard virtual router redundancy protocol for IPv4 and IPv6. 2. Develop VRRP MIB(s). 3. Separate specifications will be developed for IPv4 and IPv6. 4. Determine whether static (configuration based) load sharing is adequate or if some amount of dynamic load sharing is required. 5. Working group will examine security issues to determine what security threats it is appropriate for the VRRP protocol to handle and include the appropriate mechanisms in the VRRP protocol. 6. The internet draft "Virtual Router Redundancy Protocol" (draft-hinden-vrrp-00.txt) will be use as the basis of virtual router redundancy protocol. The working group will also consider other Internet-Drafts related to this topic allowing for issues regarding change control, security, running code, etc. 7. Intellectual property issues regarding the technology to develop a virtual router redundancy protocol will be identified and addressed. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Nov 2007 Oct 2009 Virtual Router Redundancy Protocol Version 3 for IPv4 and IPv6 Virtual World Region Agent Protocol (vwrap) ------------------------------------------- Charter Last Modified: 2009-09-29 Current Status: Active Working Group Chair(s): Barry Leiba Joshua Bell Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Alexey Melnikov Mailing Lists: General Discussion:ogpx@ietf.org To Subscribe: ogpx-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/ogpx/current/maillist.html Description of Working Group: The working group will define the Virtual World Region Agent Protocol (VWRAP) for a collaborative 3-dimensional virtual environment. The protocol permits users to interact as digital representations called "avatars". An avatar exists in at most one location within a shared virtual space. Conforming client applications use the protocol to manipulate and move the user's avatar, create virtual objects, interact with other users and their surroundings, consume and create media and information from sources inside and outside their simulated environment. A virtual space can be partitioned into "regions" to facilitate the computational and communication load balancing required to simulate the virtual environment. A region provides the service environment in which inhabitants and objects can interact. A region uniquely represents a partition of the virtual space; they are not a mechanism for load balancing by having multiple instances of the same space. Different regions may be administered by different organizations. The state of a virtual world is independent of the client applications that access it and may persist between user sessions. Within a VWRAP virtual environment, services may be deployed by multiple organizations having varying policies and trust domains. The VWRAP protocol will provide the mechanisms for these services to interoperate, when permitted by policy. The working group may document examples of policies applicable to a VWRAP environment. Foundational components of the protocol include the publication of: * an abstract type system, suitable for describing the application protocol in an implementation neutral manner, * a security model describing trust relationships between participating entities, * guidelines for the use of existing authentication and confidentiality mechanisms, * an application-layer protocol for establishing the user's avatar in a region, * an application-layer protocol for changing an avatar's position, including moving between regions, * format descriptions for objects and avatars, and * an application-layer protocol for identifying entities, and requesting information about them. The protocol defined by this group will carry information about the virtual environment, its contents and its inhabitants. It is an application layer protocol, independent of transport, based partially on these previously published internet drafts: * http://tools.ietf.org/html/draft-hamrick-ogp-intro * http://tools.ietf.org/html/draft-hamrick-llsd * http://tools.ietf.org/html/draft-hamrick-ogp-auth * http://tools.ietf.org/html/draft-hamrick-ogp-launch * http://tools.ietf.org/html/draft-lentczner-ogp-base * http://tools.ietf.org/html/draft-levine-ogp-clientcap * http://tools.ietf.org/html/draft-levine-ogp-layering The protocol should describe interaction semantics independent of transport, leveraging existing standards where practical. It should define interoperability expectations for server to server interactions as well as client-server interactions. Though the protocol is independent of transport, early interoperability trials used HTTP(S) for non-real-time messages. The working group will define specific features that must be replicated in other transports and will define the use of HTTP(S) as a transport of protocol messages. Description of Working Group: The working group will define the Virtual World Region Agent Protocol (VWRAP) for a collaborative 3-dimensional virtual environment. The protocol permits users to interact as digital representations called "avatars". An avatar exists in at most one location within a shared virtual space. Conforming client applications use the protocol to manipulate and move the user's avatar, create virtual objects, interact with other users and their surroundings, consume and create media and information from sources inside and outside their simulated environment. A virtual space can be partitioned into "regions" to facilitate the computational and communication load balancing required to simulate the virtual environment. A region provides the service environment in which inhabitants and objects can interact. A region uniquely represents a partition of the virtual space; they are not a mechanism for load balancing by having multiple instances of the same space. Different regions may be administered by different organizations. The state of a virtual world is independent of the client applications that access it and may persist between user sessions. Within a VWRAP virtual environment, services may be deployed by multiple organizations having varying policies and trust domains. The VWRAP protocol will provide the mechanisms for these services to interoperate, when permitted by policy. The working group may document examples of policies applicable to a VWRAP environment. Foundational components of the protocol include the publication of: * an abstract type system, suitable for describing the application protocol in an implementation neutral manner, * a security model describing trust relationships between participating entities, * guidelines for the use of existing authentication and confidentiality mechanisms, * an application-layer protocol for establishing the user's avatar in a region, * an application-layer protocol for changing an avatar's position, including moving between regions, * format descriptions for objects and avatars, and * an application-layer protocol for identifying entities, and requesting information about them. The protocol defined by this group will carry information about the virtual environment, its contents and its inhabitants. It is an application layer protocol, independent of transport, based partially on these previously published internet drafts: * http://tools.ietf.org/html/draft-hamrick-ogp-intro * http://tools.ietf.org/html/draft-hamrick-llsd * http://tools.ietf.org/html/draft-hamrick-ogp-auth * http://tools.ietf.org/html/draft-hamrick-ogp-launch * http://tools.ietf.org/html/draft-lentczner-ogp-base * http://tools.ietf.org/html/draft-levine-ogp-clientcap * http://tools.ietf.org/html/draft-levine-ogp-layering The protocol should describe interaction semantics independent of transport, leveraging existing standards where practical. It should define interoperability expectations for server to server interactions as well as client-server interactions. Though the protocol is independent of transport, early interoperability trials used HTTP(S) for non-real-time messages. The working group will define specific features that must be replicated in other transports and will define the use of HTTP(S) as a transport of protocol messages. Internet-Drafts: No Current Internet-Drafts. Centralized Conferencing (xcon) ------------------------------- Charter Last Modified: 2009-11-12 Current Status: Active Working Group Chair(s): Alan Johnston Richard Barnes Real-time Applications and Infrastructure Area Director(s): Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: General Discussion:xcon@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/xcon Archive: http://www.ietf.org/mail-archive/web/xcon/index.html Description of Working Group: The focus of this working group is to develop a standardized suite of protocols for tightly-coupled multimedia conferences, where strong security and authorization requirements are integral to the solution. Tightly-coupled conferences have a central point of control and authorization (known as a focus) so they can enforce specific media and membership relationships, and provide an accurate roster of participants. The media mixing or combining function of a tightly- coupled conference need not be performed centrally, however. The scope of this effort is intentionally more narrow than previous attempts to standardize conferencing (e.g. centralized control), and is intended to enable interoperability in a commercial environment which already has a number of non-standard implementations using some of the protocols. Privacy, security, and authorization mechanisms are integral to the solution generated by the working group. This includes allowing participants to be invisible to all but the conference owner, or to be visible but participate anonymously with respect to some or all of the other participants. Authorization rules allow for participants and non-participants to have roles (ex: speaker, moderator, owner), and to be otherwise authorized to perform membership and media manipulation for or on behalf of other participants. In order to preserve these properties, the protocols used will require implementation of channel security and authentication services. Due to the centralized architecture of the WG, XCON's mechanisms will place requirements on the signaling protocol used between the focus and the participants. At a high level, the signaling protocol must be able to establish, tear down, modify, and perform call control operations on multimedia streams, including voice, video, and instant messaging, in both a centralized and distributed mixing architecture. SIP will be the reference session signaling protocol used for examples; however, none of the XCON solutions themselves will be signaling protocols, nor will XCON extend existing signaling protocols. Other signaling protocols than SIP may be used between the focus and participants, including non-IETF protocols, but the requirements and possible extensions needed for other signaling protocols to utilize the full functionality of the XCON architecture is outside the scope of XCON. The deliverables for the group will be: - A mechanism for membership and authorization control - A mechanism to manipulate and describe media "mixing" or "topology" for multiple media types (audio, video, text) - A mechanism for notification of conference related events/changes (for example a floor change) - A basic floor control protocol The initial set of protocols will be developed for use in unicast media conferences. The working group will perform a second round of work to enhance the set of protocols as necessary for use with multicast media after their initial publication. The following items are specifically out-of-scope: - Voting - Fully distributed conferences - Loosely-coupled conferences (no central point of control) - Far-end device control - Protocol used between the conference controller and the mixer(s) - Capabilities negotiation of the mixer(s) - Master-slave cascaded conferences The working group will coordinate closely with the SIPPING and MMUSIC working groups. In addition the working group will cooperate with other groups as needed, including SIP, MSEC, AVT, and the W3C SMIL working groups. In addition, the working group will consider a number of existing drafts as input to the working group. Description of Working Group: The focus of this working group is to develop a standardized suite of protocols for tightly-coupled multimedia conferences, where strong security and authorization requirements are integral to the solution. Tightly-coupled conferences have a central point of control and authorization (known as a focus) so they can enforce specific media and membership relationships, and provide an accurate roster of participants. The media mixing or combining function of a tightly- coupled conference need not be performed centrally, however. The scope of this effort is intentionally more narrow than previous attempts to standardize conferencing (e.g. centralized control), and is intended to enable interoperability in a commercial environment which already has a number of non-standard implementations using some of the protocols. Privacy, security, and authorization mechanisms are integral to the solution generated by the working group. This includes allowing participants to be invisible to all but the conference owner, or to be visible but participate anonymously with respect to some or all of the other participants. Authorization rules allow for participants and non-participants to have roles (ex: speaker, moderator, owner), and to be otherwise authorized to perform membership and media manipulation for or on behalf of other participants. In order to preserve these properties, the protocols used will require implementation of channel security and authentication services. Due to the centralized architecture of the WG, XCON's mechanisms will place requirements on the signaling protocol used between the focus and the participants. At a high level, the signaling protocol must be able to establish, tear down, modify, and perform call control operations on multimedia streams, including voice, video, and instant messaging, in both a centralized and distributed mixing architecture. SIP will be the reference session signaling protocol used for examples; however, none of the XCON solutions themselves will be signaling protocols, nor will XCON extend existing signaling protocols. Other signaling protocols than SIP may be used between the focus and participants, including non-IETF protocols, but the requirements and possible extensions needed for other signaling protocols to utilize the full functionality of the XCON architecture is outside the scope of XCON. The deliverables for the group will be: - A mechanism for membership and authorization control - A mechanism to manipulate and describe media "mixing" or "topology" for multiple media types (audio, video, text) - A mechanism for notification of conference related events/changes (for example a floor change) - A basic floor control protocol The initial set of protocols will be developed for use in unicast media conferences. The working group will perform a second round of work to enhance the set of protocols as necessary for use with multicast media after their initial publication. The following items are specifically out-of-scope: - Voting - Fully distributed conferences - Loosely-coupled conferences (no central point of control) - Far-end device control - Protocol used between the conference controller and the mixer(s) - Capabilities negotiation of the mixer(s) - Master-slave cascaded conferences The working group will coordinate closely with the SIPPING and MMUSIC working groups. In addition the working group will cooperate with other groups as needed, including SIP, MSEC, AVT, and the W3C SMIL working groups. In addition, the working group will consider a number of existing drafts as input to the working group. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Apr 2006 Nov 2009 Conference Information Data Model for Centralized Conferencing (XCON) Feb 2008 Sep 2008 Conference Event Package Data Format Extension for Centralized Conferencing (XCON) Jun 2008 Nov 2009 Centralized Conferencing Manipulation Protocol Jul 2009 Jul 2009 Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples Extensible Messaging and Presence Protocol (xmpp) ------------------------------------------------- Charter Last Modified: 2009-05-29 Current Status: Active Working Group Chair(s): Joe Hildebrand Sean Turner Real-time Applications and Infrastructure Area Director(s): Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: General Discussion:xmpp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/xmpp Archive: http://www.ietf.org/mail-archive/web/xmpp/ Description of Working Group: The Extensible Messaging and Presence Protocol (XMPP) is an technology for the near-real-time exchange of messages and presence notifications, where data is exchanged over Extensible Markup Language (XML) streams. The original XMPP working group published RFCs 3920-3923. Implementation and deployment experience since that time has resulted in errata, clarifications, and suggestions for improvement to the core XMPP specifications (RFCs 3920 and 3921). Some technologies on which XMPP depends (e.g., Transport Layer Security and the Simple Authentication and Security Layer) have undergone modifications of their own, which XMPP needs to track. Finally, the group needs to define a sustainable solution to internationalization of XMPP addresses, since the approach taken in RFC 3920 (based on stringprep profiles) is limited to Unicode 3.2 characters. Both draft-saintandre-rfc3920bis-* and draft-saintandre-rfc3921bis-* reflect community input so far regarding these modifications, but the group needs to complete this work, especially with regard to internationalization. Because of the scope of changes involved, it is envisioned that these specifications will be cycled at Proposed Standard. Although RFC 3923 defines an end-to-end signing and encryption technology for use by XMPP systems, to date it has not been implemented. A goal of the group is to develop an implementable method for end-to-end encryption, preferably based on well known and widely deployed security technologies. XMPP uses TLS for encryption and the Simple Authentication and Security Layer (SASL) for authentication. In the case of a server-to-server stream, XMPP is deployed using TLS and the SASL EXTERNAL mechanism, where each peer presents an X.509 certificate. This model introduces scaling challenges in multi-domain deployments because RFC 3920 requires that a stream cannot be reused for more than one domain, thus necessitating multiple TCP connections. The group will work to overcome these challenges by defining an optional mechanism for using a single connection with multiple identities. It is anticipated that most of the work will consist of defining and providing requirements to the TLS and SASL working groups. Many of the core and extended features of XMPP have also been implemented in technologies based on the Session Initiation Protocol (SIP). To ensure interworking between XMPP systems and SIP systems, a number of Internet-Drafts (draft-saintandre-sip-xmpp-*) have been produced. The group will define a framework within which this work could be completed. In completing its work, the group will strive to retain backwards compatibility with RFCs 3920 and 3921. However, changes that are not backwards compatible might be accepted if the group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. Description of Working Group: The Extensible Messaging and Presence Protocol (XMPP) is an technology for the near-real-time exchange of messages and presence notifications, where data is exchanged over Extensible Markup Language (XML) streams. The original XMPP working group published RFCs 3920-3923. Implementation and deployment experience since that time has resulted in errata, clarifications, and suggestions for improvement to the core XMPP specifications (RFCs 3920 and 3921). Some technologies on which XMPP depends (e.g., Transport Layer Security and the Simple Authentication and Security Layer) have undergone modifications of their own, which XMPP needs to track. Finally, the group needs to define a sustainable solution to internationalization of XMPP addresses, since the approach taken in RFC 3920 (based on stringprep profiles) is limited to Unicode 3.2 characters. Both draft-saintandre-rfc3920bis-* and draft-saintandre-rfc3921bis-* reflect community input so far regarding these modifications, but the group needs to complete this work, especially with regard to internationalization. Because of the scope of changes involved, it is envisioned that these specifications will be cycled at Proposed Standard. Although RFC 3923 defines an end-to-end signing and encryption technology for use by XMPP systems, to date it has not been implemented. A goal of the group is to develop an implementable method for end-to-end encryption, preferably based on well known and widely deployed security technologies. XMPP uses TLS for encryption and the Simple Authentication and Security Layer (SASL) for authentication. In the case of a server-to-server stream, XMPP is deployed using TLS and the SASL EXTERNAL mechanism, where each peer presents an X.509 certificate. This model introduces scaling challenges in multi-domain deployments because RFC 3920 requires that a stream cannot be reused for more than one domain, thus necessitating multiple TCP connections. The group will work to overcome these challenges by defining an optional mechanism for using a single connection with multiple identities. It is anticipated that most of the work will consist of defining and providing requirements to the TLS and SASL working groups. Many of the core and extended features of XMPP have also been implemented in technologies based on the Session Initiation Protocol (SIP). To ensure interworking between XMPP systems and SIP systems, a number of Internet-Drafts (draft-saintandre-sip-xmpp-*) have been produced. The group will define a framework within which this work could be completed. In completing its work, the group will strive to retain backwards compatibility with RFCs 3920 and 3921. However, changes that are not backwards compatible might be accepted if the group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jun 2009 Nov 2009 Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence Jun 2009 Nov 2009 Extensible Messaging and Presence Protocol (XMPP): Core Aug 2009 Aug 2009 Requirements for End-to-End Encryption in the Extensible Messaging and Presence Protocol (XMPP) Yet Another Mail (yam) ---------------------- Charter Last Modified: 2009-08-04 Current Status: Active Working Group Chair(s): Tony Hansen Chris Newman Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Alexey Melnikov Secretary(ies): S Moonesamy Mailing Lists: General Discussion:yam@ietf.org To Subscribe: yam-request@ietf.org In Body: in body 'subscribe' Archive: http://www.ietf.org/mail-archive/web/yam/index.html Description of Working Group: The Yet Another Mail (YAM) WG will revise existing Internet Mail specifications currently at Draft Standard to advance them to Full Standard. YAM will focus strictly on advancing email-related specifications for which the community already has some years of experience with deployment and interoperability. Its function is not to reopen or reconsider protocols - if a specification is found to need significant technical work, YAM will remove it from the WG's agenda. This charter's scope of work is the set of email-related RFCs that are currently at Draft Standard. Each document will be examined, along with its errata, and a recommendation made as to whether it is suitable for advancement to Full Standard. If it is not, the WG may recommend whether it should be republished at Draft Standard, moved to Historic, or recycled to Proposed Standard. However, any actual work to facilitate publication of a document at other than Full Standard is outside the WG's scope. If the WG cannot quickly reach consensus about further work on a document, it will drop the documents from its agenda without further comment or effort. The purpose of this working group is to work on protocols that are already recognized as effectively full standards, improving their written specifications to align with that status. The working group does not intend to revise the actual protocols in any way and will avoid document changes that might even accidentally introduce protocol changes, destabilize a protocol, or introduce semantic or syntactic changes. In particular, it will avoid adding new document sections that were not previously required and making BNF grammar changes that didn't originate from interoperability problems or difficulties in comprehension by implementors. If an existing protocol implementation is conforming to the Draft Standard version of the protocol specification, it must also be conforming to the resulting Full Standard version. Hence, specification changes that create a violation of this requirement are out of scope of the working group charter. On a case by case basis, substantive changes may be considered, if they will modify text to match existing conforming implementations -- that is, implementations that are already deployed with significant use. Specifically, such changes will be permitted to relax requirements or to fix BNF bugs where the intent is and has been clear. The WG will consult with the IESG about proposed changes before it starts working on them. Once the document is done by the WG, approval proceeds using the normal IETF approval process. The two step approach is proposed in order to save both IESG and WG time and to avoid late surprises when a document is considered done by the WG. After the tasks of this charter are completed, the WG will consider rechartering to move selected mature specifications that are still at Proposed Standard to higher maturity levels, or to work on those documents previously identified as needing to be republished at Draft Standard or Proposed Standard. The underpinnings of this WG effort are: (1) Wide deployment and use of interoperable implementations of an existing standards-track protocol demonstrates a presumption that the existing specification is adequate. The burden of demonstrating the contrary lies with those who believe that they see significant technical or documentation defects. (2) It is generally in the best interest of the IETF and the Internet community to see specifications of mature protocols advance on the standards track, eliminating any uncertainty as to whether the protocols have been adequately understood and tested. To that end, YAM will avoid modification of documents simply to adjust them to match contemporary IETF notational or linguistic norms. Obviously, updating of references, boilerplate, and the equivalent are exceptions to this, but success in the WG requires that there be a good-faith commitment by both its participants and the IESG to avoid seeking changes that (a) do not contribute in a substantial and substantive way to the quality and comprehensibility of the specification, or that (b) force a change to the existing protocol. The steps to be followed by the WG are, approximately: o The WG will start work by analyzing the following email related documents which are currently Draft Standards, removing any that have significant technical defects or whose advancement may be controversial under the advancement criteria specified in RFC 2026: RFC 1652 8BITMIME RFC 1864 Content-MD5 RFC 2045, 2046, 2047, 2049 MIME base specs RFC 3282 Content-language RFC 3461 DSNs RFC 3462 Multipart/Report RFC 3463 Enhanced Status Codes RFC 3464 Message Format for DSNs RFC 3798 Message Disposition Notification RFC 4409 Message Submission RFC 5321 SMTP RFC 5322 Internet Message Format o Form review and editing teams for each document to be advanced. o Formulate a list of proposed changes (stated in general terms, rather than specific wording). o Obtain WG consensus and consult with IESG on these changes. o Post I-Ds for WG consideration and consensus formation. o Recommend resulting documents to IESG for publication processing. o Rinse and repeat. Description of Working Group: The Yet Another Mail (YAM) WG will revise existing Internet Mail specifications currently at Draft Standard to advance them to Full Standard. YAM will focus strictly on advancing email-related specifications for which the community already has some years of experience with deployment and interoperability. Its function is not to reopen or reconsider protocols - if a specification is found to need significant technical work, YAM will remove it from the WG's agenda. This charter's scope of work is the set of email-related RFCs that are currently at Draft Standard. Each document will be examined, along with its errata, and a recommendation made as to whether it is suitable for advancement to Full Standard. If it is not, the WG may recommend whether it should be republished at Draft Standard, moved to Historic, or recycled to Proposed Standard. However, any actual work to facilitate publication of a document at other than Full Standard is outside the WG's scope. If the WG cannot quickly reach consensus about further work on a document, it will drop the documents from its agenda without further comment or effort. The purpose of this working group is to work on protocols that are already recognized as effectively full standards, improving their written specifications to align with that status. The working group does not intend to revise the actual protocols in any way and will avoid document changes that might even accidentally introduce protocol changes, destabilize a protocol, or introduce semantic or syntactic changes. In particular, it will avoid adding new document sections that were not previously required and making BNF grammar changes that didn't originate from interoperability problems or difficulties in comprehension by implementors. If an existing protocol implementation is conforming to the Draft Standard version of the protocol specification, it must also be conforming to the resulting Full Standard version. Hence, specification changes that create a violation of this requirement are out of scope of the working group charter. On a case by case basis, substantive changes may be considered, if they will modify text to match existing conforming implementations -- that is, implementations that are already deployed with significant use. Specifically, such changes will be permitted to relax requirements or to fix BNF bugs where the intent is and has been clear. The WG will consult with the IESG about proposed changes before it starts working on them. Once the document is done by the WG, approval proceeds using the normal IETF approval process. The two step approach is proposed in order to save both IESG and WG time and to avoid late surprises when a document is considered done by the WG. After the tasks of this charter are completed, the WG will consider rechartering to move selected mature specifications that are still at Proposed Standard to higher maturity levels, or to work on those documents previously identified as needing to be republished at Draft Standard or Proposed Standard. The underpinnings of this WG effort are: (1) Wide deployment and use of interoperable implementations of an existing standards-track protocol demonstrates a presumption that the existing specification is adequate. The burden of demonstrating the contrary lies with those who believe that they see significant technical or documentation defects. (2) It is generally in the best interest of the IETF and the Internet community to see specifications of mature protocols advance on the standards track, eliminating any uncertainty as to whether the protocols have been adequately understood and tested. To that end, YAM will avoid modification of documents simply to adjust them to match contemporary IETF notational or linguistic norms. Obviously, updating of references, boilerplate, and the equivalent are exceptions to this, but success in the WG requires that there be a good-faith commitment by both its participants and the IESG to avoid seeking changes that (a) do not contribute in a substantial and substantive way to the quality and comprehensibility of the specification, or that (b) force a change to the existing protocol. The steps to be followed by the WG are, approximately: o The WG will start work by analyzing the following email related documents which are currently Draft Standards, removing any that have significant technical defects or whose advancement may be controversial under the advancement criteria specified in RFC 2026: RFC 1652 8BITMIME RFC 1864 Content-MD5 RFC 2045, 2046, 2047, 2049 MIME base specs RFC 3282 Content-language RFC 3461 DSNs RFC 3462 Multipart/Report RFC 3463 Enhanced Status Codes RFC 3464 Message Format for DSNs RFC 3798 Message Disposition Notification RFC 4409 Message Submission RFC 5321 SMTP RFC 5322 Internet Message Format o Form review and editing teams for each document to be advanced. o Formulate a list of proposed changes (stated in general terms, rather than specific wording). o Obtain WG consensus and consult with IESG on these changes. o Post I-Ds for WG consideration and consensus formation. o Recommend resulting documents to IESG for publication processing. o Rinse and repeat. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Aug 2009 Nov 2009 Preliminary Evaluation of RFC XXX "[PLACEHOLDER: INSERT TITLE HERE]", for advancement from Draft Standard to Full Standard by the YAM Working Group Aug 2009 Aug 2009 Preliminary Evaluation of RFC 1652 for Advancement to Full Standard Nov 2009 Nov 2009 Preliminary Evaluation of RFC5321, Simple Mail Transfer Protocol (SMTP), for advancement from Draft Standard to Full Standard by the YAM Working Group