16ng 6lowpan adslmib ancp atompub autoconf avt behave bfd bmwg btns calsify capwap ccamp crisp dccp dhc dime dkim dna dnsext dnsop eai eap ecrit emu enum fecframe forces geopriv grow hip hokey hubmib idr ieprep imapext imss ipcdn ipdvb ipfix iporpr ippm ipr ips iptel ipv6 isis isms keyprov kitten krb-wg l1vpn l2tpext l2vpn l3vpn lemonade ltans ltru magma manet mboned midcom mip4 mip6 mipshop mmusic monami6 mpls msec multi6 nea nemo netconf netlmm nfsv4 nsis ntp openpgp opes opsec ospf p2psip pana pce pcn pim pki4ipsec pkix pmtud pppext psamp pwe3 radext rddp rmt rohc rpsec rserpool rtgwg sasl shim6 sidr sieve sigtran simple sip sipping smime softwire speechsc speermint syslog tcpm tls trill tsvwg usefor v6ops vrrp widex xcon IP over IEEE 802.16 Networks (16ng) ----------------------------------- Charter Last Modified: 2007-01-22 Current Status: Active Working Group Chair(s): Gabriel Montenegro Soohong Daniel Park Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Technical Advisor(s): Maximilian Riegel Dave Thaler Secretary(ies): Jihoon Lee Mailing Lists: General Discussion:16ng@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/16ng Archive: http://www1.ietf.org/mail-archive/web/16ng/current/index.html 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 ------ ------- -------------------------------------------- Oct 2006 Feb 2007 Analysis of IPv6 Link Models for 802.16 based Networks Oct 2006 Feb 2007 IP over 802.16 Problem Statement and Goals Oct 2006 Mar 2007 IPv6 Over the IP Specific part of the Packet Convergence sublayer in 802.16 Networks Dec 2006 Mar 2007 Transmission of IP over Ethernet over IEEE 802.16 Networks IPv6 over Low power WPAN (6lowpan) ---------------------------------- Charter Last Modified: 2006-09-27 Current Status: Active Working Group Chair(s): Carsten Bormann Geoffrey Mulligan Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Mark Townsley Secretary(ies): Christian Schumacher Mailing Lists: General Discussion:6lowpan@lists.ietf.org To Subscribe: 6lowpan-request@lists.ietf.org In Body: subscribe Archive: https://www1.ietf.org/mailman/listinfo/6lowpan Description of Working Group: Background/Introduction: Note: Given that there is not much precedent for this type of activity at the IETF, the text that follows is of an introductory nature. Hence, its objective is to give a general idea of the application area and motivations for the work. In particular, this section is not to be construed as detailing work items for the working group. That is done in the following section entitled "Scope of the Working Group." 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 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) * Robustness and simplicity in routing or network fabric 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 ZigBee alliance, for example, is currently studying what such a work item might entail). The working group is expected to coordinate and interact with such groups. The required work includes items in the following (incomplete) list: * IP adaptation/Packet Formats and interoperability * Addressing schemes and address management * Network management * Routing in dynamically adaptive topologies * Security, including set-up and maintenance * Application programming interface * Discovery (of devices, of services, etc) * Implementation considerations Whereas at least some of the above items are within the purview of the IETF, at this point it is not clear that all of them are. Accordingly, the 6LoWPAN working group will address a reduced, more focused set of objectives. Scope of 6lowpan: Produce "Problems Statement, Assumptions and Goals for IPv6 for LoWPANs" (draft-ietf-lowpan-goals-assumptions-xx.txt) to define the problem statement and goals of 6lowpan networks. Produce "Transmission of IPv6 Packets over IEEE 802.15.4 WPAN Networks" (draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt) to define the basic packet formats and sub-IP adaptation layer for transmission of IPv6 packets over IEEE 802.15.4. This includes framing, adaptation, header compression and address generation. Furthermore, IEEE 802.15.4 devices are expected to be deployed in mesh topologies. As such, the working group may also work on an informational document to show how to apply an existing MANET protocol to LoWPANs (e.g., AODV, OLSR, DYMO, etc). The working group will reuse existing specifications whenever reasonable and possible. The working group will also serve as a venue for ongoing discussions on other topics related to the more complete list outlined above. Additional related milestones may be added in the future via a rechartering operation. Note: As may be obvious from its official name above, this particular working group will not work on IPv4 over IEEE 802.15.4 specifications. Given the limitations of the target devices, dual-stack deployments are not practical. Because of its higher potential for header compression, its support for the huge number of devices expected and of cleanly built-in features such as address autoconfiguration, IPv6 is the exclusive focus of the working group. Description of Working Group: Background/Introduction: Note: Given that there is not much precedent for this type of activity at the IETF, the text that follows is of an introductory nature. Hence, its objective is to give a general idea of the application area and motivations for the work. In particular, this section is not to be construed as detailing work items for the working group. That is done in the following section entitled "Scope of the Working Group." 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 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) * Robustness and simplicity in routing or network fabric 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 ZigBee alliance, for example, is currently studying what such a work item might entail). The working group is expected to coordinate and interact with such groups. The required work includes items in the following (incomplete) list: * IP adaptation/Packet Formats and interoperability * Addressing schemes and address management * Network management * Routing in dynamically adaptive topologies * Security, including set-up and maintenance * Application programming interface * Discovery (of devices, of services, etc) * Implementation considerations Whereas at least some of the above items are within the purview of the IETF, at this point it is not clear that all of them are. Accordingly, the 6LoWPAN working group will address a reduced, more focused set of objectives. Scope of 6lowpan: Produce "Problems Statement, Assumptions and Goals for IPv6 for LoWPANs" (draft-ietf-lowpan-goals-assumptions-xx.txt) to define the problem statement and goals of 6lowpan networks. Produce "Transmission of IPv6 Packets over IEEE 802.15.4 WPAN Networks" (draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt) to define the basic packet formats and sub-IP adaptation layer for transmission of IPv6 packets over IEEE 802.15.4. This includes framing, adaptation, header compression and address generation. Furthermore, IEEE 802.15.4 devices are expected to be deployed in mesh topologies. As such, the working group may also work on an informational document to show how to apply an existing MANET protocol to LoWPANs (e.g., AODV, OLSR, DYMO, etc). The working group will reuse existing specifications whenever reasonable and possible. The working group will also serve as a venue for ongoing discussions on other topics related to the more complete list outlined above. Additional related milestones may be added in the future via a rechartering operation. Note: As may be obvious from its official name above, this particular working group will not work on IPv4 over IEEE 802.15.4 specifications. Given the limitations of the target devices, dual-stack deployments are not practical. Because of its higher potential for header compression, its support for the huge number of devices expected and of cleanly built-in features such as address autoconfiguration, IPv6 is the exclusive focus of the working group. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jun 2005 Mar 2007 Transmission of IPv6 Packets over IEEE 802.15.4 Networks Jul 2005 Mar 2007 6LoWPAN: Overview, Assumptions, Problem Statement and Goals ADSL MIB (adslmib) ------------------ Charter Last Modified: 2006-10-05 Current Status: Active Working Group Chair(s): Michael Sneed Menachem Dodge Operations and Management Area Director(s): Dan Romascanu David Kessens 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://www1.ietf.org/mailman/listinfo/adslmib Archive: http://www.ietf.org/mail-archive/web/adslmib/index.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 ------ ------- -------------------------------------------- Feb 2006 Feb 2007 Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2) Feb 2007 Feb 2007 xDSL multi-pair bonding (G.Bond) MIB Access Node Control Protocol (ancp) ----------------------------------- Charter Last Modified: 2006-12-15 Current Status: Active Working Group Chair(s): Matthew Bocci Wojciech Dec Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Mark Townsley 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/index.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) 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 acess loop connections from Subscribers. In DSL, this is often referred to as a Digital Subscriber Line Access Multiplexer (DSLAM) Network Access Server (NAS) - Network device which aggregates multiplexedSubscriber traffic from a number of Access Nodes. The NAS plays a central role in per-subsciber policy enforcement and QoS. Often referred to as an 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 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, over a DSL access and aggregation network. 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 DSL 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 Scalabilty: 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 the management framewoirk 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 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) 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 acess loop connections from Subscribers. In DSL, this is often referred to as a Digital Subscriber Line Access Multiplexer (DSLAM) Network Access Server (NAS) - Network device which aggregates multiplexedSubscriber traffic from a number of Access Nodes. The NAS plays a central role in per-subsciber policy enforcement and QoS. Often referred to as an 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 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, over a DSL access and aggregation network. 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 DSL 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 Scalabilty: 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 the management framewoirk 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 work, and with IEEE 802.1ag. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2006 Feb 2007 Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks Jan 2007 Jan 2007 Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) Mar 2007 Mar 2007 Protocol for Access Node Control Mechanism in Broadband Networks Atom Publishing Format and Protocol (atompub) --------------------------------------------- Charter Last Modified: 2006-03-24 Current Status: Active Working Group Chair(s): Paul Hoffman Tim Bray Applications Area Director(s): Ted Hardie Lisa Dusseault Applications Area Advisor: Lisa Dusseault Secretary(ies): Sam Ruby Mailing Lists: General Discussion:atom-syntax@imc.org To Subscribe: atom-syntax-request@imc.org In Body: In Body: subscribe Archive: http://www.imc.org/atom-syntax/mail-archive/ Description of Working Group: Atom defines a feed format for representing and a protocol for editing Web resources such as Weblogs, online journals, Wikis, and similar content. The feed format enables syndication; that is, provision of a channel of information by representing multiple resources in a single document. The editing protocol enables agents to interact with resources by nominating a way of using existing Web standards in a pattern. Atom consists of: * A conceptual model of a resource * A concrete syntax for this model * A syndication and archiving format (the Atom feed format) using this syntax * An editing protocol using this syntax The format must be able to represent: * a resource that is a Weblog entry or article (e.g., it has an author, date, identifier, and content) * a feed or channel of entries, with or without enclosed content * a complete archive of all entries in a feed * existing well-formed XML (especially XHTML) content * additional information in an user-extensible manner The editing protocol must enable: * creating, editing, and deleting feed entries * multiple authors for a feed * multiple subjects or categories in a feed * user authentication * adding, editing, and deleting users * setting and getting user preferences * creating, getting and setting related resources such as comments, templates, etc. The working group will use experience gained with RSS (variably used as a name by itself and as an acronym for "RDF Site Summary", "Rich Site Summary", or "Really Simple Syndication") as the basis for a standards-track document specifying the model, syntax, and feed format. The feed format and HTTP will be used as the basis of work on a standards-track document specifying the editing protocol. The goal for the working group is to produce a single feed format and a single editing protocol; the working group will only consider additional formats or additional protocols if those charter changes are approved by the IESG. The working group will also take steps to ensure interoperability, by: * unambiguously identifying required elements in formats * clearly nominating conformance levels for different types of software * providing clear extensibility mechanisms and constraints upon them The Atom protocol will be designed to provide security services for updating and accessing dynamic online resources. The working group will consider current known issues with requirements for remote access, along with the fact that many such resources are constrained by providers who provide the resource owners with little configuration control. The working group's primary focus will be on delivering an interoperable format and corresponding protocol; it is expected that all but the most basic, generic metadata and functions will be accommodated through extensions, rather than in the core documents. Extension development is not included in this charter. The working group will consider the need to either close or to modify the charter and document extensions once the core document set has been approved by the IESG. The working group has two mailing lists: atom-syntax@imc.org for discussing the Atom format and atom-protocol@imc.org for discussing the protocol. Description of Working Group: Atom defines a feed format for representing and a protocol for editing Web resources such as Weblogs, online journals, Wikis, and similar content. The feed format enables syndication; that is, provision of a channel of information by representing multiple resources in a single document. The editing protocol enables agents to interact with resources by nominating a way of using existing Web standards in a pattern. Atom consists of: * A conceptual model of a resource * A concrete syntax for this model * A syndication and archiving format (the Atom feed format) using this syntax * An editing protocol using this syntax The format must be able to represent: * a resource that is a Weblog entry or article (e.g., it has an author, date, identifier, and content) * a feed or channel of entries, with or without enclosed content * a complete archive of all entries in a feed * existing well-formed XML (especially XHTML) content * additional information in an user-extensible manner The editing protocol must enable: * creating, editing, and deleting feed entries * multiple authors for a feed * multiple subjects or categories in a feed * user authentication * adding, editing, and deleting users * setting and getting user preferences * creating, getting and setting related resources such as comments, templates, etc. The working group will use experience gained with RSS (variably used as a name by itself and as an acronym for "RDF Site Summary", "Rich Site Summary", or "Really Simple Syndication") as the basis for a standards-track document specifying the model, syntax, and feed format. The feed format and HTTP will be used as the basis of work on a standards-track document specifying the editing protocol. The goal for the working group is to produce a single feed format and a single editing protocol; the working group will only consider additional formats or additional protocols if those charter changes are approved by the IESG. The working group will also take steps to ensure interoperability, by: * unambiguously identifying required elements in formats * clearly nominating conformance levels for different types of software * providing clear extensibility mechanisms and constraints upon them The Atom protocol will be designed to provide security services for updating and accessing dynamic online resources. The working group will consider current known issues with requirements for remote access, along with the fact that many such resources are constrained by providers who provide the resource owners with little configuration control. The working group's primary focus will be on delivering an interoperable format and corresponding protocol; it is expected that all but the most basic, generic metadata and functions will be accommodated through extensions, rather than in the core documents. Extension development is not included in this charter. The working group will consider the need to either close or to modify the charter and document extensions once the core document set has been approved by the IESG. The working group has two mailing lists: atom-syntax@imc.org for discussing the Atom format and atom-protocol@imc.org for discussing the protocol. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2004 Mar 2007 The Atom Publishing Protocol Jan 2007 Jan 2007 The application/atom+xml Type Parameter Ad-Hoc Network Autoconfiguration (autoconf) ------------------------------------------- Charter Last Modified: 2006-12-18 Current Status: Active Working Group Chair(s): Thomas Clausen Shubhranshu Singh Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:autoconf@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/autoconf Archive: http://www.ietf.org/mail-archive/web/autoconf/current/index.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, a MANET presents itself as a L3 multi-hop network formed over a collection of links. Thus, each ad hoc node in the MANET is, potentially, acting as a L3 router in order to provide connectivity to other nodes within the MANET. Each ad hoc node maintains host routes to other ad hoc nodes within the MANET - in addition to network routes to destinations outside the MANET. If connected to the Internet, MANETs are edge networks, i.e. their boundary is defined by their edge routers. Due to the nature of the links over which a MANET is formed, ad hoc nodes within a MANET do not share access to a single multicast-capable link for signaling. This implies that the usual delivery semantics of link-local multicast and broadcast are not preserved within a MANET. The address autoconfiguration related protocol specifications such as RFCs 2462, 2461, as used in traditional IP networks, assume that subnet-local signals (e.g. link-local multicast signals) are received by each of the hosts on the particular subnet without being forwarded by the routers defining the subnet boundary. Hence, ad hoc networks (as defined and understood by the IETF MANET WG) cannot use these protocol specifications as-is. The main purpose of the AUTOCONF WG is to standardize mechanisms to be used by ad hoc nodes for configuring unique local and/or globally routable IPv6 addresses. The ad hoc nodes under consideration are, once configured, expected to be able to support multi-hop communication by running MANET routing protocols as developed by the IETF MANET WG. An AUTOCONF mechanism should not be dependent on any specific MANET routing protocol, however the routing protocol may provide for optimizations. With this in mind, the goals of AUTOCONF WG are to: - Produce a "MANET architecture" document defining the MANET architecture as is related to IP networks and the Internet. - Produce a "terminology and problem statement" document, defining the problem statement and goals for AUTOCONF. - Develop an IPv6 address autoconfiguration mechanism to be used by ad hoc nodes for configuring unique local addresses as well as, in cases where Internet connectivity exists, globally routable unique addresses. - Develop a mechanism to promote configured address uniqueness in the situation where different ad hoc networks merge. Issues and requirements related to prefix and/or address providing entities, such as an Internet gateway, will be addressed within the group to the extent that they are directly related to the AUTOCONF mechanisms. Security concerns related to AUTOCONF mechanisms will also be discussed within the group. The working group will reuse existing specifications whenever reasonable and possible. 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, a MANET presents itself as a L3 multi-hop network formed over a collection of links. Thus, each ad hoc node in the MANET is, potentially, acting as a L3 router in order to provide connectivity to other nodes within the MANET. Each ad hoc node maintains host routes to other ad hoc nodes within the MANET - in addition to network routes to destinations outside the MANET. If connected to the Internet, MANETs are edge networks, i.e. their boundary is defined by their edge routers. Due to the nature of the links over which a MANET is formed, ad hoc nodes within a MANET do not share access to a single multicast-capable link for signaling. This implies that the usual delivery semantics of link-local multicast and broadcast are not preserved within a MANET. The address autoconfiguration related protocol specifications such as RFCs 2462, 2461, as used in traditional IP networks, assume that subnet-local signals (e.g. link-local multicast signals) are received by each of the hosts on the particular subnet without being forwarded by the routers defining the subnet boundary. Hence, ad hoc networks (as defined and understood by the IETF MANET WG) cannot use these protocol specifications as-is. The main purpose of the AUTOCONF WG is to standardize mechanisms to be used by ad hoc nodes for configuring unique local and/or globally routable IPv6 addresses. The ad hoc nodes under consideration are, once configured, expected to be able to support multi-hop communication by running MANET routing protocols as developed by the IETF MANET WG. An AUTOCONF mechanism should not be dependent on any specific MANET routing protocol, however the routing protocol may provide for optimizations. With this in mind, the goals of AUTOCONF WG are to: - Produce a "MANET architecture" document defining the MANET architecture as is related to IP networks and the Internet. - Produce a "terminology and problem statement" document, defining the problem statement and goals for AUTOCONF. - Develop an IPv6 address autoconfiguration mechanism to be used by ad hoc nodes for configuring unique local addresses as well as, in cases where Internet connectivity exists, globally routable unique addresses. - Develop a mechanism to promote configured address uniqueness in the situation where different ad hoc networks merge. Issues and requirements related to prefix and/or address providing entities, such as an Internet gateway, will be addressed within the group to the extent that they are directly related to the AUTOCONF mechanisms. Security concerns related to AUTOCONF mechanisms will also be discussed within the group. The working group will reuse existing specifications whenever reasonable and possible. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2007 Mar 2007 Mobile Ad hoc Network Architecture Audio/Video Transport (avt) --------------------------- Charter Last Modified: 2007-01-11 Current Status: Active Working Group Chair(s): Colin Perkins Tom Taylor Roni Even Real-time Applications and Infrastructure Area Director(s): Jon Peterson Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Cullen Jennings Mailing Lists: General Discussion:avt@ietf.org To Subscribe: https://www1.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 centralized 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 signaling information anyway necessary for the establishment of the session. 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 centralized 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 signaling information anyway necessary for the establishment of the session. 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 ------ ------- -------------------------------------------- Nov 2000 Jan 2007 RTP Payload Format for Generic Forward Error Correction Feb 2002 Oct 2006 RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback May 2002 Nov 2006 RTP Payload Format for JPEG 2000 Video Streams Oct 2003 Mar 2007 Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF) Jun 2004 Mar 2007 RTP Profile for TCP Friendly Rate Control Aug 2004 Dec 2006 RTP Payload Format for ATRAC Family Oct 2004 Sep 2006 RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs Feb 2005 Jan 2007 Definition of Events For Channel-Oriented Telephony Signalling Aug 2005 Feb 2007 Protocol Extensions for Header Compression over MPLS Aug 2005 Feb 2007 Associating Time-codes with RTP streams Aug 2005 Mar 2007 A general mechanism for RTP Header Extensions Aug 2005 Jan 2007 RTP Payload Format for ITU-T Recommendation G.722.1 May 2006 Dec 2006 How to Write an RTP Payload Format Aug 2006 Feb 2007 Transmission Time offsets in RTP streams Aug 2006 Feb 2007 RTP Topologies Aug 2006 Mar 2007 Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) Oct 2006 Mar 2007 Multiplexing RTP Data and Control Packets on a Single Port Dec 2006 Dec 2006 RTCP XR - IP Video Metrics Report Blocks Dec 2006 Mar 2007 RTP Payload Format for SVC Video Jan 2007 Mar 2007 RTP Payload Format for MIDI Jan 2007 Jan 2007 RTP payload format for EVRC-WB codec and MIME updates for EVRC-B codec Feb 2007 Feb 2007 RTCP HR - High Resolution VoIP Metrics Report Blocks Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- Charter Last Modified: 2007-02-28 Current Status: Active Working Group Chair(s): Dan Wing 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://www1.ietf.org/mail-archive/web/behave/current/index.html Description of Working Group: Given the current near-universal deployment of NATs (Network Address Translators) in the public Internet, the lack of standards for NAT behavior has given rise to a crisis. While it is widely acknowledged that NATs create problems for numerous Internet applications, our inability to describe precisely what a NAT is or how it behaves leaves us few solutions for compensating for the presence of NATs. The behavior of NATs varies dramatically 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 interactive applications such as multiuser games and interactive multimedia. NATs continue to proliferate and have seen an increasing rate of deployment. IPv6 deployments can eliminate this problem, but there is a significant interim period in which applications will need to work both in IPv4 NAT environments and with the IPv6 to IPv4 transition mechanisms. This working group proposes to generate requirements documents and best current practices to enable NATs to function in as deterministic a fashion as possible. It will consider what is broken by these devices and document approaches for characterizing and testing them. The NAT behavior practices will be application independent. The group will also advise on how to develop applications that discover and reliably function in environments with NATs that follow the best current practices identified by this working group. This will include the development of protocol-independent toolkits usable by application protocols for NAT traversal. This will include a revision of RFC 3489 for NAT binding discovery and a relay protocol that focuses on security. The work will be done with the goal of encouraging eventual migration to IPv6 and compliance with the UNSAF [RFC 3424] considerations. It will not encourage the proliferation of NATs. The behavior that will be considered includes IP fragmentation and parameters that impact ICMP, UDP, TCP, IGMP, MLD, and multicast. The proposed WG will coordinate with v6ops, midcom and nsis. The work is largely limited to examining various approaches that are already in use today and providing suggestions about which ones are likely to work best in the internet architecture. Description of Working Group: Given the current near-universal deployment of NATs (Network Address Translators) in the public Internet, the lack of standards for NAT behavior has given rise to a crisis. While it is widely acknowledged that NATs create problems for numerous Internet applications, our inability to describe precisely what a NAT is or how it behaves leaves us few solutions for compensating for the presence of NATs. The behavior of NATs varies dramatically 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 interactive applications such as multiuser games and interactive multimedia. NATs continue to proliferate and have seen an increasing rate of deployment. IPv6 deployments can eliminate this problem, but there is a significant interim period in which applications will need to work both in IPv4 NAT environments and with the IPv6 to IPv4 transition mechanisms. This working group proposes to generate requirements documents and best current practices to enable NATs to function in as deterministic a fashion as possible. It will consider what is broken by these devices and document approaches for characterizing and testing them. The NAT behavior practices will be application independent. The group will also advise on how to develop applications that discover and reliably function in environments with NATs that follow the best current practices identified by this working group. This will include the development of protocol-independent toolkits usable by application protocols for NAT traversal. This will include a revision of RFC 3489 for NAT binding discovery and a relay protocol that focuses on security. The work will be done with the goal of encouraging eventual migration to IPv6 and compliance with the UNSAF [RFC 3424] considerations. It will not encourage the proliferation of NATs. The behavior that will be considered includes IP fragmentation and parameters that impact ICMP, UDP, TCP, IGMP, MLD, and multicast. The proposed WG will coordinate with v6ops, midcom and nsis. The work is largely limited to examining various approaches that are already in use today and providing suggestions about which ones are likely to work best in the internet architecture. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2004 Mar 2007 Session Traversal Utilities for (NAT) (STUN) May 2005 Oct 2006 Network Address Port Translator (NAPT) Any-Source Multicast Requirement Feb 2006 Feb 2007 NAT Behavioral Requirements for TCP Mar 2006 Mar 2007 Obtaining Relay Addresses from Simple Traversal Underneath NAT (STUN) Mar 2006 Nov 2006 Extension to the Simple Traversal Underneath NAT (STUN) Relay Usage for IPv4/IPv6 Transition May 2006 Mar 2007 NAT Behavioral Requirements for ICMP protocol Oct 2006 Feb 2007 State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs) Feb 2007 Feb 2007 NAT Behavior Discovery Using STUN Bidirectional Forwarding Detection (bfd) ---------------------------------------- Charter Last Modified: 2006-03-24 Current Status: Active Working Group Chair(s): David Ward Jeffrey Haas Routing Area Director(s): Ross Callon Bill Fenner Routing Area Advisor: Bill Fenner 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: ftp://ftp.ietf.org/ietf-mail-archive/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 ------ ------- -------------------------------------------- Jun 2004 Oct 2006 Bidirectional Forwarding Detection Management Information Base Jul 2004 Mar 2007 BFD For MPLS LSPs Jul 2004 Mar 2007 Bidirectional Forwarding Detection Jul 2004 Mar 2007 BFD for Multihop Paths Jul 2004 Mar 2007 BFD for IPv4 and IPv6 (Single Hop) Jul 2005 Mar 2007 Generic Application of BFD Benchmarking Methodology (bmwg) ------------------------------- Charter Last Modified: 2006-12-18 Current Status: Active Working Group Chair(s): Al Morton Operations and Management Area Director(s): Dan Romascanu David Kessens Operations and Management Area Advisor: David Kessens 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 internetworking technologies. 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 internetworking technologies. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2001 Feb 2007 Benchmarking Terminology for Resource Reservation Capable Routers Jun 2003 Mar 2007 Benchmarking Methodology for IGP Data Plane Route Convergence Jun 2003 Mar 2007 Terminology for Benchmarking IGP Data Plane Route Convergence Jun 2003 Mar 2007 Considerations for Benchmarking IGP Data Plane Route Convergence Jun 2003 Mar 2007 Terminology for Accelerated Stress Benchmarking Jul 2004 Jan 2007 Hash and Stuffing: Overlooked Factors in Network Device Benchmarking Jul 2004 Mar 2007 Methodology Guidelines for Accelerated Stress Benchmarking Oct 2006 Mar 2007 Benchmarking Terminology for Protection Performance Oct 2006 Mar 2007 Methodology for benchmarking MPLS Protection mechanisms Jan 2007 Feb 2007 IPv6 Benchmarking Methodology Better-Than-Nothing Security (btns) ----------------------------------- Charter Last Modified: 2007-01-11 Current Status: Active Working Group Chair(s): Julien Laganier Love Hörnqvist-Åstrand Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Sam Hartman Mailing Lists: General Discussion:anonsec@postel.org To Subscribe: http://www.postel.org/anonsec Archive: http://www.postel.org/anonsec 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: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2005 Feb 2007 Problem and Applicability Statement for Better Than Nothing Security (BTNS) Feb 2006 Mar 2007 Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec Feb 2006 Mar 2007 IPsec Channels: Connection Latching Calendaring and Scheduling Standards Simplification (calsify) ------------------------------------------------------------- Charter Last Modified: 2006-07-26 Current Status: Active Working Group Chair(s): Eliot Lear Aki Niemi Applications Area Director(s): Ted Hardie Lisa Dusseault 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 Feb 2007 iCalendar Message-Based Interoperability Protocol (iMIP) Oct 2005 Mar 2007 iCalendar Transport-Independent Interoperability Protocol (iTIP) Oct 2005 Mar 2007 Internet Calendaring and Scheduling Core Object Specification (iCalendar) Control And Provisioning of Wireless Access Points (capwap) ----------------------------------------------------------- Charter Last Modified: 2006-12-06 Current Status: Active Working Group Chair(s): Margaret Wasserman Mahalingam Mani Dorothy Gellert Operations and Management Area Director(s): Dan Romascanu David Kessens Operations and Management Area Advisor: Dan Romascanu Technical Advisor(s): 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 2004 Mar 2007 Light Weight Access Point Protocol Mar 2005 Feb 2007 Wireless LAN Control Protocol (WiCoP) Apr 2005 Mar 2006 SLAPP : Secure Light Access Point Protocol Mar 2006 Mar 2007 CAPWAP Protocol Specification Oct 2006 Mar 2007 CAPWAP Protocol Binding for IEEE 802.11 Feb 2007 Feb 2007 CAPWAP Threat Analysis for 802.11 Deployments Common Control and Measurement Plane (ccamp) -------------------------------------------- Charter Last Modified: 2007-03-12 Current Status: Active Working Group Chair(s): Adrian Farrel Deborah Brungard Routing Area Director(s): Ross Callon Bill Fenner Routing Area Advisor: Ross Callon Technical Advisor(s): Alex Zinin Mailing Lists: General Discussion:ccamp@ops.ietf.org To Subscribe: majordomo@ops.ietf.org In Body: subscribe ccamp Archive: https://ops.ietf.org/lists/ccamp 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, ATM and Frame Relay switches, MPLS, GRE, 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 MIB modules and other OAM techniques relevant to the protocols and extensions specified within the WG. 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 ASON are not currently met by protocols defined in CCAMP; based on these, define mechanisms to address these requirements. - Document issues and strategies for the migration of MPLS-based deployments to GMPLS. Based on the outcome, identify protocol machinery that implementations may have to change to ease the migration from MPLS to GMPLS. In doing this work, the WG will work closely with at least the following other WGs: MPLS, ISIS, OSPF, IDR, L1VPN and PCE. The WG will also cooperate with the ITU-T. 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, ATM and Frame Relay switches, MPLS, GRE, 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 MIB modules and other OAM techniques relevant to the protocols and extensions specified within the WG. 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 ASON are not currently met by protocols defined in CCAMP; based on these, define mechanisms to address these requirements. - Document issues and strategies for the migration of MPLS-based deployments to GMPLS. Based on the outcome, identify protocol machinery that implementations may have to change to ease the migration from MPLS to GMPLS. In doing this work, the WG will work closely with at least the following other WGs: MPLS, ISIS, OSPF, IDR, L1VPN and PCE. The WG will also cooperate with the ITU-T. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jun 2003 Nov 2006 Exclude Routes - Extension to RSVP-TE Dec 2003 Jan 2007 Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE Apr 2004 Oct 2006 RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery Apr 2004 Oct 2006 GMPLS Based Segment Recovery Oct 2004 Jan 2007 Extensions to GMPLS RSVP Graceful Restart Feb 2005 Mar 2007 Inter domain Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering - RSVP-TE extensions Apr 2005 Mar 2007 Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE) Apr 2005 Feb 2007 A Per-domain path computation method for establishing Inter-domain Traffic Engineering (TE) Label Switched Paths (LSPs) May 2005 Oct 2006 Use of Addresses in Generalized Multi-Protocol Label Switching (GMPLS) Networks Nov 2005 Jan 2007 Routing extensions for discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) mesh membership Nov 2005 Dec 2006 IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities Jan 2006 Oct 2006 Requirements for GMPLS-based multi-region and multi-layer networks (MRN/MLN) Jan 2006 Oct 2006 Evaluation of existing GMPLS Protocols against Multi Layer and Multi Region Networks (MLN/MRN) Apr 2006 Jan 2007 Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support of Calls Apr 2006 Oct 2006 Procedures for Dynamically Signaled Hierarchical Label Switched Paths Apr 2006 Feb 2007 Framework for MPLS-TE to GMPLS migration Apr 2006 Oct 2006 MEF Ethernet Traffic Parameters Jul 2006 Mar 2007 OSPFv2 Routing Protocols Extensions for ASON Routing Sep 2006 Mar 2007 Graceful Shutdown in GMPLS Traffic Engineering Networks Sep 2006 Oct 2006 Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) Nov 2006 Mar 2007 Traffic Engineering Database Management Information Base in support of GMPLS Dec 2006 Dec 2006 Requirements for the Conversion Between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network Dec 2006 Dec 2006 Interworking Requirements to Support operation of MPLS-TE over GMPLS networks Dec 2006 Dec 2006 Analysis of Inter-domain Label Switched Path (LSP) Recovery Cross Registry Information Service Protocol (crisp) --------------------------------------------------- Charter Last Modified: 2006-08-16 Current Status: Active Working Group Chair(s): April Marine George Michaelson Applications Area Director(s): Ted Hardie Lisa Dusseault Applications Area Advisor: Ted Hardie Mailing Lists: General Discussion:crisp@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/crisp Archive: http://www.ietf.org/mail-archive/web/crisp/index.html Description of Working Group: In the standard operation of Internet systems, various labels and data are managed globally -- domain names, IPv4 and IPv6 addresses, etc. From time to time, for operational and administrative purposes, users of the Internet need to be able to find and access registered nformation associated with those labels. The CRISP (Cross-Registry Information Service Protocol) WG will define a standard mechanism that can be used for: - finding authoritative information associated with a label, - a protocol to transport queries and responses for accessing that information, - a first profile (schema & queries) to support commonly-required queries for domain registration information, - a second profile (schema & queries) to support commonly-required queries for numbering resource information. ("numbering resources" is used to refer to IP addresses and ASNs) The WG will strive to preserve an extensible architecture so that the work possibly be useful in the future to other types of registries beyond those specifically considered by the group. Specific topics that are NOT goals of this WG are: - Backwards compatibility with existing administrative directory services such as WHOIS. - Provisioning of data into registry or registrar systems. CRISP provides a uniform access to and view of data that may be held in disparate backend servers. The CRISP service definition will define: - a standard mechanism that can be used to determine the authoritative server(s) for information about a given label - a single mandatory to implement protocol for transporting application queries and responses, including - expression of input query - expression of result sets - standard expression of error conditions - authentication and verification of data integrity - specific data types and queries to be supported in the supported registry services. Deliverables: - Requirements document as an Informational RFC. (previously submitted) - First draft of protocol (use) specification. (previously submitted) - First draft of domain registration administrative directory services required schema element specification. (previously submitted) - Document specifying a new protocol, or the use of an existing one, for providing CRISP service (application transport). - Document specifying required schema elements and queries for domain registration administrative directory queries. - Document specifying required schema elements and queries for numbering resources registration administrative directory queries. Description of Working Group: In the standard operation of Internet systems, various labels and data are managed globally -- domain names, IPv4 and IPv6 addresses, etc. From time to time, for operational and administrative purposes, users of the Internet need to be able to find and access registered nformation associated with those labels. The CRISP (Cross-Registry Information Service Protocol) WG will define a standard mechanism that can be used for: - finding authoritative information associated with a label, - a protocol to transport queries and responses for accessing that information, - a first profile (schema & queries) to support commonly-required queries for domain registration information, - a second profile (schema & queries) to support commonly-required queries for numbering resource information. ("numbering resources" is used to refer to IP addresses and ASNs) The WG will strive to preserve an extensible architecture so that the work possibly be useful in the future to other types of registries beyond those specifically considered by the group. Specific topics that are NOT goals of this WG are: - Backwards compatibility with existing administrative directory services such as WHOIS. - Provisioning of data into registry or registrar systems. CRISP provides a uniform access to and view of data that may be held in disparate backend servers. The CRISP service definition will define: - a standard mechanism that can be used to determine the authoritative server(s) for information about a given label - a single mandatory to implement protocol for transporting application queries and responses, including - expression of input query - expression of result sets - standard expression of error conditions - authentication and verification of data integrity - specific data types and queries to be supported in the supported registry services. Deliverables: - Requirements document as an Informational RFC. (previously submitted) - First draft of protocol (use) specification. (previously submitted) - First draft of domain registration administrative directory services required schema element specification. (previously submitted) - Document specifying a new protocol, or the use of an existing one, for providing CRISP service (application transport). - Document specifying required schema elements and queries for domain registration administrative directory queries. - Document specifying required schema elements and queries for numbering resources registration administrative directory queries. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Aug 2004 Dec 2006 A Domain Availability Check (dchk) Registry Type for the Internet Registry Information Service (IRIS) Oct 2004 Mar 2007 A Lightweight UDP Transfer Protocol for the the Internet Registry Information Service May 2005 Mar 2007 A Common Schema for Internet Registry Information Service Transfer Protocols May 2005 Mar 2007 XML Pipelining with Chunks for the Information Registry Information Service Datagram Congestion Control Protocol (dccp) ------------------------------------------- Charter Last Modified: 2007-03-06 Current Status: Active Working Group Chair(s): Thomas Phelan Gorry Fairhurst 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 ------ ------- -------------------------------------------- Jan 2005 Nov 2006 TCP Friendly Rate Control (TFRC): the Small-Packet (SP) Variant Jul 2005 Mar 2007 Faster Restart for TCP Friendly Rate Control (TFRC) Jul 2006 Mar 2007 RTP and the Datagram Congestion Control Protocol (DCCP) Oct 2006 Mar 2007 TCP Friendly Rate Control (TFRC): Protocol Specification Dynamic Host Configuration (dhc) -------------------------------- Charter Last Modified: 2006-03-30 Current Status: Active Working Group Chair(s): Ralph Droms Stig Venaas Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:dhcwg@ietf.org To Subscribe: http://www1.ietf.org/mailman/listinfo/dhcwg Archive: http://www.ietf.org/mail-archive/web/dhcwg/index.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 (and sometimes developing) 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. The DHC WG will not (generally) be responsible for evaluating the semantic content of proposed options. The DHC WG will not adopt new proposals for extensions to DHCP as working group documents without first coordinating with other relevant working groups and determining who has the responsibility for reviewing the semantic content of an option. The DHC WG has the following main objectives: * Address security in DHCP o Develop and document security requirements for DHCP. RFC 3118 defines current security mechanisms for DHCPv4. Unfortunately, RFC 3118 has neither been implemented nor deployed to date. Specific issues to be considered include: - Improved key management and scalability - Security for messages passed between relay agents and servers - Threats of DoS attacks through DHCPFORCERENEW - The increased usage of DHC on unsecured (e.g., wireless) and public LANs - The need for clients to be able to authenticate servers, without simultaneously requiring client authentication by the server. o Develop and document a roadmap of any new documents or protocols needed to meet the security requirements for DHCP * Write an analysis of the DHCP specification, including RFC 2131, RFC 2132 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. * 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. * Assess the requirements for informing DHCPv6 clients of changes in configuration information. The DHCPv6 specification in RFC 3315 includes a mechanism through which clients can obtain other configuration information without obtaining an address or addresses. This mechanisms is sometimes called "stateless DHCPv6" and is specified in RFC 3736. RFC 3315 includes no provision for notifying DHCPv6 clients using stateless DHCPv6 of changes in the configuration information supplied to the client or any recommendations as to when a client should obtain possibly updated information. The DHC WG will evaluate solutions for informing DHCPv6 clients of changes in configuration information and select a solution that will be developed and published by the WG. 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 (and sometimes developing) 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. The DHC WG will not (generally) be responsible for evaluating the semantic content of proposed options. The DHC WG will not adopt new proposals for extensions to DHCP as working group documents without first coordinating with other relevant working groups and determining who has the responsibility for reviewing the semantic content of an option. The DHC WG has the following main objectives: * Address security in DHCP o Develop and document security requirements for DHCP. RFC 3118 defines current security mechanisms for DHCPv4. Unfortunately, RFC 3118 has neither been implemented nor deployed to date. Specific issues to be considered include: - Improved key management and scalability - Security for messages passed between relay agents and servers - Threats of DoS attacks through DHCPFORCERENEW - The increased usage of DHC on unsecured (e.g., wireless) and public LANs - The need for clients to be able to authenticate servers, without simultaneously requiring client authentication by the server. o Develop and document a roadmap of any new documents or protocols needed to meet the security requirements for DHCP * Write an analysis of the DHCP specification, including RFC 2131, RFC 2132 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. * 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. * Assess the requirements for informing DHCPv6 clients of changes in configuration information. The DHCPv6 specification in RFC 3315 includes a mechanism through which clients can obtain other configuration information without obtaining an address or addresses. This mechanisms is sometimes called "stateless DHCPv6" and is specified in RFC 3736. RFC 3315 includes no provision for notifying DHCPv6 clients using stateless DHCPv6 of changes in the configuration information supplied to the client or any recommendations as to when a client should obtain possibly updated information. The DHC WG will evaluate solutions for informing DHCPv6 clients of changes in configuration information and select a solution that will be developed and published by the WG. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2001 Mar 2007 Virtual Subnet Selection Sub-Option for the Relay Agent Information Option for DHCPv4 Feb 2003 Oct 2006 DHCP Server Identifier Override Suboption Feb 2003 Oct 2006 Subnet Allocation Option Oct 2005 Dec 2006 DHCP options for PANA Authentication Agents Oct 2005 Dec 2006 Domain Suffix Option for DHCPv6 Jan 2006 Nov 2006 DHCPv6 Relay Agent Assignment Notification (RAAN) Option May 2006 Nov 2006 A Timezone Option for DHCP Jun 2006 Feb 2007 DHCPv4 Relay Agent Flags Suboption Aug 2006 Nov 2006 Rebind Capability in DHCPv6 Reconfigure Messages Oct 2006 Oct 2006 DHCPv6 Relay Agent Echo Request Option Nov 2006 Mar 2007 DHCPv6 Server Reply Sequence Number Option Mar 2007 Mar 2007 DHCPv6 Leasequery Diameter Maintenance and Extensions (dime) ------------------------------------------ Charter Last Modified: 2007-02-26 Current Status: Active Working Group Chair(s): David Frascone Hannes Tschofenig Operations and Management Area Director(s): Dan Romascanu David Kessens Operations and Management Area Advisor: David Kessens Secretary(ies): Victor Fajardo Mailing Lists: General Discussion:dime@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/dime Archive: http://www.ietf.org/mail-archive/web/dime/index.html Description of Working Group: The Diameter Maintanence and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use in applications such as IP telephony and Local Area Network authentication, authorization and accounting. The IETF has recently completed work on the Diameter Base protocol. There is on-going work on defining RADIUS extensions. The work done in the DiME WG will ensure that work done in RADext is also available for Diameter. The immediate goals of the DiME working group are to address the following issues: - Maintaining and/or progressing, along the standards track, the Diameter procotol and Diameter Applications. Every revised document to be "maintained" requires explicit approval before it will be accepted as a WG document. - An informational RFC on a Diameter API. - Diameter Application design guidelines. This document will provide guidelines for design of new Diameter Applications. It will detail when to consider reusing an existing application and when to develop a new application. Interaction between vendor & SDO specific extensions and applications will be covered. - Diameter QoS application. This document will develop a new Diameter application for supporting QoS in AAA deployments. The NSIS WG will be consulted on proper design of QoS attributes. - Diameter URI. RFC 3588 defines an AAA URI which has some known problems. A document revising the AAA URI as a specific Diameter URI will be developed. - Diameter extensions for MIPv6. This may include support for Mobile IP extensions, like FMIP; as well as support for MIP bootstrapping. Additionally, AAA systems require interoperability in order to work. Uncontrolled extensibility is not a mechanism for interoperability. Therefore, 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 Maintanence and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use in applications such as IP telephony and Local Area Network authentication, authorization and accounting. The IETF has recently completed work on the Diameter Base protocol. There is on-going work on defining RADIUS extensions. The work done in the DiME WG will ensure that work done in RADext is also available for Diameter. The immediate goals of the DiME working group are to address the following issues: - Maintaining and/or progressing, along the standards track, the Diameter procotol and Diameter Applications. Every revised document to be "maintained" requires explicit approval before it will be accepted as a WG document. - An informational RFC on a Diameter API. - Diameter Application design guidelines. This document will provide guidelines for design of new Diameter Applications. It will detail when to consider reusing an existing application and when to develop a new application. Interaction between vendor & SDO specific extensions and applications will be covered. - Diameter QoS application. This document will develop a new Diameter application for supporting QoS in AAA deployments. The NSIS WG will be consulted on proper design of QoS attributes. - Diameter URI. RFC 3588 defines an AAA URI which has some known problems. A document revising the AAA URI as a specific Diameter URI will be developed. - Diameter extensions for MIPv6. This may include support for Mobile IP extensions, like FMIP; as well as support for MIP bootstrapping. Additionally, AAA systems require interoperability in order to work. Uncontrolled extensibility is not a mechanism for interoperability. Therefore, 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 Feb 2007 The Diameter API Jun 2006 Oct 2006 Diameter Mobile IPv6: HA-to-AAAH support Jun 2006 Feb 2007 Diameter Mobile IPv6: NAS <-> HAAA Support Dec 2006 Mar 2007 Diameter Base Protocol Feb 2007 Feb 2007 Diameter Quality of Service Application Domain Keys Identified Mail (dkim) ---------------------------------- Charter Last Modified: 2007-03-06 Current Status: Active Working Group Chair(s): Stephen Farrell Barry Leiba Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Russ Housley 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 ------ ------- -------------------------------------------- Feb 2006 Feb 2007 DomainKeys Identified Mail (DKIM) Signatures Jun 2006 Mar 2007 DomainKeys Identified Mail (DKIM) Message Signing Service Overview Aug 2006 Mar 2007 Requirements for a DKIM Signing Practices Protocol Detecting Network Attachment (dna) ---------------------------------- Charter Last Modified: 2006-09-07 Current Status: Active Working Group Chair(s): Greg Daley Suresh Krishnan Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:dna@eng.monash.edu.au To Subscribe: majordomo@ecselists.eng.monash.edu.au In Body: subscribe dna Archive: http://ecselists.eng.monash.edu.au/~warchive/dna/ Description of Working Group: When an IPv6 node detects or suspects that its underlying link layer (L2) connectivity has or may have undergone a change, it needs to check whether its IP layer (L3) addressing and routing configurations are still valid or have changed. In the case that the L3 connectivity has changed, the node needs to reconfigure and may need to initiate mobility procedures, such as sending Mobile IP binding updates. Changes in an L2 connection do not necessarily mean that there has been change in L3 connectivity. For the purposes of detecting network attachment, an L3 link is defined as the topological range within which IP packets may be sent without resorting to forwarding. In other words, a link is the range where a given IP configuration is valid. In IPv6, the IP layer configuration information includes the set of valid unicast addresses[RFC 2462, RFC 3315], the Duplicate Address Detection (DAD) status of the addresses[RFC 2462], valid routing prefixes[RFC 2461], set of default routers[RFC 2461], neighbor and destination caches[RFC 2461], multicast listener (MLD) state[RFC 2710]. The current IPv6 stateless and stateful autoconfiguration procedures may take a fairly long time due to delays associated with Router Discovery and Duplicate Address Detection. The main goal of this WG is to develop mechanisms that reduce or avoid such delays, in cases where they are not necessary. For example if an interface comes back up after having been down momentarily, it can be quicker to verify that one is still attached to the same link than rerunning the full reconfiguration as if one were connecting to a new L3 link and had no previous configuration information cached. In some wireless technologies, the link layer state and events may not give an accurate indication of whether or not the IP addressing configuration and routability have changed. For example, a host may be able to see a base station but still be unable to deliver or receive IP packets within the L3 link. Moreover, a hardware indication that a radio link is up does not necessarily mean that all link layer configuration, such as authentication or virtual LAN connectivity has been completed. Therefore detecting network attachment requires not only change detection but IP layer connectivity testing. The purpose of the DNA working group is to define standards track and BCP documents that allow hosts to detect their IP layer configuration and connectivity status quickly, proposing some optimization to the current specifications that would allow a host to reconfigure its IPv6 layer faster than today. The group will define a set of goals for detecting network attachment, describing existing issues and important properties of potential solutions. The working group will describe best current practice for nodes making use of existing information for detecting network attachment. The working group will define a set of extensions to the current IPv6 configuration protocols [RFC 2461, 2462, possibly RFC 3315] that allow the nodes to discover whether L3 configuration or connectivity may have changed more reliably and easily than today. Initiation of L3 link change detection procedures can be achieved either through reception (or lack of reception) of messages at the IP layer or through indications from other layers. The working group will produce an informational document that contains a catalogue of the indications currently available from a subset of wireless link layer technologies. The DNA WG will not define new procedures or APIs related to link layers. Documents * Define goals for detecting network attachment in IPv6 (Informational). * Specify recommendations for detecting network attachment and L3 link change in IPv6 networks (BCP). * Define a protocol extension for detecting network attachment and L3 link change in IPv6 networks more reliably and easily (Standards Track). * Document existing link layer (L2) information which is useful to start detecting network attachment (Informational). Description of Working Group: When an IPv6 node detects or suspects that its underlying link layer (L2) connectivity has or may have undergone a change, it needs to check whether its IP layer (L3) addressing and routing configurations are still valid or have changed. In the case that the L3 connectivity has changed, the node needs to reconfigure and may need to initiate mobility procedures, such as sending Mobile IP binding updates. Changes in an L2 connection do not necessarily mean that there has been change in L3 connectivity. For the purposes of detecting network attachment, an L3 link is defined as the topological range within which IP packets may be sent without resorting to forwarding. In other words, a link is the range where a given IP configuration is valid. In IPv6, the IP layer configuration information includes the set of valid unicast addresses[RFC 2462, RFC 3315], the Duplicate Address Detection (DAD) status of the addresses[RFC 2462], valid routing prefixes[RFC 2461], set of default routers[RFC 2461], neighbor and destination caches[RFC 2461], multicast listener (MLD) state[RFC 2710]. The current IPv6 stateless and stateful autoconfiguration procedures may take a fairly long time due to delays associated with Router Discovery and Duplicate Address Detection. The main goal of this WG is to develop mechanisms that reduce or avoid such delays, in cases where they are not necessary. For example if an interface comes back up after having been down momentarily, it can be quicker to verify that one is still attached to the same link than rerunning the full reconfiguration as if one were connecting to a new L3 link and had no previous configuration information cached. In some wireless technologies, the link layer state and events may not give an accurate indication of whether or not the IP addressing configuration and routability have changed. For example, a host may be able to see a base station but still be unable to deliver or receive IP packets within the L3 link. Moreover, a hardware indication that a radio link is up does not necessarily mean that all link layer configuration, such as authentication or virtual LAN connectivity has been completed. Therefore detecting network attachment requires not only change detection but IP layer connectivity testing. The purpose of the DNA working group is to define standards track and BCP documents that allow hosts to detect their IP layer configuration and connectivity status quickly, proposing some optimization to the current specifications that would allow a host to reconfigure its IPv6 layer faster than today. The group will define a set of goals for detecting network attachment, describing existing issues and important properties of potential solutions. The working group will describe best current practice for nodes making use of existing information for detecting network attachment. The working group will define a set of extensions to the current IPv6 configuration protocols [RFC 2461, 2462, possibly RFC 3315] that allow the nodes to discover whether L3 configuration or connectivity may have changed more reliably and easily than today. Initiation of L3 link change detection procedures can be achieved either through reception (or lack of reception) of messages at the IP layer or through indications from other layers. The working group will produce an informational document that contains a catalogue of the indications currently available from a subset of wireless link layer technologies. The DNA WG will not define new procedures or APIs related to link layers. Documents * Define goals for detecting network attachment in IPv6 (Informational). * Specify recommendations for detecting network attachment and L3 link change in IPv6 networks (BCP). * Define a protocol extension for detecting network attachment and L3 link change in IPv6 networks more reliably and easily (Standards Track). * Document existing link layer (L2) information which is useful to start detecting network attachment (Informational). Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Sep 2004 Feb 2007 Link-layer Event Notifications for Detecting Network Attachments Feb 2006 Mar 2007 Detecting Network Attachment in IPv6 Networks (DNAv6) DNS Extensions (dnsext) ----------------------- Charter Last Modified: 2007-01-31 Current Status: Active Working Group Chair(s): Olafur Gudmundsson Olaf Kolkman Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Mark Townsley 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: DNS was originally specified in RFC's 1034 and 1035, with subsequent updates. Within the scope of this WG are DNS protocol issues, including the specification of message formats, message handling, and data formats used for DNS client-server and server-server communication. This WG is focused on advancing the zone transfer, update, notify and DNSSECbis documents to Draft standard. The WG works on solutions for DNSSEC deployment issues that may require protocol modifications. Two of these issues are identified and are worked on under the umbrella of this WG. 1] (a) method(s) to prevent the possibility of trivial zone enumeration and 2] a method for automated rollover of trust-anchors configured in validating resolvers. Issues surrounding the operation of DNS, recommendations concerning the configuration of DNS servers, and other issues with the use of the protocol are out of scope for this Working Group. These issues are considered in other venues, such as the DNS Operations Working Group. The DNSEXT Working Group sometimes uses an additional mailing list for discussion of DNS Security related issues. This list is open to all Discussion: dnssec@cafax.se To Subscribe: dnssec-request@cafax.se Archive: http://www.cafax.se/dnssec/ and ftp://ftp.cafax.se/pub/archives/dnssec.list The 2535bis document set was edited by a team. This team was chartered with making editorial changes only, with all substantiative changes discussed on the WG list. The archive of this editors-only mailing list is available at: http://www.east.isi.edu/projects/DNSSEC Specific work items are: o Advance the DNSSECbis document set through the standards process. o Clarification of RFC1034/1035 relating to DNSEXT ongoing work. + Clarification of wildcard processing rules. o After the work items above have been completed the working group will continue on reviewing the following existing proposed standard and examine if there is a possibility to progress them on the standards track. + RFC1995 (IXFR) to Draft standard. + RFC1996 (Notify) to Draft standard. + RFC2136bis (Dynamic Update) to Draft Standard. + RFC2181 (Clarify) to IESG for advancement to Draft Standard. + RFC2308 (Neg Caching) to Draft Standard. + RFC2671 (EDNS0) to Draft Standard. + RFC2672 (DNAME) to Draft Standard, or revision. + RFC2845 (TSIG)to Draft standard. + RFC2930 (TKEY) to Draft standard. + RFC3007 (Secure Update) to Draft standard. + RFC3645 GSS/TSIG to Draft Standard + RFC3??? AXFR clarify to Draft Standard. o Identify (a) method(s) to prevent the possibility of trivial zone enumeration. o Define a method for automated rollover of trust-anchors configured in validating resolvers. o Foster the development of Link Local Multicast Name Resolution (LLMNR) standard. The WG has taken up this work since LLMNR it is very similar to the DNS protocol. LLMNR is targeted as proposed standard. The lifetime of the group is set by the work items above but while these are ongoing the working group has additional tasks: o Reviewing and providing recommendations about the specification, by other working groups, of RR types that do not require any special processing and that do not require any special naming conventions. Description of Working Group: DNS was originally specified in RFC's 1034 and 1035, with subsequent updates. Within the scope of this WG are DNS protocol issues, including the specification of message formats, message handling, and data formats used for DNS client-server and server-server communication. This WG is focused on advancing the zone transfer, update, notify and DNSSECbis documents to Draft standard. The WG works on solutions for DNSSEC deployment issues that may require protocol modifications. Two of these issues are identified and are worked on under the umbrella of this WG. 1] (a) method(s) to prevent the possibility of trivial zone enumeration and 2] a method for automated rollover of trust-anchors configured in validating resolvers. Issues surrounding the operation of DNS, recommendations concerning the configuration of DNS servers, and other issues with the use of the protocol are out of scope for this Working Group. These issues are considered in other venues, such as the DNS Operations Working Group. The DNSEXT Working Group sometimes uses an additional mailing list for discussion of DNS Security related issues. This list is open to all Discussion: dnssec@cafax.se To Subscribe: dnssec-request@cafax.se Archive: http://www.cafax.se/dnssec/ and ftp://ftp.cafax.se/pub/archives/dnssec.list The 2535bis document set was edited by a team. This team was chartered with making editorial changes only, with all substantiative changes discussed on the WG list. The archive of this editors-only mailing list is available at: http://www.east.isi.edu/projects/DNSSEC Specific work items are: o Advance the DNSSECbis document set through the standards process. o Clarification of RFC1034/1035 relating to DNSEXT ongoing work. + Clarification of wildcard processing rules. o After the work items above have been completed the working group will continue on reviewing the following existing proposed standard and examine if there is a possibility to progress them on the standards track. + RFC1995 (IXFR) to Draft standard. + RFC1996 (Notify) to Draft standard. + RFC2136bis (Dynamic Update) to Draft Standard. + RFC2181 (Clarify) to IESG for advancement to Draft Standard. + RFC2308 (Neg Caching) to Draft Standard. + RFC2671 (EDNS0) to Draft Standard. + RFC2672 (DNAME) to Draft Standard, or revision. + RFC2845 (TSIG)to Draft standard. + RFC2930 (TKEY) to Draft standard. + RFC3007 (Secure Update) to Draft standard. + RFC3645 GSS/TSIG to Draft Standard + RFC3??? AXFR clarify to Draft Standard. o Identify (a) method(s) to prevent the possibility of trivial zone enumeration. o Define a method for automated rollover of trust-anchors configured in validating resolvers. o Foster the development of Link Local Multicast Name Resolution (LLMNR) standard. The WG has taken up this work since LLMNR it is very similar to the DNS protocol. LLMNR is targeted as proposed standard. The lifetime of the group is set by the work items above but while these are ongoing the working group has additional tasks: o Reviewing and providing recommendations about the specification, by other working groups, of RR types that do not require any special processing and that do not require any special naming conventions. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jun 2001 Jun 2006 DNSSEC Opt-In Jul 2001 Oct 2006 DSA Keying and Signature Information in the DNS Jul 2001 Oct 2006 Storage of Diffie-Hellman Keying Information in the DNS Jul 2001 Mar 2007 Elliptic Curve Keys and Signatures in the Domain Name System (DNS) Oct 2004 Nov 2006 Automated Updates of DNSSEC Trust Anchors Jan 2005 Mar 2007 DNSSEC Hashed Authenticated Denial of Existence Feb 2005 Apr 2006 DNSSEC Experiments May 2005 Mar 2007 Clarifications and Implementation Notes for DNSSECbis Jul 2005 Dec 2006 Domain Name System (DNS) IANA Considerations Sep 2005 Jun 2006 DNS Name Server Identifier Option (NSID) Feb 2006 Nov 2006 Requirements related to DNSSEC Trust Anchor Rollover Sep 2006 Jan 2007 Update to DNAME Redirection in the DNS Jan 2007 Jan 2007 Measures for making DNS more resilient against forged answers Domain Name System Operations (dnsop) ------------------------------------- Charter Last Modified: 2007-02-06 Current Status: Active Working Group Chair(s): Rob Austein Peter Koch Operations and Management Area Director(s): Dan Romascanu David Kessens Operations and Management Area Advisor: David Kessens Mailing Lists: General Discussion:dnsop@ietf.org To Subscribe: http://www1.ietf.org/mailman/listinfo/dnsop Archive: http://www1.ietf.org/mail-archive/web/dnsop/current/index.html 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 ------ ------- -------------------------------------------- May 2002 Feb 2007 Requirements for a Mechanism Identifying a Name Server Instance Jun 2003 Feb 2007 DNS Referral Response Size Issues May 2006 Feb 2007 Preventing Use of Recursive Nameservers in Reflector Attacks Jun 2006 Mar 2007 Locally-served DNS Zones Sep 2006 Feb 2007 Considerations for the use of DNS Reverse Mapping Feb 2007 Feb 2007 I'm Being Attacked by PRISONER.IANA.ORG! Feb 2007 Feb 2007 AS112 Nameserver Operations Email Address Internationalization (eai) ---------------------------------------- Charter Last Modified: 2006-08-15 Current Status: Active Working Group Chair(s): Harald Alvestrand XiaoDong Lee Applications Area Director(s): Ted Hardie Lisa Dusseault Applications Area Advisor: Ted Hardie Mailing Lists: General Discussion:ima@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/ima Archive: http://www1.ietf.org/mail-archive/web/ima/index.html 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 Mar 2007 SMTP extension for internationalized email address May 2006 Feb 2007 UTF-8 Mail: Scenarios May 2006 Feb 2007 Overview and Framework for Internationalized Email May 2006 Mar 2007 Downgrading mechanism for Email Address Internationalization May 2006 Mar 2007 IMAP Support for UTF-8 Jun 2006 Mar 2007 Internationalized Email Headers Jun 2006 Jan 2007 Mailing Lists and Internationalized Email Addresses Jun 2006 Jan 2007 POP3 Support for UTF-8 Jan 2007 Jan 2007 International Delivery and Disposition Notifications Extensible Authentication Protocol (eap) ---------------------------------------- Charter Last Modified: 2007-02-16 Current Status: Active Working Group Chair(s): Bernard Aboba Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Technical Advisor(s): William Arbaugh Charles Clancy Mailing Lists: General Discussion:eap@frascone.com To Subscribe: eap-request@frascone.com In Body: subscribe in Subject line Archive: http://mail.frascone.com/pipermail/eap/ Description of Working Group: The EAP working group will restrict itself to the following work items in order to fully document and improve the interoperability of the existing EAP protocol: 1. IANA considerations for EAP. 2. Type space extension to support an expanded Type space. 3. EAP usage model. 4. Threat model and security requirements. 5. Documentation of interaction between EAP and other layers. 6. Resolution of interoperability issues. 7. EAP state machine. 8. EAP keying framework. 9. EAP network selection problem definition Items 1-6 were included within RFC 3748. Items 7-9 will be handled as separate documents. While the EAP WG is not currently chartered to standardize EAP methods, with the publication of RFC 3748, the EAP WG will assume responsibility for review of EAP methods requesting a Type code allocation, as specified in the IANA considerations section of RFC 3748. When the current work items are completed, the WG may be rechartered, or a new WG may be formed to standardize methods. Description of Working Group: The EAP working group will restrict itself to the following work items in order to fully document and improve the interoperability of the existing EAP protocol: 1. IANA considerations for EAP. 2. Type space extension to support an expanded Type space. 3. EAP usage model. 4. Threat model and security requirements. 5. Documentation of interaction between EAP and other layers. 6. Resolution of interoperability issues. 7. EAP state machine. 8. EAP keying framework. 9. EAP network selection problem definition Items 1-6 were included within RFC 3748. Items 7-9 will be handled as separate documents. While the EAP WG is not currently chartered to standardize EAP methods, with the publication of RFC 3748, the EAP WG will assume responsibility for review of EAP methods requesting a Type code allocation, as specified in the IANA considerations section of RFC 3748. When the current work items are completed, the WG may be rechartered, or a new WG may be formed to standardize methods. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2003 Feb 2007 Extensible Authentication Protocol (EAP) Key Management Framework Jan 2004 Mar 2007 Network Discovery and Selection Problem Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- Charter Last Modified: 2006-07-11 Current Status: Active Working Group Chair(s): Hannes Tschofenig Marc Linsner Real-time Applications and Infrastructure Area Director(s): Jon Peterson Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Jon Peterson Mailing Lists: General Discussion:ecrit@ietf.org To Subscribe: https://www1.ietf.org/mailman//listinfo/ecrit Archive: http://www.ietf.org/mail-archive/web/ecrit/index.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 ------ ------- -------------------------------------------- Sep 2005 Mar 2007 Requirements for Emergency Context Resolution with Internet Technologies Feb 2006 Mar 2007 A Uniform Resource Name (URN) for Services Mar 2006 Jul 2006 Security Threats and Requirements for Emergency Call Marking and Mapping Jun 2006 Mar 2007 LoST: A Location-to-Service Translation Protocol Aug 2006 Dec 2006 Location-to-URL Mapping Architecture and Framework Oct 2006 Mar 2007 Best Current Practice for Communications Services in support of Emergency Calling Oct 2006 Mar 2007 Framework for Emergency Calling in Internet Multimedia Dec 2006 Dec 2006 A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure EAP Method Update (emu) ----------------------- Charter Last Modified: 2007-01-05 Current Status: Active Working Group Chair(s): Joseph Salowey Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Sam Hartman Mailing Lists: General Discussion:emu@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/emu Archive: http://www.ietf.org/mail-archive/web/emu/current/index.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 this methods are proprietary methods and only a few methods are documented in RFCs. The lack of documented, open specifications is a deployment and interoperability problem. In addition, none of the EAP methods in the standards track implement features such as key derivation that are required for many modern applications. This poses a problem for, among other things, the selection of a mandatory to implement EAP method in new network access technologies. For example, no standards track methods meet new requirements such as those posed in RFC 4017, which documents IEEE 802.11 requirements for EAP methods. This group is chartered to work on the following types of mechanisms to meet RFC 3748 and RFC 4017 requirements: - An update to RFC 2716 to bring EAP-TLS into standards track, clarify specification, interoperability, and implementation issues gathered over the years, and update the document to meet the requirements of RFC 3748, RFC 4017, and EAP keying framework documents. Backwards compatibility with RFC 2716 is a requirement. - Enhanced functionality to enable a TLS-based EAP method to support authentication methods beyond certificates, channel bindings and other optional functions required in RFC 4017. So as to enable RFC 2716bis to focus solely on clarifications to the existing protocol, this effort will be handled in a separate document. Depending on an analysis of the behavior of existing implementations, it is possible that this effort may be able to use the existing EAP-TLS type code, or it may need to be handled via assignment of a new EAP Type Code. - A mechanism based on strong shared secrets that meets RFC 3748 and RFC 4017 requirements. This mechanism should strive to be simple and compact for implementation in resource constrained environments. - A mechanism meeting RFC 3748 and RFC 4017 requirements that makes use of existing password databases such as AAA databases. The implementation should strive to be usable in resource constrained environments. In order to facilitate the development of the shared secret and password based methods design teams will be formed. The design teams should take into consideration existing methods including mechanisms based on EAP-TLS such as TLS-PSK. 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 this methods are proprietary methods and only a few methods are documented in RFCs. The lack of documented, open specifications is a deployment and interoperability problem. In addition, none of the EAP methods in the standards track implement features such as key derivation that are required for many modern applications. This poses a problem for, among other things, the selection of a mandatory to implement EAP method in new network access technologies. For example, no standards track methods meet new requirements such as those posed in RFC 4017, which documents IEEE 802.11 requirements for EAP methods. This group is chartered to work on the following types of mechanisms to meet RFC 3748 and RFC 4017 requirements: - An update to RFC 2716 to bring EAP-TLS into standards track, clarify specification, interoperability, and implementation issues gathered over the years, and update the document to meet the requirements of RFC 3748, RFC 4017, and EAP keying framework documents. Backwards compatibility with RFC 2716 is a requirement. - Enhanced functionality to enable a TLS-based EAP method to support authentication methods beyond certificates, channel bindings and other optional functions required in RFC 4017. So as to enable RFC 2716bis to focus solely on clarifications to the existing protocol, this effort will be handled in a separate document. Depending on an analysis of the behavior of existing implementations, it is possible that this effort may be able to use the existing EAP-TLS type code, or it may need to be handled via assignment of a new EAP Type Code. - A mechanism based on strong shared secrets that meets RFC 3748 and RFC 4017 requirements. This mechanism should strive to be simple and compact for implementation in resource constrained environments. - A mechanism meeting RFC 3748 and RFC 4017 requirements that makes use of existing password databases such as AAA databases. The implementation should strive to be usable in resource constrained environments. In order to facilitate the development of the shared secret and password based methods design teams will be formed. The design teams should take into consideration existing methods including mechanisms based on EAP-TLS such as TLS-PSK. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2006 Feb 2007 The EAP TLS Authentication Protocol Oct 2006 Mar 2007 EAP Generalized Pre-Shared Key (EAP-GPSK) Telephone Number Mapping (enum) ------------------------------- Charter Last Modified: 2006-12-15 Current Status: Active Working Group Chair(s): Patrik Faltstrom Richard Shockey Real-time Applications and Infrastructure Area Director(s): Jon Peterson Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Jon Peterson 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 ------ ------- -------------------------------------------- Jul 2004 Mar 2007 ENUM Implementation Issues and Experiences Oct 2004 Oct 2005 IANA Registration for Enumservice VOID Sep 2005 Feb 2006 ENUM Validation Information Mapping for the Extensible Provisioning Protocol Oct 2005 Feb 2006 ENUM Validation Token Format Definition Nov 2005 Nov 2006 IANA Registration for vCard Enumservice Feb 2006 Oct 2006 IANA Registration for IAX Enumservice Feb 2006 Mar 2007 Guide and Template for IANA Registrations of Enumservices Mar 2006 Aug 2006 Infrastrucure ENUM Requirements Mar 2006 Mar 2007 A Telephone Number Mapping (ENUM) Service Registration for Internet Calendaring Services Mar 2006 Mar 2007 A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services Apr 2006 Jan 2007 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM Apr 2006 Sep 2006 IANA Registration for an Enumservice Calling Name Delivery (CNAM) Information and IANA Registration for Media type 'application/cnam' Aug 2006 Dec 2006 The ENUM Branch Location Record Aug 2006 Jan 2007 Combined User and Infrastructure ENUM in the e164.arpa tree Sep 2006 Sep 2006 ENUM Requirement for EDNS0 Support Sep 2006 Sep 2006 The Uniform Resource Identifier (URI) DNS Resource Record Oct 2006 Oct 2006 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) Nov 2006 Jan 2007 IANA Registration for Enumservice 'XMPP' Jan 2007 Feb 2007 IANA Registration for Enumservice UNUSED FEC Framework (fecframe) ------------------------ Charter Last Modified: 2006-05-02 Current Status: Active Working Group Chair(s): Greg Shepherd Marshall Eubanks Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Magnus Westerlund Mailing Lists: General Discussion:fecframe@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/fecframe Archive: http://www1.ietf.org/mail-archive/web/fecframe/current/index.html 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 ------ ------- -------------------------------------------- Jul 2006 Oct 2006 FECFRAME requirements Feb 2007 Feb 2007 Forward Error Correction (FEC) Framework Forwarding and Control Element Separation (forces) -------------------------------------------------- Charter Last Modified: 2006-03-24 Current Status: Active Working Group Chair(s): Patrick Droz David Putzolu Routing Area Director(s): Ross Callon Bill Fenner 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: ftp://ftp.ietf.org/ietf-mail-archive/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 ------ ------- -------------------------------------------- Aug 2003 Oct 2006 ForCES Forwarding Element Model Sep 2004 Mar 2007 ForCES Protocol Specification Jan 2006 Mar 2007 ForCES MIB Apr 2006 Feb 2007 ForCES Transport Mapping Layer (TML) Service Primitives Geographic Location/Privacy (geopriv) ------------------------------------- Charter Last Modified: 2006-03-24 Current Status: Active Working Group Chair(s): Allison Mankin Randall Gellens Andrew Newton Real-time Applications and Infrastructure Area Director(s): Jon Peterson Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Cullen Jennings 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: As more and more resources become available on the Internet, some applications need to acquire geographic location information about certain resources or entities. These applications include navigation, emergency services, management of equipment in the field, and other location-based services. But while the formatting and transfer of such information is in some sense a straightforward process, the implications of doing it, especially in regards to privacy and security, are anything but. The primary task of this working group will be to assess the the authorization, integrity and privacy requirements that must be met in order to transfer such information, or authorize the release or representation of such information through an agent. In addition, the working group will select an already standardized format to recommend for use in representing location per se. A key task will be to enhance this format and protocol approaches using the enhanced format, to ensure that the security and privacy methods are available to diverse location-aware applications. Approaches to be considered will include (among others) data formats incorporating fields directing the privacy handling of the location information and possible methods of specifying variable precision of location. Also to be considered will be: authorization of requestors and responders; authorization of proxies (for instance, the ability to authorize a carrier to reveal what timezone one is in, but not what city. An approach to the taxonomy of requestors, as well as to the resolution or precision of information given them, will be part of this deliverable. The combination of these elements should provide a service capable of transferring geographic location information in a private and secure fashion (including the option of denying transfer). For reasons of both future interoperability and assurance of the security and privacy goals, it is a goal of the working group to deliver a specification that has broad applicablity and will become mandatory to implement for IETF protocols that are location-aware. Two further deliverables of the WG will be: o An example API for application-level access to/management of link-based location information. That is, for instance, the WG may describe an API for secure, privacy-enabling user/ application handling of location information specific to a 3G wireless link technology. o Development of i-ds that make security and privacy integral to location information in HTTP and HTML, based on the work in draft-daviel-html-geo-tag-05.txt and draft-daviel-http-geo-header-03.txt. Out of Scope: This WG won't develop location-determining technology. It will work from existing technologies and where the technology is undeveloped, will state that applicability may await others' developments. This WG won't develop technology to support any particular regulatory requirement [e.g. E.911] but will provide a framework that might be used for private/secure definition of such technologies by other bodies. Coordination: The WG will coordinate with other WGs developing general privacy and location-aware functions, e.g. the SIP WG, so that the WG deliverables can be used by them. Other coordination should include the NymIP research community, WC3, and the Location Information Forum. Description of Working Group: As more and more resources become available on the Internet, some applications need to acquire geographic location information about certain resources or entities. These applications include navigation, emergency services, management of equipment in the field, and other location-based services. But while the formatting and transfer of such information is in some sense a straightforward process, the implications of doing it, especially in regards to privacy and security, are anything but. The primary task of this working group will be to assess the the authorization, integrity and privacy requirements that must be met in order to transfer such information, or authorize the release or representation of such information through an agent. In addition, the working group will select an already standardized format to recommend for use in representing location per se. A key task will be to enhance this format and protocol approaches using the enhanced format, to ensure that the security and privacy methods are available to diverse location-aware applications. Approaches to be considered will include (among others) data formats incorporating fields directing the privacy handling of the location information and possible methods of specifying variable precision of location. Also to be considered will be: authorization of requestors and responders; authorization of proxies (for instance, the ability to authorize a carrier to reveal what timezone one is in, but not what city. An approach to the taxonomy of requestors, as well as to the resolution or precision of information given them, will be part of this deliverable. The combination of these elements should provide a service capable of transferring geographic location information in a private and secure fashion (including the option of denying transfer). For reasons of both future interoperability and assurance of the security and privacy goals, it is a goal of the working group to deliver a specification that has broad applicablity and will become mandatory to implement for IETF protocols that are location-aware. Two further deliverables of the WG will be: o An example API for application-level access to/management of link-based location information. That is, for instance, the WG may describe an API for secure, privacy-enabling user/ application handling of location information specific to a 3G wireless link technology. o Development of i-ds that make security and privacy integral to location information in HTTP and HTML, based on the work in draft-daviel-html-geo-tag-05.txt and draft-daviel-http-geo-header-03.txt. Out of Scope: This WG won't develop location-determining technology. It will work from existing technologies and where the technology is undeveloped, will state that applicability may await others' developments. This WG won't develop technology to support any particular regulatory requirement [e.g. E.911] but will provide a framework that might be used for private/secure definition of such technologies by other bodies. Coordination: The WG will coordinate with other WGs developing general privacy and location-aware functions, e.g. the SIP WG, so that the WG deliverables can be used by them. Other coordination should include the NymIP research community, WC3, and the Location Information Forum. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Nov 2003 Feb 2007 Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information Oct 2004 Sep 2006 Carrying Location Objects in RADIUS Jul 2005 Mar 2007 GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations Dec 2005 Feb 2007 Revised Civic Location Format for PIDF-LO Mar 2006 Mar 2007 A Document Format for Filtering and Reporting Location Notications in the Presence Information Document Format Location Object (PIDF-LO) Jan 2007 Jan 2007 Binary to Decimal Conversion for Location Configuration Information Jan 2007 Jan 2007 GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements Global Routing Operations (grow) -------------------------------- Charter Last Modified: 2006-12-06 Current Status: Active Working Group Chair(s): Geoff Huston Operations and Management Area Director(s): Dan Romascanu David Kessens Operations and Management Area Advisor: David Kessens Technical Advisor(s): Bill Fenner Vijay Gill Mailing Lists: General Discussion:grow@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/grow Archive: http://www1.ietf.org/mail-archive/web/grow/current/index.html 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 Mar 2007 MRT routing information export format Host Identity Protocol (hip) ---------------------------- Charter Last Modified: 2006-11-03 Current Status: Active Working Group Chair(s): David Ward Gonzalo Camarillo Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Mark Townsley Mailing Lists: General Discussion:hipsec@ietf.org To Subscribe: http://www1.ietf.org/mailman/listinfo/hipsec Archive: http://www.ietf.org/mail-archive/web/hipsec/index.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. There are five publicly known interoperating HIP 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. Additionally, in order to facilitate experimenting with HIP, there is a need to study the interactions of HIP with legacy NATS and legacy applications, and to describe an API for HIP. +----------------------------------------------------------+ | The purpose of this Working Group is to define the | | minimal elements that are needed for HIP experimentation | | on a wide scale. | +----------------------------------------------------------+ In particular, the objective of this working group is to complete the base protocol specification, define one or more DNS resource records for storing HIP related data, complete the existing work on basic mobility and multi-homing, complete the work on NATs and on APIs, and produce Experimental RFCs for these. 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 in the large. There is a roughly parallel, though perhaps considerably broader, IRTF Research Group 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 applications and the Internet. 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. There are five publicly known interoperating HIP 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. Additionally, in order to facilitate experimenting with HIP, there is a need to study the interactions of HIP with legacy NATS and legacy applications, and to describe an API for HIP. +----------------------------------------------------------+ | The purpose of this Working Group is to define the | | minimal elements that are needed for HIP experimentation | | on a wide scale. | +----------------------------------------------------------+ In particular, the objective of this working group is to complete the base protocol specification, define one or more DNS resource records for storing HIP related data, complete the existing work on basic mobility and multi-homing, complete the work on NATs and on APIs, and produce Experimental RFCs for these. 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 in the large. There is a roughly parallel, though perhaps considerably broader, IRTF Research Group 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 applications and the Internet. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jun 2004 Feb 2007 Host Identity Protocol Oct 2004 Mar 2007 End-Host Mobility and Multihoming with the Host Identity Protocol Oct 2004 Oct 2006 Host Identity Protocol (HIP) Domain Name System (DNS) Extensions Oct 2004 Jun 2006 Host Identity Protocol (HIP) Rendezvous Extension Jul 2005 Feb 2007 Using ESP transport format with HIP Sep 2005 Jun 2006 Host Identity Protocol (HIP) Registration Extension Nov 2006 Mar 2007 HIP Extensions for the Traversal of Network Address Translators Nov 2006 Mar 2007 Native Application Programming Interfaces for SHIM Layer Prococols Nov 2006 Nov 2006 Using HIP with Legacy Applications Handover Keying (hokey) ----------------------- Charter Last Modified: 2007-02-23 Current Status: Active Working Group Chair(s): Charles Clancy Glen Zorn Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Russ Housley 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 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 ------ ------- -------------------------------------------- Jan 2007 Jan 2007 Handover Key Management and Re-authentication Problem Statement Jan 2007 Jan 2007 Specification for the Derivation of Usage Specific Root Keys (USRK) from an Extended Master Session Key (EMSK) Ethernet Interfaces and Hub MIB (hubmib) ---------------------------------------- Charter Last Modified: 2007-01-30 Current Status: Active Working Group Chair(s): Bert Wijnen Operations and Management Area Director(s): Dan Romascanu David Kessens Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion:hubmib@ietf.org To Subscribe: hubmib-request@ietf.org In Body: subscribe your_email_address Archive: http://www.ietf.org/mail-archive/web/hubmib/index.html Description of Working Group: The Ethernet Interfaces and Hub MIB WG is Chartered to define a set of managed objects that instrument devices, MAUs and interfaces that conform to the IEEE 802.3 standard for Ethernet. This set of objects should be largely compliant with, and even draw from IEEE 802.3, although there is no requirement that any specific object be present or absent. Close coordination with hardware standards development in IEEE 802.3 will be followed. The WG chair will support the communication with IEEE 802.3. When objects are added that require hardware support, IEEE 802.3 shall be informed, so that they consider to add them to their draft/standard. The MIB object definitions produced will be for use by SNMP and will be adequately consistent with other SNMP objects, standards and conventions. The working group will work on the following MIB modules for the IEEE 802.3ah (Ethernet First Mile) interfaces and devices: - Ethernet First Mile (EFM) MIB common attributes, OAM operations and statistics - Copper EFM MIB - Ethernet Passive Optical Networks (EPON) MIB The base for the definition of the managed objects in these MIB modules will be the management-related clauses in IEEE 802.3ah specification. The working group will also take into consideration management objects defined by other Working Groups in the IETF (ADSL MIB for example), or other standard bodies (G.983.2), will avoid work duplication, and describe the relationship with these specifications. The working group will also work on a revision of the MAU MIB so that it refers a IANA maintained TC for MAU types. This will allow to add new MAU types in the future as the Ethernet evolution requires without re-opening the MAU MIB RFC each time. Description of Working Group: The Ethernet Interfaces and Hub MIB WG is Chartered to define a set of managed objects that instrument devices, MAUs and interfaces that conform to the IEEE 802.3 standard for Ethernet. This set of objects should be largely compliant with, and even draw from IEEE 802.3, although there is no requirement that any specific object be present or absent. Close coordination with hardware standards development in IEEE 802.3 will be followed. The WG chair will support the communication with IEEE 802.3. When objects are added that require hardware support, IEEE 802.3 shall be informed, so that they consider to add them to their draft/standard. The MIB object definitions produced will be for use by SNMP and will be adequately consistent with other SNMP objects, standards and conventions. The working group will work on the following MIB modules for the IEEE 802.3ah (Ethernet First Mile) interfaces and devices: - Ethernet First Mile (EFM) MIB common attributes, OAM operations and statistics - Copper EFM MIB - Ethernet Passive Optical Networks (EPON) MIB The base for the definition of the managed objects in these MIB modules will be the management-related clauses in IEEE 802.3ah specification. The working group will also take into consideration management objects defined by other Working Groups in the IETF (ADSL MIB for example), or other standard bodies (G.983.2), will avoid work duplication, and describe the relationship with these specifications. The working group will also work on a revision of the MAU MIB so that it refers a IANA maintained TC for MAU types. This will allow to add new MAU types in the future as the Ethernet evolution requires without re-opening the MAU MIB RFC each time. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jan 2004 Nov 2006 Managed Objects of Ethernet Passive Optical Networks (EPON) Jan 2004 Feb 2007 Ethernet in the First Mile Copper (EFMCu) Interfaces MIB Feb 2004 Feb 2007 Definitions and Managed Objects for OAM Functions on Ethernet Like Interfaces Apr 2005 Jul 2006 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) Inter-Domain Routing (idr) -------------------------- Charter Last Modified: 2006-01-25 Current Status: Active Working Group Chair(s): Susan Hares Yakov Rekhter Routing Area Director(s): Ross Callon Bill Fenner Routing Area Advisor: Bill Fenner 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. 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. 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 ------ ------- -------------------------------------------- Sep 2000 Sep 2006 Outbound Route Filtering Capability for BGP-4 Jan 2001 Feb 2007 BGP Support for Four-octet AS Number Space Jul 2001 Feb 2007 Aspath Based Outbound Route Filter for BGP-4 Aug 2001 Nov 2006 Dynamic Capability for BGP-4 Feb 2002 Nov 2006 AS-wide Unique BGP Identifier for BGP-4 Aug 2003 Feb 2007 Autonomous System Confederations for BGP May 2004 Jan 2007 Multisession BGP May 2004 Dec 2005 Avoid BGP Best Path Transitions from One External to Another Aug 2004 Jul 2006 Address Prefix Based Outbound Route Filter for BGP-4 Jan 2006 Jan 2007 The AS_PATHLIMIT Path Attribute Internet Emergency Preparedness (ieprep) ---------------------------------------- Charter Last Modified: 2006-03-24 Current Status: Active Working Group Chair(s): Scott Bradner Kimberly King Real-time Applications and Infrastructure Area Director(s): Jon Peterson Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Jon Peterson Mailing Lists: General Discussion:ieprep@ietf.org To Subscribe: ieprep-request@ietf.org In Body: subscribe ieprep Archive: http://www.ietf.org/mail-archive/web/ieprep/index.html Description of Working Group: Effective telecommunications capabilities are imperative to facilitate immediate recovery operations for serious disaster events, such as, hurricanes, floods, earthquakes, and terrorist attacks. Disasters can happen any time, any place, unexpectedly. Quick response for recovery operations requires immediate access to any public telecommunications capabilities at hand. These capabilities include: conventional telephone, cellular phones, and Internet access via online terminals, IP telephones, and wireless PDAs. The commercial telecommunications infrastructure is rapidly evolving to Internet-based technology. Therefore, the Internet community needs to consider how it can best support emergency management and recovery operations. Three examples of emergency communications include: 1. Conveying information about the priority of specific phone calls that originate in a VoIP environment through gateways to the PSTN. 2. Access and transport for database and information distribution applications relevant to managing the crisis. One example of this is the I am Alive (IAA) system that can be used by people in a disaster zone to register the fact that they are alive so that their friends and family can check on their health. 3. Interpersonal communication among crisis management personnel using electronic mail and instant messaging. Initial documents will describe the problem space and its salient characteristics. In particular the working group will devlop a Requirements for Internet Emergency Preparedness in the Internet RFC which will detail the specific functions and technologies needed to provide support for Emergency Preparedness systems in the Internet. The working group may also develop a Framework for Supporting Internet Emergency Preparedness in IP Telephony RFC if it is determined that IP telephony requires special treatment above what would be in the requirements document. The international community needs advice as to what standards to rely on, in the form of a BCP. This BCP needs to identify mechanisms to provide deterministic behavior of applications, mechanisms for authentication and authorization, and recommendations for application design with existing protocols. In the IETF considerations for treatment and security of emergency communications stretch across a number of Areas and Working Groups, notably including the various telephony signaling working groups, Differentiated Services, Protocol for carrying Authentication for Network Access (pana), and various operational groups, so the IEPREP working group will have to cooperate closely with these groups and with groups outside of the IETF such as various ITU-T study groups. The working group will develop a BCP RFC or set of RFCs, regarding operational implementation of services for Emergency Preparedness using existing Internet protocols. The RFC may include identification of gaps in existing protocols and requirements for use in new protocol or protocol feature design. It is out of scope for this working group to do protocol or protocol feature development. The working group will not focus on particular national regulations. Deliverables Best Current Practice: IETF Recommendations for the Emergency Telecommunications Service using existing protocols - what can be done with existing protcols and what can not be done. Informational: Requirements for Internet Emergency Preparedness in the Internet. Framework for Supporting Internet Emergency Preparedness in IP Telephony. Description of Working Group: Effective telecommunications capabilities are imperative to facilitate immediate recovery operations for serious disaster events, such as, hurricanes, floods, earthquakes, and terrorist attacks. Disasters can happen any time, any place, unexpectedly. Quick response for recovery operations requires immediate access to any public telecommunications capabilities at hand. These capabilities include: conventional telephone, cellular phones, and Internet access via online terminals, IP telephones, and wireless PDAs. The commercial telecommunications infrastructure is rapidly evolving to Internet-based technology. Therefore, the Internet community needs to consider how it can best support emergency management and recovery operations. Three examples of emergency communications include: 1. Conveying information about the priority of specific phone calls that originate in a VoIP environment through gateways to the PSTN. 2. Access and transport for database and information distribution applications relevant to managing the crisis. One example of this is the I am Alive (IAA) system that can be used by people in a disaster zone to register the fact that they are alive so that their friends and family can check on their health. 3. Interpersonal communication among crisis management personnel using electronic mail and instant messaging. Initial documents will describe the problem space and its salient characteristics. In particular the working group will devlop a Requirements for Internet Emergency Preparedness in the Internet RFC which will detail the specific functions and technologies needed to provide support for Emergency Preparedness systems in the Internet. The working group may also develop a Framework for Supporting Internet Emergency Preparedness in IP Telephony RFC if it is determined that IP telephony requires special treatment above what would be in the requirements document. The international community needs advice as to what standards to rely on, in the form of a BCP. This BCP needs to identify mechanisms to provide deterministic behavior of applications, mechanisms for authentication and authorization, and recommendations for application design with existing protocols. In the IETF considerations for treatment and security of emergency communications stretch across a number of Areas and Working Groups, notably including the various telephony signaling working groups, Differentiated Services, Protocol for carrying Authentication for Network Access (pana), and various operational groups, so the IEPREP working group will have to cooperate closely with these groups and with groups outside of the IETF such as various ITU-T study groups. The working group will develop a BCP RFC or set of RFCs, regarding operational implementation of services for Emergency Preparedness using existing Internet protocols. The RFC may include identification of gaps in existing protocols and requirements for use in new protocol or protocol feature design. It is out of scope for this working group to do protocol or protocol feature development. The working group will not focus on particular national regulations. Deliverables Best Current Practice: IETF Recommendations for the Emergency Telecommunications Service using existing protocols - what can be done with existing protcols and what can not be done. Informational: Requirements for Internet Emergency Preparedness in the Internet. Framework for Supporting Internet Emergency Preparedness in IP Telephony. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jan 2004 Dec 2006 A Framework for Supporting Emergency Telecommunications Services (ETS) Within a Single Administrative Domain Internet Message Access Protocol Extension (imapext) ---------------------------------------------------- Charter Last Modified: 2006-03-29 Current Status: Active Working Group Chair(s): Pete Resnick Applications Area Director(s): Ted Hardie Lisa Dusseault Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion:ietf-imapext@imc.org To Subscribe: ietf-imapext-request@imc.org Archive: http://www.imc.org/ietf-imapext/ Description of Working Group: The IETF IMAP extensions Working Group shall revise and publish standards-track extensions to IMAP4 for performing the following functions: 1. Sorting, threading, and viewing (to be dealt with by one or more mechanisms) 2. Access Control Lists 3. Message-level annotations Revising the base IMAP4rev1 specification is out of the scope of this WG. However, this WG will ensure that whatever extensions it does propose do not worsen any existing problems in the base specification of IMAP, nor do they make any such problems harder to address in the future. Description of Working Group: The IETF IMAP extensions Working Group shall revise and publish standards-track extensions to IMAP4 for performing the following functions: 1. Sorting, threading, and viewing (to be dealt with by one or more mechanisms) 2. Access Control Lists 3. Message-level annotations Revising the base IMAP4rev1 specification is out of the scope of this WG. However, this WG will ensure that whatever extensions it does propose do not worsen any existing problems in the base specification of IMAP, nor do they make any such problems harder to address in the future. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Aug 1999 Nov 2006 INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS Jul 2000 Oct 2006 IMAP ANNOTATE Extension Oct 2000 Sep 2006 IMAP4 LIST Command Extensions May 2003 Mar 2007 Internet Message Access Protocol Internationalization Internet and Management Support for Storage (imss) -------------------------------------------------- Charter Last Modified: 2007-02-26 Current Status: Active Working Group Chair(s): David Black Operations and Management Area Director(s): Dan Romascanu David Kessens Operations and Management Area Advisor: Dan Romascanu Technical Advisor(s): Keith McCloghrie Margaret Wasserman Mailing Lists: General Discussion:imss@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/imss Archive: http://www.ietf.org/mail-archive/web/imss/index.html Description of Working Group: Fibre Channel is a high speed network technology primarily used for storage networking (i.e., Storage Area Networks [SANs]). Two important aspects of Fibre Channel interact with the Internet: - Fibre Channel can encapsulate and carry IP protocol traffic - Fibre Channel devices can be managed via SNMP The Internet and Management Support for Storage WG (imss) is chartered to address two areas, specifically: - IPv4 over Fibre Channel has been specified in RFC 2625. A corresponding specification for IPv6 is needed. - An initial Fibre Channel Management MIB has been developed by the IP Storage (ips) WG; extensions are needed to encompass management of additional aspects of Fibre Channel, such as zoning. In the future, other storage related MIBs for other storage transports such as INCITS T10 Serial Attached SCSI (SAS) or SCSI command specific MIBs may be proposed. This group would work with the appropriate technical committee(s) in a manner similar to that described for INCITS T11 below. As Fibre Channel standardization is handled by the INCITS T11 Technical Committee (http://www.t11.org), a close working relationship with T11 is essential to the WG's success. In particular: - The IPv6 over Fibre Channel specification will be based on draft-desanti-ipv6-over-fibre-channel-02.txt. This draft was originally developed within a T11 study group and T11 has officially recommended this draft to the IETF. - The WG will not standardize management of Fibre Channel features ahead of their incorporation into appropriate T11 Fibre Channel standards. - The WG will work closely with T11, specifically Task Group T11.5, on the functionality and structure of the MIBs it develops for management of Fibre Channel. In addition to working closely with the INCITS T11 Technical Committee, this Working Group will work closely with IETF IPv6 Working Group as appropriate. In particular, the IPv6 Working Group will be kept informed on the progress and status of the IPv6 over Fibre Channel specification. The IMSS Working Group Last Call announcement will be cross-posted to the IPv6 WG mailing list. Description of Working Group: Fibre Channel is a high speed network technology primarily used for storage networking (i.e., Storage Area Networks [SANs]). Two important aspects of Fibre Channel interact with the Internet: - Fibre Channel can encapsulate and carry IP protocol traffic - Fibre Channel devices can be managed via SNMP The Internet and Management Support for Storage WG (imss) is chartered to address two areas, specifically: - IPv4 over Fibre Channel has been specified in RFC 2625. A corresponding specification for IPv6 is needed. - An initial Fibre Channel Management MIB has been developed by the IP Storage (ips) WG; extensions are needed to encompass management of additional aspects of Fibre Channel, such as zoning. In the future, other storage related MIBs for other storage transports such as INCITS T10 Serial Attached SCSI (SAS) or SCSI command specific MIBs may be proposed. This group would work with the appropriate technical committee(s) in a manner similar to that described for INCITS T11 below. As Fibre Channel standardization is handled by the INCITS T11 Technical Committee (http://www.t11.org), a close working relationship with T11 is essential to the WG's success. In particular: - The IPv6 over Fibre Channel specification will be based on draft-desanti-ipv6-over-fibre-channel-02.txt. This draft was originally developed within a T11 study group and T11 has officially recommended this draft to the IETF. - The WG will not standardize management of Fibre Channel features ahead of their incorporation into appropriate T11 Fibre Channel standards. - The WG will work closely with T11, specifically Task Group T11.5, on the functionality and structure of the MIBs it develops for management of Fibre Channel. In addition to working closely with the INCITS T11 Technical Committee, this Working Group will work closely with IETF IPv6 Working Group as appropriate. In particular, the IPv6 Working Group will be kept informed on the progress and status of the IPv6 over Fibre Channel specification. The IMSS Working Group Last Call announcement will be cross-posted to the IPv6 WG mailing list. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Aug 2006 Nov 2006 Fibre Channel Registered State Change Notification (RSCN) MIB Aug 2006 Jan 2007 Fibre-Channel Fabric Configuration Server MIB Aug 2006 Jan 2007 Fibre-Channel Zone Server MIB IP over Cable Data Network (ipcdn) ---------------------------------- Charter Last Modified: 2006-12-18 Current Status: Active Working Group Chair(s): Richard Woundy Jean-Francois Mule Operations and Management Area Director(s): Dan Romascanu David Kessens Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion:ipcdn@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/ipcdn Archive: http://www.ietf.org/mail-archive/web/ipcdn/index.html Description of Working Group: The IETF IPCDN Working Group develops and standardizes MIBs for IP-capable data-over-cable systems, for example cable modems, multimedia terminal adapters and associated cable-data equipment in a cable headend. These MIBs cover not only cable data interfaces, but also management of cable-data equipment and systems. The WG mailing list may be used to discuss Internet-related issues in data-over-cable equipment and systems. In the event of a particular new Internet technology issue arising in the cable-data context, the WG will identify whether that is best handled within the IETF or is best handled by another standards body. In the event that new IETF MIB work is requested, the WG chairs can discuss additional WG work items with the AD. Such additions will have to go through normal re-charter process. If non-MIB work gets identified, such items are not normal work items for this IPCDN-MIB WG and must go through normal IETF new WG chartering process. Standardization of MIBs for DOCSIS and PacketCable systems are explicitly within the scope of the IPCDN Working Group. The IPCDN WG will also keep informed on what other groups in the industry are doing as it relates to the efforts of this working group. The WG will align its specifications with IPv6 and SNMP Standards. Related groups: CableLabs (http://www.cablelabs.com/) is structured into projects. In its Cable Modem DOCSIS project, CableLabs has produced three generations of data over cable specifications: DOCSIS 1.0, DOCSIS 1.1, and DOCSIS 2.0. In its PacketCable project, CableLabs has produced one generation of interface specifications for delivering real-time multimedia services over DOCSIS (http://www.packetcable.com/specifications/). Internationally, IPCablecom is the global name associated with the extensions & global standardization of PacketCable in ETSI & ITU-T SG9. DOCSIS 1.0 includes specifications for a bidirectional data-over-cable interface (RFI, or Radio Frequency Interface) and a data privacy service (BPI, or Baseline Privacy Interface). The key devices in a DOCSIS network are the Cable Modem (CM, the device at the subscriber premise) and the Cable Modem Termination System (CMTS, the device at the cable headend). For DOCSIS 1.0 systems, the IPCDN WG has published the Cable Device MIB (RFC 2669), the RF Interface MIB (RFC 2670), and the Baseline Privacy MIB (RFC 3083). DOCSIS 1.1 extends the DOCSIS 1.0 specifications to support better quality of service parameters (RFIv1.1), to enable operation in European cable networks (EuroDOCSIS), and to authenticate modems and firmware images (BPI+). The IPCDN WG will update the Cable Device and Radio Frequency MIBs for DOCSIS 1.1, and repair flaws discovered in operational use. Other IPCDN WG documents will address the operational and management issues for new DOCSIS 1.1 functional components (e.g. BPI+), for subscriber device management, and for uniform event notification. The IPCDN WG has also published the DOCSIS Subscriber Management MIB (RFC4036) for DOCSIS 1.1 and 2.0 systems. DOCSIS 2.0 enhances the DOCSIS 1.1 specifications at the physical layer, in particular to support two new physical layer encodings: S-CDMA and A-TDMA. The IPCDN WG will update the Radio Frequency MIB for DOCSIS 2.0. PacketCable 1.0 is built on top of the DOCSIS 1.1 cable modem infrastructure and it includes a suite of interface specifications covering multimedia terminal adapter (MTA) device provisioning, voice over IP session signaling, QoS signaling based on IETF standards. The key systems in a PacketCable network are the multimedia terminal adapter (MTA), a Call Management Server (CMS), a PacketCable-compliant DOCSIS 1.1 CMTS, Media Gateway Controllers, Media Gateways along with back-office systems. In ITU-T SG-9 and ETSI AT, IPCableCom has standardized PacketCable to create a set of international standards. Work items: The IPCDN WG will address issues related to network management, especially as they concern HFC access networks. It is expected that other services (i.e. RSVP, IPSEC, etc.) will operate mostly unmodified. The specific work items include -- DOCSIS, - publish MIB documents for: - subscriber device management on a DOCSIS 1.1 CMTS, - managing the quality of service parameters for a DOCSIS 1.1 device, - managing the Baseline Privacy Plus system for a DOCSIS 1.1 device, - uniform event notification on a DOCSIS 1.1 device, - revise MIB documents for: - DOCSIS 1.0 RF Interface MIB to support EuroDOCSIS parameters and DOCSIS 2.0 physical layer management, - the DOCSIS 1.0 Cable Device MIBs to address SNMPv3 and IPv6 compliance and interoperability issues, -- IPCablecom & PacketCable - publish MIB documents for: - managing the device parameters of PacketCable/IPCableCom MTA devices, - managing the signaling parameters of PacketCable/IPCableCom MTA devices, - managing events for PacketCable/IPCablecom systems, Description of Working Group: The IETF IPCDN Working Group develops and standardizes MIBs for IP-capable data-over-cable systems, for example cable modems, multimedia terminal adapters and associated cable-data equipment in a cable headend. These MIBs cover not only cable data interfaces, but also management of cable-data equipment and systems. The WG mailing list may be used to discuss Internet-related issues in data-over-cable equipment and systems. In the event of a particular new Internet technology issue arising in the cable-data context, the WG will identify whether that is best handled within the IETF or is best handled by another standards body. In the event that new IETF MIB work is requested, the WG chairs can discuss additional WG work items with the AD. Such additions will have to go through normal re-charter process. If non-MIB work gets identified, such items are not normal work items for this IPCDN-MIB WG and must go through normal IETF new WG chartering process. Standardization of MIBs for DOCSIS and PacketCable systems are explicitly within the scope of the IPCDN Working Group. The IPCDN WG will also keep informed on what other groups in the industry are doing as it relates to the efforts of this working group. The WG will align its specifications with IPv6 and SNMP Standards. Related groups: CableLabs (http://www.cablelabs.com/) is structured into projects. In its Cable Modem DOCSIS project, CableLabs has produced three generations of data over cable specifications: DOCSIS 1.0, DOCSIS 1.1, and DOCSIS 2.0. In its PacketCable project, CableLabs has produced one generation of interface specifications for delivering real-time multimedia services over DOCSIS (http://www.packetcable.com/specifications/). Internationally, IPCablecom is the global name associated with the extensions & global standardization of PacketCable in ETSI & ITU-T SG9. DOCSIS 1.0 includes specifications for a bidirectional data-over-cable interface (RFI, or Radio Frequency Interface) and a data privacy service (BPI, or Baseline Privacy Interface). The key devices in a DOCSIS network are the Cable Modem (CM, the device at the subscriber premise) and the Cable Modem Termination System (CMTS, the device at the cable headend). For DOCSIS 1.0 systems, the IPCDN WG has published the Cable Device MIB (RFC 2669), the RF Interface MIB (RFC 2670), and the Baseline Privacy MIB (RFC 3083). DOCSIS 1.1 extends the DOCSIS 1.0 specifications to support better quality of service parameters (RFIv1.1), to enable operation in European cable networks (EuroDOCSIS), and to authenticate modems and firmware images (BPI+). The IPCDN WG will update the Cable Device and Radio Frequency MIBs for DOCSIS 1.1, and repair flaws discovered in operational use. Other IPCDN WG documents will address the operational and management issues for new DOCSIS 1.1 functional components (e.g. BPI+), for subscriber device management, and for uniform event notification. The IPCDN WG has also published the DOCSIS Subscriber Management MIB (RFC4036) for DOCSIS 1.1 and 2.0 systems. DOCSIS 2.0 enhances the DOCSIS 1.1 specifications at the physical layer, in particular to support two new physical layer encodings: S-CDMA and A-TDMA. The IPCDN WG will update the Radio Frequency MIB for DOCSIS 2.0. PacketCable 1.0 is built on top of the DOCSIS 1.1 cable modem infrastructure and it includes a suite of interface specifications covering multimedia terminal adapter (MTA) device provisioning, voice over IP session signaling, QoS signaling based on IETF standards. The key systems in a PacketCable network are the multimedia terminal adapter (MTA), a Call Management Server (CMS), a PacketCable-compliant DOCSIS 1.1 CMTS, Media Gateway Controllers, Media Gateways along with back-office systems. In ITU-T SG-9 and ETSI AT, IPCableCom has standardized PacketCable to create a set of international standards. Work items: The IPCDN WG will address issues related to network management, especially as they concern HFC access networks. It is expected that other services (i.e. RSVP, IPSEC, etc.) will operate mostly unmodified. The specific work items include -- DOCSIS, - publish MIB documents for: - subscriber device management on a DOCSIS 1.1 CMTS, - managing the quality of service parameters for a DOCSIS 1.1 device, - managing the Baseline Privacy Plus system for a DOCSIS 1.1 device, - uniform event notification on a DOCSIS 1.1 device, - revise MIB documents for: - DOCSIS 1.0 RF Interface MIB to support EuroDOCSIS parameters and DOCSIS 2.0 physical layer management, - the DOCSIS 1.0 Cable Device MIBs to address SNMPv3 and IPv6 compliance and interoperability issues, -- IPCablecom & PacketCable - publish MIB documents for: - managing the device parameters of PacketCable/IPCableCom MTA devices, - managing the signaling parameters of PacketCable/IPCableCom MTA devices, - managing events for PacketCable/IPCablecom systems, Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2002 Mar 2007 Network-Based Call Signaling (NCS) MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs) Oct 2002 Oct 2006 Management Event MIB for PacketCable/IPCablecom MTAs IP over DVB (ipdvb) ------------------- Charter Last Modified: 2007-02-13 Current Status: Active Working Group Chair(s): Gorry Fairhurst Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Mark Townsley 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: Posted Revised I-D Title ------ ------- -------------------------------------------- Jun 2005 Mar 2007 Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks Dec 2006 Mar 2007 Security requirements for the Unidirectional Lightweight Encapsulation (ULE) protocol Jan 2007 Mar 2007 Extension Formats for Unidirectional Link Encapsulation (ULE) and the Generic Stream Encapsulation (GSE) IP Flow Information Export (ipfix) ---------------------------------- Charter Last Modified: 2007-03-06 Current Status: Active Working Group Chair(s): Nevil Brownlee Juergen Quittek Operations and Management Area Director(s): Dan Romascanu David Kessens Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion:ipfix@ietf.org To Subscribe: http://www1.ietf.org/mailman/listinfo/ipfix Archive: http://www1.ietf.org/mail-archive/web/ipfix/current/index.html 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). The PSAMP working group has specified the usage of the IPFIX protocol for exporting packet records. With both specifications available, several implementers have started building applications using the IPFIX protocol. At two interoperability testing events, several IPFIX protocol implementations were tested. The experiences made at these events were fed back to IPFIX protocol specification, particularly for removing ambiguities. In addition, several lessons were learned about how to implement and use IPFIX correctly and efficiently. The exchange among different implementers further led to new ideas for advanced usage of IPFIX. Many of these ideas are currently documented in individual Internet drafts. The goal of the IPFIX working group is now to produce 'best current practice' and 'guideline' documents concerning implementation, application and usage of the IPFIX protocol. Modifications to the core IPFIX and PSAMP protocol specifications is out of scope for this charter. However, the definition of new IPFIX and PSAMP information elements is within the scope of this charter. Specific Goals o Develop guidelines for implementers based on experiences gained individually by implementers and jointly at interoperability testing events. The guidelines will give recommendations for integrating IPFIX observation points, metering processes, exporting processes and collecting processes into the packet flow at different kinds of IPFIX devices. They will make suggestions for efficient implementation of the IPFIX protocol features and identify parts of the IPFIX specification that have already been misunderstood by several implementors. For some implementation choices that the protocol specification leaves to the implementer, the guidelines will discuss advantages and disadvantages of the different choices. Several recent individual drafts call for new Information Elements; The implementation guidelines will explain procedures for requesting, reviewing and approving new IEs. Deliverables: 1. IPFIX Implementation Guidelines draft, to be an Informational RFC (6 months) 2. IPFIX Testing draft, to be an Informational RFC (6 months) o Develop methods and means for an efficient use of the IPFIX protocol by reducing redundancy in flow reports. The basic idea to be followed is very simple. For multiple flow records that all report the same value in one or more of the contained IPFIX information elements, those values are removed from the flow records and instead reported once for all in a separate record. Such an approach integrates very well with the IPFIX protocol and only needs a few simple methods for expressing the relationship between flow records and corresponding separate records. Deliverable: 3. IPFIX Reducing Redundancy, to be an Informational RFC (6 months) o Create an IPFIX MIB, for reporting information and statistics of IPFIX metering, exporting and collecing processes. Much of this work has already been done by the PSAMP working group, and by individuals working on IPFIX collectors. Deliverable: 4. IPFIX MIB, to be a Standards Track RFC (12 months) o Develop an effective method for exporting information about bidirectional flows ('biflows'). The IP security community has expressed a strong need to collect data on bidrectional flows. A recent individual draft discusses several different ways to support biflows in IPFIX - this work will produce a single, best-practice method for handling them, without requiring changes to the IPFIX protocol. Deliverable: 5. IPFIX Biflow draft, to be an Informational RFC (12 months) 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). The PSAMP working group has specified the usage of the IPFIX protocol for exporting packet records. With both specifications available, several implementers have started building applications using the IPFIX protocol. At two interoperability testing events, several IPFIX protocol implementations were tested. The experiences made at these events were fed back to IPFIX protocol specification, particularly for removing ambiguities. In addition, several lessons were learned about how to implement and use IPFIX correctly and efficiently. The exchange among different implementers further led to new ideas for advanced usage of IPFIX. Many of these ideas are currently documented in individual Internet drafts. The goal of the IPFIX working group is now to produce 'best current practice' and 'guideline' documents concerning implementation, application and usage of the IPFIX protocol. Modifications to the core IPFIX and PSAMP protocol specifications is out of scope for this charter. However, the definition of new IPFIX and PSAMP information elements is within the scope of this charter. Specific Goals o Develop guidelines for implementers based on experiences gained individually by implementers and jointly at interoperability testing events. The guidelines will give recommendations for integrating IPFIX observation points, metering processes, exporting processes and collecting processes into the packet flow at different kinds of IPFIX devices. They will make suggestions for efficient implementation of the IPFIX protocol features and identify parts of the IPFIX specification that have already been misunderstood by several implementors. For some implementation choices that the protocol specification leaves to the implementer, the guidelines will discuss advantages and disadvantages of the different choices. Several recent individual drafts call for new Information Elements; The implementation guidelines will explain procedures for requesting, reviewing and approving new IEs. Deliverables: 1. IPFIX Implementation Guidelines draft, to be an Informational RFC (6 months) 2. IPFIX Testing draft, to be an Informational RFC (6 months) o Develop methods and means for an efficient use of the IPFIX protocol by reducing redundancy in flow reports. The basic idea to be followed is very simple. For multiple flow records that all report the same value in one or more of the contained IPFIX information elements, those values are removed from the flow records and instead reported once for all in a separate record. Such an approach integrates very well with the IPFIX protocol and only needs a few simple methods for expressing the relationship between flow records and corresponding separate records. Deliverable: 3. IPFIX Reducing Redundancy, to be an Informational RFC (6 months) o Create an IPFIX MIB, for reporting information and statistics of IPFIX metering, exporting and collecing processes. Much of this work has already been done by the PSAMP working group, and by individuals working on IPFIX collectors. Deliverable: 4. IPFIX MIB, to be a Standards Track RFC (12 months) o Develop an effective method for exporting information about bidirectional flows ('biflows'). The IP security community has expressed a strong need to collect data on bidrectional flows. A recent individual draft discusses several different ways to support biflows in IPFIX - this work will produce a single, best-practice method for handling them, without requiring changes to the IPFIX protocol. Deliverable: 5. IPFIX Biflow draft, to be an Informational RFC (12 months) Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2002 Sep 2006 Architecture for IP Flow Information Export Jun 2003 Feb 2007 Information Model for IP Flow Information Export Jun 2003 Nov 2006 Specification of the IPFIX Protocol for the Exchange Jun 2003 Feb 2007 IPFIX Applicability Sep 2006 Feb 2007 IPFIX Implementation Guidelines Sep 2006 Mar 2007 Reducing Redundancy in IPFIX and PSAMP Reports Sep 2006 Mar 2007 Bidirectional Flow Export using IPFIX Oct 2006 Oct 2006 IP Flow Information eXport (IPFIX) Testing Feb 2007 Feb 2007 Definitions of Managed Objects for IP Flow Information Export IP over Resilient Packet Rings (iporpr) --------------------------------------- Charter Last Modified: 2005-05-03 Current Status: Active Working Group Chair(s): Glenn Parsons Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Mark Townsley Mailing Lists: General Discussion:iporpr@ietf.org To Subscribe: iporpr-request@ietf.org In Body: subscribe iporpr Archive: http://www.ietf.org/mail-archive/web/iporpr/index.html Description of Working Group: Resilient Packet Rings (RPR), developed within the IEEE 802.17 RPR WG, provides substantial enhancements in both efficiency and flexibility over current bi-directional ring topologies. Benefits of resilient packet rings include spatial re-use (full utilization of both counter-rotating rings) while maintaining protection switching during media faults, as well as defined mechanisms for topology discovery, congestion control, and protection switching. Reference the IEEE 802.17 RPR WG at http://www.ieee802.org/17/ for further information. IEEE 802.17-2004 is currently published and work is in progress on bridging enhancements. The IPORPR Working Group will produce two documents: 1) An IPORPR definition of how to transport IP/MPLS over 802.17 RPR in "basic mode". This document will cover encapsulation formats (e.g., IPv4/IPv6), how to perform address resolution (e.g., ARP/ND), IP multicast transmission, priority mapping to the RPR "serviceClass", etc. 2) An IPORPR framework that goes beyond "basic mode," describing some of the features and characteristics of 802.17 RPR, and how they might be exploited by, e.g., IP or MPLS. For example, an RPR ring can be accessed in a number of ways: it can be viewed as a "dumb" LAN supporting traditional broadcast like Ethernet ("basic mode"), or its advanced features could be exploited. The IPoRPR WG will coordinate its activities with other appropriate standards bodies and encourage cross participation with those bodies. Coordination will take place with the following bodies in particular: IEEE 802.17 (http://www.ieee802.org/17/) - ITU-T SG15 Q9, 11, 12 (http://www.itu.int/ITU-T/studygroups/com15/sg15.html) Description of Working Group: Resilient Packet Rings (RPR), developed within the IEEE 802.17 RPR WG, provides substantial enhancements in both efficiency and flexibility over current bi-directional ring topologies. Benefits of resilient packet rings include spatial re-use (full utilization of both counter-rotating rings) while maintaining protection switching during media faults, as well as defined mechanisms for topology discovery, congestion control, and protection switching. Reference the IEEE 802.17 RPR WG at http://www.ieee802.org/17/ for further information. IEEE 802.17-2004 is currently published and work is in progress on bridging enhancements. The IPORPR Working Group will produce two documents: 1) An IPORPR definition of how to transport IP/MPLS over 802.17 RPR in "basic mode". This document will cover encapsulation formats (e.g., IPv4/IPv6), how to perform address resolution (e.g., ARP/ND), IP multicast transmission, priority mapping to the RPR "serviceClass", etc. 2) An IPORPR framework that goes beyond "basic mode," describing some of the features and characteristics of 802.17 RPR, and how they might be exploited by, e.g., IP or MPLS. For example, an RPR ring can be accessed in a number of ways: it can be viewed as a "dumb" LAN supporting traditional broadcast like Ethernet ("basic mode"), or its advanced features could be exploited. The IPoRPR WG will coordinate its activities with other appropriate standards bodies and encourage cross participation with those bodies. Coordination will take place with the following bodies in particular: IEEE 802.17 (http://www.ieee802.org/17/) - ITU-T SG15 Q9, 11, 12 (http://www.itu.int/ITU-T/studygroups/com15/sg15.html) Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2005 Aug 2006 Mapping of IP/MPLS packets into IEEE 802.17 (Resilient packet ring) Networks IP Performance Metrics (ippm) ----------------------------- Charter Last Modified: 2007-01-25 Current Status: Active Working Group Chair(s): Henk Uijterwaal Matthew Zekauskas Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Lars Eggert Technical Advisor(s): Andy Bierman Mailing Lists: General Discussion:ippm@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/ippm In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/ippm/index.html Description of Working Group: Note: Andy Bierman serves as MIB advisor. The IPPM WG will develop a set of standard metrics that can be applied to the quality, performance, and reliability of Internet data delivery services. These metrics will be 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 will produce documents that define specific metrics and procedures for accurately measuring and documenting these metrics. The metrics are: - connectivity - one-way delay and loss - round-trip delay and loss - delay variation - loss patterns - packet reordering - bulk transport capacity - link bandwidth capacity This is the cumulative set, including the metricsalready completed and published. The working group will closely review and then be guided by an IESG document on how metrics advance along the standards track within the IETF. This document will also be relevant to the work of the benchmarking working group (BMWG). The first draft of this document was discussed at IETF 51. 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, or multimedia streams. It is specifically out of scope for this working group to actually characterize traffic, for example to characterize a voice-over-IP stream. 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. Specific topics of these AS documents must be approved by the Area Directors as charter additions. The WG will produce a protocol to enable communication among test equipment that implements the one-way metrics. The intent is to create a protocol that provides a base level of functionality that will allow different manufacturer's equipment that implements the metrics according to a standard to interoperate. A protocol requirements document will guide the protocol design. The WG will also produce a MIB to retrieve the results of IPPM metrics, such as one-way delay and loss, to facilitate the communication of metrics to existing network management systems. Thus, the group will create a MIB that contains predominantly read only variables. If, after the protocol requirements document is finished, the group decides that it is appropriate to add variables that control the underlying measurements that the metrics report, such a control structure may be added as a separate document, subject to review by the IESG. The intent of the WG is to cooperate with other appropriate standards bodies and forums (such as T1A1.3, ITU-T SG 12 and SG 13) 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. These include working groups such as BMWG, RMONMIB, and TEWG. Description of Working Group: Note: Andy Bierman serves as MIB advisor. The IPPM WG will develop a set of standard metrics that can be applied to the quality, performance, and reliability of Internet data delivery services. These metrics will be 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 will produce documents that define specific metrics and procedures for accurately measuring and documenting these metrics. The metrics are: - connectivity - one-way delay and loss - round-trip delay and loss - delay variation - loss patterns - packet reordering - bulk transport capacity - link bandwidth capacity This is the cumulative set, including the metricsalready completed and published. The working group will closely review and then be guided by an IESG document on how metrics advance along the standards track within the IETF. This document will also be relevant to the work of the benchmarking working group (BMWG). The first draft of this document was discussed at IETF 51. 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, or multimedia streams. It is specifically out of scope for this working group to actually characterize traffic, for example to characterize a voice-over-IP stream. 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. Specific topics of these AS documents must be approved by the Area Directors as charter additions. The WG will produce a protocol to enable communication among test equipment that implements the one-way metrics. The intent is to create a protocol that provides a base level of functionality that will allow different manufacturer's equipment that implements the metrics according to a standard to interoperate. A protocol requirements document will guide the protocol design. The WG will also produce a MIB to retrieve the results of IPPM metrics, such as one-way delay and loss, to facilitate the communication of metrics to existing network management systems. Thus, the group will create a MIB that contains predominantly read only variables. If, after the protocol requirements document is finished, the group decides that it is appropriate to add variables that control the underlying measurements that the metrics report, such a control structure may be added as a separate document, subject to review by the IESG. The intent of the WG is to cooperate with other appropriate standards bodies and forums (such as T1A1.3, ITU-T SG 12 and SG 13) 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. These include working groups such as BMWG, RMONMIB, and TEWG. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jun 2005 Nov 2006 Defining Network Capacity Nov 2005 Mar 2007 A Two-way Active Measurement Protocol (TWAMP) Jan 2006 Mar 2007 IP Performance Metrics (IPPM) for spatial and multicast Feb 2006 Oct 2006 Spatial Composition of Metrics Feb 2006 Mar 2007 Framework for Metric Composition Jun 2006 Oct 2006 Reporting IP Performance Metrics to Users Jun 2006 Feb 2007 Traceroute Measurements Information Model and XML Data Model Intellectual Property Rights (ipr) ---------------------------------- Charter Last Modified: 2006-03-07 Current Status: Active Working Group Chair(s): Harald Alvestrand Steven Bellovin General Area Director(s): Brian Carpenter General Area Advisor: Brian Carpenter Mailing Lists: General Discussion:ipr-wg@ietf.org To Subscribe: ipr-wg-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/ipr-wg/index.html Description of Working Group: The IETF and the Internet have greatly benefited from the free exchange of ideas and technology. For many years the IETF normal behavior was to standardize only unencumbered technology. While the "Tao" of the IETF is still strongly oriented toward unencumbered technology, we can and do make use of technology that has various encumbrances. One of the goals of the IETF IPR policy has been to make it easier for the IETF to make use of encumbered technology when it made sense to do so. This group has attempted to clarify and update that IPR policy, resulting in RFC 3978, RFC 3979 and RFC 3905. The WG has also discussed the possibility of changing the IETF's patent policy, but did not detect a consensus for doing so. At the time of this recharter (February 2006), there are two remaining items of work for the WG: - An issue with the production of derivative works has led to the realization that RFC 2026 and RFC 3978 do not specify exactly the same policy on this matter, and that neither policy, when read literally, may be optimal for the IETF's purpose, in accordance with its mission statement (RFC 3935), its policy of retaining change control of its own documents, and its desire for its documents to be openly available and useful. - The creation of the IETF Trust for managing the IETF IPR has led to the question of how the Trustees should evaluate the benefit of the IETF community as a whole and if necessary the consensus of the IETF on a given matter. Specifically the question arises whether the previous discussions of the IPR WG have led to experience that should be codified for the guidance of the Trustees. The WG will produce 3 documents: - An update to RFC 3978 (BCP) that attempts to specify a complete set of rights with respect to derivative works granted to the IETF by authors, as well as technical updates necessitated by the existence of the Trust - A document (info) giving advice to the IETF Trust on what rights in IETF contributions it should attempt to grant to the public in order to retain change control while allowing open access, resolving the discrepancy between RFC 2026 and RFC 3978 - A document (info) giving other advice to the IETF Trust on IPR handling, based on the IPR WG's experience of discussions in the area The last document may include advice to the IETF Trust on mechanisms for consulting with the community on IPR issues once the IPR WG has closed, if consensus on such advice can be found. The IPR WG may decide to drop the last document from its charter if it decides that it has nothing to say. All documents should have an IETF-wide Last Call before being approved. Description of Working Group: The IETF and the Internet have greatly benefited from the free exchange of ideas and technology. For many years the IETF normal behavior was to standardize only unencumbered technology. While the "Tao" of the IETF is still strongly oriented toward unencumbered technology, we can and do make use of technology that has various encumbrances. One of the goals of the IETF IPR policy has been to make it easier for the IETF to make use of encumbered technology when it made sense to do so. This group has attempted to clarify and update that IPR policy, resulting in RFC 3978, RFC 3979 and RFC 3905. The WG has also discussed the possibility of changing the IETF's patent policy, but did not detect a consensus for doing so. At the time of this recharter (February 2006), there are two remaining items of work for the WG: - An issue with the production of derivative works has led to the realization that RFC 2026 and RFC 3978 do not specify exactly the same policy on this matter, and that neither policy, when read literally, may be optimal for the IETF's purpose, in accordance with its mission statement (RFC 3935), its policy of retaining change control of its own documents, and its desire for its documents to be openly available and useful. - The creation of the IETF Trust for managing the IETF IPR has led to the question of how the Trustees should evaluate the benefit of the IETF community as a whole and if necessary the consensus of the IETF on a given matter. Specifically the question arises whether the previous discussions of the IPR WG have led to experience that should be codified for the guidance of the Trustees. The WG will produce 3 documents: - An update to RFC 3978 (BCP) that attempts to specify a complete set of rights with respect to derivative works granted to the IETF by authors, as well as technical updates necessitated by the existence of the Trust - A document (info) giving advice to the IETF Trust on what rights in IETF contributions it should attempt to grant to the public in order to retain change control while allowing open access, resolving the discrepancy between RFC 2026 and RFC 3978 - A document (info) giving other advice to the IETF Trust on IPR handling, based on the IPR WG's experience of discussions in the area The last document may include advice to the IETF Trust on mechanisms for consulting with the community on IPR issues once the IPR WG has closed, if consensus on such advice can be found. The IPR WG may decide to drop the last document from its charter if it decides that it has nothing to say. All documents should have an IETF-wide Last Call before being approved. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Mar 2006 Jan 2007 Advice to the IAOC on Rights to be Granted in IETF Documents Oct 2006 Oct 2006 Clarification of the 3rd Party Disclosure procedure in RFC 3979 Mar 2007 Mar 2007 Rights Contributions provide to the IETF Trust IP Storage (ips) ---------------- Charter Last Modified: 2007-02-20 Current Status: Active Working Group Chair(s): David Black Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Lars Eggert Technical Advisor(s): Keith McCloghrie Murali Rajagopal Franco Travostino John Hufferd Mailing Lists: General Discussion:ips@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/ips In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/ips/index.html Description of Working Group: There is significant interest in using IP-based networks to transport block storage traffic. This group will pursue the pragmatic approach of encapsulating existing protocols, such as SCSI and Fibre Channel, in an IP-based transport or transports. The group will focus on the transport or transports and related issues (e.g., security, naming, discovery, and configuration), as opposed to modifying existing protocols. Standards for the protocols to be encapsulated are controlled by other standards organizations (e.g., T10 [SCSI] and T11 [Fibre Channel]). The WG cannot assume that any changes it desires will be made in these standards, and hence will pursue approaches that do not depend on such changes unless they are unavoidable. In that case the WG will create a document to be forwarded to the standards group responsible for the technology explaining the issue and requesting the desired changes be considered. The WG will endeavor to ensure high quality communications with these standards organizations. The WG will consider whether a layered architecture providing common transport, security, and/or other functionality for its encapsulations is the best technical approach. The protocols to be encapsulated expect a reliable transport, in that failure to deliver data is considered to be a rare event for which time-consuming recovery at higher levels is acceptable. This has implications for both the choice of transport protocols and design of the encapsulation(s). The WG's encapsulations may require quality of service assurances (e.g., bounded latency) to operate successfully; the WG will consider what assurances are appropriate and how to provide them in shared traffic environments (e.g., the Internet) based on existing IETF QoS mechanisms such as Differentiated Services. Use of IP-based transports raises issues that do not occur in the existing transports for the protocols to be encapsulated. The WG's protocol encapsulations will incorporate the following: - Congestion control suitable for shared traffic network environments such as the Internet. - Security including authentication, keyed cryptographic data integrity and confidentiality, sufficient to defend against threats up to and including those that can be expected on a public network. Implementation of basic security functionality will be required, although usage may be optional. The WG will also address the following issues related to its protocol encapsulations: - Naming and discovery mechanisms for the encapsulated protocols on IP-based networks, including both discovery of resources (e.g., storage) for access by the discovering entity, and discovery for management. - Management, including appropriate MIB definition(s) for the encapsulations. - By agreement with the IESG, the WG will additionally develop MIB definitions for the SCSI and Fiber Channel standards. The WG specifications will allow the implementation of bridges and gateways that connect to existing implementations of the encapsulated protocols. The WG will preserve the approaches to discovery, multi-pathing, booting, and similar issues taken by the protocols it encapsulates to the extent feasible. It may be necessary for traffic using the WG's encapsulations to pass through Network Address Translators (NATs) and/or firewalls in some circumstances; the WG will endeavor to design NAT- and firewall-friendly protocols that do not dynamically select target ports or require Application Level Gateways. Effective implementations of some IP transports for the encapsulated protocols are likely to require hardware acceleration; the WG will consider issues concerning the effective implementation of its protocols in hardware. The standard internet checksum is weaker than the checksums use by other implementations of the protocols to be encapsulated. The WG will consider what levels of data integrity assurance are required and how they should be achieved. The WG will produce requirements and specification documents for each protocol encapsulation, and may produce applicability statements. The requirements and specification documents will consider both disk and tape devices, taking note of the variation in scale from single drives to large disk arrays and tape libraries, although the requirements and specifications need not encompass all such devices. The WG will not work on: - Extensions to existing protocols such as SCSI and Fibre Channel beyond those strictly necessary for the use of IP-based transports. - Modifications to internet transport protocols or approaches requiring transport protocol options that are not widely supported, although the WG may recommend use of such options for block storage traffic. - Support for environments in which significant data loss or data corruption is acceptable. - File system protocols. Operational Structure: Keith McCloghrie (kzm@cisco.com) will serve as the MIB and Network Management advisor for the WG. Due to the scope of the task and the need for parallel progress on multiple work items, the WG effort is organized as follows: A technical coordinator will be identified and selected for each protocol encapsulation adopted as a work item by the group. This person will be responsible for coordinating the technical efforts of the group with respect to that encapsulation, working with and motivating the document editors, and evangelizing the group's work within both the community and relevant external organizations such as T10 and T11. In addition to the normal responsibilities of IETF working group chairs, the IPS chairs are responsible for selection of coordinators, identifying areas of technical commonality and building cross-technology efforts within the group. Coordinators for initially important encapsulations: SCSI over IP (aka iSCSI): John Hufferd (hufferd@us.ibm.com) Fibre Channel (FC-2) over IP: Murali Rajagopal (muralir@cox.net) iFCP: Franco Travostino (travos@nortelnetworks.com) Description of Working Group: There is significant interest in using IP-based networks to transport block storage traffic. This group will pursue the pragmatic approach of encapsulating existing protocols, such as SCSI and Fibre Channel, in an IP-based transport or transports. The group will focus on the transport or transports and related issues (e.g., security, naming, discovery, and configuration), as opposed to modifying existing protocols. Standards for the protocols to be encapsulated are controlled by other standards organizations (e.g., T10 [SCSI] and T11 [Fibre Channel]). The WG cannot assume that any changes it desires will be made in these standards, and hence will pursue approaches that do not depend on such changes unless they are unavoidable. In that case the WG will create a document to be forwarded to the standards group responsible for the technology explaining the issue and requesting the desired changes be considered. The WG will endeavor to ensure high quality communications with these standards organizations. The WG will consider whether a layered architecture providing common transport, security, and/or other functionality for its encapsulations is the best technical approach. The protocols to be encapsulated expect a reliable transport, in that failure to deliver data is considered to be a rare event for which time-consuming recovery at higher levels is acceptable. This has implications for both the choice of transport protocols and design of the encapsulation(s). The WG's encapsulations may require quality of service assurances (e.g., bounded latency) to operate successfully; the WG will consider what assurances are appropriate and how to provide them in shared traffic environments (e.g., the Internet) based on existing IETF QoS mechanisms such as Differentiated Services. Use of IP-based transports raises issues that do not occur in the existing transports for the protocols to be encapsulated. The WG's protocol encapsulations will incorporate the following: - Congestion control suitable for shared traffic network environments such as the Internet. - Security including authentication, keyed cryptographic data integrity and confidentiality, sufficient to defend against threats up to and including those that can be expected on a public network. Implementation of basic security functionality will be required, although usage may be optional. The WG will also address the following issues related to its protocol encapsulations: - Naming and discovery mechanisms for the encapsulated protocols on IP-based networks, including both discovery of resources (e.g., storage) for access by the discovering entity, and discovery for management. - Management, including appropriate MIB definition(s) for the encapsulations. - By agreement with the IESG, the WG will additionally develop MIB definitions for the SCSI and Fiber Channel standards. The WG specifications will allow the implementation of bridges and gateways that connect to existing implementations of the encapsulated protocols. The WG will preserve the approaches to discovery, multi-pathing, booting, and similar issues taken by the protocols it encapsulates to the extent feasible. It may be necessary for traffic using the WG's encapsulations to pass through Network Address Translators (NATs) and/or firewalls in some circumstances; the WG will endeavor to design NAT- and firewall-friendly protocols that do not dynamically select target ports or require Application Level Gateways. Effective implementations of some IP transports for the encapsulated protocols are likely to require hardware acceleration; the WG will consider issues concerning the effective implementation of its protocols in hardware. The standard internet checksum is weaker than the checksums use by other implementations of the protocols to be encapsulated. The WG will consider what levels of data integrity assurance are required and how they should be achieved. The WG will produce requirements and specification documents for each protocol encapsulation, and may produce applicability statements. The requirements and specification documents will consider both disk and tape devices, taking note of the variation in scale from single drives to large disk arrays and tape libraries, although the requirements and specifications need not encompass all such devices. The WG will not work on: - Extensions to existing protocols such as SCSI and Fibre Channel beyond those strictly necessary for the use of IP-based transports. - Modifications to internet transport protocols or approaches requiring transport protocol options that are not widely supported, although the WG may recommend use of such options for block storage traffic. - Support for environments in which significant data loss or data corruption is acceptable. - File system protocols. Operational Structure: Keith McCloghrie (kzm@cisco.com) will serve as the MIB and Network Management advisor for the WG. Due to the scope of the task and the need for parallel progress on multiple work items, the WG effort is organized as follows: A technical coordinator will be identified and selected for each protocol encapsulation adopted as a work item by the group. This person will be responsible for coordinating the technical efforts of the group with respect to that encapsulation, working with and motivating the document editors, and evangelizing the group's work within both the community and relevant external organizations such as T10 and T11. In addition to the normal responsibilities of IETF working group chairs, the IPS chairs are responsible for selection of coordinators, identifying areas of technical commonality and building cross-technology efforts within the group. Coordinators for initially important encapsulations: SCSI over IP (aka iSCSI): John Hufferd (hufferd@us.ibm.com) Fibre Channel (FC-2) over IP: Murali Rajagopal (muralir@cox.net) iFCP: Franco Travostino (travos@nortelnetworks.com) Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2001 Oct 2006 Definitions of Managed Objects for iSNS (Internet Storage Name Service) Sep 2004 Dec 2006 Datamover Architecture for iSCSI (DA) Sep 2004 Oct 2005 iSCSI Extensions for RDMA Specification Jul 2005 Feb 2007 iSCSI Corrections and Clarifications May 2006 Nov 2006 Declarative Public Extension Key for iSCSI Node Architecture IP Telephony (iptel) -------------------- Charter Last Modified: 2006-04-10 Current Status: Active Working Group Chair(s): Jonathan Rosenberg Real-time Applications and Infrastructure Area Director(s): Jon Peterson Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Cullen Jennings Mailing Lists: General Discussion:iptel@ietf.org To Subscribe: iptel-request@ietf.org In Body: put subscribe in subject Archive: http://www.ietf.org/mail-archive/web/iptel/index.html Description of Working Group: The focus of the IP Telephony (iptel) group is on the problems related to naming and routing for Voice over IP (VoIP) protocols. Naming is accomplished through the use of the tel URI, which specifies a URI for telephone numbers. The tel URI was originally defined in RFC 2806, which was developed outside of any IETF working group. The iptel working group is responsible for updating the specification based on extensive experience with the tel URI. It is chartered to develop any extensions to the tel URI, such as support for number portability indicators and trunk groups. Routing protocols for VoIP allow intermediaries, such as SIP proxies and H.323 gatekeepers, to make call routing decisions based on reachability information learned from peer elements. The iptel group has already defined a protocol, Telephony Routing over IP (TRIP), RFC 3219, which solves one aspect of this problem. Specifically, it handles the case where calls need to be routed between domains. It allows for the exchange of routing information between these providers, so that policies can be applied to the resulting data to create a forwarding information base. However, this protocol does not address all the scenarios of route information exchange between servers. One important scenario is the propagation of routing information between gateways and the signaling servers in front of them. This is also known as "gateway registration". It allows the signaling server to make a routing decision about which gateway to use based on dynamic information about the gateway resources. Vendors have deployed proprietary solutions for this communications interface. A standard is needed. The group will generate a standards track document that defines a protocol (possibly based on TRIP) for this interface. TRIP and the gateway registration protocol are orthogonal to the DNS-based mechanisms specified in ENUM and RFC 3264. Those mechanisms are used to translate a URI, representing a name, to an address. If that address is a phone number in the telephone network, trip and tgrep can be used to assist in determining the right route (through various gateways) to that number. The group will also generate a MIB document for TRIP. Note that the group is not working on elevating TRIP to Draft Standard at this time. Deliverables: 1. A proposed standard specification for gateway to server route exchange. 2. A proposed standard TRIP MIB specification, based heavily on the existing BGP-4 MIB documents. 3. A standards track update to the tel URI. 4. Standards track extensions to the tel URI for PSTN interoperability, such as number portability and trunk group identification. Description of Working Group: The focus of the IP Telephony (iptel) group is on the problems related to naming and routing for Voice over IP (VoIP) protocols. Naming is accomplished through the use of the tel URI, which specifies a URI for telephone numbers. The tel URI was originally defined in RFC 2806, which was developed outside of any IETF working group. The iptel working group is responsible for updating the specification based on extensive experience with the tel URI. It is chartered to develop any extensions to the tel URI, such as support for number portability indicators and trunk groups. Routing protocols for VoIP allow intermediaries, such as SIP proxies and H.323 gatekeepers, to make call routing decisions based on reachability information learned from peer elements. The iptel group has already defined a protocol, Telephony Routing over IP (TRIP), RFC 3219, which solves one aspect of this problem. Specifically, it handles the case where calls need to be routed between domains. It allows for the exchange of routing information between these providers, so that policies can be applied to the resulting data to create a forwarding information base. However, this protocol does not address all the scenarios of route information exchange between servers. One important scenario is the propagation of routing information between gateways and the signaling servers in front of them. This is also known as "gateway registration". It allows the signaling server to make a routing decision about which gateway to use based on dynamic information about the gateway resources. Vendors have deployed proprietary solutions for this communications interface. A standard is needed. The group will generate a standards track document that defines a protocol (possibly based on TRIP) for this interface. TRIP and the gateway registration protocol are orthogonal to the DNS-based mechanisms specified in ENUM and RFC 3264. Those mechanisms are used to translate a URI, representing a name, to an address. If that address is a phone number in the telephone network, trip and tgrep can be used to assist in determining the right route (through various gateways) to that number. The group will also generate a MIB document for TRIP. Note that the group is not working on elevating TRIP to Draft Standard at this time. Deliverables: 1. A proposed standard specification for gateway to server route exchange. 2. A proposed standard TRIP MIB specification, based heavily on the existing BGP-4 MIB documents. 3. A standards track update to the tel URI. 4. Standards track extensions to the tel URI for PSTN interoperability, such as number portability and trunk group identification. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2002 Jan 2007 A Telephony Gateway REgistration Protocol (TGREP) Nov 2002 Jan 2007 Representing trunk groups in tel/sip Uniform Resource Identifiers (URIs) Dec 2005 Dec 2006 The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry IP Version 6 Working Group (ipv6) --------------------------------- Charter Last Modified: 2007-02-20 Current Status: Active Working Group Chair(s): Robert Hinden Brian Haberman Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:ipv6@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/ipv6 In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/ipv6/index.html Description of Working Group: The IPv6 working group is responsible for the specification and standardization of the Internet Protocol version 6 (IPv6). IPv6 provides a much larger global addresses space than its predecessor IPv4. This enables global end-to-end communication and restores valuable properties of the IP architecture that have been lost in the IPv4 Internet. The core IPv6 standards are widely implemented and are starting to see global deployment. The IPv6 working group was originally chartered by the IESG as the IP Next Generation (IPng) working group to implement the recommendations of the IPng Area Directors as outlined at the July 1994 IETF meeting and in "The Recommendation for the IP Next Generation Protocol," RFC1752, January 1995. The primary focus of the IPv6 w.g. is to complete the standardization of the IPv6 protocols, and to review and update the IPv6 specifications based on implementation and deployment experience, and advancing them on the standardization track as appropriate. The working group's work items are as follows: o Complete Prefix Delegation requirements and publish. Related remaining work is: - Develop Proxy Neighbor Discovery solution for prefix delegation and publish. This enables a simple site border router to re-advertise downstream a prefix it hears on its upstream link. o Complete revision of IPv6 MIBs (combined IPv4/IPv6 versions) and publish. o Complete "Default Router Preferences, More-Specific Routes, and "Load Sharing" and publish. o Update to ICMPv6 (RFC2463) and publish. o Complete "Node Information Queries" and publish. o Update Auto Configuration (RFC2462) and Neighbor Discovery (RFC2461) and publish. o Investigate approaches to optimize or eliminate Duplicate Address Detection (DAD) to make reduce the delays incurred by DAD when there is a change of network attachment points. Publish a document defining DAD optimizations. o Update "Privacy Extensions for Stateless Autoconfiguration" document (RFC3041) and publish. o Complete work on IPv6 Node Requirements and publish. o Complete work stemming from the working group decision to deprecate site-local addressing. This includes: - Publish document deprecating the usage of Site-Local addressing. - Publish revision of the IPv6 Address Architecture that includes the deprecation of site-local addressing. - Publish a replacement for site-local addresses that removes the major limitations and allows for local allocations. o Update the IPv6 Address Architecture to resolve the issues raised in the IAB response to the Robert Elz appeal and publish as a Draft Standard. o Complete work on Scoped Addressing Architecture and publish. o Update IPv6 over PPP (RFC2472) and publish. o Complete work on "Link Scoped IPv6 Multicast Addresses" and publish. All new work items not listed above require the approval of the working group and IESG before they will be taken on by the working group. Description of Working Group: The IPv6 working group is responsible for the specification and standardization of the Internet Protocol version 6 (IPv6). IPv6 provides a much larger global addresses space than its predecessor IPv4. This enables global end-to-end communication and restores valuable properties of the IP architecture that have been lost in the IPv4 Internet. The core IPv6 standards are widely implemented and are starting to see global deployment. The IPv6 working group was originally chartered by the IESG as the IP Next Generation (IPng) working group to implement the recommendations of the IPng Area Directors as outlined at the July 1994 IETF meeting and in "The Recommendation for the IP Next Generation Protocol," RFC1752, January 1995. The primary focus of the IPv6 w.g. is to complete the standardization of the IPv6 protocols, and to review and update the IPv6 specifications based on implementation and deployment experience, and advancing them on the standardization track as appropriate. The working group's work items are as follows: o Complete Prefix Delegation requirements and publish. Related remaining work is: - Develop Proxy Neighbor Discovery solution for prefix delegation and publish. This enables a simple site border router to re-advertise downstream a prefix it hears on its upstream link. o Complete revision of IPv6 MIBs (combined IPv4/IPv6 versions) and publish. o Complete "Default Router Preferences, More-Specific Routes, and "Load Sharing" and publish. o Update to ICMPv6 (RFC2463) and publish. o Complete "Node Information Queries" and publish. o Update Auto Configuration (RFC2462) and Neighbor Discovery (RFC2461) and publish. o Investigate approaches to optimize or eliminate Duplicate Address Detection (DAD) to make reduce the delays incurred by DAD when there is a change of network attachment points. Publish a document defining DAD optimizations. o Update "Privacy Extensions for Stateless Autoconfiguration" document (RFC3041) and publish. o Complete work on IPv6 Node Requirements and publish. o Complete work stemming from the working group decision to deprecate site-local addressing. This includes: - Publish document deprecating the usage of Site-Local addressing. - Publish revision of the IPv6 Address Architecture that includes the deprecation of site-local addressing. - Publish a replacement for site-local addresses that removes the major limitations and allows for local allocations. o Update the IPv6 Address Architecture to resolve the issues raised in the IAB response to the Robert Elz appeal and publish as a Draft Standard. o Complete work on Scoped Addressing Architecture and publish. o Update IPv6 over PPP (RFC2472) and publish. o Complete work on "Link Scoped IPv6 Multicast Addresses" and publish. All new work items not listed above require the approval of the working group and IESG before they will be taken on by the working group. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2004 May 2005 IPv6 Stateless Address Autoconfiguration Jun 2004 Jun 2005 IP Version 6 over PPP Jul 2004 Mar 2007 Neighbor Discovery for IP version 6 (IPv6) Sep 2004 Oct 2006 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 IS-IS for IP Internets (isis) ----------------------------- Charter Last Modified: 2006-12-06 Current Status: Active Working Group Chair(s): Chris Hopps David Ward Routing Area Director(s): Ross Callon Bill Fenner Routing Area Advisor: Bill Fenner 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 2000 Oct 2005 Routing IPv6 with IS-IS Feb 2001 Oct 2005 M-ISIS: Multi Topology (MT) Routing in IS-IS Sep 2001 Apr 2006 Point-to-point operation over LAN in link-state routing protocols Aug 2002 Feb 2005 A Policy Control Mechanism is IS-IS Using Administrative Tags Jan 2005 Feb 2007 Definition of an IS-IS Link Attribute sub-TLV Jan 2005 Feb 2007 IS-IS Extensions for Advertising Router Information Jul 2006 Feb 2007 IS-IS HMAC SHA Cryptographic Authentication Nov 2006 Nov 2006 Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) Integrated Security Model for SNMP (isms) ----------------------------------------- Charter Last Modified: 2006-12-18 Current Status: Active Working Group Chair(s): Juergen Schoenwaelder Juergen Quittek Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Sam Hartman 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, for which there is one currently defined model - the User-based Security Model (USM). However, the USM approach has seen limited deployment so far. One frequently reported reasons is the lack of integration of USM key and user management into deployed authentication infrastructures. SSH is a widely deployed access protocol for remote devices configuration. Many devices support the integration of SSH user authentication with AAA systems via protocols such as RADIUS. The goal of the ISMS working group is developing a new security model for SNMP that integrates with widely deployed user and key management systems, as a supplement to the USM security model. For this integration the working group will define a standard method for mapping from AAA-provisioned authorization parameter(s) to corresponding SNMP parameters. In order to leverage the authentication information already accessible at managed devices, the new security model will use the SSH protocol for message protection, and RADIUS for AAA-provisioned user authentication and authorization. However, the integration of a transport mapping security model into the SNMPv3 architecture should be defined such that it is open to support potential alternative transport mappings to protocols such as BEEP and TLS. The new security model must not modify any other aspects of SNMPv3 protocol as defined in STD 62 (e.g., it must not create new PDU types). Work on new access control models or centralized administration of View-based Access Control Model (VACM) rules and mappings is outside the scope of the working group. The working group will cover the following work items: - Specify an architectural extension that describes how transport mapping security models (TMSMs) fit into the SNMPv3 architecture. - Specify an architectural extension that describes how to perform a mapping from AAA-provisioned user-authentication and authorization parameter(s)to securityName and other corresponding SNMP parameters. - Specify a mapping from RADIUS-provisioned authentication and authorization parameter(s) to securityName and other corresponding SNMP parameters. This item may be a RADEXT work item last-aclled in both groups. - Specify a mapping from locally-provisioned authentication and authorization parameter(s) to securityName and other corresponding SNMP parameters. - Define how to use SSH between the two SNMP engines - Specify the SSH security model for SNMP. Description of Working Group: The Simple Network Management Protocol version 3 (SNMPv3) provides message security services through the security subsystem, for which there is one currently defined model - the User-based Security Model (USM). However, the USM approach has seen limited deployment so far. One frequently reported reasons is the lack of integration of USM key and user management into deployed authentication infrastructures. SSH is a widely deployed access protocol for remote devices configuration. Many devices support the integration of SSH user authentication with AAA systems via protocols such as RADIUS. The goal of the ISMS working group is developing a new security model for SNMP that integrates with widely deployed user and key management systems, as a supplement to the USM security model. For this integration the working group will define a standard method for mapping from AAA-provisioned authorization parameter(s) to corresponding SNMP parameters. In order to leverage the authentication information already accessible at managed devices, the new security model will use the SSH protocol for message protection, and RADIUS for AAA-provisioned user authentication and authorization. However, the integration of a transport mapping security model into the SNMPv3 architecture should be defined such that it is open to support potential alternative transport mappings to protocols such as BEEP and TLS. The new security model must not modify any other aspects of SNMPv3 protocol as defined in STD 62 (e.g., it must not create new PDU types). Work on new access control models or centralized administration of View-based Access Control Model (VACM) rules and mappings is outside the scope of the working group. The working group will cover the following work items: - Specify an architectural extension that describes how transport mapping security models (TMSMs) fit into the SNMPv3 architecture. - Specify an architectural extension that describes how to perform a mapping from AAA-provisioned user-authentication and authorization parameter(s)to securityName and other corresponding SNMP parameters. - Specify a mapping from RADIUS-provisioned authentication and authorization parameter(s) to securityName and other corresponding SNMP parameters. This item may be a RADEXT work item last-aclled in both groups. - Specify a mapping from locally-provisioned authentication and authorization parameter(s) to securityName and other corresponding SNMP parameters. - Define how to use SSH between the two SNMP engines - Specify the SSH security model for SNMP. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2005 Oct 2006 Secure Shell Transport Model for SNMP Oct 2005 Mar 2007 Transport Subsystem for the Simple Network Management Protocol (SNMP) Oct 2006 Feb 2007 Transport Security Model for SNMP Provisioning of Symmetric Keys (keyprov) ---------------------------------------- Charter Last Modified: 2007-01-30 Current Status: Active Working Group Chair(s): Phillip Hallam-Baker Hannes Tschofenig Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Russ Housley Mailing Lists: General Discussion:ietf-keyprov@safehaus.org To Subscribe: http://www.safehaus.org/mailman/listinfo/ietf-keyprov Archive: http://www.safehaus.org/pipermail/ietf-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: No Current Internet-Drafts. Kitten (GSS-API Next Generation) (kitten) ----------------------------------------- Charter Last Modified: 2007-03-12 Current Status: Active Working Group Chair(s): Jeffrey Altman Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Sam Hartman Mailing Lists: General Discussion:kitten@lists.ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/kitten Archive: http://www1.ietf.org/mail-archive/web/kitten/current/index.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 o Document internationalization issues 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 GSS-API o Define a GSS-API 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 GSS-API 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 pseudo-Random Function for GSS-API o Specify extensions to GSS-API to address internationalization issues. 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 GSS-API Language Binding specification work: o Specify a language binding for C# 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 o Document internationalization issues 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 GSS-API o Define a GSS-API 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 GSS-API 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 pseudo-Random Function for GSS-API o Specify extensions to GSS-API to address internationalization issues. 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 GSS-API Language Binding specification work: o Specify a language binding for C# Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Dec 2004 Sep 2006 GSS-API Domain-Based Service Names and Name Type Dec 2004 Sep 2006 GSS-API Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism Feb 2005 Oct 2006 GSS-API Extension for Storing Delegated Credentials Kerberos (krb-wg) ----------------- Charter Last Modified: 2006-10-17 Current Status: Active Working Group Chair(s): Jeffrey Hutzelman Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Sam Hartman Mailing Lists: General Discussion:ietf-krb-wg@anl.gov To Subscribe: majordomo@anl.gov In Body: subscribe ietf-krb-wg your_email_address Archive: ftp://ftp.ietf.org/ietf-mail-archive/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 over the years, and interoperability has been problematic. A number of draft proposals have been issued concerning aspects of new or extended functionality. The group will strive to improve the interoperability of these systems while improving security. Specifically, the Working Group will: * Clarify and amplify the Kerberos specification (RFC 1510) to make sure interoperability problems encountered in the past that occurred because of unclear specifications do not happen again. The output of this process should be suitable for Draft Standard status. * Select from existing proposals on new or extended functionality those that will add significant value while improving interoperability and security, and publish these as one or more Proposed Standards. 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 over the years, and interoperability has been problematic. A number of draft proposals have been issued concerning aspects of new or extended functionality. The group will strive to improve the interoperability of these systems while improving security. Specifically, the Working Group will: * Clarify and amplify the Kerberos specification (RFC 1510) to make sure interoperability problems encountered in the past that occurred because of unclear specifications do not happen again. The output of this process should be suitable for Draft Standard status. * Select from existing proposals on new or extended functionality those that will add significant value while improving interoperability and security, and publish these as one or more Proposed Standards. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Mar 2001 Mar 2007 Generating KDC Referrals to Locate Kerberos Realms Jul 2001 Oct 2006 Passwordless Initial Authentication to Kerberos by Hardware Preauthentication May 2003 Mar 2007 Kerberos Set/Change Key/Password Protocol Version 2 Feb 2004 Mar 2007 A Generalized Framework for Kerberos Pre-Authentication Jan 2005 Mar 2007 The Kerberos Network Authentication Service (Version 5) Sep 2005 Mar 2007 ECC Support for PKINIT May 2006 Sep 2006 Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges Over TCP Jun 2006 Mar 2007 Anonymity Support for Kerberos Jun 2006 Mar 2007 Additional Kerberos Naming Constraints Jun 2006 Mar 2007 PK-INIT Cryptographic Algorithm Agility Nov 2006 Mar 2007 Kerberos Version 5 GSS-API Channel Binding Hash Agility Layer 1 Virtual Private Networks (l1vpn) ---------------------------------------- Charter Last Modified: 2006-06-15 Current Status: Active Working Group Chair(s): Hamid Ould-Brahim Adrian Farrel Tomonori Takeda Routing Area Director(s): Ross Callon Bill Fenner Routing Area Advisor: Ross Callon Mailing Lists: General Discussion:l1vpn@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html Description of Working Group: The L1VPN Working Group's task is to specify mechanisms necessary for providing layer-1 VPN services (establishment of layer-1 connections between CE devices) over a GMPLS-enabled transport service-provider network. The following two service models will be addressed: 1. Basic mode: the CE-PE interface's functional repertoire is limited to path setup signalling only. Provider's network is not involved in distribution of customer network's routing information. 2. Enhanced mode: the CE-PE interface provides the signaling capabilities as in the Basic mode, plus permits limited exchange of information between the control planes of the provider and the customer to help such functions as discovery of reachability information in remote sites, or parameters of the part of the provider's network dedicated to the customer. The WG will work on the following items: 1. Framework document defining the reference network model, L1VPN service model, fundamental assumptions, and terminology. 2. Specification of the L1VPN signaling functionality between the customer and the provider network to support the basic mode. 3. Specification of the L1VPN signaling and routing functionality within the provider network to support the basic mode. 4. OAM features and MIB modules and/or extensions required for the basic mode. 5. Specification of the L1VPN signaling and routing functionality between the customer and the provider network to support the extended mode. 6. Specification of the L1VPN signaling and routing functionality within the provider network to support the extended mode. 7. OAM features and MIB modules and/or extensions required for the extended mode. 8. Applicability guidelines to compare the basic and extended modes. At this point the WG will address the single-AS scenario only. The multi-AS/provider scenario may be considered in future. Protocol extensions required for L1VPN will be done in cooperation with MPLS, CCAMP, OSPF, IS-IS, IDR, L3VPN, and other WGs where necessary. L1VPN WG shall also cooperate with ITU-T SG13 through the established IETF process, and use documents Y.1312 and Y.1313 (describing L1VPN requirements and network architectures) as input to its design process. The documents will be available at the IETF liaison web-site. Description of Working Group: The L1VPN Working Group's task is to specify mechanisms necessary for providing layer-1 VPN services (establishment of layer-1 connections between CE devices) over a GMPLS-enabled transport service-provider network. The following two service models will be addressed: 1. Basic mode: the CE-PE interface's functional repertoire is limited to path setup signalling only. Provider's network is not involved in distribution of customer network's routing information. 2. Enhanced mode: the CE-PE interface provides the signaling capabilities as in the Basic mode, plus permits limited exchange of information between the control planes of the provider and the customer to help such functions as discovery of reachability information in remote sites, or parameters of the part of the provider's network dedicated to the customer. The WG will work on the following items: 1. Framework document defining the reference network model, L1VPN service model, fundamental assumptions, and terminology. 2. Specification of the L1VPN signaling functionality between the customer and the provider network to support the basic mode. 3. Specification of the L1VPN signaling and routing functionality within the provider network to support the basic mode. 4. OAM features and MIB modules and/or extensions required for the basic mode. 5. Specification of the L1VPN signaling and routing functionality between the customer and the provider network to support the extended mode. 6. Specification of the L1VPN signaling and routing functionality within the provider network to support the extended mode. 7. OAM features and MIB modules and/or extensions required for the extended mode. 8. Applicability guidelines to compare the basic and extended modes. At this point the WG will address the single-AS scenario only. The multi-AS/provider scenario may be considered in future. Protocol extensions required for L1VPN will be done in cooperation with MPLS, CCAMP, OSPF, IS-IS, IDR, L3VPN, and other WGs where necessary. L1VPN WG shall also cooperate with ITU-T SG13 through the established IETF process, and use documents Y.1312 and Y.1313 (describing L1VPN requirements and network architectures) as input to its design process. The documents will be available at the IETF liaison web-site. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Aug 2005 Jan 2007 Framework and Requirements for Layer 1 Virtual Private Networks May 2006 Oct 2006 BGP-based Auto-Discovery for L1VPNs May 2006 Oct 2006 Layer 1 VPN Basic Mode Jun 2006 Mar 2007 OSPF Based L1VPN Auto-Discovery Nov 2006 Nov 2006 Applicability analysis of Generalized Multiprotocol Label Switching (GMPLS) protocols for the Layer 1 Virtual Private Network (L1VPN) Enhanced Mode Nov 2006 Mar 2007 Applicability Statement for Layer 1 Virtual Private Networks (L1VPNs) Basic Mode Layer Two Tunneling Protocol Extensions (l2tpext) ------------------------------------------------- Charter Last Modified: 2006-10-09 Current Status: Active Working Group Chair(s): Ignacio Goyret Carlos Pignataro Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Mark Townsley 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: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2001 Nov 2006 PPP Tunneling Using Layer Two Tunneling Protocol Version 3 (L2TPv3) Aug 2001 Mar 2007 PPP over L2TP Tunnel Switching May 2002 Feb 2007 Fail Over extensions for L2TP "failover" Jun 2002 Sep 2006 Layer Two Tunneling Protocol (Version 3) "L2TPv3" Management Information Base Feb 2005 Mar 2007 Layer Two Tunneling Protocol - Setup of TDM Pseudowires Oct 2005 Feb 2007 Signaling and Encapsulation for the Transport of IP over L2TPv3 Dec 2005 Mar 2007 L2TP Proxy Authenticate Extensions for EAP Layer 2 Virtual Private Networks (l2vpn) ---------------------------------------- Charter Last Modified: 2007-03-01 Current Status: Active Working Group Chair(s): Shane Amante Vach Kompella Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Mark Townsley Technical Advisor(s): Alex Zinin Mailing Lists: General Discussion:l2vpn@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/l2vpn Archive: http://www.ietf.org/mail-archive/web/l2vpn/index.html Description of Working Group: Alex Zinin is the routing advisor. Russ Housley is the security advisor. This working group is responsible for defining and specifying a limited number of solutions for supporting provider-provisioned layer-2 virtual private networks (L2VPNs). The WG is responsible for standardization of the following solutions: 1. Virtual Private LAN Service (VPLS)--L2 service that emulates LAN across an IP and an MPLS-enabled IP network, allowing standard Ethernet devices communicate with each other as if they were connected to a common LAN segment. 2. Virtual Private Wire Service (VPWS)--L2 service that provides L2 point-to-point connectivity (e.g. Frame Relay DLCI, ATM VPI/VCI, point-to-point Ethernet) across an IP and an MPLS-enabled IP network. 3. IP-only VPNs -- An L2 service across an IP and MPLS-enabled IP network, allowing standard IP devices to communicate with each other as if they were connected to a common LAN or with some mesh of point-to-point circuits (not necessarily fully meshed). The WG will address both of the following cases: - the customer attachment uses the same L2 protocol at all attachment points in the L2VPN. - the customer attachment uses different L2 protocols at the attachment points in the L2VPN. This case is intended to address the needs of service providers who may start out with a single L2 protocol at attachment points, but wish to incrementally upgrade individual attachment points over time to newer technologies. This is a restricted form of "interworking" that is limited to providing the facilities necessary to carry IP over the L2VPN; general L2 interworking is not in scope. The WG will address intra-AS scenarios only at this point (other scenarios will be considered for inclusion in the updated charter when the current one is completed.) 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. As a specific example, this WG will not define new encapsulation mechanism, but will use those defined in the PWE3 WG. L2VPN WG will review proposed protocol extensions for L2VPNs before they are recommended to appropriate protocol-specific WGs. The WG will work on the following items. Adding new work items will require rechartering. 1. Discovery of PEs participating in L2 service, and topology of required connectivity 2. Signaling of l2vpn related information for the purpose of setup and maintenance of l2vpn circuits. As much as possible PWE3 signaling procedures should be used 3. Solution documents (providing the framework for a specific solution, should include info on how discovery, signaling, and encaps work together, include security, AS as a separate document) 4. MIBs 5. L2VPN-specific OAM extensions--extensions to existing OAM solutions for VPLS, VPWS, and IP-only L2VPNs. Where necessary, the WG will coordinate its activities with IEEE 802.1 Description of Working Group: Alex Zinin is the routing advisor. Russ Housley is the security advisor. This working group is responsible for defining and specifying a limited number of solutions for supporting provider-provisioned layer-2 virtual private networks (L2VPNs). The WG is responsible for standardization of the following solutions: 1. Virtual Private LAN Service (VPLS)--L2 service that emulates LAN across an IP and an MPLS-enabled IP network, allowing standard Ethernet devices communicate with each other as if they were connected to a common LAN segment. 2. Virtual Private Wire Service (VPWS)--L2 service that provides L2 point-to-point connectivity (e.g. Frame Relay DLCI, ATM VPI/VCI, point-to-point Ethernet) across an IP and an MPLS-enabled IP network. 3. IP-only VPNs -- An L2 service across an IP and MPLS-enabled IP network, allowing standard IP devices to communicate with each other as if they were connected to a common LAN or with some mesh of point-to-point circuits (not necessarily fully meshed). The WG will address both of the following cases: - the customer attachment uses the same L2 protocol at all attachment points in the L2VPN. - the customer attachment uses different L2 protocols at the attachment points in the L2VPN. This case is intended to address the needs of service providers who may start out with a single L2 protocol at attachment points, but wish to incrementally upgrade individual attachment points over time to newer technologies. This is a restricted form of "interworking" that is limited to providing the facilities necessary to carry IP over the L2VPN; general L2 interworking is not in scope. The WG will address intra-AS scenarios only at this point (other scenarios will be considered for inclusion in the updated charter when the current one is completed.) 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. As a specific example, this WG will not define new encapsulation mechanism, but will use those defined in the PWE3 WG. L2VPN WG will review proposed protocol extensions for L2VPNs before they are recommended to appropriate protocol-specific WGs. The WG will work on the following items. Adding new work items will require rechartering. 1. Discovery of PEs participating in L2 service, and topology of required connectivity 2. Signaling of l2vpn related information for the purpose of setup and maintenance of l2vpn circuits. As much as possible PWE3 signaling procedures should be used 3. Solution documents (providing the framework for a specific solution, should include info on how discovery, signaling, and encaps work together, include security, AS as a separate document) 4. MIBs 5. L2VPN-specific OAM extensions--extensions to existing OAM solutions for VPLS, VPWS, and IP-only L2VPNs. Where necessary, the WG will coordinate its activities with IEEE 802.1 Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Sep 2003 May 2006 Provisioning, Autodiscovery, and Signaling in L2VPNs Sep 2004 Mar 2007 L2VPN OAM Requirements and Framework Oct 2005 Mar 2007 Requirements for Multicast Support in Virtual Private LAN Services Dec 2005 Mar 2007 Multicast in VPLS Jul 2006 Nov 2006 VPLS Interoperability with CE Bridges Aug 2006 Mar 2007 PIM Snooping over VPLS Layer 3 Virtual Private Networks (l3vpn) ---------------------------------------- Charter Last Modified: 2006-03-30 Current Status: Active Working Group Chair(s): Rick Wilder Ronald Bonica Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Mark Townsley Technical Advisor(s): Alex Zinin Mailing Lists: General Discussion:l3vpn@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/l3vpn Archive: http://www.ietf.org/mail-archive/web/l3vpn/index.html Description of Working Group: Alex Zinin is the routing advisor. 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: Alex Zinin is the routing advisor. 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 ------ ------- -------------------------------------------- Jul 2001 Dec 2005 An Architecture for Provider Provisioned CE-based Virtual Private Networks using IPsec Jul 2001 Aug 2005 Architecture for the Use of PE-PE IPsec Tunnels in BGP/MPLS IP VPNs Jul 2001 Sep 2006 Using BGP as an Auto-Discovery Mechanism for VR-based Layer-3 VPNs Jul 2001 Mar 2006 Network based IP VPN Architecture Using Virtual Routers Sep 2001 Aug 2005 Virtual Router Management Information Base Using SMIv2 Aug 2002 Aug 2006 Applicability Statement for Virtual Router-based Layer 3 PPVPN Approaches Jan 2004 Jan 2004 Applicability Statement for Provider Provisioned CE-based Virtual Private Networks using IPsec Feb 2005 Nov 2006 Requirements for Multicast in L3 Provider-Provisioned VPNs Jun 2005 Oct 2006 Multicast in MPLS/BGP IP VPNs Aug 2006 Mar 2007 BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs Enhancements to Internet email to Support Diverse Service Environments (lemonade) --------------------------------------------------------------------------------- Charter Last Modified: 2007-03-12 Current Status: Active Working Group Chair(s): Glenn Parsons Eric Burger Applications Area Director(s): Ted Hardie Lisa Dusseault Applications Area Advisor: Ted Hardie 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 ------ ------- -------------------------------------------- Oct 2005 Jan 2007 IMAP URL Scheme Oct 2005 Oct 2006 CONVERT Dec 2005 Mar 2007 Support for Sieve in Internet Message Access Protocol (IMAP4) Jan 2006 Oct 2006 LEMONADE profile bis Mar 2006 Mar 2007 Deployment Considerations for lemonade-compliant Mobile Email Mar 2006 Mar 2007 WITHIN Search extension to the IMAP Protocol Mar 2006 Jan 2007 The IMAP COMPRESS Extension Jun 2006 Mar 2007 Internet Message Store Events Jun 2006 Mar 2007 Streaming Multimedia Messaging Attachments Jun 2006 Feb 2007 IMAP4 Extensions for Quick Mailbox Resynchronization Long-Term Archive and Notary Services (ltans) --------------------------------------------- Charter Last Modified: 2006-10-18 Current Status: Active Working Group Chair(s): Carl Wallace Tobias Gondrom Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Russ Housley Mailing Lists: General Discussion:ietf-ltans@imc.org To Subscribe: ietf-ltans-request@imc.org In Body: subscribe Archive: http://www.imc.org/ietf-ltans 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 ------ ------- -------------------------------------------- Feb 2004 Dec 2006 Long-Term Archive Service Requirements Feb 2004 Mar 2007 Evidence Record Syntax (ERS) Jul 2005 Mar 2007 Long-term Archive Protocol (LTAP) Sep 2005 Feb 2007 Using SCVP to Convey Long-term Evidence Records Jan 2006 Oct 2006 Infrastructure Support for Retention of PKI Artifacts Oct 2006 Jan 2007 Verification Data Oct 2006 Oct 2006 LTANS Architecture Feb 2007 Feb 2007 Extensible Markup Language Evidence Record Syntax Language Tag Registry Update (ltru) ----------------------------------- Charter Last Modified: 2006-11-30 Current Status: Active Working Group Chair(s): Randy Presuhn Martin Duerst Applications Area Director(s): Ted Hardie Lisa Dusseault Applications Area Advisor: Ted Hardie Mailing Lists: General Discussion:ltru@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/ltru Archive: http://www.ietf.org/mail-archive/web/ltru/index.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: Posted Revised I-D Title ------ ------- -------------------------------------------- Sep 2006 Dec 2006 Tags for Identifying Languages Sep 2006 Jan 2007 Update to the Language Subtag Registry Multicast & Anycast Group Membership (magma) -------------------------------------------- Charter Last Modified: 2006-04-18 Current Status: Active Working Group Chair(s): Isidor Kouvelas Brian Haberman Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:magma@ietf.org To Subscribe: magma-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/magma/index.html Description of Working Group: Group management protocols are crucial to the operation of multicast within the Internet, and there are some benefits in extending group management protocols to also be able to support anycast. These protocols allow hosts to inform routers of their membership status within groups. This working group will be responsible for developing the functionalities required for group membership reporting and other related actions. This group will also address the initial authentication and access control issues associated with anycast group membership; this is likely to be limited to shared secrets and message authentication codes (MACs) much like current routing protocol security. Other aspects of Anycast, including architecture and routing, are outside the groups scope. The draft names listed below are the starting point for the work in the WG. MAGMA specifications will include: - Core IGMPv3/MLDv2 specifications. These specifications will describe the protocol used between hosts and routers to share group membership information. IGMPv3 and MLDv2 build on IGMPv2 and MLDv1 by adding two types of source-specific filtering; "include" (in which the system tells the router exactly which sources it desires) and "exclude" (in which the system tells the router that it does *not* desire a list of sources). - IGMPv3: The IDMR working group has submitted this for Proposed Standard. MAGMA takes ownership after publication as RFC. - MLDv2: draft-vida-mld-v2-00.txt - Multicast Source Filtering API. This specification describes the API used to interact with IGMPv3 and MLDv2 to indicate source filters. - draft-ietf-idmr-msf-api-01.txt - Host determination of network group membership. In a multicast environment, systems may be interested in learning whether or not there are any group members, in order to save the trouble of sending data that nobody is listening to. - Multicast Source Notification of Interest Protocol: draft-ietf-idmr-msnip-00 - Multicast forwarding in tree topologies using IGMP/MLD Proxying - Create a single document from: - draft-ietf-idmr-igmp-proxy-00 - draft-he-mixed-igmp-proxy-00 - Source-Specific Multicast (SSM) consideration document. This work will describe the use of IGMPv3/MLDv2 in an SSM environment. - draft-holbrook-idmr-igmpv3-ssm-01.txt - Considerations for "IGMP snooping" switches (switches that watch IGMP exchanges in order to determine multicast forwarding behavior) - Multicast Router Discovery: The MAGMA group has taken ownership of this draft over from IDMR. It will be revised and submitted as a Proposed Standard. - Snooping Considerations: draft-ietf-magma-mrdisc-00.txt (previous revisions draft-ietf-idmr-snoop-XX.txt) - Group management MIBs - update RFC 2933 for IGMPv3 - update RFC 3019 for MLDv2 - Interaction between IGMP/MLD and routing protocols - draft-ietf-idmr-igmpv3-and-routing-00.txt - Extensions to MLD supporting anycast group memberships including authentication and access control mechanisms - draft-haberman-ipngwg-host-anycast-00.txt In addition, this working group will coordinate with other IETF working groups where multicast and anycast group management protocols are utilized as well as coordinating with the Multicast Security WG. Description of Working Group: Group management protocols are crucial to the operation of multicast within the Internet, and there are some benefits in extending group management protocols to also be able to support anycast. These protocols allow hosts to inform routers of their membership status within groups. This working group will be responsible for developing the functionalities required for group membership reporting and other related actions. This group will also address the initial authentication and access control issues associated with anycast group membership; this is likely to be limited to shared secrets and message authentication codes (MACs) much like current routing protocol security. Other aspects of Anycast, including architecture and routing, are outside the groups scope. The draft names listed below are the starting point for the work in the WG. MAGMA specifications will include: - Core IGMPv3/MLDv2 specifications. These specifications will describe the protocol used between hosts and routers to share group membership information. IGMPv3 and MLDv2 build on IGMPv2 and MLDv1 by adding two types of source-specific filtering; "include" (in which the system tells the router exactly which sources it desires) and "exclude" (in which the system tells the router that it does *not* desire a list of sources). - IGMPv3: The IDMR working group has submitted this for Proposed Standard. MAGMA takes ownership after publication as RFC. - MLDv2: draft-vida-mld-v2-00.txt - Multicast Source Filtering API. This specification describes the API used to interact with IGMPv3 and MLDv2 to indicate source filters. - draft-ietf-idmr-msf-api-01.txt - Host determination of network group membership. In a multicast environment, systems may be interested in learning whether or not there are any group members, in order to save the trouble of sending data that nobody is listening to. - Multicast Source Notification of Interest Protocol: draft-ietf-idmr-msnip-00 - Multicast forwarding in tree topologies using IGMP/MLD Proxying - Create a single document from: - draft-ietf-idmr-igmp-proxy-00 - draft-he-mixed-igmp-proxy-00 - Source-Specific Multicast (SSM) consideration document. This work will describe the use of IGMPv3/MLDv2 in an SSM environment. - draft-holbrook-idmr-igmpv3-ssm-01.txt - Considerations for "IGMP snooping" switches (switches that watch IGMP exchanges in order to determine multicast forwarding behavior) - Multicast Router Discovery: The MAGMA group has taken ownership of this draft over from IDMR. It will be revised and submitted as a Proposed Standard. - Snooping Considerations: draft-ietf-magma-mrdisc-00.txt (previous revisions draft-ietf-idmr-snoop-XX.txt) - Group management MIBs - update RFC 2933 for IGMPv3 - update RFC 3019 for MLDv2 - Interaction between IGMP/MLD and routing protocols - draft-ietf-idmr-igmpv3-and-routing-00.txt - Extensions to MLD supporting anycast group memberships including authentication and access control mechanisms - draft-haberman-ipngwg-host-anycast-00.txt In addition, this working group will coordinate with other IETF working groups where multicast and anycast group management protocols are utilized as well as coordinating with the Multicast Security WG. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2001 Oct 2003 IGMPv3/MLDv2 and Multicast Routing Protocol Interaction Jun 2003 Mar 2006 Multicast Group Membership Discovery MIB Mobile Ad-hoc Networks (manet) ------------------------------ Charter Last Modified: 2006-10-02 Current Status: Active Working Group Chair(s): Joseph Macker Ian Chakeres Routing Area Director(s): Ross Callon Bill Fenner Routing Area Advisor: Bill Fenner 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 ------ ------- -------------------------------------------- Feb 2005 Mar 2007 Dynamic MANET On-demand (DYMO) Routing Jul 2005 Mar 2007 Simplified Multicast Forwarding for MANET Oct 2005 Mar 2007 The Optimized Link State Routing Protocol version 2 Mar 2006 Mar 2007 Generalized MANET Packet/Message Format Jun 2006 Mar 2007 MANET Neighborhood Discovery Protocol (NHDP) Feb 2007 Feb 2007 MANET IANA Needs MBONE Deployment (mboned) ------------------------- Charter Last Modified: 2006-12-06 Current Status: Active Working Group Chair(s): Hiroshi Ohta Marshall Eubanks Operations and Management Area Director(s): Dan Romascanu David Kessens Operations and Management Area Advisor: David Kessens Technical Advisor(s): Scott Bradner Mailing Lists: General Discussion:mboned@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/mboned Archive: http://www1.ietf.org/mail-archive/web/mboned/current/index.html 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 ------ ------- -------------------------------------------- Feb 2001 Nov 2006 Automatic IP Multicast Without Explicit Tunnels (AMT) Jul 2002 Mar 2007 Unicast-Prefix-based IPv4 Multicast Addresses Nov 2004 Oct 2006 Overview of the Internet Multicast Addressing Architecture Apr 2005 Feb 2006 Requirements for Accounting, Authentication and Authorization in Well Managed IP Multicasting Services Apr 2005 Nov 2006 Overview of the Internet Multicast Routing Architecture Apr 2006 Mar 2007 IP Multicast MIB Apr 2006 Oct 2006 AAA Framework for Multicasting Dec 2006 Dec 2006 Lightweight IGMPv3 and MLDv2 Protocols Feb 2007 Feb 2007 Moving MCAST.NET into the ARPA infrastructure top level domain Middlebox Communication (midcom) -------------------------------- Charter Last Modified: 2007-01-25 Current Status: Active Working Group Chair(s): Melinda Shore Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Magnus Westerlund Mailing Lists: General Discussion:midcom@ietf.org To Subscribe: midcom-request@ietf.org In Body: subscribe your_email_address Archive: http://www.ietf.org/mail-archive/web/midcom/index.html Description of Working Group: As trusted third parties are increasingly being asked to make policy decisions on behalf of the various entities participating in an application's operation, a need has developed for applications to be able to communicate their needs to the devices in the network that provide transport policy enforcement. Examples of these devices include firewalls, network address translators (both within and between address families), signature management for intrusion detection systems, and multimedia buffer management. These devices are a subset of what can be referred to as 'middleboxes.' This working group will focus its attention on communication with firewalls and network address translators (including translation between IPv6 and IPv4). Work will not preclude extensibility to other categories of middle box. Decomposing applications requiring policy decisions by removing application logic from the middle box and instead providing a generalized communications interface provides a number of benefits, including improved performance, lower software development and maintenance costs, improved ability to support traversal of packet filters by complex protocols, easier deployment of new applications, and the ability to consolidate management functions. For example, by moving stateful inspection of protocols such as H.323 and SIP out of firewalls, it is possible to improve performance and scalability and reduce development and costs. This working group will concern itself with an environment that consists of: - one or more middle boxes in the data path - an external requesting entity - a policy entity for consultation purposes when the requesting entity is untrusted. The requesting entity may be trusted or untrusted. In the case where it is trusted, the middle box will treat the request from the entity as authoritative. In the case where it is not trusted, the intermediate device will have to verify that it is authorized to complete the request. That authorization could come from a separate or a built in policy server. The primary focus of the working group will be the application of this architecture to communicating requests between applications and firewalls or NATs. This will not preclude other uses, and care will be taken to ensure that the protocol is extensible. The working group will evaluate existing IETF protocols for their applicability to this problem, using the framework and requirements documents developed during the working group's first phase as criteria for the evaluation. If a protocol is found to be suitable it will be used as the basis for the development of a middlebox communication protocol. In the unlikely case that one is not found to be suitable, the working group will undertake development of a new protocol. Discovery of middle boxes is out of scope. The deliverables will be o a document evaluating existing IETF protocols for their suitability o a document specifying a middlebox communication protocol or profile based on the results of the protocol evaluation. This working group will only deal with firewalls and network address translators. Ubiquitous deployment of midcom in all middleboxes could take many years. In the interim, a solution is needed that allows applications to operate in the presence of midcom-unaware middleboxes. To support this, the midcom group will develop or document a protocol or approach that allows clients to indirectly obtain address bindings from midcom- unaware middleboxes, through communications with server elements on the public side of the middlebox. The key goals for this effort are rapid delivery of a simple solution (since it is an interim solution), consistency with the midcom framework, and security. In particular, any proposed interim approaches will address (and document) the architectural and pragmatic concerns described in [UNSAF]. Description of Working Group: As trusted third parties are increasingly being asked to make policy decisions on behalf of the various entities participating in an application's operation, a need has developed for applications to be able to communicate their needs to the devices in the network that provide transport policy enforcement. Examples of these devices include firewalls, network address translators (both within and between address families), signature management for intrusion detection systems, and multimedia buffer management. These devices are a subset of what can be referred to as 'middleboxes.' This working group will focus its attention on communication with firewalls and network address translators (including translation between IPv6 and IPv4). Work will not preclude extensibility to other categories of middle box. Decomposing applications requiring policy decisions by removing application logic from the middle box and instead providing a generalized communications interface provides a number of benefits, including improved performance, lower software development and maintenance costs, improved ability to support traversal of packet filters by complex protocols, easier deployment of new applications, and the ability to consolidate management functions. For example, by moving stateful inspection of protocols such as H.323 and SIP out of firewalls, it is possible to improve performance and scalability and reduce development and costs. This working group will concern itself with an environment that consists of: - one or more middle boxes in the data path - an external requesting entity - a policy entity for consultation purposes when the requesting entity is untrusted. The requesting entity may be trusted or untrusted. In the case where it is trusted, the middle box will treat the request from the entity as authoritative. In the case where it is not trusted, the intermediate device will have to verify that it is authorized to complete the request. That authorization could come from a separate or a built in policy server. The primary focus of the working group will be the application of this architecture to communicating requests between applications and firewalls or NATs. This will not preclude other uses, and care will be taken to ensure that the protocol is extensible. The working group will evaluate existing IETF protocols for their applicability to this problem, using the framework and requirements documents developed during the working group's first phase as criteria for the evaluation. If a protocol is found to be suitable it will be used as the basis for the development of a middlebox communication protocol. In the unlikely case that one is not found to be suitable, the working group will undertake development of a new protocol. Discovery of middle boxes is out of scope. The deliverables will be o a document evaluating existing IETF protocols for their suitability o a document specifying a middlebox communication protocol or profile based on the results of the protocol evaluation. This working group will only deal with firewalls and network address translators. Ubiquitous deployment of midcom in all middleboxes could take many years. In the interim, a solution is needed that allows applications to operate in the presence of midcom-unaware middleboxes. To support this, the midcom group will develop or document a protocol or approach that allows clients to indirectly obtain address bindings from midcom- unaware middleboxes, through communications with server elements on the public side of the middlebox. The key goals for this effort are rapid delivery of a simple solution (since it is an interim solution), consistency with the midcom framework, and security. In particular, any proposed interim approaches will address (and document) the architectural and pragmatic concerns described in [UNSAF]. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2004 Oct 2006 Definitions of Managed Objects for Middlebox Communication Mobility for IPv4 (mip4) ------------------------ Charter Last Modified: 2007-02-20 Current Status: Active Working Group Chair(s): Henrik Levkowetz Pete McCann Internet Area Director(s): Jari Arkko Mark Townsley 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 specs to DS, the MIPv4 NAI RFC (2794) will be revised to reflect implementation experience. 2. Work items that are pending from the previous Mobile IP WG, which will be completed by the MIP4 WG, are: - completion of the MIB for the revised base Mobile IP specification (2006bis) - regional registration draft. 3. The MIP4 WG will also complete the work on MIPv4 interactions in VPN scenarios. This work will involve identifying the requirements and a solution development for MIPv4 operation in the presence of IPsec VPNs. 4. Additionally, a proposal has been made for how MOBIKE could work together with MIPv4. This proposal does not describe any new protocol, but formulates a best current practice for deploying MOBIKE together with MIPv4. The working group will adopt and complete this document. 5. Some issues have been raised with respect to RFC3519. These will be identified and addressed as appropriate, through errata, revision of RFC 3519, and/or supplemental documents as needed. 6. It has been proposed that the FMIP protocol, which has been standardised for MIPv6 in the MIPSHOP working group, should also be published as an experimental protocol for MIPv4. A draft for this exists. The working group will take up and carry this work forward to publication 7. An extension to carry generic strings in the Registration Reply message has been proposed. The purpose is to supply supplemental human-readable information intended to the MN user. The working group will complete the specification and applicability statement of such an extension. 8. RADIUS attributes for MIP4. A set of RADIUS attributes has been proposed for MIPv4. The working group will first produce a requirements specification, describing how the work differs from the requirements in RFC 2977 and the functionality provided by RFC 4004 (the MIPv4 Diameter App). The reason why this first step is required is that RFC 3127 shows that full RFC 2977 functionality can't be provided by even a considerably extended RADIUS, so we need to match the requirements to what can be done within RADIUS. Provided the requirements work finds approval with ADs and RADEXT WG, the workgroup 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. 9. MIPv4 Extension for Configuration Options. Several drafts have proposed extensions to help improve configuration of MIPv4 clients. The latest proposal is for a general configuration option extension which could carry information such as e.g., DNS address and DHCP server address. The working group will take on and complete one proposal for a configuration option extension. 10. Dual-stack Support There have been several proposals for how to enable an IPv6 connection over a network that supports Mobile IPv4. A protocol enhancement to MIPv4 would allow for IPv6 support in a region where Mobile IPv4 has already been implemented and deployed. This would allow a dual stack mobile node to maintain IPv6 connectivity when using MIPv4. The solution would therefore be applicable only to networks that are not deploying Mobile IPv6. The working group will take on and complete one proposal for IPv6 over Mobile IPv4. This work is restricted to a small protocol extension similar to current Mobile IPv4 functionality. Support for advanced Mobile IPv6 functionality is strictly outside the scope. A problem statement covering both Mobile IPv4 and IPv6 dual-stack issues is expected to come out of MIP6 WG, and will not be developed in MIP4 WG. 11. MIPv4 Moving Network Support The Network Mobility (nemo) working group deals with the problem of mobility of a whole network, such as might exist inside a vehicle, train, or airplane. The nemo working group has developed draft specifications for both IPv6 and IPv4 mobile networks. However, it has been recognized that the IPv4 version of the protocol can be viewed as an extension of the basic Mobile IPv4 protocol, and there is good reason to do this extension in the mip4 working group. The working group will take on the MIPv4 network mobility internet draft and progress it along the standards track. In addition, the working group will take up extensions to the basic MIPv4 moving network support in the areas of dynamic prefix assignment and foreign agent support. 12. Asynchronous Notification Mechanism In some situations, there is a need for Mobile IPv4 entities, such as the home agent, foreign agent and mobile node to send and receive asynchronous notification events related to the operation of the MIPv4 protocol. A couple of examples of such events are registration revocation from a home agent to a foreign agent in order to terminate the service (to release resources and end charging), and notification of pending HA shutdown and indication of alternative serving HA, from a HA to the mobile node. The base Mobile IP Specification [RFC3344] does not have a provision for this. A new MIPv4 message pair which would support asynchronous notifications, and a notification model describing how to use these messages has been proposed. The working group will take on the existing MIPv4 notification message draft as a starting point, review and update it as needed, and progress it as a standards track document. In addition, the working group will also consider defining specific usages of the notification message based on the examples in the current document. 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 specs to DS, the MIPv4 NAI RFC (2794) will be revised to reflect implementation experience. 2. Work items that are pending from the previous Mobile IP WG, which will be completed by the MIP4 WG, are: - completion of the MIB for the revised base Mobile IP specification (2006bis) - regional registration draft. 3. The MIP4 WG will also complete the work on MIPv4 interactions in VPN scenarios. This work will involve identifying the requirements and a solution development for MIPv4 operation in the presence of IPsec VPNs. 4. Additionally, a proposal has been made for how MOBIKE could work together with MIPv4. This proposal does not describe any new protocol, but formulates a best current practice for deploying MOBIKE together with MIPv4. The working group will adopt and complete this document. 5. Some issues have been raised with respect to RFC3519. These will be identified and addressed as appropriate, through errata, revision of RFC 3519, and/or supplemental documents as needed. 6. It has been proposed that the FMIP protocol, which has been standardised for MIPv6 in the MIPSHOP working group, should also be published as an experimental protocol for MIPv4. A draft for this exists. The working group will take up and carry this work forward to publication 7. An extension to carry generic strings in the Registration Reply message has been proposed. The purpose is to supply supplemental human-readable information intended to the MN user. The working group will complete the specification and applicability statement of such an extension. 8. RADIUS attributes for MIP4. A set of RADIUS attributes has been proposed for MIPv4. The working group will first produce a requirements specification, describing how the work differs from the requirements in RFC 2977 and the functionality provided by RFC 4004 (the MIPv4 Diameter App). The reason why this first step is required is that RFC 3127 shows that full RFC 2977 functionality can't be provided by even a considerably extended RADIUS, so we need to match the requirements to what can be done within RADIUS. Provided the requirements work finds approval with ADs and RADEXT WG, the workgroup 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. 9. MIPv4 Extension for Configuration Options. Several drafts have proposed extensions to help improve configuration of MIPv4 clients. The latest proposal is for a general configuration option extension which could carry information such as e.g., DNS address and DHCP server address. The working group will take on and complete one proposal for a configuration option extension. 10. Dual-stack Support There have been several proposals for how to enable an IPv6 connection over a network that supports Mobile IPv4. A protocol enhancement to MIPv4 would allow for IPv6 support in a region where Mobile IPv4 has already been implemented and deployed. This would allow a dual stack mobile node to maintain IPv6 connectivity when using MIPv4. The solution would therefore be applicable only to networks that are not deploying Mobile IPv6. The working group will take on and complete one proposal for IPv6 over Mobile IPv4. This work is restricted to a small protocol extension similar to current Mobile IPv4 functionality. Support for advanced Mobile IPv6 functionality is strictly outside the scope. A problem statement covering both Mobile IPv4 and IPv6 dual-stack issues is expected to come out of MIP6 WG, and will not be developed in MIP4 WG. 11. MIPv4 Moving Network Support The Network Mobility (nemo) working group deals with the problem of mobility of a whole network, such as might exist inside a vehicle, train, or airplane. The nemo working group has developed draft specifications for both IPv6 and IPv4 mobile networks. However, it has been recognized that the IPv4 version of the protocol can be viewed as an extension of the basic Mobile IPv4 protocol, and there is good reason to do this extension in the mip4 working group. The working group will take on the MIPv4 network mobility internet draft and progress it along the standards track. In addition, the working group will take up extensions to the basic MIPv4 moving network support in the areas of dynamic prefix assignment and foreign agent support. 12. Asynchronous Notification Mechanism In some situations, there is a need for Mobile IPv4 entities, such as the home agent, foreign agent and mobile node to send and receive asynchronous notification events related to the operation of the MIPv4 protocol. A couple of examples of such events are registration revocation from a home agent to a foreign agent in order to terminate the service (to release resources and end charging), and notification of pending HA shutdown and indication of alternative serving HA, from a HA to the mobile node. The base Mobile IP Specification [RFC3344] does not have a provision for this. A new MIPv4 message pair which would support asynchronous notifications, and a notification model describing how to use these messages has been proposed. The working group will take on the existing MIPv4 notification message draft as a starting point, review and update it as needed, and progress it as a standards track document. In addition, the working group will also consider defining specific usages of the notification message based on the examples in the current document. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2001 Oct 2005 Low Latency Handoffs in Mobile IPv4 Sep 2003 Jan 2007 The Definitions of Managed Objects for IP Mobility Support using SMIv2, revised Jul 2004 Mar 2007 IP Mobility Support for IPv4, revised Nov 2004 Oct 2006 Mobile IPv4 Regional Registration Jan 2006 Mar 2007 Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE Jan 2006 Mar 2007 Mobile IPv4 Message String Extension Feb 2006 Feb 2007 Mobile IPv4 RADIUS requirements Feb 2006 Mar 2007 Mobile IPv4 Fast Handovers Jun 2006 Feb 2007 Mobile IPv4 Extension for Configuration Options Exchange Aug 2006 Dec 2006 Dual Stack Mobile IPv4 Mar 2007 Mar 2007 IPv4 Network Mobility (NEMO) Protocol Mar 2007 Mar 2007 Generic Notification Message for Mobile IPv4 Mobility for IPv6 (mip6) ------------------------ Charter Last Modified: 2007-02-20 Current Status: Active Working Group Chair(s): Basavaraj Patil Gopal Dommety Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:mip6@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mip6 Archive: http://www.ietf.org/mail-archive/web/mip6/index.html Description of Working Group: Mobile IPv6 (MIP6) 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. The base specifications for Mobile IPv6 consist of: o RFC 3775 o RFC 3776 The primary goal of the MIP6 working group will be to enhance base IPv6 mobility by continuing work on developments that are required for wide-scale deployments. Additionally the working group will ensure that any issues identified by implementation and interoperability experience are addressed, and that the base specifications are maintained. The group will also produce informational documentation, such as design rationale documents or description of specific issues within the protocol. Deployment considerations call for work to reduce per-mobile node configuration and enrollment effort, solutions to enable dual-stack operation, mechanisms to support high-availabity home agents, and ways to employ Mobile IPv6 in the presence of firewalls. Work items related to base specification maintenance include: - Create and maintain an issue list that is 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. - Update RFC 3776 to specify the usage of IKEv2 for the establishment of the IPsec SA between the MN and HA. This work also provides a way for a mobile node to change its home address or employ multiple home addresses as needed. - Update the IANA considerations of RFC 3775 to allow extensions for experimental purposes as well passing of optional vendor-specific information. Work items related to large scale deployment include: - Bootstrapping Mobile IPv6: A bootstrapping mechanism is intended to be used when the device is turned on the very first time and activates Mobile IPv6, or periodically such as when powering on. The WG should investigate and define the scope before solving the problem. Work on the problem statement and the solutions needed for various deployment scenarios. Work with other WGs such as DHC for defining the options needed for bootstrapping. - Capture the AAA requirements needed for bootstrapping and deployment, and work with the Radext and DiME WGs on the solutions. - A Solution for MIP6 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 MIP6 capable dual-stack hosts. This work will be done in collaboration with the NEMO WG. - A protocol based solution for enhancing the reliability of home agents and a method to force a host 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 may need to be taken offline for maintenance. - Work on solutions to deal with firewalls and the problems that firewalls cause as identified in RFC 4487. Work items related to informational documentation include: - Produce a problem statement relating to location privacy and the use of Mobile IPv6. Work with the IRTF MOBOPTS RG on developing the solution. - Produce a design rationale that documents the historical thinking behind the introduction of an alternative security mechanism, the Authentication Protocol (RFC 4285). It should be noted that some of the features that are directly related to Mobile IPv6 are being worked on in the MONAMI6, MIPSHOP, and NEMO working groups. The specific extensions from these groups are out of scope for the MIP6 working group. In particular, all optimizations are out of scope. However, MIP6 may assist these groups when they use features listed above and have requirements on them. Description of Working Group: Mobile IPv6 (MIP6) 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. The base specifications for Mobile IPv6 consist of: o RFC 3775 o RFC 3776 The primary goal of the MIP6 working group will be to enhance base IPv6 mobility by continuing work on developments that are required for wide-scale deployments. Additionally the working group will ensure that any issues identified by implementation and interoperability experience are addressed, and that the base specifications are maintained. The group will also produce informational documentation, such as design rationale documents or description of specific issues within the protocol. Deployment considerations call for work to reduce per-mobile node configuration and enrollment effort, solutions to enable dual-stack operation, mechanisms to support high-availabity home agents, and ways to employ Mobile IPv6 in the presence of firewalls. Work items related to base specification maintenance include: - Create and maintain an issue list that is 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. - Update RFC 3776 to specify the usage of IKEv2 for the establishment of the IPsec SA between the MN and HA. This work also provides a way for a mobile node to change its home address or employ multiple home addresses as needed. - Update the IANA considerations of RFC 3775 to allow extensions for experimental purposes as well passing of optional vendor-specific information. Work items related to large scale deployment include: - Bootstrapping Mobile IPv6: A bootstrapping mechanism is intended to be used when the device is turned on the very first time and activates Mobile IPv6, or periodically such as when powering on. The WG should investigate and define the scope before solving the problem. Work on the problem statement and the solutions needed for various deployment scenarios. Work with other WGs such as DHC for defining the options needed for bootstrapping. - Capture the AAA requirements needed for bootstrapping and deployment, and work with the Radext and DiME WGs on the solutions. - A Solution for MIP6 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 MIP6 capable dual-stack hosts. This work will be done in collaboration with the NEMO WG. - A protocol based solution for enhancing the reliability of home agents and a method to force a host 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 may need to be taken offline for maintenance. - Work on solutions to deal with firewalls and the problems that firewalls cause as identified in RFC 4487. Work items related to informational documentation include: - Produce a problem statement relating to location privacy and the use of Mobile IPv6. Work with the IRTF MOBOPTS RG on developing the solution. - Produce a design rationale that documents the historical thinking behind the introduction of an alternative security mechanism, the Authentication Protocol (RFC 4285). It should be noted that some of the features that are directly related to Mobile IPv6 are being worked on in the MONAMI6, MIPSHOP, and NEMO working groups. The specific extensions from these groups are out of scope for the MIP6 working group. In particular, all optimizations are out of scope. However, MIP6 may assist these groups when they use features listed above and have requirements on them. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2004 Dec 2006 Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture Jan 2005 Mar 2007 Using IPsec between Mobile and Correspondent IPv6 Nodes May 2005 Sep 2006 AAA Goals for Mobile IPv6 Jun 2005 Dec 2006 Mobile IPv6 bootstrapping in split scenario Jul 2005 Jan 2007 Problem Statement: Dual Stack Mobility Oct 2005 Feb 2007 IP Address Location Privacy and Mobile IPv6: Problem Statement Oct 2005 Feb 2007 MIP6-bootstrapping for the Integrated Scenario Oct 2005 Mar 2007 Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6) Jun 2006 Mar 2007 Mobility Header Home Agent Switch Message Jun 2006 Mar 2007 Home Agent Reliability Protocol Aug 2006 Feb 2007 DHCP Option for Home Information Discovery in MIPv6 Oct 2006 Mar 2007 RADIUS Mobile IPv6 Support Dec 2006 Feb 2007 Mobile IPv6 Experimental Messages Dec 2006 Feb 2007 Mobile IPv6 Vendor Specific Option Mar 2007 Mar 2007 Authentication Protocol for Mobile IPv6 Mobility for IP: Performance, Signaling and Handoff Optimization (mipshop) -------------------------------------------------------------------------- Charter Last Modified: 2006-12-19 Current Status: Active Working Group Chair(s): Stefano Faccin Vijay Devarapalli Internet Area Director(s): Jari Arkko Mark Townsley 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 using a given "home address" in spite of changes in its point of attachment to the network. These changes may cause packet loss, and also represent overhead traffic on the network. The previous MIPSHOP charter directed the group to continue work (started by the Mobile IP Working group) on two technologies to address these issues. Hierarchical Mobile IPv6 (HMIPv6, RFC 4140) reduces the amount and latency of signaling between a MN, its Home Agent and one or more correspondent nodes. Fast Handovers for Mobile IPv6 (FMIPv6, RFC 4068) reduces packet loss by providing fast IP connectivity as soon as the mobile node establishes a new point of attachment at a new link. As part of its previous set of work items, MIPSHOP published these two protocols as experimental RFCs. An information document on how FMIPv6 can operate over IEEE 802.11 was also published as an informational RFC. Further implementation work by the community has increased the understanding of how FMIPv6 behaves or should behave on other link layers, and in general. Similarly, further implementation and experimentation with HMIPv6 has resulted in better understanding of the protocol. Accordingly, MIPSHOP will continue work on HMIPv6 and FMIPv6 in order to prepare their publication as proposed standards. Additionally, the IEEE 802.21 Media Independent Handoff (MIH) working group aims at providing services to assist with handoffs between heterogeneous link-layer technologies, and across IP subnet boundaries. The information exchanges defined by IEEE 802.21 are classified as MI (Media Independent) Event Service (MIES), MI Command Service (MICS), and MI Information Service (MIIS). The MIIS provides topological and location-related information of service networks. The MIES provides timely communications of wireless environment information via the delivery of events originating across the link-layer or farther away. The MICS is an analogous service for commands which can change the state of the wireless link or of a host's point of attachment, potentially triggering further event generation. 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. Notice that this allows the network information to reside anywhere (not necessarily across the link-layer hop), and enables MIH services even in the absence of the corresponding link-layer support. An L2 or L3 based mechanism to identify a valid information server is also required; in particular for L3, we expect that any of the several current L3 discovery mechanisms will be used. A liaison with IEEE 802.21 has been established, and access to the IEEE 802.21 drafts is granted to mipshop members. Interested members need to send a request to the WG chairs in order to obtain a copy of the current IEEE 802.21 draft. There have been several proposals to improve upon the Return Routability procedure defined in MIPv6 (RFC 3775), both in terms of the security of the mechanism as well as with respect to its performance. In particular, discussions within the MOBOPTS Research Group of the IRTF have centered on reducing the round trip times required to complete the procedure, and on increasing the length of time before the procedure needs to be run again. Some proposals are mature enough that they will be taken over by MIPSHOP for standardization. The WG will be very proactive in seeking AD-coordinated security reviews of the drafts developed in the WG. Scope of MIPSHOP: The working group will: 1. Revise the specification of HMIPv6 (RFC 4140) protocol to advance it to Proposed Standard. This implies: * Work on MN-MAP security * Streamline and refine the current HMIPv6 specification. * Document: draft-ietf-mipshop-hmipv6-rev-XX.txt 2. Revise the specification of FMIPv6 protocol (RFC 4068) to advance it to Proposed Standard. * Work on MN-AR (access router) security using both the AAA infrastructure, and keys derived from SeND o Documents: draft-ietf-mipshop-handover-keys-aaa-XX.txt, draft-ietf-mipshop-handover-key-send-XX.txt * Streamline and refine the current FMIPv6 specification (draft-ietf-mipshop-fmipv6-rev-XX.txt) 3. Work on the application of FMIPv6 on two examples link-layers for advancement as Informational RFCs: * IEEE 802.16e (and WiMax), and * 3G CDMA 2K networks * Documents: draft-ietf-mipshop-fh80216e-XX.txt, draft-ietf-mipshop-3gfh-XX.txt 4. Produce a document on improving MIPv6 Return Routability via both Cryptographically Generated Addresses and Credit-based Authorization for advancement as Proposed Standard * Documents: draft-ietf-mipshop-cga-cba-XX.txt 5. Work on areas of mutual interest to IEEE 802.21 and MIPSHOP: * Produce the required protocol enhancements or specifications for IP-based support of Media-Independent Information, Command and Event Services. * Documents: draft-ietf-mipshop-mih-info-elements-XX.txt (information elements), draft-ietf-mipshop-mih-support-XX.txt (transport of 802.21 services over IP, including security aspects) Tackling further work, although possible, requires re-chartering. Description of Working Group: Mobile IPv6 enables IPv6 mobile nodes to continue using a given "home address" in spite of changes in its point of attachment to the network. These changes may cause packet loss, and also represent overhead traffic on the network. The previous MIPSHOP charter directed the group to continue work (started by the Mobile IP Working group) on two technologies to address these issues. Hierarchical Mobile IPv6 (HMIPv6, RFC 4140) reduces the amount and latency of signaling between a MN, its Home Agent and one or more correspondent nodes. Fast Handovers for Mobile IPv6 (FMIPv6, RFC 4068) reduces packet loss by providing fast IP connectivity as soon as the mobile node establishes a new point of attachment at a new link. As part of its previous set of work items, MIPSHOP published these two protocols as experimental RFCs. An information document on how FMIPv6 can operate over IEEE 802.11 was also published as an informational RFC. Further implementation work by the community has increased the understanding of how FMIPv6 behaves or should behave on other link layers, and in general. Similarly, further implementation and experimentation with HMIPv6 has resulted in better understanding of the protocol. Accordingly, MIPSHOP will continue work on HMIPv6 and FMIPv6 in order to prepare their publication as proposed standards. Additionally, the IEEE 802.21 Media Independent Handoff (MIH) working group aims at providing services to assist with handoffs between heterogeneous link-layer technologies, and across IP subnet boundaries. The information exchanges defined by IEEE 802.21 are classified as MI (Media Independent) Event Service (MIES), MI Command Service (MICS), and MI Information Service (MIIS). The MIIS provides topological and location-related information of service networks. The MIES provides timely communications of wireless environment information via the delivery of events originating across the link-layer or farther away. The MICS is an analogous service for commands which can change the state of the wireless link or of a host's point of attachment, potentially triggering further event generation. 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. Notice that this allows the network information to reside anywhere (not necessarily across the link-layer hop), and enables MIH services even in the absence of the corresponding link-layer support. An L2 or L3 based mechanism to identify a valid information server is also required; in particular for L3, we expect that any of the several current L3 discovery mechanisms will be used. A liaison with IEEE 802.21 has been established, and access to the IEEE 802.21 drafts is granted to mipshop members. Interested members need to send a request to the WG chairs in order to obtain a copy of the current IEEE 802.21 draft. There have been several proposals to improve upon the Return Routability procedure defined in MIPv6 (RFC 3775), both in terms of the security of the mechanism as well as with respect to its performance. In particular, discussions within the MOBOPTS Research Group of the IRTF have centered on reducing the round trip times required to complete the procedure, and on increasing the length of time before the procedure needs to be run again. Some proposals are mature enough that they will be taken over by MIPSHOP for standardization. The WG will be very proactive in seeking AD-coordinated security reviews of the drafts developed in the WG. Scope of MIPSHOP: The working group will: 1. Revise the specification of HMIPv6 (RFC 4140) protocol to advance it to Proposed Standard. This implies: * Work on MN-MAP security * Streamline and refine the current HMIPv6 specification. * Document: draft-ietf-mipshop-hmipv6-rev-XX.txt 2. Revise the specification of FMIPv6 protocol (RFC 4068) to advance it to Proposed Standard. * Work on MN-AR (access router) security using both the AAA infrastructure, and keys derived from SeND o Documents: draft-ietf-mipshop-handover-keys-aaa-XX.txt, draft-ietf-mipshop-handover-key-send-XX.txt * Streamline and refine the current FMIPv6 specification (draft-ietf-mipshop-fmipv6-rev-XX.txt) 3. Work on the application of FMIPv6 on two examples link-layers for advancement as Informational RFCs: * IEEE 802.16e (and WiMax), and * 3G CDMA 2K networks * Documents: draft-ietf-mipshop-fh80216e-XX.txt, draft-ietf-mipshop-3gfh-XX.txt 4. Produce a document on improving MIPv6 Return Routability via both Cryptographically Generated Addresses and Credit-based Authorization for advancement as Proposed Standard * Documents: draft-ietf-mipshop-cga-cba-XX.txt 5. Work on areas of mutual interest to IEEE 802.21 and MIPSHOP: * Produce the required protocol enhancements or specifications for IP-based support of Media-Independent Information, Command and Event Services. * Documents: draft-ietf-mipshop-mih-info-elements-XX.txt (information elements), draft-ietf-mipshop-mih-support-XX.txt (transport of 802.21 services over IP, including security aspects) Tackling further work, although possible, requires re-chartering. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Apr 2006 Jan 2007 Mobile IPv6 Fast Handovers over IEEE 802.16e Networks May 2006 Mar 2007 Mobile IPv6 Fast Handovers for 3G CDMA Networks May 2006 Mar 2007 Fast Handovers for Mobile IPv6 Aug 2006 Feb 2007 Enhanced Route Optimization for Mobile IPv6 Jan 2007 Jan 2007 Mobility Independent Services: Problem Statement Mar 2007 Mar 2007 Distributing a Symmetric FMIPv6 Handover Key using SEND Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- Charter Last Modified: 2006-07-05 Current Status: Active Working Group Chair(s): Joerg Ott Colin Perkins Jean-Francois Mule Real-time Applications and Infrastructure Area Director(s): Jon Peterson 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 deployment. The group is now focussed on the revisions of these protocols in the light of implementation experience and additional demands that have arisen from other WGs (such as AVT, SIP, SIPPING, and MEGACO). 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. In spite of these, it is widely deployed. - To support this current deployment, MMUSIC will revise SDP suitable for publication as a Draft Standard RFC. This will involve correcting minor bugs and clarifying the current specification. - Various extensions to SDP will be pursued to remedy the most urgent of SDP's shortcomings. These will be limited to use of SDP in conjunction with connection-oriented media such as TCP and SCTP, offering support to work with NATs and firewalls (e.g. via the ICE methodology), and exchange of media session security keys. 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 address the more fundamental issues with SDP, a next generation of SDP, referred to as SDPng, will be needed. An initial proposal is now available, and will be progressed to Experimental RFC while we gain experience with implementations. An informational document will be produced describing how the transition to a new session description protocol can be managed, to prepare implementors for such a future change. MMUSIC will 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. An Internet Media Guide (IMG) is a collection of multimedia session descriptions expressed using SDP or some other session description format. It is used to describe a collection of multimedia sessions (e.g. television programme schedules). The IMG must be delivered to a potentially large audience, who use it to join a subset of the sessions described, and who may need to be notified of changes to the IMG. MMUSIC will investigate delivery mechanisms for IMGs, generalizing our work on session announcement and discovery protocols (SAP, RTSP, SIP). We will investigate and document requirements for IMG delivery mechanisms, and identify the requirements that these delivery mechanisms impose on the session description formats used by the IMG. We will then work to produce a framework document outlining the use of (existing) protocols to create an IMG delivery infrastructure. After successful completion of these initial milestones for IMG delivery, the MMUSIC working group will decide whether or not MMUSIC is the proper place to pursue any needed mechanisms for IMGs, and if so, recharter accordingly The MMUSIC work items will be pursued in close coordination with other IETF WGs related to multimedia conferencing and IP telephony (AVT, SIP, SIPPING, SIMPLE, XCON, MEGACO and, where appropriate, MIDCOM and NSIS). Where appropriate, new separate working groups may be split off (as has happened with the SIP WG). The Working Group is also charged with addressing security issues related to the protocols it develops. 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 deployment. The group is now focussed on the revisions of these protocols in the light of implementation experience and additional demands that have arisen from other WGs (such as AVT, SIP, SIPPING, and MEGACO). 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. In spite of these, it is widely deployed. - To support this current deployment, MMUSIC will revise SDP suitable for publication as a Draft Standard RFC. This will involve correcting minor bugs and clarifying the current specification. - Various extensions to SDP will be pursued to remedy the most urgent of SDP's shortcomings. These will be limited to use of SDP in conjunction with connection-oriented media such as TCP and SCTP, offering support to work with NATs and firewalls (e.g. via the ICE methodology), and exchange of media session security keys. 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 address the more fundamental issues with SDP, a next generation of SDP, referred to as SDPng, will be needed. An initial proposal is now available, and will be progressed to Experimental RFC while we gain experience with implementations. An informational document will be produced describing how the transition to a new session description protocol can be managed, to prepare implementors for such a future change. MMUSIC will 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. An Internet Media Guide (IMG) is a collection of multimedia session descriptions expressed using SDP or some other session description format. It is used to describe a collection of multimedia sessions (e.g. television programme schedules). The IMG must be delivered to a potentially large audience, who use it to join a subset of the sessions described, and who may need to be notified of changes to the IMG. MMUSIC will investigate delivery mechanisms for IMGs, generalizing our work on session announcement and discovery protocols (SAP, RTSP, SIP). We will investigate and document requirements for IMG delivery mechanisms, and identify the requirements that these delivery mechanisms impose on the session description formats used by the IMG. We will then work to produce a framework document outlining the use of (existing) protocols to create an IMG delivery infrastructure. After successful completion of these initial milestones for IMG delivery, the MMUSIC working group will decide whether or not MMUSIC is the proper place to pursue any needed mechanisms for IMGs, and if so, recharter accordingly The MMUSIC work items will be pursued in close coordination with other IETF WGs related to multimedia conferencing and IP telephony (AVT, SIP, SIPPING, SIMPLE, XCON, MEGACO and, where appropriate, MIDCOM and NSIS). Where appropriate, new separate working groups may be split off (as has happened with the SIP WG). The Working Group is also charged with addressing security issues related to the protocols it develops. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2002 May 2003 SDPng Transition Feb 2002 Dec 2006 Real Time Streaming Protocol 2.0 (RTSP) Oct 2003 Mar 2007 Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols Dec 2004 Sep 2006 An Extension to the Session Description Protocol (SDP) for Media Loopback Feb 2005 Oct 2006 Security Preconditions for Session Description Protocol (SDP) Media Streams Mar 2006 Mar 2007 TCP Candidates with Interactive Connectivity Establishment (ICE Dec 2006 Mar 2007 SDP Capability Negotiation: Requirements and Review of Existing Work Dec 2006 Dec 2006 A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer Jan 2007 Mar 2007 SDP Capability Negotiation Feb 2007 Feb 2007 SDP media capabilities Negotiation Mobile Nodes and Multiple Interfaces in IPv6 (monami6) ------------------------------------------------------ Charter Last Modified: 2006-12-27 Current Status: Active Working Group Chair(s): Thierry Ernst Nicolas Montavont Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:monami6@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/monami6 Archive: http://www.ietf.org/mail-archive/web/monami6/current/index.html Description of Working Group: There is currently rapid development in the area of new wireless standards (802.11*, 802.16, 802.20, UMTS, Bluetooth and others). At the same time, terminals which have radio and protocol support for two, three or even more standards are appearing. This opens the possibility of using multiple access types simultaneously, with each access used to transport the traffic for which it is most appropriate. For instance, an intermittent, but high-bandwidth access type might be used for file transfers (e.g. music download) while a low-bandwidth, high reliability access might simultaneously be used for a voice call. In the meantime, IP-level mobility support protocols such as Mobile IPv6 (RFC 3775) and NEMO Basic Support (RFC 3963) have been conceived by the IETF to support handoffs for IPv6 mobile hosts and routers, respectively. However, these protocols do not today provide standardized support for simultaneous differentiated use of multiple access technologies, although 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. Some of the issues are very specific to mobility and are generally applicable to both mobile hosts and mobile routers using Mobile IPv6 and NEMO Basic Support respectively. Some of these issues can be resolved with relatively small and straight-forward changes to Mobile IPv6 and NEMO Basic Support (e.g. multiple CoAs registration). The objective of the Monami6 WG is to produce a clear problem statement and to produce standard track specifications to the straight-forward 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, Monami6 will consider a generalized approach to cater for multiple prefixes available to a mobile host/router. Once this is done, the WG might re-charter in order to work on more generic issues that prevent taking advantage of the multiple CoAs and HoAs available to mobile nodes and routers. The WG does not plan to define a tunnel selection mechanism, but may 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). WG Deliverables: - 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 Mobile IPv6 (RFC 3775) and NEMO Basic Support (RFC 3963) 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 [Standard Track]. Description of Working Group: There is currently rapid development in the area of new wireless standards (802.11*, 802.16, 802.20, UMTS, Bluetooth and others). At the same time, terminals which have radio and protocol support for two, three or even more standards are appearing. This opens the possibility of using multiple access types simultaneously, with each access used to transport the traffic for which it is most appropriate. For instance, an intermittent, but high-bandwidth access type might be used for file transfers (e.g. music download) while a low-bandwidth, high reliability access might simultaneously be used for a voice call. In the meantime, IP-level mobility support protocols such as Mobile IPv6 (RFC 3775) and NEMO Basic Support (RFC 3963) have been conceived by the IETF to support handoffs for IPv6 mobile hosts and routers, respectively. However, these protocols do not today provide standardized support for simultaneous differentiated use of multiple access technologies, although 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. Some of the issues are very specific to mobility and are generally applicable to both mobile hosts and mobile routers using Mobile IPv6 and NEMO Basic Support respectively. Some of these issues can be resolved with relatively small and straight-forward changes to Mobile IPv6 and NEMO Basic Support (e.g. multiple CoAs registration). The objective of the Monami6 WG is to produce a clear problem statement and to produce standard track specifications to the straight-forward 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, Monami6 will consider a generalized approach to cater for multiple prefixes available to a mobile host/router. Once this is done, the WG might re-charter in order to work on more generic issues that prevent taking advantage of the multiple CoAs and HoAs available to mobile nodes and routers. The WG does not plan to define a tunnel selection mechanism, but may 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). WG Deliverables: - 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 Mobile IPv6 (RFC 3775) and NEMO Basic Support (RFC 3963) 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 [Standard Track]. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2006 Feb 2007 Analysis of Multihoming in Mobile IPv6 Mar 2006 Oct 2006 Motivations and Scenarios for Using Multiple Interfaces and Global Addresses Jun 2006 Mar 2007 Multiple Care-of Addresses Registration Multiprotocol Label Switching (mpls) ------------------------------------ Charter Last Modified: 2006-03-24 Current Status: Active Working Group Chair(s): George Swallow Loa Andersson Routing Area Director(s): Ross Callon Bill Fenner Routing Area Advisor: Ross Callon Mailing Lists: General Discussion:mpls@lists.ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/mpls Archive: http://cell.onecall.net/cell-relay/archives/mpls/mpls.index.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 MIBs 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 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 MIBs 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 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 1999 Feb 2007 ICMP Extensions for MultiProtocol Label Switching Jul 2002 Mar 2007 Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute Apr 2003 Oct 2006 MPLS Traffic Engineering Soft Preemption Oct 2003 Oct 2005 Label Switching Router Self-Test Oct 2004 Sep 2006 LDP Specification Oct 2004 Feb 2007 Avoiding Equal Cost Multipath Treatment in MPLS Networks Nov 2004 Jan 2007 Extensions to RSVP-TE for Point-to-Multipoint TE LSPs Feb 2005 Nov 2006 Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3 Sep 2005 Mar 2007 Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping Sep 2005 Oct 2006 Component Link Recording and Resource Control for GMPLS Link Bundles Sep 2005 Sep 2005 Experience with the LDP protocol Oct 2005 Oct 2005 LDP Implementation Survey Results Feb 2006 Mar 2007 MPLS Multicast Encapsulations Mar 2006 Oct 2006 Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths Mar 2006 Mar 2007 MPLS Upstream Label Assignment and Context Specific Label Space Mar 2006 Mar 2007 MPLS Upstream Label Assignment for RSVP-TE Apr 2006 Mar 2007 MPLS Upstream Label Assignment for LDP May 2006 Mar 2007 Requirements for Point-To-Multipoint Extensions to the Label Distribution Protocol May 2006 Dec 2006 A Link-Type sub-TLV to convey the number of Traffic Engineering Label Switched Paths signalled with zero reserved bandwidth across a link Jul 2006 Feb 2007 Codepoint Registry for The Flags Field in the Resource Reservation Protocol Traffic Engineering (RSVP-TE) Session Attribute Object Sep 2006 Feb 2007 Point-to-Multipoint Multiprotocol Label Switching (MPLS)Traffic Engineering (TE) Management Information Base (MIB) module Jan 2007 Jan 2007 LDP Typed Wildcard FEC Mar 2007 Mar 2007 Detecting MPLS Data Plane Failures in Inter-AS and inter-provider Scenarios Multicast Security (msec) ------------------------- Charter Last Modified: 2007-02-16 Current Status: Active Working Group Chair(s): Ran Canetti Lakshminath Dondeti Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Russ Housley Mailing Lists: General Discussion:msec@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/msec Archive: http://www.ietf.org/mail-archive/web/msec/current/index.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 ------ ------- -------------------------------------------- Jul 2005 Oct 2006 ECC Algorithms for MIKEY Jul 2005 Feb 2007 Multicast Extensions to the Security Architecture for the Internet Protocol Sep 2005 Feb 2007 GKDP: Group Key Distribution Protocol May 2006 Dec 2006 On the applicability of various MIKEY modes and extensions Jun 2006 Mar 2007 Updates to the Group Domain of Interpretation (GDOI) Jun 2006 Mar 2007 Use of TESLA in the ALC and NORM Protocols Nov 2006 Feb 2007 Multicast IP Security Composite Cryptographic Groups Feb 2007 Feb 2007 GDOI Key Establishment for the SRTP Data Security Protocol Feb 2007 Feb 2007 Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic Site Multihoming in IPv6 (multi6) --------------------------------- Charter Last Modified: 2007-01-24 Current Status: Active Working Group Chair(s): Kurt Lindqvist Operations and Management Area Director(s): Dan Romascanu David Kessens Operations and Management Area Advisor: David Kessens Mailing Lists: General Discussion:multi6@ops.ietf.org To Subscribe: majordomo@ops.ietf.org In Body: subscribe multi6 Archive: https://ops.ietf.org/lists/multi6 Description of Working Group: A multihomed site is a site that has more than one connection to the public internet with those connections through either the same or different ISPs. Sites choose to multihome for several reasons, especially to improve fault tolerance, perform load balancing, etc. Multihoming today is done largely by having a site obtain a dedicated block of address space and then advertising a route for its prefix through each of its ISP connections. The address block may be from the so-called provider independent space, or may be a sub-allocation from one of its ISPs. A site's ISPs in turn advertise the prefix to some or all of their upstream connections and the route for the prefix may propagate to all of the routers connected to the default-free zone (DFZ). As the number of sites multihoming in this manner increase, the number of routes propagated throughout the DFZ increases and overall routing stability decreases because of the burden on convergence time. This WG will seek alternative approaches with better scaling properties. Specifically, the WG will prefer multihoming solutions that tend to minimise adverse impacts on the end-to-end routing system and limit the number of prefixes that need to be advertised in the Default-Free Zone (DFZ). Just as sites have multiple reasons to choose multihoming, they may have multiple reasons to want to provide these benefits more directly to hosts within their sites, for instance, because some of those hosts may have network stacks capable of detecting and surviving a provider/prefix change. Phasing in hosts with capabilities of multihoming might be part of the Multi6 solution space. In the course of this work, the WG may also study the deeper underlying questions of identity and location of services, hosts and sites as they directly affect multihoming.However, the working group is not chartered to make significant changes to the nature of IP addresses or to inter-domain routing. This WG will consider the problem of how to multihome sites in IPv6. The multihoming approaches currently used in IPv4 can of course be used in IPv6, but IPv6 represents an opportunity for more scalable approaches. IPv6 differs from IPv4 in ways that may allow for different approaches to multihoming that are not immediately applicable to IPv4. For example, IPv6 has larger addresses, hosts support multiple addresses per interface, and relatively few IPv6 address blocks have been given out (i.e., there are no issues with legacy allocations as in IPv4). Also, IPv6 deployment is at an early stage, so modest enhancements to IPv6 could still be proposed. The WG has already produced a document, RFC 3582, on goals for IPv6 site multihoming architectures. It is recognised that this set of goals is ambitious and that some goals may conflict with others. The solution or solutions adopted may only be able to satisfy some of the goals presented there. The WG will take on the following tasks: ======================================== Produce a document describing how multihoming is done today in IPv4, including an explanation of both the advantages and limitations of the approaches. Produce a document outlining practical questions to be considered when evaluating proposals meeting the RFC 3582 goals, including questions concerning upper layer protocols. Produce a document describing the security threats to be addressed by multihoming solutions. Solicit and evaluate specific proposals to multihoming in IPv6 (both existing and new), extract and analyse common architectural features, and select one or a small number of proposals for further development. The architectural analysis will include applications layer considerations and transport layer considerations, as well as lower layer issues. Development of specific solutions will require chartering of work in the appropriate Area or Areas. Description of Working Group: A multihomed site is a site that has more than one connection to the public internet with those connections through either the same or different ISPs. Sites choose to multihome for several reasons, especially to improve fault tolerance, perform load balancing, etc. Multihoming today is done largely by having a site obtain a dedicated block of address space and then advertising a route for its prefix through each of its ISP connections. The address block may be from the so-called provider independent space, or may be a sub-allocation from one of its ISPs. A site's ISPs in turn advertise the prefix to some or all of their upstream connections and the route for the prefix may propagate to all of the routers connected to the default-free zone (DFZ). As the number of sites multihoming in this manner increase, the number of routes propagated throughout the DFZ increases and overall routing stability decreases because of the burden on convergence time. This WG will seek alternative approaches with better scaling properties. Specifically, the WG will prefer multihoming solutions that tend to minimise adverse impacts on the end-to-end routing system and limit the number of prefixes that need to be advertised in the Default-Free Zone (DFZ). Just as sites have multiple reasons to choose multihoming, they may have multiple reasons to want to provide these benefits more directly to hosts within their sites, for instance, because some of those hosts may have network stacks capable of detecting and surviving a provider/prefix change. Phasing in hosts with capabilities of multihoming might be part of the Multi6 solution space. In the course of this work, the WG may also study the deeper underlying questions of identity and location of services, hosts and sites as they directly affect multihoming.However, the working group is not chartered to make significant changes to the nature of IP addresses or to inter-domain routing. This WG will consider the problem of how to multihome sites in IPv6. The multihoming approaches currently used in IPv4 can of course be used in IPv6, but IPv6 represents an opportunity for more scalable approaches. IPv6 differs from IPv4 in ways that may allow for different approaches to multihoming that are not immediately applicable to IPv4. For example, IPv6 has larger addresses, hosts support multiple addresses per interface, and relatively few IPv6 address blocks have been given out (i.e., there are no issues with legacy allocations as in IPv4). Also, IPv6 deployment is at an early stage, so modest enhancements to IPv6 could still be proposed. The WG has already produced a document, RFC 3582, on goals for IPv6 site multihoming architectures. It is recognised that this set of goals is ambitious and that some goals may conflict with others. The solution or solutions adopted may only be able to satisfy some of the goals presented there. The WG will take on the following tasks: ======================================== Produce a document describing how multihoming is done today in IPv4, including an explanation of both the advantages and limitations of the approaches. Produce a document outlining practical questions to be considered when evaluating proposals meeting the RFC 3582 goals, including questions concerning upper layer protocols. Produce a document describing the security threats to be addressed by multihoming solutions. Solicit and evaluate specific proposals to multihoming in IPv6 (both existing and new), extract and analyse common architectural features, and select one or a small number of proposals for further development. The architectural analysis will include applications layer considerations and transport layer considerations, as well as lower layer issues. Development of specific solutions will require chartering of work in the appropriate Area or Areas. Internet-Drafts: No Current Internet-Drafts. Network Endpoint Assessment (nea) --------------------------------- Charter Last Modified: 2006-12-15 Current Status: Active Working Group Chair(s): Susan Thomson Stephen Hanna Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Russ Housley Mailing Lists: General Discussion:nea@ietf.org To Subscribe: http://www1.ietf.org/mailman/listinfo/nea Archive: http://www1.ietf.org/mail-archive/web/nea/current/index.html 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 priority of the NEA working group is to develop standard protocols at the higher layers in the architecture: the Posture Attribute protocol (PA) and the Posture Broker protocol (PB). PA and PB will be designed to support a variety of lower layer protocols. When used with standards for lower layers, the PA and PB 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 higher 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). PT protocols may be standardized in other WGs since these protocols may not be specific to NEA. The NEA WG will identify and specify the use of one mandatory to implement PT protocol that is fully documented in an RFC. 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 NEA working group will not specify protocols other than PA and PB at this time. The expectation is that an existing protocol can be used for the PT. 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 priority of the NEA working group is to develop standard protocols at the higher layers in the architecture: the Posture Attribute protocol (PA) and the Posture Broker protocol (PB). PA and PB will be designed to support a variety of lower layer protocols. When used with standards for lower layers, the PA and PB 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 higher 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). PT protocols may be standardized in other WGs since these protocols may not be specific to NEA. The NEA WG will identify and specify the use of one mandatory to implement PT protocol that is fully documented in an RFC. 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 NEA working group will not specify protocols other than PA and PB at this time. The expectation is that an existing protocol can be used for the PT. 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 ------ ------- -------------------------------------------- Jan 2007 Mar 2007 Requirements for Network Endpoint Assessment (NEA) Network Mobility (nemo) ----------------------- Charter Last Modified: 2006-12-15 Current Status: Active Working Group Chair(s): TJ Kniveton Thierry Ernst Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Technical Advisor(s): Steven Bellovin Mailing Lists: General Discussion:nemo@ietf.org To Subscribe: nemo-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/nemo/index.html Description of Working Group: The NEMO Working Group is concerned with managing the mobility of an entire network, which changes, as a unit, its point of attachment to the Internet and thus its reachability in the topology. The mobile network includes one or more mobile routers (MRs) which connect it to the global Internet. A mobile network is assumed to be a leaf network, i.e. it will not carry transit traffic. However,it could be multihomed, either with a single MR that has multiple attachments to the internet, or by using multiple MRs that attach the mobile network to the Internet. Initially,the WG will assume that none of the nodes behind the MR will be aware of the network's mobility, thus the network's movement needs to be completely transparent to the nodes inside the mobile network. This assumption will be made to accomodate nodes inside the network that are not generally aware of mobility. A basic approach for network mobility support is for each Mobile Router to have a Home Agent, and use bidirectional tunneling between the MR and HA to preserve session continuity while the MR moves. The MR will acquire a Care-of-address from its attachment point much like what is done for Mobile Nodes using Mobile IP. This approach allows nesting of mobile networks, since each MR will appear to its attachment point as a single node. The WG will take a stepwise approach by standardizing some basic support mechanisms based on the bidirectional tunneling approach, and at the same time study the possible approaches and issues with providing more optimal routing than can be had with (potentially nested) tunneling. However, the WG is not chartered to actually standardize a solution to such route optimization for mobile networks at this point in time. The WG will work on: - A threat analysis and security solution for the basic problem (tunneling between HA and MR) - A solution to the basic problem for both IPv4 and IPv6. The solution will allow all nodes in the mobile network to be reachable via permanent IP addresses, as well as maintain ongoing sessions as the MR changes its point of attachment within the topology. This will be done by maintaining a bidirectional tunnel between the MR and its Home Agent. The WG will investigate reusing the existing Mobile IPv6 mechanisms for the tunnel management, or extend it if deemed necessary. - An informational document which specifies a detailed problem statement for route optimization and looks at various approaches to solving this problem. This document will look into the issues and tradeoffs involved in making the network's movement visible to some nodes, by optionally making them "NEMO aware". The interaction between route optimization and IP routing will also be described in this document. Furthermore, security considerations for the various approaches will also be considered. The WG will: - Ensure that solutions will scale and function for the different mobile network configurations, without requiring changes to Correspondent Nodes in the Internet. All solutions will aim at preserving route aggregation within the Internet and will satisfy an acceptable level of security (a thorough survey of new threats and an analysis of their severity will be conducted) - Ensure that various mechanisms defined within other IETF WGs will be useful for mobile networks. To achieve this, the NEMO WG will interact with other WGs when needed, and may place requirements on the protocols developed by those WGs. The WG will not: - consider routing issues inside the mobile network. Existing routing protocols (including MANET protocols) can be used to solve these problems. Description of Working Group: The NEMO Working Group is concerned with managing the mobility of an entire network, which changes, as a unit, its point of attachment to the Internet and thus its reachability in the topology. The mobile network includes one or more mobile routers (MRs) which connect it to the global Internet. A mobile network is assumed to be a leaf network, i.e. it will not carry transit traffic. However,it could be multihomed, either with a single MR that has multiple attachments to the internet, or by using multiple MRs that attach the mobile network to the Internet. Initially,the WG will assume that none of the nodes behind the MR will be aware of the network's mobility, thus the network's movement needs to be completely transparent to the nodes inside the mobile network. This assumption will be made to accomodate nodes inside the network that are not generally aware of mobility. A basic approach for network mobility support is for each Mobile Router to have a Home Agent, and use bidirectional tunneling between the MR and HA to preserve session continuity while the MR moves. The MR will acquire a Care-of-address from its attachment point much like what is done for Mobile Nodes using Mobile IP. This approach allows nesting of mobile networks, since each MR will appear to its attachment point as a single node. The WG will take a stepwise approach by standardizing some basic support mechanisms based on the bidirectional tunneling approach, and at the same time study the possible approaches and issues with providing more optimal routing than can be had with (potentially nested) tunneling. However, the WG is not chartered to actually standardize a solution to such route optimization for mobile networks at this point in time. The WG will work on: - A threat analysis and security solution for the basic problem (tunneling between HA and MR) - A solution to the basic problem for both IPv4 and IPv6. The solution will allow all nodes in the mobile network to be reachable via permanent IP addresses, as well as maintain ongoing sessions as the MR changes its point of attachment within the topology. This will be done by maintaining a bidirectional tunnel between the MR and its Home Agent. The WG will investigate reusing the existing Mobile IPv6 mechanisms for the tunnel management, or extend it if deemed necessary. - An informational document which specifies a detailed problem statement for route optimization and looks at various approaches to solving this problem. This document will look into the issues and tradeoffs involved in making the network's movement visible to some nodes, by optionally making them "NEMO aware". The interaction between route optimization and IP routing will also be described in this document. Furthermore, security considerations for the various approaches will also be considered. The WG will: - Ensure that solutions will scale and function for the different mobile network configurations, without requiring changes to Correspondent Nodes in the Internet. All solutions will aim at preserving route aggregation within the Internet and will satisfy an acceptable level of security (a thorough survey of new threats and an analysis of their severity will be conducted) - Ensure that various mechanisms defined within other IETF WGs will be useful for mobile networks. To achieve this, the NEMO WG will interact with other WGs when needed, and may place requirements on the protocols developed by those WGs. The WG will not: - consider routing issues inside the mobile network. Existing routing protocols (including MANET protocols) can be used to solve these problems. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2003 Nov 2006 Network Mobility Support Goals and Requirements May 2003 Nov 2006 Network Mobility Support Terminology Apr 2004 Feb 2006 NEMO Home Network models Jul 2004 Feb 2007 Analysis of Multihoming in Network Mobility Support Oct 2004 Oct 2006 NEMO Management Information Base Jul 2005 Sep 2006 Network Mobility Route Optimization Problem Statement Aug 2005 Sep 2006 DHCPv6 Prefix Delegation for NEMO Aug 2005 Dec 2006 Mobile Network Prefix Delegation Sep 2005 Sep 2006 Network Mobility Route Optimization Solution Space Analysis Network Configuration (netconf) ------------------------------- Charter Last Modified: 2007-03-08 Current Status: Active Working Group Chair(s): Simon Leinen Andy Bierman Operations and Management Area Director(s): Dan Romascanu David Kessens Operations and Management Area Advisor: Dan Romascanu Technical Advisor(s): Wesley Hardaker Mailing Lists: General Discussion:netconf@ops.ietf.org To Subscribe: netconf-request@ops.ietf.org In Body: in msg body: subscribe Archive: https://ops.ietf.org/lists/netconf Description of Working Group: Wes Hardaker 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 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 the following support for asynchronous notifications: - Specify the message (capability exchange) details to support notifications. - Specify the application mapping details to support notifications. - Specify the protocol syntax and semantics of a notification message. - Specify or select a notification content information model. - Specify a mechanism for controlling the delivery (turn on/off) of notifications during a session. - Specify a mechanism for selectively receiving a configurable subset of all possible notification types. The Netconf protocol will use XML for data encoding purposes, because XML is a widely deployed standard which is supported by a large number of applications. XML also supports hierarchical data structures. 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 It should be possible to transport the Netconf protocol using several different protocols. The group will select at least one suitable transport mechanism, and define a mapping for the selected protocol(s). The initial work (has completed) and was restricted to the following items: - Netconf Protocol Specification, which defines the operational model, protocol operations, transaction model, data model requirements, security requirements, and transport layer requirements. - Netconf over SSH Specification: Implementation Mandatory; Netconf over BEEP Specification: Implementation Optional; 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. Additional Notification work (as described above) will now be addressed since the initial work has been completed. An individual submission Internet Draft has been proposed to the WG as the starting point for the Notification work. The WG shall adopt the document identified as 'draft-chisholm-netconf-event-01.txt' as the starting point for this work. Description of Working Group: Wes Hardaker 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 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 the following support for asynchronous notifications: - Specify the message (capability exchange) details to support notifications. - Specify the application mapping details to support notifications. - Specify the protocol syntax and semantics of a notification message. - Specify or select a notification content information model. - Specify a mechanism for controlling the delivery (turn on/off) of notifications during a session. - Specify a mechanism for selectively receiving a configurable subset of all possible notification types. The Netconf protocol will use XML for data encoding purposes, because XML is a widely deployed standard which is supported by a large number of applications. XML also supports hierarchical data structures. 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 It should be possible to transport the Netconf protocol using several different protocols. The group will select at least one suitable transport mechanism, and define a mapping for the selected protocol(s). The initial work (has completed) and was restricted to the following items: - Netconf Protocol Specification, which defines the operational model, protocol operations, transaction model, data model requirements, security requirements, and transport layer requirements. - Netconf over SSH Specification: Implementation Mandatory; Netconf over BEEP Specification: Implementation Optional; 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. Additional Notification work (as described above) will now be addressed since the initial work has been completed. An individual submission Internet Draft has been proposed to the WG as the starting point for the Notification work. The WG shall adopt the document identified as 'draft-chisholm-netconf-event-01.txt' as the starting point for this work. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jan 2006 Feb 2007 NETCONF Event Notifications Network-based Localized Mobility Management (netlmm) ---------------------------------------------------- Charter Last Modified: 2007-02-13 Current Status: Active Working Group Chair(s): Phil Roberts Vidya Narayanan Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:netlmm@ietf.org To Subscribe: http://www1.ietf.org/mailman/listinfo/netlmm In Body: to subscribe Archive: http://www1.ietf.org/mail-archive/web/netlmm/current/index.html Description of Working Group: There is considerable evidence that mobility for IP nodes can be more efficiently handled if mobility management is broken down into localized mobility management and global mobility management. Local mobility involves movements across some administratively and geographically contiguous set of subnets, while global mobility involves movements across broader administrative, geographical, and topological domains. Previous work in the IETF has focused on supporting localized mobility management for a Mobile IPv6 node, and the protocols developed have required mobile node-side support at the IP layer. Recently in the IETF, new work on global mobility management approaches other than Mobile IPv6 suggests that a localized mobility management approach decoupled from the global mobility management protocol might result in a more modular mobility management system design and therefore more longevity and an easier evolution path. In the WLAN infrastructure market, WLAN switches, which perform localized mobility management without any mobile node involvement, have seen widespread deployment, indicating the technical feasibility and positive user acceptance of this approach. This suggests a design paradigm that could be used to accommodate global mobility management protocols of different types while not increasing software complexity: a network-based, localized mobility protocol with no mobile node software to specifically implement localized mobility management and no requirement for a network interface to change IP address when the mobile node changes to a new router. The task of the NETLMM Working Group is to design a protocol solution for network-based localized mobility management. The network-based localized mobility management protocol will conform to the following framework. Mobility anchor points within the backbone network maintain a collection of routes for individual mobile nodes. The routes point to the access routers on which mobile nodes currently are located. Packets for the mobile node are routed to and from the mobile node through the mobility anchor point. When a mobile node moves from one access router to another, the access routers send a route update to the mobility anchor point. While some mobile node involvement is necessary and expected for generic mobility functions such as movement detection and to inform the access router about mobile node movement, no specific mobile node to network protocol will be required for localized mobility management itself. The working group will develop a protocol between the access routers and mobility anchor points that minimally has the following functions: - Handles a new mobile node that powers on or moves from another localized mobility management domain, or an existing mobile node that shuts down without any notice (i.e. crashes), - Handles routing update when a mobile node moves from one access router to another within the localized mobility management domain, The necessity for additional protocol functions may arise during Working Group discussions, so this list should not be taken as final. The protocol will be independent of any particular global mobility management protocol, and it will be link-layer agnostic by running on top of IP. The protocol itself will be agnostic with respect to the last hop link layer protocol between the mobile node and the access router. Adaptation of the protocol to different kinds of last hop link layers is accomplished through an interface on the access router common to all link layers under which specific link layer mechanisms (possibly together with authentication mechanisms) can provide a reliable handover indication and unique identity for the mobile node. This will enable the access router to do a route update using NETLMM on behalf of the mobile node. In addition to the NETLMM protocol document, the Working Group will produce an informational document that describes how existing and developing IETF standards for node to access router communication on the local link can be used to accomplish secure triggering of route update. This document will be informational only, because some link protocols are expected to provide their own mechanisms. The scope of the work is initially limited to IPv6 both in the backbone and on the edges, and is primarily for networks covering larger geographical regions such as multiple corporate campuses and metropolitian areas. The protocol will not attempt to hide handover between two separate interfaces on the mobile node. The protocol will not define a new tunneling protocol but will reuse existing IP tunneling mechanisms if necessary. The NETLMM protocol will maintain compatibility with other IETF standards, both existing and developing, such as DNS, DNA, and global mobility protocols such as Mobile IPv6 and NEMO Basic Support. Security between access routers and the mobility anchor will be defined for the protocol based on an IETF-approved threat model giving preference to existing security solutions where applicable. The threat model will be described in a document delivered sufficiently in advance of completion of the protocol design that the protocol design can accommodate mitigation measures. In addition, the mobile node to router interface document will describe threats to the protocol when the default, IP-level mobile node to router protocol is used, and will prescribe how existing security protocols are used to counter the threats. The Working Group has the following deliverables: - A problem statement document that clearly and succinctly describes the problem posed by localized mobility management and why a network-based approach is desirable, - A requirements and gap analysis that examines a selection of existing IETF protocols, particularly within the mobility space, for applicability as a solution. If a proposed protocol is insufficient as a solution, the reasons why will be clearly stated. - A threat model draft that describes the threats to a netlmm protocol, based on the framework described in this charter, and how the threats can be mitigated giving preference to existing security solutions where applicable. - A protocol design for an interoperable, scalable network-based localized mobility management protocol between the access routers and the mobility anchor point including security for the access router to mobility anchor interface, - A document describing how existing or developing IETF protocol standards can be used between the access router and the mobile node to inform the access router about the arrival of a mobile node, for use when the wireless link protocol does not provide support for this function. This document will also discuss threats and security countermeasures for mobile node identification. Out of scope for the first design are: route optimization, inter-access router tunneling to optimize handover, mechanisms for handover between localized mobility management domains (other than standard global mobility management protocols), IPv4 support, and multiple mobility anchor points. During the design process, these enhancements will be kept in mind, but actual work to incorporate them or other enhancements will be deferred until after the initial design is complete and the working group recharters. Description of Working Group: There is considerable evidence that mobility for IP nodes can be more efficiently handled if mobility management is broken down into localized mobility management and global mobility management. Local mobility involves movements across some administratively and geographically contiguous set of subnets, while global mobility involves movements across broader administrative, geographical, and topological domains. Previous work in the IETF has focused on supporting localized mobility management for a Mobile IPv6 node, and the protocols developed have required mobile node-side support at the IP layer. Recently in the IETF, new work on global mobility management approaches other than Mobile IPv6 suggests that a localized mobility management approach decoupled from the global mobility management protocol might result in a more modular mobility management system design and therefore more longevity and an easier evolution path. In the WLAN infrastructure market, WLAN switches, which perform localized mobility management without any mobile node involvement, have seen widespread deployment, indicating the technical feasibility and positive user acceptance of this approach. This suggests a design paradigm that could be used to accommodate global mobility management protocols of different types while not increasing software complexity: a network-based, localized mobility protocol with no mobile node software to specifically implement localized mobility management and no requirement for a network interface to change IP address when the mobile node changes to a new router. The task of the NETLMM Working Group is to design a protocol solution for network-based localized mobility management. The network-based localized mobility management protocol will conform to the following framework. Mobility anchor points within the backbone network maintain a collection of routes for individual mobile nodes. The routes point to the access routers on which mobile nodes currently are located. Packets for the mobile node are routed to and from the mobile node through the mobility anchor point. When a mobile node moves from one access router to another, the access routers send a route update to the mobility anchor point. While some mobile node involvement is necessary and expected for generic mobility functions such as movement detection and to inform the access router about mobile node movement, no specific mobile node to network protocol will be required for localized mobility management itself. The working group will develop a protocol between the access routers and mobility anchor points that minimally has the following functions: - Handles a new mobile node that powers on or moves from another localized mobility management domain, or an existing mobile node that shuts down without any notice (i.e. crashes), - Handles routing update when a mobile node moves from one access router to another within the localized mobility management domain, The necessity for additional protocol functions may arise during Working Group discussions, so this list should not be taken as final. The protocol will be independent of any particular global mobility management protocol, and it will be link-layer agnostic by running on top of IP. The protocol itself will be agnostic with respect to the last hop link layer protocol between the mobile node and the access router. Adaptation of the protocol to different kinds of last hop link layers is accomplished through an interface on the access router common to all link layers under which specific link layer mechanisms (possibly together with authentication mechanisms) can provide a reliable handover indication and unique identity for the mobile node. This will enable the access router to do a route update using NETLMM on behalf of the mobile node. In addition to the NETLMM protocol document, the Working Group will produce an informational document that describes how existing and developing IETF standards for node to access router communication on the local link can be used to accomplish secure triggering of route update. This document will be informational only, because some link protocols are expected to provide their own mechanisms. The scope of the work is initially limited to IPv6 both in the backbone and on the edges, and is primarily for networks covering larger geographical regions such as multiple corporate campuses and metropolitian areas. The protocol will not attempt to hide handover between two separate interfaces on the mobile node. The protocol will not define a new tunneling protocol but will reuse existing IP tunneling mechanisms if necessary. The NETLMM protocol will maintain compatibility with other IETF standards, both existing and developing, such as DNS, DNA, and global mobility protocols such as Mobile IPv6 and NEMO Basic Support. Security between access routers and the mobility anchor will be defined for the protocol based on an IETF-approved threat model giving preference to existing security solutions where applicable. The threat model will be described in a document delivered sufficiently in advance of completion of the protocol design that the protocol design can accommodate mitigation measures. In addition, the mobile node to router interface document will describe threats to the protocol when the default, IP-level mobile node to router protocol is used, and will prescribe how existing security protocols are used to counter the threats. The Working Group has the following deliverables: - A problem statement document that clearly and succinctly describes the problem posed by localized mobility management and why a network-based approach is desirable, - A requirements and gap analysis that examines a selection of existing IETF protocols, particularly within the mobility space, for applicability as a solution. If a proposed protocol is insufficient as a solution, the reasons why will be clearly stated. - A threat model draft that describes the threats to a netlmm protocol, based on the framework described in this charter, and how the threats can be mitigated giving preference to existing security solutions where applicable. - A protocol design for an interoperable, scalable network-based localized mobility management protocol between the access routers and the mobility anchor point including security for the access router to mobility anchor interface, - A document describing how existing or developing IETF protocol standards can be used between the access router and the mobile node to inform the access router about the arrival of a mobile node, for use when the wireless link protocol does not provide support for this function. This document will also discuss threats and security countermeasures for mobile node identification. Out of scope for the first design are: route optimization, inter-access router tunneling to optimize handover, mechanisms for handover between localized mobility management domains (other than standard global mobility management protocols), IPv4 support, and multiple mobility anchor points. During the design process, these enhancements will be kept in mind, but actual work to incorporate them or other enhancements will be deferred until after the initial design is complete and the working group recharters. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2006 Oct 2006 Goals for Network-based Localized Mobility Management (NETLMM) Feb 2006 Sep 2006 Problem Statement for Network-based Localized Mobility Management Apr 2006 Sep 2006 Security Threats to Network-Based Localized Mobility Management Network File System Version 4 (nfsv4) ------------------------------------- Charter Last Modified: 2006-03-24 Current Status: Active Working Group Chair(s): Brian Pawlowski Spencer Shepler Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Lars Eggert Mailing Lists: General Discussion:nfsv4@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/nfsv4 Archive: http://www.ietf.org/mail-archive/web/nfsv4/index.html Description of Working Group: The objective of this working group is to advance the state of NFS technology by producing specifications to extend the original NFS Version 4 work (RFC 3010) to provide additional capabilities, as described below. o NFS version 4 Advance the protocol along the standards track, coordinating the development of test suites to provide a high level of implementation quality. The ONC RPC standards that NFSv4 references must also be advanced. This includes work to make NFSv4 and the underlying ONC RPC protocol compatible with IPv6. Specifically, we will advance RFC 3010, RFC 1831, RFC 1833 and RFC 2203 to Draft Standard. The working group will help advance related security RFCs, specifically through the definition of a method to advance APIs. o Replication and Migration The original working group defined a mechanism for NFS clients and servers to support replication and migration of data transparently to an application. Left undefined in the initial work was the server back end migration and replication mechanism. The working group will produce a draft submission of a replication/migration protocol that supports NFS Version 4 clients - needed to create and maintain replicated filesystems as well as migrating filesystems from one location to another - and servers for consideration as Proposed Standard. o Management The working group will produce a draft submission for consideration as Proposed Standard of a management MIBs to provide better management and administration capabilities for NFS and ONC RPC. o Minor Versions NFS Version 4 contains within it the capability for minor versioning. Some discussions within the working group suggest addressing additional requirements over the original charter. The WG will work to identify additional requirements for NFSv4 and determine if they are appropriate and worthwhile for a minor version. This work may lead to proposals for additional work items. If it does a specific proposal to add these work items to the charter will be forwarded to the IESG and IAB. o RDMA/RDDP enabling The performance benefit of RDMA/RDDP transports in NFS-related applications, by reducing the overhead of data and metadata exchange, has been demonstrated sufficiently such that the working group will pursue in parallel enabling NFS and RPC over the transport defined by the RDDP working group. The WG will restrict its initial activities to defining the problem statement and specifying the requirements for possible extensions to RPC and NFS (in the context of a minor revision). Description of Working Group: The objective of this working group is to advance the state of NFS technology by producing specifications to extend the original NFS Version 4 work (RFC 3010) to provide additional capabilities, as described below. o NFS version 4 Advance the protocol along the standards track, coordinating the development of test suites to provide a high level of implementation quality. The ONC RPC standards that NFSv4 references must also be advanced. This includes work to make NFSv4 and the underlying ONC RPC protocol compatible with IPv6. Specifically, we will advance RFC 3010, RFC 1831, RFC 1833 and RFC 2203 to Draft Standard. The working group will help advance related security RFCs, specifically through the definition of a method to advance APIs. o Replication and Migration The original working group defined a mechanism for NFS clients and servers to support replication and migration of data transparently to an application. Left undefined in the initial work was the server back end migration and replication mechanism. The working group will produce a draft submission of a replication/migration protocol that supports NFS Version 4 clients - needed to create and maintain replicated filesystems as well as migrating filesystems from one location to another - and servers for consideration as Proposed Standard. o Management The working group will produce a draft submission for consideration as Proposed Standard of a management MIBs to provide better management and administration capabilities for NFS and ONC RPC. o Minor Versions NFS Version 4 contains within it the capability for minor versioning. Some discussions within the working group suggest addressing additional requirements over the original charter. The WG will work to identify additional requirements for NFSv4 and determine if they are appropriate and worthwhile for a minor version. This work may lead to proposals for additional work items. If it does a specific proposal to add these work items to the charter will be forwarded to the IESG and IAB. o RDMA/RDDP enabling The performance benefit of RDMA/RDDP transports in NFS-related applications, by reducing the overhead of data and metadata exchange, has been demonstrated sufficiently such that the working group will pursue in parallel enabling NFS and RPC over the transport defined by the RDDP working group. The WG will restrict its initial activities to defining the problem statement and specifying the requirements for possible extensions to RPC and NFS (in the context of a minor revision). Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- May 2003 Dec 2006 RPC: Remote Procedure Call Protocol Specification Version 2 Feb 2004 Oct 2006 NFS RDMA Problem Statement Jul 2004 Oct 2006 RDMA Transport for ONC RPC Jul 2004 Oct 2006 NFS Direct Data Placement Oct 2005 Mar 2007 NFSv4 Minor Version 1 Jan 2006 Mar 2007 pNFS Block/Volume Layout Jan 2006 Mar 2007 Object-based pNFS Operations Next Steps in Signaling (nsis) ------------------------------ Charter Last Modified: 2006-10-13 Current Status: Active Working Group Chair(s): John Loughney Martin Stiemerling 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 Mar 2007 NSLP for Quality-of-Service Signaling Oct 2003 Mar 2007 NAT/Firewall NSIS Signaling Layer Protocol (NSLP) Oct 2003 Mar 2007 GIST: General Internet Signalling Transport Sep 2004 Feb 2007 QoS NSLP QSPEC Template Oct 2004 Mar 2007 Applicability Statement of NSIS Protocols in Mobile Environments Nov 2004 Mar 2007 RMD-QOSM - The Resource Management in Diffserv QOS Model Jul 2005 Mar 2007 GIST State Machine Aug 2005 Nov 2006 Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes Jun 2006 Mar 2007 NSIS Operation Over IP Tunnels Jun 2006 Mar 2007 General Internet Signaling Transport (GIST) over SCTP Network Time Protocol (ntp) --------------------------- Charter Last Modified: 2005-09-27 Current Status: Active Working Group Chair(s): Karen O'Donoghue Brian Haberman Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Mark Townsley 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 Jan 2007 Network Time Protocol Version 4 Protocol And Algorithms Specification Jun 2006 Mar 2007 Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4) An Open Specification for Pretty Good Privacy (openpgp) ------------------------------------------------------- Charter Last Modified: 2005-07-10 Current Status: Active Working Group Chair(s): Derek Atkins Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Sam Hartman Mailing Lists: General Discussion:ietf-openpgp@imc.org To Subscribe: ietf-openpgp-request@imc.org In Body: Only the word subscribe Archive: http://www.imc.org/ietf-openpgp/mail-archive/ Description of Working Group: PGP, or Pretty Good Privacy, first appeared on the Internet in 1991. It has enjoyed significant popularity amongst the Internet Community. PGP is used both for protecting E-mail and File Storage. It presents a way to digitally sign and encrypt information "objects." As such it is well suited for any store and forward application. The goal of the OpenPGP working group is to provide IETF standards for the algorithms and formats of PGP processed objects as well as providing the MIME framework for exchanging them via e-mail or other transport protocols. Because there is a significant installed base of PGP users, the working group will consider compatibilty issues to avoid disenfranchising the existing community of PGP users. Security Issues: The whole purpose of Open-PGP is to provide security services. Description of Working Group: PGP, or Pretty Good Privacy, first appeared on the Internet in 1991. It has enjoyed significant popularity amongst the Internet Community. PGP is used both for protecting E-mail and File Storage. It presents a way to digitally sign and encrypt information "objects." As such it is well suited for any store and forward application. The goal of the OpenPGP working group is to provide IETF standards for the algorithms and formats of PGP processed objects as well as providing the MIME framework for exchanging them via e-mail or other transport protocols. Because there is a significant installed base of PGP users, the working group will consider compatibilty issues to avoid disenfranchising the existing community of PGP users. Security Issues: The whole purpose of Open-PGP is to provide security services. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Dec 1999 Mar 2007 OpenPGP Message Format Open Pluggable Edge Services (opes) ----------------------------------- Charter Last Modified: 2006-12-29 Current Status: Active Working Group Chair(s): Tony Hansen Markus Hofmann Applications Area Director(s): Ted Hardie Lisa Dusseault Applications Area Advisor: Ted Hardie Technical Advisor(s): Allison Mankin Hilarie Orman Mailing Lists: General Discussion:ietf-openproxy@imc.org To Subscribe: ietf-openproxy-request@imc.org Archive: http://www1.ietf.org/mail-archive/web/newtrk/current/ Description of Working Group: The Internet facilitates the development of networked services at the application level that both offload origin servers and improve the user experience. Web proxies, for example, are commonly deployed to provide services such as Web caching, virus scanning, and request filtering. Lack of standardized mechanisms to trace and to control such intermediaries causes problems with respect to failure detection, data integrity, privacy, and security. The OPES Working Group has previously developed an architectural framework to authorize, invoke, and trace such application-level services for HTTP. The framework follows a one-party consent model, which requires that each service be authorized explicitly by at least one of the application-layer endpoints. It further requires that OPES services are reversible by mutual agreement of the application endpoints. In particular, the WG has developed a protocol suite for invocation and tracking of OPES services inside the net. The protocol suite includes a generic, application-agnostic protocol core (OCP Core) that is supplemented by profiles specific to the application-layer protocol used between the endpoints. So far, the WG has specified an OCP profile for HTTP, which supports OPES services that operate on HTTP messages. In a next step, the WG will specify one or more OCP profiles that will support OPES services operating on SMTP. In particular, the profile to be specified will enable an SMTP server (the OPES processor) to encapsulate and forward SMTP data and metadata to a callout server for additional processing. Several kinds of agents participate in SMTP exchanges, including MSA, MTA, MDA, and MUA. The first OCP/SMTP profile will address the needs of at least the MTA and/or MDA. More profiles may be needed to address other agent-specific needs, such as for LMTP and/or SUBMIT. The security and privacy concerns of SMTP must be carefully analyzed as part of the definition of the profile. In addition, the WG will define a rules language to control selection and invocation of services by an OPES processor. This includes a mechanism allowing an OPES processor to perform a runtime check of service parameters, leveraging existing interface description standards like WSDL, if possible, or OPES-specific description otherwise. Defining language(s) for implementing OPES services is out of the WG scope. The rules language will be based on previous work of the WG on a rules language named "P". The WG will have a design goal that the language be compatible with existing policy work within the IETF (e.g. IETF Policy Framework) and be able to interface with systems automating distribution of policies to multiple endpoints. It will be out of scope for this WG to develop the policy framework and specify multiple-endpoint policy distribution. The group's new work items can be listed as: - Develop a document about "Scenarios and Use Cases for OPES Services operating on SMTP". - Define profile(s) for OCP core that handle SMTP messages or parts thereof. - Define a rules language to control the selection and invocation of HTTP-based or SMTP-based OPES services. Each deliverable must follow the previously developed OPES architecture. As each deliverable is developed, it must address the IAB considerations specified in RFC 3238. Description of Working Group: The Internet facilitates the development of networked services at the application level that both offload origin servers and improve the user experience. Web proxies, for example, are commonly deployed to provide services such as Web caching, virus scanning, and request filtering. Lack of standardized mechanisms to trace and to control such intermediaries causes problems with respect to failure detection, data integrity, privacy, and security. The OPES Working Group has previously developed an architectural framework to authorize, invoke, and trace such application-level services for HTTP. The framework follows a one-party consent model, which requires that each service be authorized explicitly by at least one of the application-layer endpoints. It further requires that OPES services are reversible by mutual agreement of the application endpoints. In particular, the WG has developed a protocol suite for invocation and tracking of OPES services inside the net. The protocol suite includes a generic, application-agnostic protocol core (OCP Core) that is supplemented by profiles specific to the application-layer protocol used between the endpoints. So far, the WG has specified an OCP profile for HTTP, which supports OPES services that operate on HTTP messages. In a next step, the WG will specify one or more OCP profiles that will support OPES services operating on SMTP. In particular, the profile to be specified will enable an SMTP server (the OPES processor) to encapsulate and forward SMTP data and metadata to a callout server for additional processing. Several kinds of agents participate in SMTP exchanges, including MSA, MTA, MDA, and MUA. The first OCP/SMTP profile will address the needs of at least the MTA and/or MDA. More profiles may be needed to address other agent-specific needs, such as for LMTP and/or SUBMIT. The security and privacy concerns of SMTP must be carefully analyzed as part of the definition of the profile. In addition, the WG will define a rules language to control selection and invocation of services by an OPES processor. This includes a mechanism allowing an OPES processor to perform a runtime check of service parameters, leveraging existing interface description standards like WSDL, if possible, or OPES-specific description otherwise. Defining language(s) for implementing OPES services is out of the WG scope. The rules language will be based on previous work of the WG on a rules language named "P". The WG will have a design goal that the language be compatible with existing policy work within the IETF (e.g. IETF Policy Framework) and be able to interface with systems automating distribution of policies to multiple endpoints. It will be out of scope for this WG to develop the policy framework and specify multiple-endpoint policy distribution. The group's new work items can be listed as: - Develop a document about "Scenarios and Use Cases for OPES Services operating on SMTP". - Define profile(s) for OCP core that handle SMTP messages or parts thereof. - Define a rules language to control the selection and invocation of HTTP-based or SMTP-based OPES services. Each deliverable must follow the previously developed OPES architecture. As each deliverable is developed, it must address the IAB considerations specified in RFC 3238. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- May 2006 Feb 2007 Integrity, privacy and security in OPES for SMTP Operational Security Capabilities for IP Network Infrastructure (opsec) ----------------------------------------------------------------------- Charter Last Modified: 2007-01-22 Current Status: Active Working Group Chair(s): Ross Callon Patrick Cain Operations and Management Area Director(s): Dan Romascanu David Kessens Operations and Management Area Advisor: David Kessens Technical Advisor(s): George Jones Mailing Lists: General Discussion:opsec@ops.ietf.org To Subscribe: opsec-request@ops.ietf.org In Body: In Body: subscribe Archive: http://ops.ietf.org/lists/opsec/ Description of Working Group: Goals The goal of the Operational Security Working Group is to codify knowledge gained through operational experience about feature sets that are needed to securely deploy and operate managed network elements providing transit services at the data link and IP layers. It is anticipated that the codification of this knowledge will be an aid to vendors in producing more securable network elements, and an aid to operators in increasing security by deploying and configuring more secure network elements. Scope The working group will list capabilities appropriate for devices use in: * Internet Service Provider (ISP) Networks * Enterprise Networks The following areas are excluded from the charter at this time: * Wireless devices * Small-Office-Home-Office (SOHO) devices * Security devices (firewalls, Intrusion Detection Systems, Authentication Servers) * Hosts Methods Framework Document A framework document will be produced describing the scope, format, intended use and documents to be produced. Current Practices Document A single 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. Individual Capability Documents A series of documents will be produced covering various groupings of security management capabilities needed to operate network elements in a secure fashion. The capabilities will be described in terms that allow implementations to change over time and will attempt to avoid requiring any particular implementation. The capabilities documents will cite the Current Practices document where possible for justification. Profile Documents Profiles documents will be produced, which cite the capabilities relevant to different operating environments. Operator Outreach Much of the operational security knowledge that needs to be codified resides with operators. In order to access their knowledge and reach the working group goal, informal BoFs will be held at relevant operator fora. RFC3871 will be used as a jumping off point. Description of Working Group: Goals The goal of the Operational Security Working Group is to codify knowledge gained through operational experience about feature sets that are needed to securely deploy and operate managed network elements providing transit services at the data link and IP layers. It is anticipated that the codification of this knowledge will be an aid to vendors in producing more securable network elements, and an aid to operators in increasing security by deploying and configuring more secure network elements. Scope The working group will list capabilities appropriate for devices use in: * Internet Service Provider (ISP) Networks * Enterprise Networks The following areas are excluded from the charter at this time: * Wireless devices * Small-Office-Home-Office (SOHO) devices * Security devices (firewalls, Intrusion Detection Systems, Authentication Servers) * Hosts Methods Framework Document A framework document will be produced describing the scope, format, intended use and documents to be produced. Current Practices Document A single 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. Individual Capability Documents A series of documents will be produced covering various groupings of security management capabilities needed to operate network elements in a secure fashion. The capabilities will be described in terms that allow implementations to change over time and will attempt to avoid requiring any particular implementation. The capabilities documents will cite the Current Practices document where possible for justification. Profile Documents Profiles documents will be produced, which cite the capabilities relevant to different operating environments. Operator Outreach Much of the operational security knowledge that needs to be codified resides with operators. In order to access their knowledge and reach the working group goal, informal BoFs will be held at relevant operator fora. RFC3871 will be used as a jumping off point. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jan 2005 Mar 2007 Framework for Operational Security Capabilities for IP Network Infrastructure Jan 2005 Dec 2006 Security Best Practices Efforts and Documents Oct 2005 Mar 2007 Filtering and Rate Limiting Capabilities for IP Network Infrastructure Sep 2006 Sep 2006 Service Provider Infrastructure Security Oct 2006 Feb 2007 Routing Control Plane Security Capabilities Oct 2006 Mar 2007 Logging Capabilities for IP Network Infrastructure Open Shortest Path First IGP (ospf) ----------------------------------- Charter Last Modified: 2006-06-07 Current Status: Active Working Group Chair(s): Acee Lindem Rohit Dube Routing Area Director(s): Ross Callon Bill Fenner Routing Area Advisor: Bill Fenner 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/index.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 ------ ------- -------------------------------------------- Nov 2000 Jan 2007 OSPF Link-local Signaling Apr 2003 Jan 2007 Traffic Engineering Extensions to OSPF version 3 Jul 2003 Feb 2007 Extensions to OSPF for Advertising Optional Router Capabilities Apr 2004 Sep 2006 Support of address families in OSPFv3 Apr 2004 Jun 2006 OSPF Multi-Area Adjacency Oct 2004 Jan 2007 Multi-Topology (MT) Routing in OSPF Oct 2004 May 2006 OSPFv3 Graceful Restart Nov 2004 Dec 2006 OSPF for IPv6 Apr 2005 Mar 2007 IANA Considerations for OSPF Dec 2006 Dec 2006 The OSPF Opaque LSA Option Jan 2007 Jan 2007 OSPF Database Exchange Summary List Optimization Jan 2007 Jan 2007 OSPF Version 2 MIB for Multi-Topology (MT) Routing Peer-to-Peer Session Initiation Protocol (p2psip) ------------------------------------------------- Charter Last Modified: 2007-02-22 Current Status: Active Working Group Chair(s): David Bryan Brian Rosen Real-time Applications and Infrastructure Area Director(s): Jon Peterson Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Cullen Jennings Mailing Lists: General Discussion:p2psip@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/p2psip Archive: http://www1.ietf.org/mail-archive/web/p2psip/current 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: No Current Internet-Drafts. Protocol for carrying Authentication for Network Access (pana) -------------------------------------------------------------- Charter Last Modified: 2007-03-05 Current Status: Active Working Group Chair(s): Basavaraj Patil Alper Yegin Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Mark Townsley 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 ------ ------- -------------------------------------------- Apr 2003 Mar 2007 Protocol for Carrying Authentication for Network Access (PANA) Oct 2003 Jul 2005 PANA Enabling IPsec based Access Control May 2004 Aug 2006 Protocol for Carrying Authentication for Network Access (PANA) Framework Path Computation Element (pce) ------------------------------ Charter Last Modified: 2006-03-24 Current Status: Active Working Group Chair(s): Adrian Farrel JP Vasseur Routing Area Director(s): Ross Callon Bill Fenner Routing Area Advisor: Ross Callon Mailing Lists: General Discussion:pce@ietf.org To Subscribe: pce-request@ietf.org In Body: subscribe 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 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 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 Mar 2007 Path Computation Element (PCE) communication Protocol (PCEP) Nov 2005 Mar 2007 PCC-PCE Communication Requirements for Inter-Layer Traffic Engineering Dec 2005 Dec 2006 PCE Communication Protocol (PCECP) Specific Requirements for Inter-Area Multi Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Apr 2006 Mar 2007 Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering Aug 2006 Mar 2007 Policy-Enabled Path Computation Framework Aug 2006 Oct 2006 Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP) Aug 2006 Mar 2007 A Backward Recursive PCE-based Computation (BRPC) procedure to compute shortest inter-domain Traffic Engineering Label Switched Paths Sep 2006 Feb 2007 IS-IS protocol extensions for Path Computation Element (PCE) Discovery Sep 2006 Feb 2007 OSPF protocol extensions for Path Computation Element (PCE) Discovery Dec 2006 Mar 2007 Definitions of Textual Conventions for Path Computation Element Dec 2006 Mar 2007 Definitions of Managed Objects for Path Computation Element Discovery Jan 2007 Mar 2007 Inclusion of Manageability Sections in PCE Working Group Drafts Congestion and Pre-Congestion Notification (pcn) ------------------------------------------------ Charter Last Modified: 2007-02-28 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: No Current Internet-Drafts. Protocol Independent Multicast (pim) ------------------------------------ Charter Last Modified: 2006-10-18 Current Status: Active Working Group Chair(s): Tom Pusateri Mike McBride Routing Area Director(s): Ross Callon Bill Fenner Routing Area Advisor: Bill Fenner 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 is chartered to standardize and promote the Protocol Independent Multicast Version 2 (PIMv2), Sparse Mode and Dense Mode, as a scalable, efficient and robust multicast routing protocol, capable of supporting thousands of groups, different types of multicast applications, and all major underlying layer-2 subnetwork technologies. The working group will decide if there is a need for any follow on work or version 3 of the protocol. This working group will act as a consultant to any PIM-over-Foo proposals, including but not limited to PIM-over-ATM, using PIM for multiprotocol label switching, and PIM-over-UDLR links. Documents: 1) PIM-SM v2 specification (standards track) This document is a specification for Sparse Mode Protocol Independent Multicast. 2) PIM-DM v2 speficication (standards track) This document is a specification for Dense Mode Protocol Independent Multicast. 3) PIM MIB (standards track) This document contains the MIB definitions for PIMv2. Description of Working Group: The Protocol Independent Multicast (PIM) Working Group is chartered to standardize and promote the Protocol Independent Multicast Version 2 (PIMv2), Sparse Mode and Dense Mode, as a scalable, efficient and robust multicast routing protocol, capable of supporting thousands of groups, different types of multicast applications, and all major underlying layer-2 subnetwork technologies. The working group will decide if there is a need for any follow on work or version 3 of the protocol. This working group will act as a consultant to any PIM-over-Foo proposals, including but not limited to PIM-over-ATM, using PIM for multiprotocol label switching, and PIM-over-UDLR links. Documents: 1) PIM-SM v2 specification (standards track) This document is a specification for Sparse Mode Protocol Independent Multicast. 2) PIM-DM v2 speficication (standards track) This document is a specification for Dense Mode Protocol Independent Multicast. 3) PIM MIB (standards track) This document contains the MIB definitions for PIMv2. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Mar 2000 Feb 2007 Bi-directional Protocol Independent Multicast (BIDIR-PIM) Feb 2001 Feb 2007 Bootstrap Router (BSR) Mechanism for PIM Jun 2002 Mar 2007 Protocol Independent Multicast MIB Feb 2005 Oct 2006 The RPF Vector TLV Oct 2005 Oct 2006 Format for using TLVs in PIM messages Aug 2006 Feb 2007 PIM Bootstrap Router MIB Oct 2006 Oct 2006 Security Issues in PIM-SM Link-local Messages Oct 2006 Oct 2006 Last-hop Threats to Protocol Independent Multicast (PIM) Profiling Use of PKI in IPSEC (pki4ipsec) ----------------------------------------- Charter Last Modified: 2006-02-23 Current Status: Active Working Group Chair(s): Paul Knight Gregory Lebovitz Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Russ Housley Mailing Lists: General Discussion:pki4ipsec@icsalabs.com To Subscribe: http://honor.icsalabs.com/mailman/listinfo/pki4ipsec In Body: (un)subscribe Archive: http://honor.icsalabs.com/mailman/listinfo/pki4ipsec Description of Working Group: IPsec has been standardized for over 5 years, and the use of X.509 certificates have been specified within the IPsec standards for the same time. However, very few IPsec deployments use certificates. One reason is the lack of a clear description of how X.509 certificates should be used with IPsec. Another is the lack of a simple, scalable, and clearly specified way for IPsec systems to obtain certificates and perform other certificate lifecycle operations with PKI systems. THE WG WILL DELIVER: 1) A standards-track document that gives specific instructions on how X.509 certificates should be handled with respect to the IKEv1 and IKEv2 protocols. This document will include a certificate profile, addressing which fields in the certificate should have which values and how those values should be handled. This effort is the WG's primary priority. 2) An informational document identifying and describing requirements for a profile of a certificate management protocol to handle PKI enrolment as well as certificate lifecycle interactions between IPsec VPN systems and PKI systems. Enrolment is defined as certificate request and retrieval. Certificate lifecycle interactions is defined as certificate renewals/changes, evocation, validation, and repository lookups. These requirements will be designed so that they meet the needs of enterprise scale IPsec VPN deployments. Once the above to items enter WG last call, we will begin work on: 3) A standards-track document describing a detailed profile of the CMC (Certificate Management Messages over CMS protocol, RFC 2797 at this writing) that meets the requirements laid out in the requirements document. Profile documents for other enrolment and/or management protocols may also be created. SCOPE The working group will focus on the needs of enterprise scale IPsec VPN deployments. Gateway-to-gateway access (tunnel and transport mode) and end-user remote access to a gateway (either tunnel or transport mode) are both in scope. NON-GOALS User-to-user IPsec connections will be considered, but are not explicitly in scope. We will consider the requirements for this scenario only until doing so significantly slows the progress of the explicitly scoped items, at which point it will be dropped. Specification of communications between an IPsec administrative function and IPsec systems is explicitly out of scope. Purely PKI to PKI issues will not be addressed. Cross-certification will not be addressed. Long term non-repudiation will also not be addressed. Description of Working Group: IPsec has been standardized for over 5 years, and the use of X.509 certificates have been specified within the IPsec standards for the same time. However, very few IPsec deployments use certificates. One reason is the lack of a clear description of how X.509 certificates should be used with IPsec. Another is the lack of a simple, scalable, and clearly specified way for IPsec systems to obtain certificates and perform other certificate lifecycle operations with PKI systems. THE WG WILL DELIVER: 1) A standards-track document that gives specific instructions on how X.509 certificates should be handled with respect to the IKEv1 and IKEv2 protocols. This document will include a certificate profile, addressing which fields in the certificate should have which values and how those values should be handled. This effort is the WG's primary priority. 2) An informational document identifying and describing requirements for a profile of a certificate management protocol to handle PKI enrolment as well as certificate lifecycle interactions between IPsec VPN systems and PKI systems. Enrolment is defined as certificate request and retrieval. Certificate lifecycle interactions is defined as certificate renewals/changes, evocation, validation, and repository lookups. These requirements will be designed so that they meet the needs of enterprise scale IPsec VPN deployments. Once the above to items enter WG last call, we will begin work on: 3) A standards-track document describing a detailed profile of the CMC (Certificate Management Messages over CMS protocol, RFC 2797 at this writing) that meets the requirements laid out in the requirements document. Profile documents for other enrolment and/or management protocols may also be created. SCOPE The working group will focus on the needs of enterprise scale IPsec VPN deployments. Gateway-to-gateway access (tunnel and transport mode) and end-user remote access to a gateway (either tunnel or transport mode) are both in scope. NON-GOALS User-to-user IPsec connections will be considered, but are not explicitly in scope. We will consider the requirements for this scenario only until doing so significantly slows the progress of the explicitly scoped items, at which point it will be dropped. Specification of communications between an IPsec administrative function and IPsec systems is explicitly out of scope. Purely PKI to PKI issues will not be addressed. Cross-certification will not be addressed. Long term non-repudiation will also not be addressed. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jun 2004 Feb 2007 The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX Public-Key Infrastructure (X.509) (pkix) ---------------------------------------- Charter Last Modified: 2006-12-27 Current Status: Active Working Group Chair(s): Stephen Kent Stefan Santesson Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Russ Housley Mailing Lists: General Discussion:ietf-pkix@imc.org To Subscribe: ietf-pkix-request@imc.org In Body: subscribe (In Body) Archive: http://www.imc.org/ietf-pkix Description of Working Group: The PKIX Working Group was established in the Fall of 1995 with the intent of developing Internet standards needed to support an X.509-based PKI. The scope of PKIX work has expanded beyond this initial goal. PKIX not only profiles ITU PKI standards, but also develops new standards apropos to the use of X.509-based PKIs in the Internet. PKIX has produced several informational and standards track documents in support of the original and revised scope of the WG. The first of these standards, RFC 2459, profiled X.509 version 3 certificates and version 2 CRLs for use in the Internet. Profiles for the use of Attribute Certificates (RFC XXXX [pending]), LDAP v2 for certificate and CRL storage (RFC 2587), the Internet X.509 Public Key Infrastructure Qualified Certificates Profile (RFC 3039), and the Internet X.509 Public Key Infrastructure Certificate Policy and certification Practices Framework (RFC 2527 - Informational) are in line with the initial scope. The Certificate Management Protocol (CMP) (RFC 2510), the Online Certificate Status Protocol (OCSP) (RFC 2560), Certificate Management Request Format (CRMF) (RFC 2511), Time-Stamp Protocol (RFC 3161), Certificate Management Messages over CMS (RFC 2797), Internet X.509 Public Key Infrastructure Time Stamp Protocols (RFC 3161), and the use of FTP and HTTP for transport of PKI operations (RFC 2585) are representative of the expanded scope of PKIX, as these are new protocols developed in the working group, not profiles of ITU PKI standards. A roadmap, providing a guide to the growing set of PKIX document, also has been developed as an informational RFC. Ongoing PKIX Work items An ongoing PKIX task is the progression of existing, standards track RFCs from PROPOSED to DRAFT. Also, to the extent that PKIX work relates to protocols from other areas, e.g., LDAP, it is necessary to track the evolution of the other protocols and produce updated RFCs. For example, the LDAP v2 documents from PKIX are evolving to address LDAP v3. Finally, since the profiling of X.509 standards for use in the Internet remains a major focus, the WG will continue to track the evolution of these standards and incorporate changes and additions as appropriate. New Work items for PKIX - production of a requirements RFC for delegated path discovery and path validation protocols (DPD/DPV) and subsequent production of RFCs for protocols that satisfy the requirements - development of a logotype extension for certificates - development of a proxy certificate extension and associated processing rules - development of an informational document on PKI disaster recovery These work items may become standards track, INFORMATIONAL or EXPERIMENTAL RFCs, or may not even be published as RFCs. Other deliverables may be agreed upon as extensions are proposed. New deliverables must be approved by the Security Area Directors before inclusion on the charter or IETF meeting agendas. Description of Working Group: The PKIX Working Group was established in the Fall of 1995 with the intent of developing Internet standards needed to support an X.509-based PKI. The scope of PKIX work has expanded beyond this initial goal. PKIX not only profiles ITU PKI standards, but also develops new standards apropos to the use of X.509-based PKIs in the Internet. PKIX has produced several informational and standards track documents in support of the original and revised scope of the WG. The first of these standards, RFC 2459, profiled X.509 version 3 certificates and version 2 CRLs for use in the Internet. Profiles for the use of Attribute Certificates (RFC XXXX [pending]), LDAP v2 for certificate and CRL storage (RFC 2587), the Internet X.509 Public Key Infrastructure Qualified Certificates Profile (RFC 3039), and the Internet X.509 Public Key Infrastructure Certificate Policy and certification Practices Framework (RFC 2527 - Informational) are in line with the initial scope. The Certificate Management Protocol (CMP) (RFC 2510), the Online Certificate Status Protocol (OCSP) (RFC 2560), Certificate Management Request Format (CRMF) (RFC 2511), Time-Stamp Protocol (RFC 3161), Certificate Management Messages over CMS (RFC 2797), Internet X.509 Public Key Infrastructure Time Stamp Protocols (RFC 3161), and the use of FTP and HTTP for transport of PKI operations (RFC 2585) are representative of the expanded scope of PKIX, as these are new protocols developed in the working group, not profiles of ITU PKI standards. A roadmap, providing a guide to the growing set of PKIX document, also has been developed as an informational RFC. Ongoing PKIX Work items An ongoing PKIX task is the progression of existing, standards track RFCs from PROPOSED to DRAFT. Also, to the extent that PKIX work relates to protocols from other areas, e.g., LDAP, it is necessary to track the evolution of the other protocols and produce updated RFCs. For example, the LDAP v2 documents from PKIX are evolving to address LDAP v3. Finally, since the profiling of X.509 standards for use in the Internet remains a major focus, the WG will continue to track the evolution of these standards and incorporate changes and additions as appropriate. New Work items for PKIX - production of a requirements RFC for delegated path discovery and path validation protocols (DPD/DPV) and subsequent production of RFCs for protocols that satisfy the requirements - development of a logotype extension for certificates - development of a proxy certificate extension and associated processing rules - development of an informational document on PKI disaster recovery These work items may become standards track, INFORMATIONAL or EXPERIMENTAL RFCs, or may not even be published as RFCs. Other deliverables may be agreed upon as extensions are proposed. New deliverables must be approved by the Security Area Directors before inclusion on the charter or IETF meeting agendas. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jun 1999 Jan 2007 Server-based Certificate Validation Protocol (SCVP) Mar 2001 Mar 2006 Certificate Management Messages over CMS Jul 2001 May 2006 Certificate Management over CMS (CMC) Transport Protocols Jul 2001 Mar 2006 CMC Complience Document Aug 2004 Oct 2006 Additional Algorithms and Identifiers for use of Elliptic Curve Cryptography with PKIX Oct 2004 Feb 2007 Lightweight OCSP Profile for High Volume Environments Apr 2005 Feb 2007 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Sep 2005 Dec 2006 Internet X.509 Public Key Infrastructure Subject Alternative Name for expression of service name Path MTU Discovery (pmtud) -------------------------- Charter Last Modified: 2007-02-16 Current Status: Active Working Group Chair(s): Matt Mathis Matthew Zekauskas Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Lars Eggert Mailing Lists: General Discussion:pmtud@ietf.org To Subscribe: pmtud-request@ietf.org In Body: In Body: subscribe email_address Archive: http://www.ietf.org/mail-archive/web/pmtud/index.html Description of Working Group: The goal of the PMTUD working group is to specify a robust method for determining the IP Maximum Transmission Unit supported over an end-to-end path. This new method is expected to update most uses of RFC1191 and RFC1981, the current standards track protocols for this purpose. Various weakness in the current methods are documented in RFC2923, and have proven to be a chronic impediment to the deployment of new technologies that alter the path MTU, such as tunnels and new types of link layers. The proposed new method does not rely on ICMP or other messages from the network. It finds the proper MTU by starting a connection using relatively small packets (e.g. TCP segments) and searching upwards by probing with progressively larger test packets (containing application data). If a probe packet is successfully delivered, then the path MTU is raised. The isolated loss of a probe packet (with or without an ICMP can't fragment message) is treated as an indication of a MTU limit, and not a congestion indicator. The working group will specify the method for use in TCP, SCTP, and will outline what is necessary to support the method in transports such as DCCP. It will particularly describe the precise conditions under which lost packets are not treated as congestion indications. The work will pay particular attention to details that affect robustness and security. Path MTU discovery has the potential to interact with many other parts of the Internet, including all link, transport, encapsulation and tunnel protocols. Thereforethis working group will particularly encourage input from a wide cross section of the IETF to help to maximize the robustness of path MTU discovery in the presence of pathological behaviors from other components. Input draft: Packetization Layer Path MTU Discovery draft-mathis-plpmtud-00.txt Description of Working Group: The goal of the PMTUD working group is to specify a robust method for determining the IP Maximum Transmission Unit supported over an end-to-end path. This new method is expected to update most uses of RFC1191 and RFC1981, the current standards track protocols for this purpose. Various weakness in the current methods are documented in RFC2923, and have proven to be a chronic impediment to the deployment of new technologies that alter the path MTU, such as tunnels and new types of link layers. The proposed new method does not rely on ICMP or other messages from the network. It finds the proper MTU by starting a connection using relatively small packets (e.g. TCP segments) and searching upwards by probing with progressively larger test packets (containing application data). If a probe packet is successfully delivered, then the path MTU is raised. The isolated loss of a probe packet (with or without an ICMP can't fragment message) is treated as an indication of a MTU limit, and not a congestion indicator. The working group will specify the method for use in TCP, SCTP, and will outline what is necessary to support the method in transports such as DCCP. It will particularly describe the precise conditions under which lost packets are not treated as congestion indications. The work will pay particular attention to details that affect robustness and security. Path MTU discovery has the potential to interact with many other parts of the Internet, including all link, transport, encapsulation and tunnel protocols. Thereforethis working group will particularly encourage input from a wide cross section of the IETF to help to maximize the robustness of path MTU discovery in the presence of pathological behaviors from other components. Input draft: Packetization Layer Path MTU Discovery draft-mathis-plpmtud-00.txt Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2003 Dec 2006 Packetization Layer Path MTU Discovery Point-to-Point Protocol Extensions (pppext) ------------------------------------------- Charter Last Modified: 2005-06-07 Current Status: Active Working Group Chair(s): James Carlson Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Mark Townsley Mailing Lists: General Discussion:pppext@ietf.org To Subscribe: https://www1.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 group will actively advance PPP's most useful extensions to full standard, while defending against further enhancements of questionable value. 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 group will actively advance PPP's most useful extensions to full standard, while defending against further enhancements of questionable value. Internet-Drafts: No Current Internet-Drafts. Packet Sampling (psamp) ----------------------- Charter Last Modified: 2006-06-27 Current Status: Active Working Group Chair(s): Juergen Quittek Operations and Management Area Director(s): Dan Romascanu David Kessens Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion:psamp@ietf.org To Subscribe: psamp-request@ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/psamp/index.html Description of Working Group: The Packet Sampling working group is chartered to define a standard set of capabilities for network elements to sample subsets of packets by statistical and other methods. The capabilities should be simple enough that they can be implemented ubiquitously at maximal line rate. They should be rich enough to support a range of existing and emerging measurement-based applications, and other IETF working groups where appropriate. The focus of the WG will be to (i) specify a set of selection operations by which packets are sampled (ii) specify the information that is to be made available for reporting on sampled packets; (iii) describe protocols by which information on sampled packets is reported to applications; (iv) describe protocols by which packet selection and reporting configured. Packet reports must be communicable in a timely manner, to applications either on-board of off-board the sampling network element. The streams of packet reports produced by a packet sampling must (i) allow consistent interpretation, independent of the particular network element that produced them; (ii) be self-defining, in that their interpretation does not require additional information to be supplied by the network element; (iii) allow robustness of interpretation with respect to missing reports or part of reports; Network elements shall support multiple parallel packet samplers, each with independently configurable packet selectors, reports, report streams, and export. Network elements must allow easy and secure reconfiguration of these packet samplers by on-board or external applications. Export of a report stream across a network must be congestion avoiding in compliance with RFC 2914. Unreliable transport is permitted because the requirements at the exporter for reliable transport (state maintenance, addressibilty, acknowledgment processing, buffering unacknowledged data) would prevent ubiquitous deployment. Congestion avoidance with unreliable export is to be accomplished by the following measures, which shall be mandatory to implement and use. The maximum export rate of a report stream must be configurable at the exporter. A report stream must contain sufficient information for transmission loss to be detected a collector. Then the collector must run a congestion control algorithm to compute a new sending rate, and reconfigure the exporter with this rate. In order to maintain report collection during periods of congestion, PSAMP report streams may claim more than a fair share of link bandwidth, provided the number of report streams in competition with fair sharing traffic is limited. Selection of the content of packet reports will be cognizant of privacy and anonymity issues while being responsive to the needs of measurement applications, and in accordance with RFC 2804. Re-use of existing protocols will be encouraged provided the protocol capabilities are compatible with PSAMP requirements. Specifically, the PSAMP WG will perform the following tasks, in accordance with the principles stated above: 1. Selectors for packet sampling. Define the set of primitive packet selection operations for network elements, the parameters by which they may be configured, and the ways in which they can be combined. 2. Packet Information. Specify extent of packet that is to be made available for reporting. Target for inclusion the packet's IP header, some subsequent bytes of the packet, and encapsulating headers if present. Full packet capture of arbitrary packet streams is explicitly out of scope. Specify variants for IPv4 and IPv6, extent of IP packet available under encapsulation methods, and under packet encryption. 3. Sampled packet reports. Define the format of the report that is constructed by the network element for each sampled packet for communication to applications. The format shall be sufficiently rich as to allow inclusion in the packet report of (i) IP packet information as specified in paragraph 2 above; (ii) encapsulating packet headers as specified in paragraph 2 above; (iii) interface or channel identifiers associated with transit of the packet across the network element; (iv) quantities computable from packet content and router state, (v) quantities computed during the selection operation. All reported quantities must reflect the router state and configuration encountered by the packet in the network element. 4. Report Streams. Define a format for a stream of packet reports, to include: (i) the format of packet reports in the stream; (ii) the packet reports themselves; (iii) configuration parameters of the selectors of the packets reported on; (iv) configuration parameters and state information of the network element; (v) quantities that enable collectors and applications to infer of attained packet sampling rates, detect loss during samping, report loss in transmission, and correct for information missing from the packet report stream; (vi) indication of the inherent accuracy of the reported quantities, e.g., of timestamps. 5. Multiple Report Streams. Define requirements for multiple parallel packet samplers in one network element, including the allowed degradation of packet reporting when packets are selected by multiple packet samplers. 6. Configuration and Management. Define a packet sampler MIB to reside at the network element, including parameters for packet selection, packet report and stream format, and export. Select or define a communication protocol to configure/read this MIB. 7. Presentation, Export, and Transport of Packet Reports. Define interface for presentation of reports to on-board applications. Select unreliable transport protocol for remote export. Determine rate control algorithms for export. Initial Internet-Draft: A Framework for Passive Packet Measurement [draft-duffield-framework-papame] Description of Working Group: The Packet Sampling working group is chartered to define a standard set of capabilities for network elements to sample subsets of packets by statistical and other methods. The capabilities should be simple enough that they can be implemented ubiquitously at maximal line rate. They should be rich enough to support a range of existing and emerging measurement-based applications, and other IETF working groups where appropriate. The focus of the WG will be to (i) specify a set of selection operations by which packets are sampled (ii) specify the information that is to be made available for reporting on sampled packets; (iii) describe protocols by which information on sampled packets is reported to applications; (iv) describe protocols by which packet selection and reporting configured. Packet reports must be communicable in a timely manner, to applications either on-board of off-board the sampling network element. The streams of packet reports produced by a packet sampling must (i) allow consistent interpretation, independent of the particular network element that produced them; (ii) be self-defining, in that their interpretation does not require additional information to be supplied by the network element; (iii) allow robustness of interpretation with respect to missing reports or part of reports; Network elements shall support multiple parallel packet samplers, each with independently configurable packet selectors, reports, report streams, and export. Network elements must allow easy and secure reconfiguration of these packet samplers by on-board or external applications. Export of a report stream across a network must be congestion avoiding in compliance with RFC 2914. Unreliable transport is permitted because the requirements at the exporter for reliable transport (state maintenance, addressibilty, acknowledgment processing, buffering unacknowledged data) would prevent ubiquitous deployment. Congestion avoidance with unreliable export is to be accomplished by the following measures, which shall be mandatory to implement and use. The maximum export rate of a report stream must be configurable at the exporter. A report stream must contain sufficient information for transmission loss to be detected a collector. Then the collector must run a congestion control algorithm to compute a new sending rate, and reconfigure the exporter with this rate. In order to maintain report collection during periods of congestion, PSAMP report streams may claim more than a fair share of link bandwidth, provided the number of report streams in competition with fair sharing traffic is limited. Selection of the content of packet reports will be cognizant of privacy and anonymity issues while being responsive to the needs of measurement applications, and in accordance with RFC 2804. Re-use of existing protocols will be encouraged provided the protocol capabilities are compatible with PSAMP requirements. Specifically, the PSAMP WG will perform the following tasks, in accordance with the principles stated above: 1. Selectors for packet sampling. Define the set of primitive packet selection operations for network elements, the parameters by which they may be configured, and the ways in which they can be combined. 2. Packet Information. Specify extent of packet that is to be made available for reporting. Target for inclusion the packet's IP header, some subsequent bytes of the packet, and encapsulating headers if present. Full packet capture of arbitrary packet streams is explicitly out of scope. Specify variants for IPv4 and IPv6, extent of IP packet available under encapsulation methods, and under packet encryption. 3. Sampled packet reports. Define the format of the report that is constructed by the network element for each sampled packet for communication to applications. The format shall be sufficiently rich as to allow inclusion in the packet report of (i) IP packet information as specified in paragraph 2 above; (ii) encapsulating packet headers as specified in paragraph 2 above; (iii) interface or channel identifiers associated with transit of the packet across the network element; (iv) quantities computable from packet content and router state, (v) quantities computed during the selection operation. All reported quantities must reflect the router state and configuration encountered by the packet in the network element. 4. Report Streams. Define a format for a stream of packet reports, to include: (i) the format of packet reports in the stream; (ii) the packet reports themselves; (iii) configuration parameters of the selectors of the packets reported on; (iv) configuration parameters and state information of the network element; (v) quantities that enable collectors and applications to infer of attained packet sampling rates, detect loss during samping, report loss in transmission, and correct for information missing from the packet report stream; (vi) indication of the inherent accuracy of the reported quantities, e.g., of timestamps. 5. Multiple Report Streams. Define requirements for multiple parallel packet samplers in one network element, including the allowed degradation of packet reporting when packets are selected by multiple packet samplers. 6. Configuration and Management. Define a packet sampler MIB to reside at the network element, including parameters for packet selection, packet report and stream format, and export. Select or define a communication protocol to configure/read this MIB. 7. Presentation, Export, and Transport of Packet Reports. Define interface for presentation of reports to on-board applications. Select unreliable transport protocol for remote export. Determine rate control algorithms for export. Initial Internet-Draft: A Framework for Passive Packet Measurement [draft-duffield-framework-papame] Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Sep 2002 Jan 2005 A Framework for Packet Selection and Reporting Oct 2002 Jul 2005 Sampling and Filtering Techniques for IP Packet Selection Oct 2003 Oct 2006 Packet Sampling (PSAMP) Protocol Specifications Oct 2003 Oct 2006 Information Model for Packet Sampling Exports Pseudowire Emulation Edge to Edge (pwe3) ---------------------------------------- Charter Last Modified: 2007-03-06 Current Status: Active Working Group Chair(s): Stewart Bryant Danny McPherson Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Mark Townsley Secretary(ies): Matthew Bocci 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. 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 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 two endpoints of the PW. PWE3 will investigate mechanisms necessary to perform clock recovery and other real-time signaling functions. This work will be coordinated with the AVT WG and RTP will be used where appropriate. 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. 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. PWE3 will work closely with the L2VPN WG to ensure a clear demarcation is defined for where PWE3 stops and L2VPN starts. 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. WG Objectives: Specify the following PW types: Ethernet, Frame Relay, PPP, HDLC, ATM, low-rate TDM, SONET/SDH and Fibre Channel. 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. 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. Further enhance PW specifications to enable more transparent emulation when necessary, for example the retention of FCS across a PW. Define a mechanism for MPLS PWs that provides interoperability with currently deployed equal cost multiple path (ECMP) algorithms such that packets for a given PW follow the same path through an MPLS PSN. 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. 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. 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 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 two endpoints of the PW. PWE3 will investigate mechanisms necessary to perform clock recovery and other real-time signaling functions. This work will be coordinated with the AVT WG and RTP will be used where appropriate. 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. 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. PWE3 will work closely with the L2VPN WG to ensure a clear demarcation is defined for where PWE3 stops and L2VPN starts. 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. WG Objectives: Specify the following PW types: Ethernet, Frame Relay, PPP, HDLC, ATM, low-rate TDM, SONET/SDH and Fibre Channel. 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. 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. Further enhance PW specifications to enable more transparent emulation when necessary, for example the retention of FCS across a PW. Define a mechanism for MPLS PWs that provides interoperability with currently deployed equal cost multiple path (ECMP) algorithms such that packets for a given PW follow the same path through an MPLS PSN. 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. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jun 2002 Feb 2007 Pseudo Wire (PW) Management Information Base Jun 2002 Mar 2007 Pseudo-Wire (PW) over MPLS PSN Management Information Base Jun 2002 Feb 2007 Definitions for Textual Conventions and for Managing Pseudo-Wires over PSN Jul 2002 Dec 2006 SONET/SDH Circuit Emulation over Packet (CEP) Aug 2002 Oct 2006 SONET/SDH Circuit Emulation Service Over Packet (CEP) Management Information Base Using SMIv2 Oct 2002 Feb 2007 Ethernet Pseudo-Wire (PW) Management Information Base Jul 2003 Mar 2007 Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) Oct 2003 Feb 2007 Managed Objects for ATM over Packet Switched Network (PSN) Feb 2004 May 2006 Structure-aware TDM Circuit Emulation Service over Packet Switched Network (CESoPSN) Feb 2004 Dec 2006 TDM over IP May 2004 Feb 2007 Managed Objects for TDM over Packet Switched Network (PSN) Sep 2004 Mar 2007 Pseudo Wire (PW) OAM Message Mapping Jun 2005 Jan 2007 Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3) Jul 2005 Mar 2007 Segmented Pseudo Wire Jul 2005 Oct 2006 Control Protocol Extensions for Setup of TDM Pseudowires Jan 2006 Oct 2006 Dynamic Placement of Multi Segment Pseudo Wires Jan 2006 Oct 2006 An Architecture for Multi-Segment Pseudo Wire Emulation Edge-to-Edge Jan 2006 Oct 2006 Wildcard Pseudowire Type Feb 2006 Feb 2007 AII Types for Aggregation Mar 2006 Oct 2006 Encapsulation Methods for Transport of Fibre Channel frames Over MPLS Networks Feb 2007 Feb 2007 Pseudowire Congestion Control Framework RADIUS EXTensions (radext) -------------------------- Charter Last Modified: 2006-05-19 Current Status: Active Working Group Chair(s): David Nelson Bernard Aboba Operations and Management Area Director(s): Dan Romascanu David Kessens Operations and Management Area Advisor: David Kessens 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 enable its use in applications such as IP telephony and Local Area Network authentication, authorization and accounting. The IETF has recently completed work on the Diameter Base protocol. In order to support the deployment of Diameter, and 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 RADIUS work MUST be backward compatible with existing RADIUS RFCs, including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, and 3580. - 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. - No new RADIUS transports (e.g. TCP, SCTP) will be defined. - No new security mechanisms will be defined for protecting RADIUS. - No new commands will be defined. 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 implementation issues and fixes. This document will address common RADIUS implementation issues and describe proposed solutions. - Revised NAI specification. This document, known as "RFC 2486bis" will revise the NAI specification to correct known errors, add support for privacy and internationalization, and provide more details on routing. - Pre-paid support. Prepaid services are contemplated in a number of potential applications, including wireless LAN access and IP telephony. In order to enable support of pre-paid services in an interoperable way, the WG will provide definitions of the attributes required to support operator service models for pre-paid, as documented in liaison communications. This document will include within it a specification for interoperation with Diameter Credit Control. - SIP support. RADIUS is currently used for SIP authentication, authorization and accounting. Standardization of these attributes will enable improved interoperability. This document will be upwards compatible with the Diameter SIP application, and conform to existing IETF RFCs on HTTP Digest, including RFC 2617, 3261, and 3310. - LAN attributes. New attributes have been proposed to enable use of authentication, authorization and accounting in wired and wireless LANs. Standardization of these attributes will enable improved interoperability. - RADIUS MIB update. RFC 2618-2621 lack IPv6 compatibility, and modest changes are required to address this issue. MIBs for RFC 3576 are also needed. Description of Working Group: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to enable its use in applications such as IP telephony and Local Area Network authentication, authorization and accounting. The IETF has recently completed work on the Diameter Base protocol. In order to support the deployment of Diameter, and 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 RADIUS work MUST be backward compatible with existing RADIUS RFCs, including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, and 3580. - 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. - No new RADIUS transports (e.g. TCP, SCTP) will be defined. - No new security mechanisms will be defined for protecting RADIUS. - No new commands will be defined. 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 implementation issues and fixes. This document will address common RADIUS implementation issues and describe proposed solutions. - Revised NAI specification. This document, known as "RFC 2486bis" will revise the NAI specification to correct known errors, add support for privacy and internationalization, and provide more details on routing. - Pre-paid support. Prepaid services are contemplated in a number of potential applications, including wireless LAN access and IP telephony. In order to enable support of pre-paid services in an interoperable way, the WG will provide definitions of the attributes required to support operator service models for pre-paid, as documented in liaison communications. This document will include within it a specification for interoperation with Diameter Credit Control. - SIP support. RADIUS is currently used for SIP authentication, authorization and accounting. Standardization of these attributes will enable improved interoperability. This document will be upwards compatible with the Diameter SIP application, and conform to existing IETF RFCs on HTTP Digest, including RFC 2617, 3261, and 3310. - LAN attributes. New attributes have been proposed to enable use of authentication, authorization and accounting in wired and wireless LANs. Standardization of these attributes will enable improved interoperability. - RADIUS MIB update. RFC 2618-2621 lack IPv6 compatibility, and modest changes are required to address this issue. MIBs for RFC 3576 are also needed. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2006 Mar 2007 RADIUS Attributes for Filtering and Redirection Mar 2006 Oct 2006 RADIUS Delegated-IPv6-Prefix Attribute Jun 2006 Jan 2007 RADIUS Filter Rule Attribute Jan 2007 Jan 2007 RADIUS Extension for Digest Authentication Jan 2007 Feb 2007 Common RADIUS Implementation Issues and Suggested Fixes Jan 2007 Jan 2007 Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) Remote Direct Data Placement (rddp) ----------------------------------- Charter Last Modified: 2007-02-21 Current Status: Active Working Group Chair(s): David Black Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Lars Eggert Technical Advisor(s): Allyn Romanow Stephen Bailey Mailing Lists: General Discussion:rddp@ietf.org To Subscribe: rddp-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/rddp/index.html Description of Working Group: The purpose of this WG is to enable Remote Direct Data Placement (rddp) capabilities with IP transport protocols, in particular with SCTP. RDDP capabilities refer to the ability to place data directly from the NIC into application buffers, without intensive CPU usage. This strategy avoids the costs of data copying and enables using IP as a method for high speed buffer to buffer transfer, allowing IP to replace special purpose networks currently in use. Remote Direct Memory Access (RDMA) is an example of this concept. Conceptually, RDDP functionality can be viewed as consisting of two layers. First the direct data placement capability, which is accomplished through a tag and a lookup table on the NIC. Above this core functionality, an RDDP control protocol is needed to specify how the direct data placement can be used, for example READ and WRITE commands. The work of the WG is to accomplish four items: 1) A (transport independent) protocol core to support direct data placement from the NIC into specified memory, usually application buffers. 2) A (transport independent) protocol core layered on top of the direct data placement protocol that specifies control of RDDP. 3) A mapping of the direct data placement protocol onto SCTP, for standards track, including a clear applicability statement of the expected service from the mapping. 4) A mapping of the direct data placement protocol onto TCP, for informational, because TCP's service is a less good match to RDDP, including an applicability statement of the issues regarding the service available from the mapping. The working group will ensure that the resulting technology will be secure and will not enable new attacks on systems supporting RDDP. The WG will not modify existing Internet transport protocols, but may forward issues it discovers in such transport protocols that are not full Internet Standards to the appropriate IETF WGs for their consideration. Description of Working Group: The purpose of this WG is to enable Remote Direct Data Placement (rddp) capabilities with IP transport protocols, in particular with SCTP. RDDP capabilities refer to the ability to place data directly from the NIC into application buffers, without intensive CPU usage. This strategy avoids the costs of data copying and enables using IP as a method for high speed buffer to buffer transfer, allowing IP to replace special purpose networks currently in use. Remote Direct Memory Access (RDMA) is an example of this concept. Conceptually, RDDP functionality can be viewed as consisting of two layers. First the direct data placement capability, which is accomplished through a tag and a lookup table on the NIC. Above this core functionality, an RDDP control protocol is needed to specify how the direct data placement can be used, for example READ and WRITE commands. The work of the WG is to accomplish four items: 1) A (transport independent) protocol core to support direct data placement from the NIC into specified memory, usually application buffers. 2) A (transport independent) protocol core layered on top of the direct data placement protocol that specifies control of RDDP. 3) A mapping of the direct data placement protocol onto SCTP, for standards track, including a clear applicability statement of the expected service from the mapping. 4) A mapping of the direct data placement protocol onto TCP, for informational, because TCP's service is a less good match to RDDP, including an applicability statement of the issues regarding the service available from the mapping. The working group will ensure that the resulting technology will be secure and will not enable new attacks on systems supporting RDDP. The WG will not modify existing Internet transport protocols, but may forward issues it discovers in such transport protocols that are not full Internet Standards to the appropriate IETF WGs for their consideration. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2003 Sep 2006 A Remote Direct Memory Access Protocol Specification Feb 2003 Sep 2006 Direct Data Placement over Reliable Transports Jun 2003 Jun 2006 Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP) Sep 2003 Sep 2006 Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation Oct 2003 Oct 2006 Marker PDU Aligned Framing for TCP Specification Oct 2003 Jun 2006 DDP/RDMAP Security Reliable Multicast Transport (rmt) ---------------------------------- Charter Last Modified: 2006-10-16 Current Status: Active Working Group Chair(s): Brian Adamson Lorenzo Vicisano 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 ------ ------- -------------------------------------------- Feb 2005 Mar 2007 Raptor Forward Error Correction Scheme for Object Delivery May 2005 Feb 2007 Forward Error Correction (FEC) Building Block Jul 2005 Feb 2007 Layered Coding Transport (LCT) Building Block Jul 2005 Feb 2007 Asynchronous Layered Coding (ALC) Protocol Instantiation Jul 2005 Feb 2007 Basic Forward Error Correction (FEC) Schemes Oct 2005 Jan 2007 FLUTE - File Delivery over Unidirectional Transport Oct 2005 Dec 2006 Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes Oct 2005 Mar 2007 Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol Oct 2005 Sep 2006 Multicast Negative-Acknowledgment (NACK) Building Blocks Mar 2006 Dec 2006 Reed-Solomon Forward Error Correction (FEC) Robust Header Compression (rohc) -------------------------------- Charter Last Modified: 2006-11-29 Current Status: Active Working Group Chair(s): Lars-Erik Jonsson 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 ------ ------- -------------------------------------------- Feb 2002 Feb 2007 RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP) Nov 2002 Dec 2006 Formal Notation for Robust Header Compression (ROHC-FN) May 2003 Jan 2007 Implementer's Guide for SigComp Jun 2003 Mar 2007 Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP) Nov 2005 Feb 2007 Integration of Header Compression over IPsec Security Associations Dec 2005 Nov 2006 The RObust Header Compression (ROHC) Framework Sep 2006 Sep 2006 RObust Header Compression Version 2 (RoHCv2): Profiles for RTP, UDP, IP, ESP and UDP Lite Sep 2006 Feb 2007 IKEv2 Extensions to Support Header Compression over IPsec (HCoIPsec) Routing Protocol Security Requirements (rpsec) ---------------------------------------------- Charter Last Modified: 2006-03-24 Current Status: Active Working Group Chair(s): Tony Tauber Russ White Routing Area Director(s): Ross Callon Bill Fenner Routing Area Advisor: Ross Callon Mailing Lists: General Discussion:rpsec@ietf.org To Subscribe: rpsec-request@ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/rpsec/index.html Description of Working Group: The lack of a common set of security requirements and methods for routing protocols has resulted in a wide variety of security mechanisms for individual routing protocols. Ongoing work on requirements for the next generation routing system and future work on the actual mechanisms for it will require well documented routing security requirements. The products of this working group will be used by routing protocol designers to ensure adequate coverage of security in the future, including well known and possible threats. The scope of work is limited to router-to-router protocols only for both unicast and multicast systems, and does NOT include host-to-router protocol such as IGMP, ICMP, ARP, or ND. It is also a non-goal at this point to produce new or change the current security mechanisms in the existing routing protocols. The RPSEC working group is charged with the following tasks: - Document threat models for routing systems - Document security requirements for routing systems - Document security analysis and requirements for specific routing protocols (e.g., OSPF, BGP) - Provide a common area for discussion between security and routing experts on the topic of securing the routing system Possible Future Work - Evaluate and document existing and proposed routing security mechanisms with respect to established RPSEC requirements - Recommend mechanism(s) Description of Working Group: The lack of a common set of security requirements and methods for routing protocols has resulted in a wide variety of security mechanisms for individual routing protocols. Ongoing work on requirements for the next generation routing system and future work on the actual mechanisms for it will require well documented routing security requirements. The products of this working group will be used by routing protocol designers to ensure adequate coverage of security in the future, including well known and possible threats. The scope of work is limited to router-to-router protocols only for both unicast and multicast systems, and does NOT include host-to-router protocol such as IGMP, ICMP, ARP, or ND. It is also a non-goal at this point to produce new or change the current security mechanisms in the existing routing protocols. The RPSEC working group is charged with the following tasks: - Document threat models for routing systems - Document security requirements for routing systems - Document security analysis and requirements for specific routing protocols (e.g., OSPF, BGP) - Provide a common area for discussion between security and routing experts on the topic of securing the routing system Possible Future Work - Evaluate and document existing and proposed routing security mechanisms with respect to established RPSEC requirements - Recommend mechanism(s) Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Dec 2004 Feb 2007 BGP Security Requirements Reliable Server Pooling (rserpool) ---------------------------------- Charter Last Modified: 2006-11-08 Current Status: Active Working Group Chair(s): Lyndon Ong Maureen Stillman Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Magnus Westerlund Technical Advisor(s): Ned Freed Mailing Lists: General Discussion:rserpool@ietf.org To Subscribe: rserpool-request@ietf.org In Body: subscribe email_address Archive: http://www.ietf.org/mail-archive/web/rserpool/index.html Description of Working Group: The purpose of the WG is to develop an architecture and protocols for the management and operation of server pools supporting highly reliable applications, and for client access mechanisms to a server pool. The WG will define architecture and requirements for management and access to server pools, including requirements from a variety of applications, building blocks and interfaces, different styles of pooling, security requirements and performance requirements, such as failover times and coping with heterogeneous latencies. This will be documented in an Informational RFC. Scope: The working group will focus on supporting high availability and scalability of applications through the use of pools of servers. This requires both a way to keep track of what servers are in the pool and are able to receive requests and a way for the client to bind to a desired server. The Working Group will NOT address: 1) reliable multicast protocols - the use of multicast for reliable server pooling is optional. Reliable multicast protocols will be developed by the RMT WG. 2) synchronization/consistency of data between server pool elements, e.g. shared memory 3) mechanisms for sharing state information between server pool elements 4) Transaction failover. If a server fails during processing of a transaction this transaction may be lost. Some services may provide a way to handle the failure, but this is not guaranteed. The WG will address client access mechanisms for server pools, specifically: 1) An access mechanism that allows geographically dispersed servers in the pool 2) A client-server binding mechanism that allows dynamic assignment of client to servers based on load balancing or application specific assignment policies. 3) Support of automatic reconfiguration of the client/server binding in case of server failure or administrative changes. To the extent that new protocols are necessary to support the requirements for server pooling, these will be documented in a Standards Track RFC on client access to a binding service (i.e. name space) protocol. The WG will also address use of proxying to interwork existing client access mechanisms to any new binding service. The WG will address server pool management and a distributed service to support client/server binding, including: 1) A scalable mechanism for tracking server pool membership (incl. registration) 2) A scalable protocol for performing node failure detection, reconfiguration and failover, and otherwise managing the server pool (supporting caching, membership, query, authentication, and security) 3) A distributed service to support binding of clients to servers, based on information specific to the server pool. Given that this service is essential to access the server pool, a high degree of availability is necessary. 4) A means for allowing flexible load assignment and balancing policies The protocols and procedures for server pool management will be documented in a Standards Track RFC. The WG will address: - transport protocol(s) that would be supported (eg. UDP, SCTP, TCP) - any new congestion management issues - relationship to existing work such as URI resolution mechanisms Rserpool will consult with other IETF working groups such as Reliable multicast, DNS extensions, AAA, URN, WREC and Sigtran as appropriate and will not duplicate any of these efforts. Description of Working Group: The purpose of the WG is to develop an architecture and protocols for the management and operation of server pools supporting highly reliable applications, and for client access mechanisms to a server pool. The WG will define architecture and requirements for management and access to server pools, including requirements from a variety of applications, building blocks and interfaces, different styles of pooling, security requirements and performance requirements, such as failover times and coping with heterogeneous latencies. This will be documented in an Informational RFC. Scope: The working group will focus on supporting high availability and scalability of applications through the use of pools of servers. This requires both a way to keep track of what servers are in the pool and are able to receive requests and a way for the client to bind to a desired server. The Working Group will NOT address: 1) reliable multicast protocols - the use of multicast for reliable server pooling is optional. Reliable multicast protocols will be developed by the RMT WG. 2) synchronization/consistency of data between server pool elements, e.g. shared memory 3) mechanisms for sharing state information between server pool elements 4) Transaction failover. If a server fails during processing of a transaction this transaction may be lost. Some services may provide a way to handle the failure, but this is not guaranteed. The WG will address client access mechanisms for server pools, specifically: 1) An access mechanism that allows geographically dispersed servers in the pool 2) A client-server binding mechanism that allows dynamic assignment of client to servers based on load balancing or application specific assignment policies. 3) Support of automatic reconfiguration of the client/server binding in case of server failure or administrative changes. To the extent that new protocols are necessary to support the requirements for server pooling, these will be documented in a Standards Track RFC on client access to a binding service (i.e. name space) protocol. The WG will also address use of proxying to interwork existing client access mechanisms to any new binding service. The WG will address server pool management and a distributed service to support client/server binding, including: 1) A scalable mechanism for tracking server pool membership (incl. registration) 2) A scalable protocol for performing node failure detection, reconfiguration and failover, and otherwise managing the server pool (supporting caching, membership, query, authentication, and security) 3) A distributed service to support binding of clients to servers, based on information specific to the server pool. Given that this service is essential to access the server pool, a high degree of availability is necessary. 4) A means for allowing flexible load assignment and balancing policies The protocols and procedures for server pool management will be documented in a Standards Track RFC. The WG will address: - transport protocol(s) that would be supported (eg. UDP, SCTP, TCP) - any new congestion management issues - relationship to existing work such as URI resolution mechanisms Rserpool will consult with other IETF working groups such as Reliable multicast, DNS extensions, AAA, URN, WREC and Sigtran as appropriate and will not duplicate any of these efforts. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Apr 2001 Nov 2006 Architecture for Reliable Server Pooling Apr 2001 Nov 2006 Comparison of Protocols for Reliable Server Pooling Jun 2001 Jan 2007 Aggregate Server Access Protocol (ASAP) Jun 2001 Jan 2007 Endpoint Handlespace Redundancy Protocol (ENRP) May 2002 Oct 2006 Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters Dec 2002 Nov 2006 Threats Introduced by Rserpool and Requirements for Security in response to Threats Oct 2004 Mar 2007 Reliable Server Pooling Policies Oct 2006 Oct 2006 An Overview of Reliable Server Pooling Protocols Routing Area Working Group (rtgwg) ---------------------------------- Charter Last Modified: 2007-02-20 Current Status: Active Working Group Chair(s): John Scudder Alex Zinin Routing Area Director(s): Ross Callon Bill Fenner Routing Area Advisor: Bill Fenner 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 ------ ------- -------------------------------------------- Mar 2004 Jan 2007 The Generalized TTL Security Mechanism (GTSM) Jun 2004 Oct 2006 IP Fast Reroute Framework Sep 2004 Mar 2007 Basic Specification for IP Fast-Reroute: Loop-free Alternates Dec 2006 Dec 2006 Loop-free convergence using oFIB Dec 2006 Dec 2006 IP Fast Reroute Using Not-via Addresses Dec 2006 Dec 2006 A Framework for Loop-free Convergence Simple Authentication and Security Layer (sasl) ----------------------------------------------- Charter Last Modified: 2006-08-16 Current Status: Active Working Group Chair(s): Tom Yu Kurt Zeilenga Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Sam Hartman Mailing Lists: General Discussion:ietf-sasl@imc.org To Subscribe: ietf-sasl-request@imc.org In Body: subscribe Archive: http://www.imc.org/ietf-sasl/mail-archive/ Description of Working Group: The Simple Authentication and Security Layer [RFC2222] 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 deliver a revised SASL Technical Specification suitable for consideration as a Draft Standard. This work will be based upon RFC 2222 and draft-myers-saslrev. This group will deliver revised Technical Specifications suitable for consideration as Draft Standards for the following SASL mechanisms: ANONYMOUS, PLAIN, CRAM-MD5, DIGEST-MD5, and EXTERNAL. This work will be based upon RFC 2195, RFC 2222, RFC 2831, draft-zeilenga-sasl-anon, draft-zeilenga-sasl-plain, draft-nerenberg-sasl-crammd5 and draft-melnikov-rfc2831bis, and draft-myers-saslrev-xx.txt. This group will deliver a revised Technical Specification suitable for publication as Proposed Standard for the GSSAPI family of SASL mechanisms. This work will be based upon RFC 2222 and draft-ietf-cat-sasl-gssapi. 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 [RFC2222] 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 deliver a revised SASL Technical Specification suitable for consideration as a Draft Standard. This work will be based upon RFC 2222 and draft-myers-saslrev. This group will deliver revised Technical Specifications suitable for consideration as Draft Standards for the following SASL mechanisms: ANONYMOUS, PLAIN, CRAM-MD5, DIGEST-MD5, and EXTERNAL. This work will be based upon RFC 2195, RFC 2222, RFC 2831, draft-zeilenga-sasl-anon, draft-zeilenga-sasl-plain, draft-nerenberg-sasl-crammd5 and draft-melnikov-rfc2831bis, and draft-myers-saslrev-xx.txt. This group will deliver a revised Technical Specification suitable for publication as Proposed Standard for the GSSAPI family of SASL mechanisms. This work will be based upon RFC 2222 and draft-ietf-cat-sasl-gssapi. 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 2003 Mar 2007 Using Digest Authentication as a SASL Mechanism Jun 2003 Mar 2007 The CRAM-MD5 SASL Mechanism Feb 2006 Mar 2007 Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family Site Multihoming by IPv6 Intermediation (shim6) ----------------------------------------------- Charter Last Modified: 2006-05-03 Current Status: Active Working Group Chair(s): Kurt Lindqvist Geoff Huston Internet Area Director(s): Jari Arkko Mark Townsley 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: For the purposes of redundancy, load sharing, operational policy or cost, a site may be multi-homed, with the site's network having connections to multiple IP service providers. The current Internet routing infrastructure permits multi-homing using provider independent addressing, and adapts to changes in the availability of these connections. However if the site uses multiple provider-assigned address prefixes for every host within the site, host application associations cannot use alternate paths, such as for surviving the changes or for creating new associations, when one or more of the site's address prefixes becomes unreachable. This working group will produce specifications for an IPv6-based site multi-homing solution that inserts a new sub-layer (shim) into the IP stack of end-system hosts. It will enable hosts on multi-homed sites to use a set of provider- assigned IP address prefixes and switch between them without upsetting transport protocols or applications. The work will be based on the architecture developed by the IETF multi6 working group. The shim6 working group is to complete the required protocol developments and the architecture and security analysis of the required protocols. Requirements for the solution are: o The approach must handle re-homing both existing communication and being able to establish new communication when one or more of the addresses is unreachable. o IPv6 NAT devices are assumed not to exist, or not to present an obstacle about which the shim6 solution needs to be concerned. o Only IPv6 is considered. o Changes in the addresses that are used below the shim will be invisible to the upper layers, which will see a fixed address (termed Upper Layer Identifier or ULID). o ULIDs will be actual IP addresses, permitting existing applications to continue to work unchanged, and permitting application referrals to work, as long as the IP Addresses are available. o The solution should assume ingress filtering may be applied at network boundaries. o The solution must allow the global routing system to scale even if there is a very large number of multi-homed sites. This implies that re-homing not be visible to the routing system. o Compatibility will remain for existing mobility mechanisms. It will be possible to use Mobile IPv6 on a node that also supports Shim6. However, any optimizations or advanced configurations are out of scope for shim6. o The approach is to provide an optimized way to handle a static set of addresses, while also providing a way to securely handle dynamic changes in the set of addresses. The dynamic changes might be useful for future combinations of multi-homing and IP mobility, but the working group will not take on such mobility capabilities directly. o The specifications must specifically refer to all applicable threats and describe how they are handled, with the requirement being that the resulting solution not introduce any threats that make the security any less than in today's Internet. The background documents to be considered by the WG include: RFC 3582 draft-ietf-multi6-architecture-04.txt draft-ietf-multi6-things-to-think-about-01.txt draft-ietf-multi6-multihoming-threats-03.txt The input documents that the WG will use as the basis for its design are: draft-huston-l3shim-arch-00.txt draft-ietf-multi6-functional-dec-00.txt draft-ietf-multi6-l3shim-00.txt draft-ietf-multi6-failure-detection-00.txt draft-ietf-multi6-hba-00.txt draft-ietf-multi6-app-refer-00.txt In addition to the network layer shim solution, the shim6 WG is specifically chartered to work on: o Solutions for site exit router selection that work when each ISP uses ingress filtering, i.e. when the chosen site exit needs to be related to the source address chosen by the host. This site exit router selection and the associated address selection process should work whether or not the peer site supports the shim6 protocol. o Solutions to establish new communications after an outage has occurred that do not require shim support from the non-multihomed end of the communication. The Working Group will explore whether such solutions are also useful when both ends support the shim. o The possible impact of the use of multiple locators at both ends on congestion control, traffic engineering, and QoS will be analysed in conjunction with the Transport Area. o The relationships between Upper Layer Identifiers (ULIDs) and unique local addresses. o ICMP error demuxing for locator failure discovery. o If necessary, develop and specify formats and structure for: - Cryptographically protected locators - Carrying the flow label across the shim layer defined in the multi6 architecture. The shim6 WG is to publish, as standards track RFC's, specifications with enough details to allow fully interoperable implementations. Description of Working Group: For the purposes of redundancy, load sharing, operational policy or cost, a site may be multi-homed, with the site's network having connections to multiple IP service providers. The current Internet routing infrastructure permits multi-homing using provider independent addressing, and adapts to changes in the availability of these connections. However if the site uses multiple provider-assigned address prefixes for every host within the site, host application associations cannot use alternate paths, such as for surviving the changes or for creating new associations, when one or more of the site's address prefixes becomes unreachable. This working group will produce specifications for an IPv6-based site multi-homing solution that inserts a new sub-layer (shim) into the IP stack of end-system hosts. It will enable hosts on multi-homed sites to use a set of provider- assigned IP address prefixes and switch between them without upsetting transport protocols or applications. The work will be based on the architecture developed by the IETF multi6 working group. The shim6 working group is to complete the required protocol developments and the architecture and security analysis of the required protocols. Requirements for the solution are: o The approach must handle re-homing both existing communication and being able to establish new communication when one or more of the addresses is unreachable. o IPv6 NAT devices are assumed not to exist, or not to present an obstacle about which the shim6 solution needs to be concerned. o Only IPv6 is considered. o Changes in the addresses that are used below the shim will be invisible to the upper layers, which will see a fixed address (termed Upper Layer Identifier or ULID). o ULIDs will be actual IP addresses, permitting existing applications to continue to work unchanged, and permitting application referrals to work, as long as the IP Addresses are available. o The solution should assume ingress filtering may be applied at network boundaries. o The solution must allow the global routing system to scale even if there is a very large number of multi-homed sites. This implies that re-homing not be visible to the routing system. o Compatibility will remain for existing mobility mechanisms. It will be possible to use Mobile IPv6 on a node that also supports Shim6. However, any optimizations or advanced configurations are out of scope for shim6. o The approach is to provide an optimized way to handle a static set of addresses, while also providing a way to securely handle dynamic changes in the set of addresses. The dynamic changes might be useful for future combinations of multi-homing and IP mobility, but the working group will not take on such mobility capabilities directly. o The specifications must specifically refer to all applicable threats and describe how they are handled, with the requirement being that the resulting solution not introduce any threats that make the security any less than in today's Internet. The background documents to be considered by the WG include: RFC 3582 draft-ietf-multi6-architecture-04.txt draft-ietf-multi6-things-to-think-about-01.txt draft-ietf-multi6-multihoming-threats-03.txt The input documents that the WG will use as the basis for its design are: draft-huston-l3shim-arch-00.txt draft-ietf-multi6-functional-dec-00.txt draft-ietf-multi6-l3shim-00.txt draft-ietf-multi6-failure-detection-00.txt draft-ietf-multi6-hba-00.txt draft-ietf-multi6-app-refer-00.txt In addition to the network layer shim solution, the shim6 WG is specifically chartered to work on: o Solutions for site exit router selection that work when each ISP uses ingress filtering, i.e. when the chosen site exit needs to be related to the source address chosen by the host. This site exit router selection and the associated address selection process should work whether or not the peer site supports the shim6 protocol. o Solutions to establish new communications after an outage has occurred that do not require shim support from the non-multihomed end of the communication. The Working Group will explore whether such solutions are also useful when both ends support the shim. o The possible impact of the use of multiple locators at both ends on congestion control, traffic engineering, and QoS will be analysed in conjunction with the Transport Area. o The relationships between Upper Layer Identifiers (ULIDs) and unique local addresses. o ICMP error demuxing for locator failure discovery. o If necessary, develop and specify formats and structure for: - Cryptographically protected locators - Carrying the flow label across the shim layer defined in the multi6 architecture. The shim6 WG is to publish, as standards track RFC's, specifications with enough details to allow fully interoperable implementations. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2005 Dec 2006 Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming Jul 2005 Oct 2006 Applicability Statement for the Level 3 Multihoming Shim Protocol (Shim6) Jul 2005 Oct 2006 Hash Based Addresses (HBA) Oct 2005 Dec 2006 Level 3 multihoming shim protocol May 2006 Oct 2006 Default Locator-pair selection algorithm for the SHIM6 protocol Oct 2006 Oct 2006 Ingress filtering compatibility for IPv6 multihomed sites Oct 2006 Mar 2007 Socket Application Program Interface (API) for Multihoming Shim Secure Inter-Domain Routing (sidr) ---------------------------------- Charter Last Modified: 2007-02-20 Current Status: Active Working Group Chair(s): Sandra Murphy Geoff Huston Routing Area Director(s): Ross Callon Bill Fenner 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 Feb 2007 A Profile for X.509 PKIX Resource Certificates Oct 2006 Feb 2007 Certificate Policy (CP) for the Internet IP Address and AS Number (PKI) Oct 2006 Mar 2007 Template for an Internet Registry's Certification Practice Statement (CPS) for the Internet IP Address and AS Number (PKI) Feb 2007 Mar 2007 Template for an Internet Service Provider's Certification Practice Statement (CPS) for the Internet IP address and AS Number PKI Feb 2007 Feb 2007 A Profile for Route Origin Authorizations (ROA) Feb 2007 Feb 2007 An Infrastructure to Support Secure Internet Routing Sieve Mail Filtering Language (sieve) ------------------------------------- Charter Last Modified: 2007-01-16 Current Status: Active Working Group Chair(s): Cyrus Daboo Alexey Melnikov Applications Area Director(s): Ted Hardie Lisa Dusseault Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion:ietf-mta-filters@imc.org To Subscribe: ietf-mta-filters-request@imc.org In Body: body=subscribe Archive: http://www.imc.org/ietf-mta-filters/mail-archive/ Description of Working Group: The sieve mail filtering language specified in RFC 3028 has now been implemented in a wide variety of user agents (UAs), mail delivery agents (MDAs), and mail transfer agents (MTAs). Several extensions have been specified (RFCs 3431, 3598, 3685, 3894) and have also been widely implemented. Several additional sieve extensions have been defined in various internet-drafts. All of these documents are individual submissions; up to this point work on sieve has been done informally and not under the auspices of any IETF working group. The sieve working group is being chartered to: (1) Revise the base sieve specification, RFC 3028, with the intention of moving it to draft standard. Substantive additions or revisions to the base specification are out of scope of this working group. However, the need to loosen current restrictions on side effects of tests as well as the need for a normative reference to the newly-defined comparators registry may necessitate a recycle at proposed. (2) Produce updated sieve relational (RFC 3431), subaddress (RFC 3598), spamtest/virustest (RFC 3685), and copy (RFC 3894) extension specifications, again with the intention of making a move to draft standard possible. It may be necessary to recycle some or all of these documents at proposed, depending on the scope of any changes. (3) Finalize and publish the sieve extensions as proposed standards: (a) Variables (draft-homme-sieve-variables-04.txt) (b) Vacation action (draft-showalter-sieve-vacation-05.txt) (c) Message body tests (draft-degener-sieve-body-02.txt) (d) Regular expressions (draft-murchison-sieve-regex-07.txt) (e) MIME part tests (draft-daboo-sieve-mime-00.txt) (f) Notification action (draft-martin-sieve-notify-02.txt) (g) IMAP flags (draft-melnikov-sieve-imapflags-06.txt) (h) Header editing actions (draft-degener-sieve-editheader-01.txt) (i) Reject before delivery (draft-elvey-refuse-sieve-01.txt) Additional drafts may be added 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. Some aspects of sieve have complex internationalization issues; the working group will seek out internationalization expertise as needed to complete its work. Description of Working Group: The sieve mail filtering language specified in RFC 3028 has now been implemented in a wide variety of user agents (UAs), mail delivery agents (MDAs), and mail transfer agents (MTAs). Several extensions have been specified (RFCs 3431, 3598, 3685, 3894) and have also been widely implemented. Several additional sieve extensions have been defined in various internet-drafts. All of these documents are individual submissions; up to this point work on sieve has been done informally and not under the auspices of any IETF working group. The sieve working group is being chartered to: (1) Revise the base sieve specification, RFC 3028, with the intention of moving it to draft standard. Substantive additions or revisions to the base specification are out of scope of this working group. However, the need to loosen current restrictions on side effects of tests as well as the need for a normative reference to the newly-defined comparators registry may necessitate a recycle at proposed. (2) Produce updated sieve relational (RFC 3431), subaddress (RFC 3598), spamtest/virustest (RFC 3685), and copy (RFC 3894) extension specifications, again with the intention of making a move to draft standard possible. It may be necessary to recycle some or all of these documents at proposed, depending on the scope of any changes. (3) Finalize and publish the sieve extensions as proposed standards: (a) Variables (draft-homme-sieve-variables-04.txt) (b) Vacation action (draft-showalter-sieve-vacation-05.txt) (c) Message body tests (draft-degener-sieve-body-02.txt) (d) Regular expressions (draft-murchison-sieve-regex-07.txt) (e) MIME part tests (draft-daboo-sieve-mime-00.txt) (f) Notification action (draft-martin-sieve-notify-02.txt) (g) IMAP flags (draft-melnikov-sieve-imapflags-06.txt) (h) Header editing actions (draft-degener-sieve-editheader-01.txt) (i) Reject before delivery (draft-elvey-refuse-sieve-01.txt) Additional drafts may be added 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. Some aspects of sieve have complex internationalization issues; the working group will seek out internationalization expertise as needed to complete its work. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Nov 2004 Dec 2005 Sieve Extension: Variables Feb 2005 Jul 2006 SIEVE Email Filtering: Spamtest and Virustest Extensions Feb 2005 Feb 2007 Sieve Email Filtering: Body Extension Feb 2005 Mar 2007 Sieve Email Filtering: Editheader Extension Feb 2005 May 2006 SIEVE Email Filtering: IMAP flag Extension Feb 2005 Jun 2006 Sieve Email Filtering -- Subaddress Extension Feb 2005 Dec 2005 Sieve Extension: Relational Tests Mar 2005 Mar 2007 Sieve Email Filtering: Vacation Extension May 2005 Feb 2007 Sieve: An Email Filtering Language May 2005 Oct 2006 The SIEVE mail filtering language - reject extension Sep 2005 Feb 2007 Sieve Extension: Notifications Dec 2005 Mar 2007 Sieve Notification Mechanism: mailto Jan 2006 Mar 2007 Sieve Notification Mechanism: xmpp Mar 2006 Oct 2006 SIEVE Email Filtering: MIME part Tests, Iteration, Replacement and Enclosure Signaling Transport (sigtran) ----------------------------- Charter Last Modified: 2006-03-24 Current Status: Active Working Group Chair(s): Lyndon Ong Real-time Applications and Infrastructure Area Director(s): Jon Peterson Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Cullen Jennings Technical Advisor(s): Shawn Routhier Mailing Lists: General Discussion:sigtran@ietf.org To Subscribe: sigtran-request@ietf.org In Body: subscribe email_address Archive: http://www.ietf.org/mail-archive/web/sigtran/index.html Description of Working Group: The primary purpose of this working group will be to address the transport of packet-based PSTN signaling over IP Networks, taking into account functional and performance requirements of the PSTN signaling. For interworking with PSTN, IP networks will need to transport signaling such as Q.931 or SS7 ISUP messages between IP nodes such as a Signaling Gateway and Media Gateway Controller or Media Gateway. Examples of such transport include: - transport of signaling between a Signaling Gateway and Media Gateway or Media Gateway Controller - transport of signaling ("backhaul") from a Media Gateway to a Media Gateway Controller - transport of TCAP between a Signaling Gateway and other IP nodes Applications include: - Internet dial-up remote access - IP telephony interworking with PSTN - Other services as identified Specific goals are: 1. Architecture and Performance Requirements: The working group will produce an informational RFC identifying functionality and performance requirements to support signaling over IP. Signaling messages have very stringent loss and delay requirements in the existing telephone networks that need to be supported. 2- Transport: The working group will produce a standards track proposal or proposals defining transport of signaling protocols using SCTP, based on the requirements identified above. These proposals will identify the method of encapsulation of different signaling protocols. This will include differentiating between different protocols being carried, and what components are transported, translated or terminated at the SG. Security and resilience must be addressed. Note: TCAP is a transaction protocol with different functions and requirements than call control signaling. This will need to be taken into account in its mapping to IP networks. This work will be done in conjunction with other IETF working groups looking at similar issues. The working group will also ensure that good information conduits exist with groups in other standards groups with expertise in the relevant signaling protocols or in the network requirements for the transport of the relevant signaling protocols. The group will make use of existing IETF QoS and security technology and will not address creation of new QoS or security functions for IP networks. Nor will the working group work on defining new call control or device control protocols. Description of Working Group: The primary purpose of this working group will be to address the transport of packet-based PSTN signaling over IP Networks, taking into account functional and performance requirements of the PSTN signaling. For interworking with PSTN, IP networks will need to transport signaling such as Q.931 or SS7 ISUP messages between IP nodes such as a Signaling Gateway and Media Gateway Controller or Media Gateway. Examples of such transport include: - transport of signaling between a Signaling Gateway and Media Gateway or Media Gateway Controller - transport of signaling ("backhaul") from a Media Gateway to a Media Gateway Controller - transport of TCAP between a Signaling Gateway and other IP nodes Applications include: - Internet dial-up remote access - IP telephony interworking with PSTN - Other services as identified Specific goals are: 1. Architecture and Performance Requirements: The working group will produce an informational RFC identifying functionality and performance requirements to support signaling over IP. Signaling messages have very stringent loss and delay requirements in the existing telephone networks that need to be supported. 2- Transport: The working group will produce a standards track proposal or proposals defining transport of signaling protocols using SCTP, based on the requirements identified above. These proposals will identify the method of encapsulation of different signaling protocols. This will include differentiating between different protocols being carried, and what components are transported, translated or terminated at the SG. Security and resilience must be addressed. Note: TCAP is a transaction protocol with different functions and requirements than call control signaling. This will need to be taken into account in its mapping to IP networks. This work will be done in conjunction with other IETF working groups looking at similar issues. The working group will also ensure that good information conduits exist with groups in other standards groups with expertise in the relevant signaling protocols or in the network requirements for the transport of the relevant signaling protocols. The group will make use of existing IETF QoS and security technology and will not address creation of new QoS or security functions for IP networks. Nor will the working group work on defining new call control or device control protocols. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2005 Nov 2006 SUA Implementor's guide SIP for Instant Messaging and Presence Leveraging Extensions (simple) --------------------------------------------------------------------- Charter Last Modified: 2006-03-24 Current Status: Active Working Group Chair(s): Robert Sparks Hisham Khartabil Real-time Applications and Infrastructure Area Director(s): Jon Peterson Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Jon Peterson 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 Presence and 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. The primary work of this group will be to generate: 1. A proposed standard SIP extension documenting the transport of Instant Messages in SIP, compliant to the requirements for IM outlined in RFC 2779, CPIM and in BCP 41 (so that the transport implications of the extension with respect to network congestion are considered in the design). 2. A proposed standard SIP event package and any related protocol mechanisms used to support presence, compliant to the requirements for presence outlined in RFC 2779 and CPIM. 3. An architecture for the implementation of a traditional buddylist-based instant messaging and presence application with SIP. Included might be new mechanisms for message confirmation delivery, indications for when a party is in the process of typing a message, secure buddylist manipulation operations, and the extension of the CPIM presence format to describe typical IM states. Each of these mechanisms will be consistent with a SIP-based architecture, as well as meeting the constraints otherwise described in this charter. All SIMPLE proposals fulfilling these goals must document the mappings of their operation to CPIM. 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. 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. The working group will operate in close cooperation with the IMPP working group, which will be completing CPIM in parallel. The working group will also cooperate with any other groups defined to standardize other presence and IM systems, to ensure maximum sharing of information and avoid reinvention of the wheel. The working group will cooperate with the SIP working group, soliciting reviews to ensure its extensions meet SIPs requirements. The working group will also collaborate with the SIP WG to ensure consistent operation of the SUBSCRIBE and NOTIFY methods across the other applications being defined for its use. 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 Presence and 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. The primary work of this group will be to generate: 1. A proposed standard SIP extension documenting the transport of Instant Messages in SIP, compliant to the requirements for IM outlined in RFC 2779, CPIM and in BCP 41 (so that the transport implications of the extension with respect to network congestion are considered in the design). 2. A proposed standard SIP event package and any related protocol mechanisms used to support presence, compliant to the requirements for presence outlined in RFC 2779 and CPIM. 3. An architecture for the implementation of a traditional buddylist-based instant messaging and presence application with SIP. Included might be new mechanisms for message confirmation delivery, indications for when a party is in the process of typing a message, secure buddylist manipulation operations, and the extension of the CPIM presence format to describe typical IM states. Each of these mechanisms will be consistent with a SIP-based architecture, as well as meeting the constraints otherwise described in this charter. All SIMPLE proposals fulfilling these goals must document the mappings of their operation to CPIM. 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. 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. The working group will operate in close cooperation with the IMPP working group, which will be completing CPIM in parallel. The working group will also cooperate with any other groups defined to standardize other presence and IM systems, to ensure maximum sharing of information and avoid reinvention of the wheel. The working group will cooperate with the SIP working group, soliciting reviews to ensure its extensions meet SIPs requirements. The working group will also collaborate with the SIP WG to ensure consistent operation of the SUBSCRIBE and NOTIFY methods across the other applications being defined for its use. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- May 2003 Feb 2007 The Message Session Relay Protocol Jun 2003 Oct 2006 The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Jun 2003 Feb 2005 Extensible Markup Language (XML) Formats for Representing Resource Lists Sep 2003 Feb 2007 Session Initiation Protocol (SIP) extension for Partial Notification of Presence Information Jan 2004 Nov 2006 Presence Information Data format (PIDF) Extension for Partial Presence Feb 2004 Jul 2006 Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF) May 2004 Mar 2007 Presence Authorization Rules May 2004 Oct 2004 An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents May 2004 Dec 2006 Relay Extensions for the Message Sessions Relay Protocol (MSRP) Oct 2004 Feb 2007 Publication of Partial Presence Information Feb 2005 Mar 2007 An Extensible Markup Language (XML) Document Format for Indicating A Change in XML Configuration Access Protocol (XCAP) Resources Nov 2005 Mar 2006 An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors May 2006 Feb 2007 Instant Message Disposition Notification Feb 2007 Feb 2007 Problem Statement for SIP/SIMPLE Session Initiation Protocol (sip) --------------------------------- Charter Last Modified: 2007-02-28 Current Status: Active Working Group Chair(s): Dean Willis Keith Drage Real-time Applications and Infrastructure Area Director(s): Jon Peterson Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Cullen Jennings Technical Advisor(s): Dan Romascanu Mailing Lists: General Discussion:sip@ietf.org To Subscribe: sip-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/sip/index.html Description of Working Group: The Session Initiation Protocol (SIP) working group is chartered to maintain and continue the development of SIP, currently specified as proposed standard RFC 3261, and its family of extensions. SIP is a text-based protocol, similar to HTTP and SMTP, for initiating interactive communication sessions between users. Such sessions include voice, video, chat, interactive games, and virtual reality. The main tasks of the group involve bringing SIP from proposed to draft standard and specifying and developing proposed extensions that arise out of strong requirements. The SIP working group will concentrate on the specification of SIP and its extensions, and will not explore the use of SIP for specific environments or applications. It will, however respond to general- purpose requirements for changes to SIP provided by other working groups, including the SIPPING working group, when those requirements are within the scope and charter of SIP. The process and requirements for such extensions are documented in RFC 3427, "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. Standards-track extensions and new features must be generally applicable, and not applicable only to a specific set of session types. 3. Simplicity is key. 4. Reuse of existing Internet protocols and architectures and integrating with other Internet applications is crucial. The primary source of change requirements to be considered by the SIP Working Group is the SIPPING working group, which analyzes the requirements for application of SIP to several different tasks, including the tasks of standards-development organizations that are developing systems based on SIP and that may require changes or extensions thereto. Additional requirements are produced by the other IETF working groups that are using SIP, including the SIMPLE WG (which is using SIP for messaging and presence) and the XCON working group (which is using SIP for centralized conferencing). In addition to extending SIP as required to address these externally- derived requirements, the deliverables of the group include assuring capable security and privacy mechanisms within SIP and increasing the stability of the SIP specification. Specific deliverables toward these goals include: 1. Mechanisms for secure expression of identity in requests and responses. 2. Mechanism to securely request services delivery by non-terminal elements ("end-to-middle"). 3. Guidelines for use of existing security mechanisms such as TLS, IPsec, and certificates. 4. Guidelines for the use of descriptive techniques such as SAML (Security Association Markup Language) with SIP. 5. Draft standard versions of SIP and critical supporting specifications. Other deliverables may be agreed upon as extensions are understood to be necessary. Prospective deliverables will be discussed with the Area Director before inclusion on agendas, and new proposed work must be approved via a charter update. Description of Working Group: The Session Initiation Protocol (SIP) working group is chartered to maintain and continue the development of SIP, currently specified as proposed standard RFC 3261, and its family of extensions. SIP is a text-based protocol, similar to HTTP and SMTP, for initiating interactive communication sessions between users. Such sessions include voice, video, chat, interactive games, and virtual reality. The main tasks of the group involve bringing SIP from proposed to draft standard and specifying and developing proposed extensions that arise out of strong requirements. The SIP working group will concentrate on the specification of SIP and its extensions, and will not explore the use of SIP for specific environments or applications. It will, however respond to general- purpose requirements for changes to SIP provided by other working groups, including the SIPPING working group, when those requirements are within the scope and charter of SIP. The process and requirements for such extensions are documented in RFC 3427, "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. Standards-track extensions and new features must be generally applicable, and not applicable only to a specific set of session types. 3. Simplicity is key. 4. Reuse of existing Internet protocols and architectures and integrating with other Internet applications is crucial. The primary source of change requirements to be considered by the SIP Working Group is the SIPPING working group, which analyzes the requirements for application of SIP to several different tasks, including the tasks of standards-development organizations that are developing systems based on SIP and that may require changes or extensions thereto. Additional requirements are produced by the other IETF working groups that are using SIP, including the SIMPLE WG (which is using SIP for messaging and presence) and the XCON working group (which is using SIP for centralized conferencing). In addition to extending SIP as required to address these externally- derived requirements, the deliverables of the group include assuring capable security and privacy mechanisms within SIP and increasing the stability of the SIP specification. Specific deliverables toward these goals include: 1. Mechanisms for secure expression of identity in requests and responses. 2. Mechanism to securely request services delivery by non-terminal elements ("end-to-middle"). 3. Guidelines for use of existing security mechanisms such as TLS, IPsec, and certificates. 4. Guidelines for the use of descriptive techniques such as SAML (Security Association Markup Language) with SIP. 5. Draft standard versions of SIP and critical supporting specifications. Other deliverables may be agreed upon as extensions are understood to be necessary. Prospective deliverables will be discussed with the Area Director before inclusion on agendas, and new proposed work must be approved via a charter update. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Mar 2000 Sep 2006 Management Information Base for the Session Initiation Protocol (SIP) Aug 2003 Oct 2006 Connection Reuse in the Session Initiation Protocol (SIP) Jan 2004 Mar 2007 Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP) Jun 2005 Feb 2007 Session Initiation Protocol Location Conveyance Jul 2005 Mar 2007 Managing Client Initiated Connections in the Session Initiation Protocol (SIP) Jul 2005 Mar 2007 End-to-middle Security in the Session Initiation Protocol (SIP) Dec 2005 Mar 2007 Requesting Answering Modes for the Session Initiation Protocol (SIP) Jan 2006 Mar 2007 Rejecting Anonymous Requests in the Session Initiation Protocol (SIP) Mar 2006 Oct 2006 Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies Apr 2006 Feb 2007 Connected Identity in the Session Initiation Protocol (SIP) May 2006 Mar 2007 Certificate Management Service for The Session Initiation Protocol (SIP) Jun 2006 Oct 2006 SIP SAML Profile and Binding Jun 2006 Mar 2007 A Hitchhiker's Guide to the Session Initiation Protocol (SIP) Sep 2006 Jan 2007 Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP) Sep 2006 Jan 2007 Referring to Multiple Resources in the Session Initiation Protocol (SIP) Sep 2006 Jan 2007 Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP) Sep 2006 Jan 2007 Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP) Sep 2006 Nov 2006 A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP) Oct 2006 Oct 2006 Extensions to the Session Initiation Protocol (SIP) User Agent Profile Delivery Change Notification Event Package for the Extensible Markup Language Language Configuration Access Protocol (XCAP) Oct 2006 Feb 2007 A Framework for Session Initiation Protocol (SIP) Session Policies Dec 2006 Mar 2007 Guidelines for the use of the SIPS URI Scheme in the Session Initiation Protocol (SIP) Jan 2007 Mar 2007 Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP) Session Initiation Proposal Investigation (sipping) --------------------------------------------------- Charter Last Modified: 2007-01-23 Current Status: Active Working Group Chair(s): Mary Barnes Gonzalo Camarillo Real-time Applications and Infrastructure Area Director(s): Jon Peterson Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Jon Peterson Secretary(ies): Oscar Novo Mailing Lists: General Discussion:sipping@ietf.org To Subscribe: sipping-request@ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/sipping/index.html Description of Working Group: The Session Initiation Protocol Project INvestiGation (SIPPING) working group is chartered to document the use of SIP for several applications related to telephony and multimedia, and to develop requirements for extensions to SIP needed for those applications. Such requirements will be referred to the SIP working group for development of any new SIP method, header, or option-tag as described in Change Policy for SIP (RFC 3427). Guiding principles for the performance of SIPPING's work will include: 1. Documenting the requirements of specific chartered tasks. 2. Documenting the usage of SIP to solve real problems that need to be solved in a standardized way. Examples of important topics identified are the session policy architecture, allowing network entities to convey policy into an User Agent's activity; requirements analysis for session border controllers to determine how best such devices can operate with SIP usage; guidance on IPv4-IPv6 co-existence support by SIP and SIP-supported media; and inclusion of real-time text conversation (ToIP), service invocations benefitting hearing and speech impaired users, and other SIP equal access services as requirements are proposed. 3. Looking for commonalities among the chartered tasks and ongoing SIP-related development, as commonalities may indicate for general, reusable functionality in SIP. 4. Describing the requirements for any extension determined to pass there hurdles, and handing the development task to the SIP WG. 5. Developing procedures and requirements for configuration and delivery of SIP User Profiles Besides performing needed specification of several applications of SIP, SIPPING can be seen as also working out use cases that clarify the role of SIP in the Internet, and help to ensure that Occam's razor is appropriately applied to SIP usage. The security of all the deliverables will be of special importance. The technology for security will be keyed from the SIP Security specification within RFC 3261, and additional SIP specifications as they apply. Description of Working Group: The Session Initiation Protocol Project INvestiGation (SIPPING) working group is chartered to document the use of SIP for several applications related to telephony and multimedia, and to develop requirements for extensions to SIP needed for those applications. Such requirements will be referred to the SIP working group for development of any new SIP method, header, or option-tag as described in Change Policy for SIP (RFC 3427). Guiding principles for the performance of SIPPING's work will include: 1. Documenting the requirements of specific chartered tasks. 2. Documenting the usage of SIP to solve real problems that need to be solved in a standardized way. Examples of important topics identified are the session policy architecture, allowing network entities to convey policy into an User Agent's activity; requirements analysis for session border controllers to determine how best such devices can operate with SIP usage; guidance on IPv4-IPv6 co-existence support by SIP and SIP-supported media; and inclusion of real-time text conversation (ToIP), service invocations benefitting hearing and speech impaired users, and other SIP equal access services as requirements are proposed. 3. Looking for commonalities among the chartered tasks and ongoing SIP-related development, as commonalities may indicate for general, reusable functionality in SIP. 4. Describing the requirements for any extension determined to pass there hurdles, and handing the development task to the SIP WG. 5. Developing procedures and requirements for configuration and delivery of SIP User Profiles Besides performing needed specification of several applications of SIP, SIPPING can be seen as also working out use cases that clarify the role of SIP in the Internet, and help to ensure that Occam's razor is appropriately applied to SIP usage. The security of all the deliverables will be of special importance. The technology for security will be keyed from the SIP Security specification within RFC 3261, and additional SIP specifications as they apply. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2002 Jan 2007 Session Initiation Protocol Service Examples Mar 2002 Mar 2007 A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP) Jun 2002 Mar 2007 Best Current Practices for NAT Traversal for SIP Oct 2002 Oct 2006 Session Initiation Protocol Call Control - Transfer Mar 2003 Mar 2007 A Framework for Session Initiation Protocol User Agent Profile Delivery Oct 2003 Jul 2005 A Framework for Application Interaction in the Session Initiation Protocol (SIP) Feb 2004 Dec 2006 Framework for Transcoding with the Session Initiation Protocol (SIP) Jul 2004 Sep 2006 Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services Oct 2004 Aug 2006 Framework for real-time text over IP using the Session Initiation Protocol (SIP) Feb 2005 Feb 2007 The Session Initiation Protocol (SIP) and Spam Jun 2005 Jun 2006 The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model Jul 2005 Sep 2006 IPv6 Transition in the Session Initiation Protocol (SIP) Oct 2005 Oct 2006 Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs) Oct 2005 Mar 2007 A User Agent Profile Data Set for Media Policy Nov 2005 Feb 2007 Multiple Dialog Usages in the Session Initiation Protocol Dec 2005 Feb 2006 Session Initiation Protocol Package for Voice Quality Reporting Event Feb 2006 Dec 2006 Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists Apr 2006 Feb 2007 A Session Initiation Protocol (SIP) Event Package for Session-Specific Session Policies. Sep 2006 Nov 2006 The Session Initiation Protocol (SIP) Pending Additions Event Package Sep 2006 Nov 2006 A Document Format for Requesting Consent Nov 2006 Feb 2007 Requirements from SIP (Session Initiation Protocol) Session Border Control Deployments Nov 2006 Nov 2006 Requirements for Management of Overload in the Session Initiation Protocol Nov 2006 Mar 2007 Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6) Dec 2006 Dec 2006 SIP (Session Initiation Protocol) Usage of Offer/Answer Model Dec 2006 Mar 2007 Examples call flow in race condition on Session Initiation Protocol S/MIME Mail Security (smime) ---------------------------- Charter Last Modified: 2005-10-03 Current Status: Active Working Group Chair(s): Sean Turner Blake Ramsdell Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Russ Housley Mailing Lists: General Discussion:ietf-smime@imc.org To Subscribe: ietf-smime-request@imc.org Archive: http://www.imc.org/ietf-smime/ 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 ------ ------- -------------------------------------------- Dec 1999 Jan 2003 CMS Symmetric Key Management and Distribution Mar 2006 Jan 2007 ESS Update: Adding CertID Algorithm Agility Apr 2006 Feb 2007 Cryptographic Message Syntax (CMS) Multiple Signer Clarification Jun 2006 Mar 2007 Identity-based Encryption Architecture Jun 2006 Mar 2007 Using the Boneh-Franklin and Boneh-Boyen identity-based encryption algorithms with the Cryptographic Message Syntax (CMS) Dec 2006 Dec 2006 Multiple Signatures in S/MIME Jan 2007 Feb 2007 Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type Jan 2007 Jan 2007 Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS) Softwires (softwire) -------------------- Charter Last Modified: 2006-02-22 Current Status: Active Working Group Chair(s): David Ward Alain Durand Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Mark Townsley 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/index.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 (financial or political), native IPv4 and/or IPv6 transport may not be available in all cases, and there is need to tunnel IPv4 in IPv6 or IPv6 in IPv4 to cross a part of the network which is not IPv4 or IPv6 capable. Configured tunnels or softwires are suited for the inter-networking job. Non-interoperable tunneling mechanisms have been developed based on the RFC3053 tunnel broker concept, and in addition, standardized mechanisms like RFC2893, RFC2473, GRE, L2TP, etc. have been used in some scenarios. Other deployments use non-standardized, incomplete solutions. The lack of interoperable and/or standardized solution in that space has been noted in the v6ops WG scenario analysis. The focus of this WG is to define a softwire setup negotiation protocol and encapsulation to be used between a node and the corresponding softwire end-point. Softwire configuration includes two phases: softwire end point discovery and softwire set-up. The WG will attempt to reuse existing technologies as much as possible and if necessary, create additional building blocks. It is expected that existing encapsulations will be the starting point. In the softwire set-up phase, the initator and the ISP negotiate the parameters necessary to establish the softwire. Those include: - The encapsulation type: IPv4-over-IPv6 or IPv6-over-IPv4 with a possible intermediary layer (e.g. UDP). This encapsulation negotiation should be extensible to cover future methods of both unicast and multicast traffic. - How to obtain the IP addresses to use for the softwire end-points. This could be done with an out-of-band mechanism or directly negotiated at set-up phase. In the softwire end point discovery phase, the initiator gets a name or an IP address for the ISP-side end point of the softwire to establish. This phase is orthogonal to the set-up one. The initial milestone for this working group will be the set-up phase. This WG is not chartered to work on the discovery phase and a re- charter will be needed prior to undertaking such work; once the base work has been completed (or is well under way), WG may consider re-chartering to address discovery. The WG will reuse existing technologies as much as possible and will create additional building blocks when necessary. The WG is chartered to complete the following work items: 1. Document problem statement and submit to IESG as Informational. If this problem statement cannot be written within the IETF process of rough concensus, then the following items will not be advanced. 2. Document softwire encapsulation and control protocol usage for IPv4-over-IPv6 or IPv6-over-IPv4 with possible intermediary layer and submit the specification to the IESG for publication as a Proposed Standard. 3. Develop the softwire MIB module and submit it to the IESG for publication as a Proposed Standard. 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 (financial or political), native IPv4 and/or IPv6 transport may not be available in all cases, and there is need to tunnel IPv4 in IPv6 or IPv6 in IPv4 to cross a part of the network which is not IPv4 or IPv6 capable. Configured tunnels or softwires are suited for the inter-networking job. Non-interoperable tunneling mechanisms have been developed based on the RFC3053 tunnel broker concept, and in addition, standardized mechanisms like RFC2893, RFC2473, GRE, L2TP, etc. have been used in some scenarios. Other deployments use non-standardized, incomplete solutions. The lack of interoperable and/or standardized solution in that space has been noted in the v6ops WG scenario analysis. The focus of this WG is to define a softwire setup negotiation protocol and encapsulation to be used between a node and the corresponding softwire end-point. Softwire configuration includes two phases: softwire end point discovery and softwire set-up. The WG will attempt to reuse existing technologies as much as possible and if necessary, create additional building blocks. It is expected that existing encapsulations will be the starting point. In the softwire set-up phase, the initator and the ISP negotiate the parameters necessary to establish the softwire. Those include: - The encapsulation type: IPv4-over-IPv6 or IPv6-over-IPv4 with a possible intermediary layer (e.g. UDP). This encapsulation negotiation should be extensible to cover future methods of both unicast and multicast traffic. - How to obtain the IP addresses to use for the softwire end-points. This could be done with an out-of-band mechanism or directly negotiated at set-up phase. In the softwire end point discovery phase, the initiator gets a name or an IP address for the ISP-side end point of the softwire to establish. This phase is orthogonal to the set-up one. The initial milestone for this working group will be the set-up phase. This WG is not chartered to work on the discovery phase and a re- charter will be needed prior to undertaking such work; once the base work has been completed (or is well under way), WG may consider re-chartering to address discovery. The WG will reuse existing technologies as much as possible and will create additional building blocks when necessary. The WG is chartered to complete the following work items: 1. Document problem statement and submit to IESG as Informational. If this problem statement cannot be written within the IETF process of rough concensus, then the following items will not be advanced. 2. Document softwire encapsulation and control protocol usage for IPv4-over-IPv6 or IPv6-over-IPv4 with possible intermediary layer and submit the specification to the IESG for publication as a Proposed Standard. 3. Develop the softwire MIB module and submit it to the IESG for publication as a Proposed Standard. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Dec 2005 May 2006 Softwire Problem Statement Jun 2006 Feb 2007 Softwires Hub & Spoke Deployment Framework with L2TPv2 Jun 2006 Mar 2007 Softwire Security Analysis and Requirements Speech Services Control (speechsc) ---------------------------------- Charter Last Modified: 2006-08-22 Current Status: Active Working Group Chair(s): David Oran Eric Burger Real-time Applications and Infrastructure Area Director(s): Jon Peterson Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Jon Peterson 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 Mar 2007 Media Resource Control Protocol Version 2 (MRCPv2) Session PEERing for Multimedia INTerconnect (speermint) ------------------------------------------------------- Charter Last Modified: 2006-03-24 Current Status: Active Working Group Chair(s): Dave Meyer Jason Livingood Real-time Applications and Infrastructure Area Director(s): Jon Peterson Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Jon Peterson 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 ------ ------- -------------------------------------------- May 2006 Sep 2006 SPEERMINT Terminology Jun 2006 Oct 2006 SPEERMINT Requirements for SIP-based VoIP Interconnection Aug 2006 Oct 2006 SPEERMINT Peering Architecture Sep 2006 Sep 2006 SPEERMINT Routing Architecture Message Flows Oct 2006 Nov 2006 Use of DNS SRV and NAPTR Records for SPEERMINT Feb 2007 Feb 2007 Presence & IM Use Cases Mar 2007 Mar 2007 VoIP SIP Peering Use Cases Security Issues in Network Event Logging (syslog) ------------------------------------------------- Charter Last Modified: 2007-02-20 Current Status: Active Working Group Chair(s): David Harrington Chris Lonvick Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Sam Hartman Mailing Lists: General Discussion:syslog@ietf.org To Subscribe: syslog-request@ietf.org In Body: in body: (un)subscribe Archive: http://www1.ietf.org/mail-archive/web/syslog/current/index.html Description of Working Group: Syslog is a de-facto standard for logging system events. However, the protocol component of this event logging system has not been formally documented. While the protocol has been very useful and scalable, it has some known security problems which were documented in the INFORMATIONAL RFC 3164. The goal of this working group is to address the security and integrity problems, and to standardize the syslog protocol, transport, and a select set of mechanisms in a manner that considers the ease of migration between and the co-existence of existing versions and the standard. Reviews have shown that there are very few similarities between the message formats generated by heterogeneous systems. In fact, the only consistent commonality between messages is that all of them contain the at the start. Additional testing has shown that as long as the is present in a syslog message, all tested receivers will accept any generated message as a valid syslog message. In designing a standard syslog message format, this Working Group will retain the at the start of the message and will introduce protocol versioning. Along these same lines, many different charsets have been used in syslog messages observed in the wild but no indication of the charset has been given in any message. The Working Group also feels that multiple charsets will not be beneficial to the community; much code would be needed to distinguish and interpret different charsets. For compatibility with existing implementations, the Working Group will allow that messages may still be sent that do not indicate the charset used. However, the Working Group will recommend that messages contain a way to identify the charset used for the message, and will also recommend a single default charset. syslog has traditionally been transported over UDP and this WG has already defined RFC 3195 for the reliable transport for the syslog messages. The WG will separate the UDP transport from the protocol so that others may define additional transports in the future. The threats that this WG will primarily address are modification, disclosure, and masquerading. A secondary threat is message stream modification. Threats that will not be addressed by this WG are DoS and traffic analysis. The primary attacks may be thwarted by a secure transport. However, it must be remembered that a great deal of the success of syslog has been attributed to its ease of implementation and relatively low maintenance level. The Working Group will consider those factors, as well as current implementations, when deciding upon a secure transport. The secondary threat of message stream modification can be addressed by a mechanism that will verify the end-to-end integrity and sequence of messages. The Working Group feels that these aspects may be addressed by a dissociated signature upon sent messages. - A document will be produced that describes a standardized syslog protocol. A mechanism will also be defined in this document that will provide a means to convey structured data. - A document will be produced that describes a standardized UDP transport for syslog. - A document will be produced that requires a secure transport for the delivery of syslog messages. - A document will be produced to describe the MIB for syslog entities. - A document will be produced that describes a standardized mechanism to sign syslog messages to provide integrity checking and source authentication. Description of Working Group: Syslog is a de-facto standard for logging system events. However, the protocol component of this event logging system has not been formally documented. While the protocol has been very useful and scalable, it has some known security problems which were documented in the INFORMATIONAL RFC 3164. The goal of this working group is to address the security and integrity problems, and to standardize the syslog protocol, transport, and a select set of mechanisms in a manner that considers the ease of migration between and the co-existence of existing versions and the standard. Reviews have shown that there are very few similarities between the message formats generated by heterogeneous systems. In fact, the only consistent commonality between messages is that all of them contain the at the start. Additional testing has shown that as long as the is present in a syslog message, all tested receivers will accept any generated message as a valid syslog message. In designing a standard syslog message format, this Working Group will retain the at the start of the message and will introduce protocol versioning. Along these same lines, many different charsets have been used in syslog messages observed in the wild but no indication of the charset has been given in any message. The Working Group also feels that multiple charsets will not be beneficial to the community; much code would be needed to distinguish and interpret different charsets. For compatibility with existing implementations, the Working Group will allow that messages may still be sent that do not indicate the charset used. However, the Working Group will recommend that messages contain a way to identify the charset used for the message, and will also recommend a single default charset. syslog has traditionally been transported over UDP and this WG has already defined RFC 3195 for the reliable transport for the syslog messages. The WG will separate the UDP transport from the protocol so that others may define additional transports in the future. The threats that this WG will primarily address are modification, disclosure, and masquerading. A secondary threat is message stream modification. Threats that will not be addressed by this WG are DoS and traffic analysis. The primary attacks may be thwarted by a secure transport. However, it must be remembered that a great deal of the success of syslog has been attributed to its ease of implementation and relatively low maintenance level. The Working Group will consider those factors, as well as current implementations, when deciding upon a secure transport. The secondary threat of message stream modification can be addressed by a mechanism that will verify the end-to-end integrity and sequence of messages. The Working Group feels that these aspects may be addressed by a dissociated signature upon sent messages. - A document will be produced that describes a standardized syslog protocol. A mechanism will also be defined in this document that will provide a means to convey structured data. - A document will be produced that describes a standardized UDP transport for syslog. - A document will be produced that requires a secure transport for the delivery of syslog messages. - A document will be produced to describe the MIB for syslog entities. - A document will be produced that describes a standardized mechanism to sign syslog messages to provide integrity checking and source authentication. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jan 2001 Dec 2006 Signed syslog Messages Nov 2001 Mar 2007 Syslog Management Information Base Dec 2003 Nov 2006 The syslog Protocol Mar 2004 Nov 2006 Transmission of syslog messages over UDP Mar 2006 Dec 2006 TLS Transport Mapping for Syslog TCP Maintenance and Minor Extensions (tcpm) ------------------------------------------- Charter Last Modified: 2006-08-08 Current Status: Active Working Group Chair(s): Ted Faber Mark Allman 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 Feb 2007 Improving TCP's Robustness to Blind In-Window Attacks Feb 2005 Feb 2007 Defending TCP Against Spoofing Attacks May 2005 Mar 2007 TCP User Timeout Option Jan 2006 Oct 2006 Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets Jan 2006 Feb 2007 TCP Congestion Control Feb 2006 Jan 2007 TCP's Reaction to Soft Errors Feb 2006 Oct 2006 ICMP attacks against TCP Jul 2006 Mar 2007 TCP SYN Flooding Attacks and Common Mitigations Transport Layer Security (tls) ------------------------------ Charter Last Modified: 2006-04-17 Current Status: Active Working Group Chair(s): Eric Rescorla Pasi Eronen Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Russ Housley Technical Advisor(s): Allison Mankin Mailing Lists: General Discussion:tls@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/tls Archive: http://www.ietf.org/mail-archive/web/tls/current/index.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 ------ ------- -------------------------------------------- Mar 2001 Dec 2006 Using SRP for TLS Authentication Jan 2002 Aug 2006 Using OpenPGP keys for TLS authentication Mar 2006 Mar 2007 The TLS Protocol Version 1.2 Oct 2006 Oct 2006 Clientside interoperability experiences for the SSL and TLS protocols Transparent Interconnection of Lots of Links (trill) ---------------------------------------------------- Charter Last Modified: 2006-10-11 Current Status: Active Working Group Chair(s): Erik Nordmark Donald Eastlake 3rd Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Mark Townsley 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 Mar 2007 RBridges: Base Protocol Specification Jun 2006 Oct 2006 Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement Sep 2006 Mar 2007 The Architecture of an RBridge Solution to TRILL Sep 2006 Feb 2007 TRILL Routing Requirements in Support of RBridges Transport Area Working Group (tsvwg) ------------------------------------ Charter Last Modified: 2006-12-15 Current Status: Active Working Group Chair(s): James Polk Magnus Westerlund Lars Eggert 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 ------ ------- -------------------------------------------- May 2001 Feb 2007 Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration Jun 2001 Dec 2006 Sockets API Extensions for Stream Control Transmission Protocol (SCTP) Feb 2002 Mar 2007 TCP Extended Statistics MIB Jun 2005 Feb 2007 Authenticated Chunks for Stream Control Transmission Protocol (SCTP) Jul 2005 Sep 2006 Aggregation of RSVP Reservations over MPLS TE/DS-TE Tunnels Jan 2006 Oct 2006 Security Attacks Found Against SCTP and Current Countermeasures Feb 2006 Feb 2007 QoS Signaling in a Nested Virtual Private Network Mar 2006 Feb 2007 Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations Jun 2006 Oct 2006 Padding Chunk and Parameter for SCTP Jun 2006 Mar 2007 Aggregation of DiffServ Service Classes Oct 2006 Mar 2007 Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services Dec 2006 Dec 2006 An EF DSCP for Capacity-Admitted Traffic Feb 2007 Feb 2007 RSVP Extensions for Path-Triggered RSVP Receiver Proxy Feb 2007 Feb 2007 RSVP Proxy Approaches Mar 2007 Mar 2007 Specifying New Congestion Control Algorithms Mar 2007 Mar 2007 Explicit Congestion Marking in MPLS Usenet Article Standard Update (usefor) --------------------------------------- Charter Last Modified: 2007-02-13 Current Status: Active Working Group Chair(s): Harald Alvestrand Alexey Melnikov Applications Area Director(s): Ted Hardie Lisa Dusseault Applications Area Advisor: Lisa Dusseault Editor(s): Charles Lindsey Ken Murchison Mailing Lists: General Discussion:ietf-usefor@imc.org To Subscribe: ietf-usefor-request@imc.org In Body: 'subscribe' in the body of the message Archive: http://www.imc.org/ietf-usefor/index.html Description of Working Group: Note: A charter rewrite/update is underway. Motivation The Standard for Interchange of USENET Messages, defined in RFC 1036, was released in December 1987. This RFC defines the format that format that all usenet articles must follow (similar to the way RFC 822 does for email) and also covers the algorithm that is used to distribute usenet articles. Since that time there has been no official update published despite the rapid growth in Usenet and other networks that use the RFC 1036 article format. A draft update to RFC 1036 ( "Son of RFC 1036" ) was released by Henry Spencer in June 1994 but this was not further pursued and is now itself out of date. Currently a combination of this and RFC 1036 are regarded as the de-facto standard. At the present time an urgent need has been identified to formalize and document many of the current and proposed extensions to the Usenet Article format. Many extensions are only vaguely documented and have competing and overlapping alternatives. A draft update to RFC 1036 ( "Son of RFC 1036" ) was released by Henry Spencer in June 1994 but this was not further pursued and is now itself out of date. Currently a combination of this and RFC 1036 are regarded as the de-facto standard. At the present time an urgent need has been identified to formalize and document many of the current and proposed extensions to the Usenet Article format. Many extensions are only vaguely documented and have competing and overlapping alternatives. In particular the following areas need urgent attention: - Standards for the signing of articles (sign-control and PGP-MOOSE) - Authentication of cancels. - Use of non-ASCII character sets in article headers and bodies - Standardization of article bodies and the use of MIME in articles. - Standardization and extension of 3rd party control messages affecting articles (NOCEM) - General revision of various limits (eg article size) listed in previous standards. and many other aspects of the standards need reviewing. Description The Goal of this working group is to publish a standards-track successor to RFC 1036 that with particular attention to backward compatibility, formalizes best current practice and best proposed practice. The Group shall also aid and/or oversee the production of other Usenet related Internet Drafts and Standards. The Working Group shall: 1. Produce an Internet Draft (or series of drafts) that describes the core standards for a Usenet article and the features that all Usenet software should take account of. 2. Produce a group of Internet Drafts formally describing extensions to the core standard for a Usenet article (see above). 3. Produce a further Internet Draft that incorporates the core standard for a Usenet article (see 1) plus all those extensions (see 2) that the working group believe should become part of a final standard. 4. Publish a standards-track successor to RFC 1036 that formalizes best current practice and best proposed practice. 5. Publish any other extensions to the Usenet Article Standard that warrant being formal extensions but are outside the scope of the main standard. Description of Working Group: Note: A charter rewrite/update is underway. Motivation The Standard for Interchange of USENET Messages, defined in RFC 1036, was released in December 1987. This RFC defines the format that format that all usenet articles must follow (similar to the way RFC 822 does for email) and also covers the algorithm that is used to distribute usenet articles. Since that time there has been no official update published despite the rapid growth in Usenet and other networks that use the RFC 1036 article format. A draft update to RFC 1036 ( "Son of RFC 1036" ) was released by Henry Spencer in June 1994 but this was not further pursued and is now itself out of date. Currently a combination of this and RFC 1036 are regarded as the de-facto standard. At the present time an urgent need has been identified to formalize and document many of the current and proposed extensions to the Usenet Article format. Many extensions are only vaguely documented and have competing and overlapping alternatives. A draft update to RFC 1036 ( "Son of RFC 1036" ) was released by Henry Spencer in June 1994 but this was not further pursued and is now itself out of date. Currently a combination of this and RFC 1036 are regarded as the de-facto standard. At the present time an urgent need has been identified to formalize and document many of the current and proposed extensions to the Usenet Article format. Many extensions are only vaguely documented and have competing and overlapping alternatives. In particular the following areas need urgent attention: - Standards for the signing of articles (sign-control and PGP-MOOSE) - Authentication of cancels. - Use of non-ASCII character sets in article headers and bodies - Standardization of article bodies and the use of MIME in articles. - Standardization and extension of 3rd party control messages affecting articles (NOCEM) - General revision of various limits (eg article size) listed in previous standards. and many other aspects of the standards need reviewing. Description The Goal of this working group is to publish a standards-track successor to RFC 1036 that with particular attention to backward compatibility, formalizes best current practice and best proposed practice. The Group shall also aid and/or oversee the production of other Usenet related Internet Drafts and Standards. The Working Group shall: 1. Produce an Internet Draft (or series of drafts) that describes the core standards for a Usenet article and the features that all Usenet software should take account of. 2. Produce a group of Internet Drafts formally describing extensions to the core standard for a Usenet article (see above). 3. Produce a further Internet Draft that incorporates the core standard for a Usenet article (see 1) plus all those extensions (see 2) that the working group believe should become part of a final standard. 4. Publish a standards-track successor to RFC 1036 that formalizes best current practice and best proposed practice. 5. Publish any other extensions to the Usenet Article Standard that warrant being formal extensions but are outside the scope of the main standard. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2004 Jan 2007 Netnews Article Format Aug 2004 Jan 2007 Netnews Architecture and Protocols IPv6 Operations (v6ops) ----------------------- Charter Last Modified: 2006-02-18 Current Status: Active Working Group Chair(s): Fred Baker Kurt Lindqvist Operations and Management Area Director(s): Dan Romascanu David Kessens Operations and Management Area Advisor: David Kessens 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 ------ ------- -------------------------------------------- Oct 2003 Jan 2006 IPv6 Neighbor Discovery On-Link Assumption Considered Harmful Sep 2004 Dec 2006 IPv6 Enterprise Network Analysis - IP Layer 3 Focus Mar 2005 Jan 2007 Local Network Protection for IPv6 May 2005 Oct 2006 IPv6 Transition/Co-existence Security Considerations Jul 2005 Jan 2007 Using IPsec to Secure IPv6-in-IPv4 Tunnels Apr 2006 Feb 2007 Recommendations for Filtering ICMPv6 Messages in Firewalls May 2006 Feb 2007 IPv6 Deployment Scenarios in 802.16 Networks Jun 2006 Mar 2007 IPv6 Unicast Address Assignment Considerations Jun 2006 Feb 2007 IPv6 Routing Policies Guidelines Jun 2006 Mar 2007 IPv6 Implications for Network Scanning Oct 2006 Oct 2006 IPv6 Campus Transition Scenario Description and Analysis Nov 2006 Feb 2007 Requirements for the address selection mechanisms Nov 2006 Nov 2006 Problem Statement of Default Address Selection in Multi-prefix Environment: Operational Issues of RFC3484 Default Rules Feb 2007 Feb 2007 Reasons to Move NAT-PT to Historic Status Virtual Router Redundancy Protocol (vrrp) ----------------------------------------- Charter Last Modified: 2006-10-26 Current Status: Active Working Group Chair(s): Radia Perlman Mukesh Gupta Routing Area Director(s): Ross Callon Bill Fenner Routing Area Advisor: Bill Fenner 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 ------ ------- -------------------------------------------- Oct 2001 Mar 2007 Virtual Router Redundancy Protocol for IPv6 Oct 2003 Dec 2006 Definitions of Managed Objects for the VRRP over IPv4 and IPv6 Widget Description Exchange Service (widex) ------------------------------------------- Charter Last Modified: 2006-06-15 Current Status: Active Working Group Chair(s): Dean Willis Applications Area Director(s): Ted Hardie Lisa Dusseault Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion:widex@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/widex Archive: http://www.ietf.org/mail-archive/web/widex/index.html Description of Working Group: With the Internet reaching out to more and more devices, people are increasingly expecting to have access to services at anytime, from anywhere and using any device. Such services are being developed using Web technologies such as XML and distributed across the network rather than resident on any one device. An example is a service to access flight arrival times, where the user interface expressed in XHTML is rendered on a client device, the application logic runs on a remote server and a technique as user interface remoting is used to keep the user interface synchronized with the application logic. What is currently lacking is a convenient means for continous fine grained synchronization rather than the one provided by a request/response protocol (e.g. HTTP) for Web pages, which occurs in between page loads. This would allow the user interface to reflect changes in application state and offer greater flexibility for applications to respond to user input events. The WiDeX (Widget Description Exchange Service) Working Group seeks to define a light weight mechanism used in an IP-based network for remoting user interfaces where the user interface is represented in XML, and synchronization involves XML DOM events and XML DOM mutation/update operations. The WG will strive to preserve an extensible architecture so that the work possibly be useful in the future with other types of descriptive user interfaces beyond those specifically considered by the group. Specific topics that are NOT goals of this WG are: - XML representation of user interface objects. - Means to establish sessions and support for device coordination. The WiDeX service definition will define: - A mechanism for synchronizing distributed XML DOM objects by propagating DOM mutations/updates and DOM events. - A set of parameters that need to be negotiated by a service discovery and session setup mechanism in order to start the UI remoting session. - A framework that enables a mechanism for remoting user interfaces represented in XML format by using distributed XML DOM synchronization, and a service discovery and session setup mechanism as building blocks. Deliverables: - Requirements document. - Document specifying the framework for remoting user interfaces represented in XML format. - Document specifying the message formats for XML DOM events and updates using XML in a way that is independent of the transport protocol. - Document(s) specifying normative binding(s) to at least one transport protocol. It is possible that work undertaken in other working groups and even other standards bodies (e.g. W3C) will be referenced by this working group. It is even possible that entire deliverables could be satisfied by the work of other working groups (e.g. discovery protocols). This working group will seek to maximize the use of existing specifications where applicable. Description of Working Group: With the Internet reaching out to more and more devices, people are increasingly expecting to have access to services at anytime, from anywhere and using any device. Such services are being developed using Web technologies such as XML and distributed across the network rather than resident on any one device. An example is a service to access flight arrival times, where the user interface expressed in XHTML is rendered on a client device, the application logic runs on a remote server and a technique as user interface remoting is used to keep the user interface synchronized with the application logic. What is currently lacking is a convenient means for continous fine grained synchronization rather than the one provided by a request/response protocol (e.g. HTTP) for Web pages, which occurs in between page loads. This would allow the user interface to reflect changes in application state and offer greater flexibility for applications to respond to user input events. The WiDeX (Widget Description Exchange Service) Working Group seeks to define a light weight mechanism used in an IP-based network for remoting user interfaces where the user interface is represented in XML, and synchronization involves XML DOM events and XML DOM mutation/update operations. The WG will strive to preserve an extensible architecture so that the work possibly be useful in the future with other types of descriptive user interfaces beyond those specifically considered by the group. Specific topics that are NOT goals of this WG are: - XML representation of user interface objects. - Means to establish sessions and support for device coordination. The WiDeX service definition will define: - A mechanism for synchronizing distributed XML DOM objects by propagating DOM mutations/updates and DOM events. - A set of parameters that need to be negotiated by a service discovery and session setup mechanism in order to start the UI remoting session. - A framework that enables a mechanism for remoting user interfaces represented in XML format by using distributed XML DOM synchronization, and a service discovery and session setup mechanism as building blocks. Deliverables: - Requirements document. - Document specifying the framework for remoting user interfaces represented in XML format. - Document specifying the message formats for XML DOM events and updates using XML in a way that is independent of the transport protocol. - Document(s) specifying normative binding(s) to at least one transport protocol. It is possible that work undertaken in other working groups and even other standards bodies (e.g. W3C) will be referenced by this working group. It is even possible that entire deliverables could be satisfied by the work of other working groups (e.g. discovery protocols). This working group will seek to maximize the use of existing specifications where applicable. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jan 2006 Jan 2007 Widget Description Exchange Service (WIDEX) Requirements Centralized Conferencing (xcon) ------------------------------- Charter Last Modified: 2006-03-24 Current Status: Active Working Group Chair(s): Adam Roach Alan Johnston Real-time Applications and Infrastructure Area Director(s): Jon Peterson Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Cullen Jennings Mailing Lists: General Discussion:xcon@ietf.org To Subscribe: https://www1.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 ------ ------- -------------------------------------------- May 2005 Jan 2007 A Framework and Data Model for Centralized Conferencing Dec 2005 Mar 2007 Connection Establishment in the Binary Floor Control Protocol (BFCP) Apr 2006 Mar 2007 Conference Information Data Model for Centralized Conferencing (XCON)