List of accepted nominations for IETF appointment to ISOC BoT
The procedure used by the Internet Architecture Board to select an individual to serve a three year term as a Trustee of the Internet Society is documented in RFC3677. The individuals who have accepted a nomination to be a candidate in this process are: - Fred Baker - Scott Bradner - John Klensin - Jordi Palet Martinez Comments on these candidates may be submitted to the IAB until the 18th March. The IAB will make a selection by March 25, 2005, and pass this selection to the Internet Engineering Steering Group for confirmation. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
New BOF in Internet Area - TRILL
Transparent Interconnection of Lots of Links BOF (trill) Thursday, March 10 at 1300-1500 === CHAIR: Erik Nordmark [EMAIL PROTECTED] AGENDA: - Welcome and Administrivia 5 minutes Chair - Charter review 10 minutes Chair - Problem statement discussion 30 minutes Erik Nordmark Including the service that a cloud of hybrid devices will provide, whether it is equivalent to IEEE 802.1D devices, or handles IP packets differently When is it ok to reorder packets? MTU considerations? - Threats and security considerations 10 minutes ??? What should the goal be? What can we do better? - Requirements on routing protocols 20 minutes ??? For zero configuration Carrying MAC addresses Broadcast IS-IS vs. OSPF vs. something else - Connecting different L2 types 30 minutes Radia Perlman - Choices for ARP/ND 10 minutes Joe Touch Constraints from security discussion (intentionally duplicate L2 addresses), mobility, SeND support, etc. - Choices for broadcast/multicast 10 minutes Joe Touch?? Worth doing any optimizations? Spanning tree between rbridges? Reading list: - Participants are encouraged to read draft-perlman-rbridge-01.txt to familiarize themselves with the problem space. There are also some papers available at the web page. DESCRIPTION: While IEEE 802 bridges are attractive due to not needing explicit configuration and allowing hosts to move within the bridged topology, they are more limited than IP routers since bridges only support IEEE 802 technologies, and the most common layer 2 interconnection method (dynamically created spanning tree formation using bridges) is not as flexible and robust as layer 3 routing. The WG will design a hybrid solution that combines the simplicity of configuration while taking full advantage of complex topologies. The design should have the following properties: - zero configuration of the hybrid devices - ability for hosts to move without changing their IP address - it should be possible to forward packets using pair-wise shortest paths, and exploit the redundant paths through the network for increased aggregate bandwidth - possible optimizations for ARP and Neighbor Discovery packets (potentially avoid flooding all the time) - support Secure Neighbor Discovery - the packet header should have a hop count for robustness in the presence of temporary routing loops - nodes should be able to have multiple attachments to the network - no delay when a new node is attached to the network - multicast should work (and after a re-charter it might make sense to look at optimizations for IP multicast) - be no less secure than existing bridges (and explore whether the protocol can make L2 address theft harder or easier to detect) A required piece of the solution is an IP routing protocol which is extended to carry L2 address reachability, handle broadcast, and is friendly to zero-configuration. Likely candidate are the link-state routing protocols since they can easily be extended to provide for broadcast, which is believed to be difficult for distance vector protocols. This working group will define the requirements on such routing protocol(s), and select the routing protocol(s) to be used. The intent is that the actual extensions to the routing protocol(s) be performed in the WGs with expertise in the routing protocol(s). The working group will look into solutions that can interconnect different layer 2 technologies, and also look at providing support for non-IP protocols, even though one can not combine those two features together; the interconnection of different layer 2 technologies (with different layer 2 address formats) will most likely only work for the IP family of protocols. Whether the same or different address formats are used, there might be a need to handle different MTUs. The WG will design a protocol that combines the benefits of bridges and routers in a way that will co-exist with existing hosts, IP routers and bridges. The design must support both IPv4 and IPv6 The working group will not work any layer 3 aspects except to provide - Possible optimizations for ARP and ND packets (not always flooded everywhere) - Being able to carry IP broadcast and multicast packets (which might just fall out from supporting L2 multicast) - Defining the L3 operations needed to interconnect different L2 technologies The work consists of several, separable pieces: - Defining the requirement on the routing protocol(s), and select one or more routing protocols. The detailed specification of the extensions to a particular routing protocol will be left as an action item for the specific routing protocol WG. - Defining what information must be carried in an encapsulation header for data packets, and how to map that information to various link types (e.g., IEEE LAN, Fibrechannel, MPLS) - Defining how address resolution (ARP and Neighbor Discovery) is performed, taking into account the
New BOF in Applications Area - SLRRP
Simple Lightweight RFID Reader Protocol BOF (slrrp) Tuesday, March 8 at 1300-1500 = CHAIRS: Scott Barvick [EMAIL PROTECTED] Marshall Rose [EMAIL PROTECTED] AGENDA: - Welcome and agenda bashing - Review of proposed WG history, mailing list activity, and progress update on SLRRP I-D - Discussion of proposed WG charter with goal of quantifying critical interest and achieving consensus on the WG charter - Milestone discussions with development of next steps and assignment of owners. - Remaining time will be devoted to technical discussion of SLRRP and development of open item list for further discussion on mailing list. DESCRIPTION: Radio Frequency Identification (RFID) is a technique whereby a device, known as an RFID 'reader', can remotely sense the presence of, and access embedded memory on, a transponder, known as a 'tag'. Tags may be affixed to objects as a means to track the location and movement of said objects within facilities equipped with readers. Tags may also include environmental sensors that may capture and report conditions to which the tag has been subjected. The tags can be stationary (attached to fixed locations in a facility) or mobile (attached to things moving about the facility). The readers can be stationary (attached to doors, walls, shelving, or scaffolding) or mobile (handheld, or vehicle- mounted). Recently, as a result of the development of standard RF (air) protocols and through the application of low-cost embedded computing technology, the implementation of RFID readers has evolved from peripherals, typically connected to a host computer via a serial port; to standalone devices supporting TCP/IP stacks, connected via wired (Ethernet) or wireless (802.11) LAN technology to enterprise computing resources supporting RFID-enabled client applications. We envision a typical RFID deployment comprising of a network of RFID readers controlled by one or more reader network controller elements (which may be software in a server, embedded software in a router/switch, or a standalone device). These controller elements in turn are connected to hosts/servers running client applications that ultimately consume the acquired tag data and management applications that monitor the operation of the reader network. This working group will specify a controller-to-reader protocol, the Simple Lightweight RFID Reader Protocol, or SLRRP (pronounced 'slurp') for use in an IP-based network to convey configuration, control, status, and tag information to and from readers. This will be the initial priority of the working group. In the future, the working group may specify a set of cooperating functions and possibly protocols that achieve the level of operations support and management expected of devices in today's IP network infrastructure. It is possible that work undertaken in other working groups and even other standards bodies (e.g. MIBs, discovery protocols) 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. SLRRP Interaction With Other Standards Bodies: There are currently two organizations that develop specifications for RFID air protocols, ISO and EPCGlobal. Because the IETF will not define a specific RFID air protocol, it is an appropriate venue for the development of an air protocol-independent framework for RFID reader communications and management. This is the goal of SLRRP. Because this working group seeks to develop operations and protocols based on RFID operations defined in publically available documents, there is no need for a formal liason between this working group and other organizations. Members of the working group are encouraged to participate in the other standards development forums so that the proper awareness of dependencies and cooperating functions can be maintained. Goals and Milestones: November 04 Post draft-krishna-slrrp-00.txt and draft working group charter (Complete) Jaunary 05 Post updates to draft-krishna-slrrp-00.txt (Complete) Febrary 05 Plan for BoF at 62nd IETF March05 BoF at 62nd IETF April05 Complete required charter actions Sept.05 Submit SLRRP to IESG as Proposed Standard Internet-Drafts: http://www.ietf.org/internet-drafts/draft-krishna-slrrp-01.txt Informational Links: http://www.iso.org http://www.epcglobalinc.org http://www.rfidjournal.com ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
New BOF in Applications Area - CALSIFY
Calendaring and Scheduling Simplification BOF (calsify) Thursday, March 10 at 1300-1500 === CHAIRS: Cyrus Daboo [EMAIL PROTECTED] RL 'Bob' Morgan [EMAIL PROTECTED] DESCRIPTION: Calendaring and Scheduling is currently defined in RFCs 2445, 2446 and 2447. These documents have been available for several years now, and a number of implementations exist. However, a number of interoperability problems exist between these implementations, some due to bugs in the specifications, some due to lack of clarity in the specifications and some due to under specification of key behaviors. As a result, interoperable calendaring and scheduling has not been truly achieved. The purpose of this BOF is to discuss revising RFCs 2445, 2446 and 2447 with the primary goal of achieving interoperability over the range of calendaring and scheduling tasks needed in real world situations. The goal of the BOF is to come up with a clear direction on how those revisions should be done, including the scope of changes. The desired outcome is a set of major charter points and milestones for a proposed IETF calsify working group. Input to this BOF will be a problem statement internet-draft draft-daboo-calsify-issues-00.txt that pulls together existing document errata, known problems with the specs and results from interoperability tests. In addition, draft-royer-ical-basic-01.txt provides one possible direction for revisions. AGENDA: - Introduction (blue sheets, scribe etc) (1 min) - Agenda Bashing (3 mins) - Introduction (6 mins) - Problem statement document (60 mins) - Possible Solutions (40 mins) - Next Steps/WG CHarter (10 mins) Total 120 mins Mailing list: [EMAIL PROTECTED] Subscriptions: mailto:[EMAIL PROTECTED] List archive: http://lists.osafoundation.org/pipermail/ietf-calsify ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
New BOF in Internet Area - TC
Tunneling Configuration BOF (tc) Monday, March 7 at 1530-1730 CHAIRS: Alain Durand [EMAIL PROTECTED] Thomas Narten [EMAIL PROTECTED] AGENDA: Problem space: - Administrativia (2 min) Alain Durand Thomas Narten - Problem statement (10 min) Thomas Narten - v6ops initial combine goals (10 min) Jordi draft-palet-v6tc-goals-tunneling-00.txt - Use of the configuration protocol outside of the context of IPv6 tunneling (10 min), TBD - NAT traversial issues (10 min) Florent Parent - Is Tunnel End point discovery required? (10 min) Alain Durand / Thomas Narten Solution space: - Existing protocol analysis (20 min) Florent Parent Pekka Savola draft-blanchet-t-v6ops-tunnelbroker-tsp-01.txt draft-parent-v6tc-protocol-exploration-01.txt - Tunnel end-point discovery analysis (10 min) Pekka Savola draft-palet-v6ops-tun-auto-disc-03.txt Open discussion (30 minutes) - Should we do something specific for IP in IP tunneling or something more generic that will work with any kind of encapsulation (GRE, MPLS,...) - Should this wg to be address the tunnel end point discovery part of the problem? - Should we cover the case of the set-up of a mesh of multiple tunnel ? DESCRIPTION === ISPs will likely deploy IPv6 incrementally, meaning that parts, rather than all of their networks will support native IPv6 service. They will need a way to provide IPv6 service to customers without requiring that native IPv6 service be provided on the access link. Automatic transition mechanisms like 6to4, teredo do not really leverage the infrastructure the ISP had put in place and offer little insight on how to gradually introduce native IPv6 in the access network. Configured tunnels are better suited for the job, and a number of deployments have been undertaken using the tunnel broker approach. However, the lack of standard on how to configure those tunnels remains a serious obstacle and manual configuration of all the parameters is a significant burden for typical customers. ISP assumptions: It is assumed that the ISP has upgraded its core network and has global IPv6 connectivity. It is also assumed that the ISP has obtained global address space (that it will delegate to its customers), either from an RIR or an upstream ISP. They key point is that the ISP does not (yet) provide native IPv6 access to all of its customers, but does want to provide an IPv6-over-IPv4 tunneling service. It is also assumed that large ISPs will have multiple POPs, and roaming customers will want to use a tunnel service topologically close to the current POP, rather than always using the same one. Access media assumptions: No assumptions are made on the access network. They will have high or low bandwidth, high or low latency, high or low access cost, and there will be more or less secure. Especially in the case of wireless access network, confidentiality of the data cannot always be guaranteed. Address spoofing may or may not be a problem. Although those environment vary widely, it is expected that a single configuration protocol with a number of options can be designed to accommodate all the different cases. Customer assumptions: Customers connecting with IPv6 to their ISP can have multiple configurations. The most common topologies expected to be encountered are: - a single node, directly attached to the ISP access network - a router, directly attached to the ISP access network - a router, behind an unmodifiable IPv4-only customer owned NAT The IPv4 addresses of the customer may change over time and be dynamically allocated. In the case of NAT environment, both the internal and the external addresses may be dynamically allocated. Another case to consider in the roaming user within its home ISP network. When the customer is roaming within the ISP network(s), this is not really different than having a dynamic IPv4 address, except that the nearest ISP tunnel end point to use may be different. When the customer is roaming in another ISP network that does not offer IPv6 service, the home ISP may be willing to still offer tunneling service, however the security implications and the tunnel end point discovery mechanism to use will be different. Work items: A generic tunnel setup protocol. The key requirement is to allow the creation of a tunnel for sending IPv6 over IPv4. In order to setup a tunnel, some negotiation may be needed in order to determine such properties as the encapsulation (e.g., GRE, IPv6-over-IPv4, etc.), MTU parameters, authentication and/or security properites, etc. For reasons of efficiency over very high latency networks, minimizing the number of packet exchanges is desirable. This group will not create new tunneling encapsulations. Moreover, it will reuse the work of other WGs rather than inventing unneeded mechanism. For example, IPsec can be used to create tunnels. The setup protocol
New BOF in Internet Area - ICOS
IP Configuration Security BOF (icos) Thursday, March 10 at 0900-1130 === CHAIRS: Bernard Aboba [EMAIL PROTECTED] Jari Arkko [EMAIL PROTECTED] AGENDA: Pleminaries: (5 minutes) - Minute Takers - Bluesheets IP Configuration Security Problem, Bernard Aboba (10 minutes) http://www.drizzle.com/~aboba/IETF62/icos.ppt Why do we care, TBD (10 minutes) EAP and its Applicability, Bernard Aboba (15 minutes) http://www.drizzle.com/~aboba/IETF62/icos.ppt http://www.ietf.org/rfc/rfc3748.txt http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-04.txt Overview of The MIPv6 Bootstrap Problem, James Kempf (15 minutes) http://www.ietf.org/internet-drafts/draft-ietf-mipv6-bootstrap-ps-01.txt http://www.ietf.org/internet-drafts/draft-giaretta-mip6-authorization-eap-02.txt http://www.ietf.org/internet-drafts/draft-chakrabarti-mip6-bmip-00.txt http://www.ietf.org/internet-drafts/draft-ietf-mipv6-ikev2-ipsec-00.txt (more documents in the reading list) Overview of DHCP Security, Mark Stapp/Ralph Droms (15 minutes) http://www.ietf.org/rfc/rfc3118.txt http://www.ietf.org/rfc/rfc3315.txt http://www.ietf.org/internet-drafts/draft-ietf-dhc-v4-threat-analysis-03.txt http://www.ietf.org/internet-drafts/draft-yegin-eap-boot-rfc3118-01.txt http://bgp.potaroo.net/ietf/all-ids/draft-ietf-dhc-auth-sigzero-00.txt http://www.drizzle.com/~aboba/IETF62/draft-stapp-dhc-eap-00.txt (To Be Provided) Overview of Secure Configuration in SEND, Jari Arkko (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-send-cga-06.txt http://www.ietf.org/internet-drafts/draft-ietf-send-ndopt-06.txt NSIS Secure Configuration Issues, Hannes Tschofenig (5 mins) http://www.tschofenig.com/drafts/draft-tschofenig-nsis-qos-ext-authz-00.txt Overview of Other IP Layer Needs, TBD (5 min) - Mobile IPv4 - PANA - IKEv2 Discussion and Wrapup (25 minutes)here are also some papers available at the web page. DESCRIPTION: Internet layer configuration is defined as the configuration required to support the operation of the Internet layer. This includes IP address configuration, default gateway(s), name server configuration, boot configuration (TFTP, NFS), service location and directory configuration, mobility configuration, and time server configuration (NTP). Configuration is typically performed insecurely today. For example, DHCP is rarely secured due to the need for keys to be set up between clients and servers. In other cases, such as in Mobile IPv6, tools for secure configuration exist and their use is required, but there are deployment barriers. As a result, Internet Area working groups are exploring alternative solutions. These include use of EAP for use for key derivation, and configuration. For example, the DHC WG has considered employment of EAP-derived keys for use with DHCP security, as defined in RFC 3118 and 3315. The MIPv6 WG, in investigating the bootstrapping problem, has considered proposals involving use of IKEv2 with EAP, as well as utilization of link layer EAP exchanges for configuration. The SEND working group defined a certificate-based authorization for routers, where hosts prefer a router that has a certificate traceable to a trusted root configured for the host. SEND also defined zero configuration mechanism for secure IP address configuration, based on Cryptographically Generated Addresses (CGAs). This BOF will provide an overview of Internet layer secure configuration needs, discussing the architectural issues and potential solutions under discussion. The purpose of the BOF is to discuss a common topic that touches several existing Working Groups, and it is not expected that a new working group will be formed as a result. Reading list: [RFC3118] Droms, R. and W. Arbaugh, Authentication for DHCP Messages, RFC 3118, June 2001. [RFC3315] Droms, R., Ed., Bound, J., Volz,, B., Lemon, T., Perkins, C. and M. Carney, Dynamic Host Configuration Protocol for IPv6 (DHCPv6), RFC 3315, July 2003. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Lefkowetz, Extensible Authentication Protocol (EAP), RFC 3748, June 2004. [RFC3736] Droms, R., Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6, RFC 3736, April 2004. [RFC3756] Nikander, P., Kempf, J. and E. Nordmark, IPv6 Neighbor Discovery (ND) Trust Models and Threats, RFC 3756, May 2004. [RFC3818] Schryver, V., IANA Considerations for Point-to-Point Protocol, RFC 3818, June 2004. [ANYCAST] Hagino, J., and K. Ettikan, An Analysis of IPv6 Anycast, draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt, Internet draft (work in progress), June 2003. [DHCPv4Threat] Hibbs, R., Smith, C., Volz, B., Zohar, M., Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis, draft-ietf-dhc-v4-threat-analysis-02.txt, Internet draft (work in progress), April 2004.
New BOF in Internet Area - SHIM6
Site MultiHoming by IPv6 InterMediation BOF (shim6) Friday, March 11 at 0900-1130 = CHAIRS: Brian Carpenter [EMAIL PROTECTED] Kurtis Lindqvist [EMAIL PROTECTED] AGENDA: 1. Administrivia, Chairs (5 mins) - Agenda - Scribes 1. Introduction, Charis (5 mins) 2. shim6 solutions architecture overview, Geoff Huston draft-huston-l3shim-arch-00.txt (15 mins) 3. review proposed charter, Chairs (25 mins) 3.1 General goals and scope 3.2 Specific deliverables and milestones 4. AOB, chairs (10 mins) - Next steps DESCRIPTION: The multi6 WG was tasked with investigating solutions to the site multihoming problem that will allow the global routing system to scale. The outcome of the multi6 WG is a specific network layer shim architecture for addressing and address handling of sites and nodes. This includes switching to different locator addresses when connectivity changes, but without the changes of address being visible to upper layers, which see a fixed Upper Layer Identifier address (ULID). The proposed shim6 WG is to complete this work with the required protocol developments and complete the architecture and security analysis of the required protocols. Interim mailing list for pre-discussion: [EMAIL PROTECTED] Join by sending subscribe shim6 to [EMAIL PROTECTED] ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
