Network Working Group P. Nikander Internet-Draft J. Melen Intended status: Informational Ericsson Research Nomadic Lab Expires: May 22, 2008 M. Komu Helsinki Institute for Information Technology M. Bagnulo Universidad Carlos III de Madrid November 19, 2007 Mapping STUN and TURN messages on HIP draft-manyfolks-hip-sturn-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 22, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This memo defines how one can map the STUN and TURN functionality, as used by ICE, to HIP. Nikander, et al. Expires May 22, 2008 [Page 1] Internet-Draft Mapping STUN and TURN messages on HIP November 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Message formats . . . . . . . . . . . . . . . . . . . . . . 3 2.1. HIP parameter format . . . . . . . . . . . . . . . . . . . . 3 2.2. STUN attribute format . . . . . . . . . . . . . . . . . . . 3 2.3. Mapping STUN, TURN and ICE attributes to HIP parameters . . 4 2.4. Mapping STUN attribute Types to HIP parameter Types . . . . 4 3. Mapping STUN attribute Types defined in the STUN specification . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Mapping of STUN MAPPED-ADDRESS and XOR-MAPPED-ADDRESS . . . 5 3.2. Mapping of STUN SERVER parameter . . . . . . . . . . . . . . 5 3.3. Mapping of STUN security mechanisms . . . . . . . . . . . . 5 3.4. Mapping of STUN error attributes . . . . . . . . . . . . . . 5 3.5. Mapping of STUN ALTERNATE-SERVER . . . . . . . . . . . . . . 6 4. Mapping STUN attribute Types defined in the TURN specification . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Mapping of TURN error codes . . . . . . . . . . . . . . . . 7 5. Mapping STUN attribute Types defined in the ICE specification . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Mapping of ICE error codes . . . . . . . . . . . . . . . . . 7 5.2. Mapping of PRIORITY attribute . . . . . . . . . . . . . . . 7 5.3. Mapping of USE-CANDIDATE attribute . . . . . . . . . . . . . 8 5.4. Mapping of ICE-CONTROLLING and ICE-CONTROLLED attributes . . 8 6. Mapping STUN protocol operations to HIP . . . . . . . . . . 8 6.1. Forming a Request or an Indication and sending it . . . . . 8 7. Mapping TURN protocol operations to HIP . . . . . . . . . . 9 7.1. Allocate . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.2. Set Active Destination, Connect, and Connect Status Indication . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.3. Send and Data indications . . . . . . . . . . . . . . . . . 10 8. Mapping ICE protocol operations to HIP . . . . . . . . . . . 10 8.1. Connectivity checks . . . . . . . . . . . . . . . . . . . . 10 8.2. Controlling and controlled host election . . . . . . . . . . 10 9. Security considerations . . . . . . . . . . . . . . . . . . 11 10. IANA considerations . . . . . . . . . . . . . . . . . . . . 11 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11 12. Informative references . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . 14 Nikander, et al. Expires May 22, 2008 [Page 2] Internet-Draft Mapping STUN and TURN messages on HIP November 2007 1. Introduction The HIP protocol defines a number of messages and parameters [1]. The parameters are encoded as TLVs, as shown in Section 2.1. The STUN specification defines a number of messages and attributes [5]. The attributes are encoded as TLVs, as shown in Section 2.2. As it turn out that the HIP parameter format and the STUN attribute format are almost the same, this document provides a trivial mapping for encoding STUN attributes as HIP parameters. Additionally, this document specifies a number of options how one can use HIP messages to carry the equivalent of STUN messages. 2. Message formats 2.1. HIP parameter format The HIP parameter format is defined in Section 5.2.1 of [1], and copied below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |C| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Contents / / +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Type code for the parameter C Critical bit, part of the Type. Length Length of the parameter, in bytes. Contents Parameter specific, defined by Type. Padding Padding, 0-7 bytes, added if needed. 2.2. STUN attribute format The STUN Attribute format is define in Section 14 of [5], and copied below. Nikander, et al. Expires May 22, 2008 [Page 3] Internet-Draft Mapping STUN and TURN messages on HIP November 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (variable) .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Length contains the length of the Value part, prior to padding, measured in bytes. Since STUN attributes are aligned in 32 bit boundaries, there may be 0-3 bytes of padding. 2.3. Mapping STUN, TURN and ICE attributes to HIP parameters As the only difference between the HIP parameter and STUN attribute format is alignment, which is 64 bits for HIP and 32 bits for STUN, it becomes trivial to map STUN attribute formats to HIP parameter formats. All that is needed is to pad them according to the HIP format, to 64 bits, and we are done. 2.4. Mapping STUN attribute Types to HIP parameter Types Table 1 maps the currently defined STUN attribute types [5] to HIP parameter types. Table 3 maps the currently defined TURN attribute types [6] to HIP parameter types. Table 5 maps the currently defined ICE attribute types [7] to HIP parameter types. For attributes not discussed below, the method to define the corresponding HIP parameter is as follows: Try to find a HIP parameter that has exactly the same semantics. If so, figure out how to do the conceptual, semantic level mapping. This method was used to map the STUN MESSAGE-INTEGRITY to HIP HMAC below. Try to find a HIP parameter that encodes semantically similar data (but has otherwise different semantics). If so, create a new HIP parameter using the format from the existing HIP parameter, and define the new semantics. This method was used to map the STUN MAPPED-ADDRESS and XOR-MAPPED-ADDRESS parameters to the new HIP RLOCATOR parameter below. Otherwise, define a new HIP parameter that has the same value syntax and semantics as the STUN attribute. This method was used to map the STUN SERVER parameter to a new HIP parameter below. Nikander, et al. Expires May 22, 2008 [Page 4] Internet-Draft Mapping STUN and TURN messages on HIP November 2007 3. Mapping STUN attribute Types defined in the STUN specification +--------------------+---------------+------------------------------+ | STUN Type | STUN Encoding | HIP Encoding | +--------------------+---------------+------------------------------+ | MAPPED-ADDRESS | 0x0001 | A new HIP RLOCATOR parameter | | USERNAME | 0x0006 | Replaced by HIP identities | | MESSAGE-INTEGRITY | 0x0008 | Replaced by HIP HMAC | | ERROR-CODE | 0x0009 | Mapped to HIP NOTIFICATION | | UNKNOWN-ATTRIBUTES | 0x000A | Mapped to HIP NOTIFICATION | | REALM | 0x0014 | Replaced by HIP identities | | NONCE | 0x0015 | Replaced by HIP base | | | | protocol | | XOR-MAPPED-ADDRESS | 0x0020 | A new HIP RLOCATOR parameter | | SERVER | 0x8022 | A new HIP SERVER parameter | | ALTERNATE-SERVER | 0x8023 | For future study | | FINGERPRINT | 0x8028 | Not needed in HIP | +--------------------+---------------+------------------------------+ Table 1: Type mapping 3.1. Mapping of STUN MAPPED-ADDRESS and XOR-MAPPED-ADDRESS The STUN MAPPED-ADDRESS and XOR-MAPPED-ADDRESS attributes are both replaced by a new HIP parameter, RLOCATOR (for Reverse Locator), which has a format identical to the LOCATOR parameter as defined in [2]. This parameter carries the STUN reflexive and other transport addresses. 3.2. Mapping of STUN SERVER parameter The STUN SERVER parameter is mapped to a new HIP SERVER parameter. The syntax of the value is identical. 3.3. Mapping of STUN security mechanisms When HIP is used, the HIP security mechanisms completely replace the STUN security mechanisms. Hence, the STUN USERNAME, MESSAGE- INTEGRITY, REALM, and NONCE parameters are not needed at all. 3.4. Mapping of STUN error attributes The STUN error indication attributes ERROR-CODE and UNKNOWN- ATTRIBUTES are mapped into HIP NOTIFICATION payload as follows: The STUN UNKNOWN-ATTRIBUTE is mapped to HIP UNSUPPORTED_CRITICAL_PARAMETER_TYPE NOTIFICATION. Since the STUN parameter allows listing multiple unknown attributes, the Nikander, et al. Expires May 22, 2008 [Page 5] Internet-Draft Mapping STUN and TURN messages on HIP November 2007 corresponding HIP message may contain multiple parameters instead of one. The STUN ERROR_CODE codes are mapped to HIP NOTIFICATIONs as indicated in Table 2. +-----------------+------------------------------------------------+ | STUN error code | HIP error type | +-----------------+------------------------------------------------+ | 300 | Currently not supported; see below | | 400 | INVALID_SYNTAX (or some more specific) | | 401 | AUTHENTICATION_FAILED or BLOCKED_BY_POLICY | | 420 | UNSUPPORTED_CRITICAL_PARAMETER_TYPE; see above | | 438 | Not possible as NONCEs are not used | | 500 | SERVER_BUSY_PLEASE_RETRY | +-----------------+------------------------------------------------+ Table 2 3.5. Mapping of STUN ALTERNATE-SERVER Supporting STUN ALTERNATE-SERVERs and the 300 (Redirect) error code would require full delegation in the HIP case. As HIP delegation has not been fully specified, the definition of such a redirection mechanism is left for future work. 4. Mapping STUN attribute Types defined in the TURN specification TBD. +----------------------+-----------+--------------------------------+ | STUN Type | STUN | HIP Encoding | | | Encoding | | +----------------------+-----------+--------------------------------+ | LIFETIME | 0x000D | Part of HIP REG_REQUEST or | | | | REG_RESPONSE | | BANDWIDTH | 0x0010 | A new HIP parameter | | REMOTE-ADDRESS | 0x0012 | Mapped to the existing HIP | | | | LOCATOR parameter | | DATA | 0x0013 | Replaced by HIP upper layer | | | | payload | | RELAY-ADDRESS | 0x0016 | Mapped to the new HIP RLOCATOR | | | | parameter | | REQUESTED-PORT-PROPS | 0x0018 | A new HIP parameter | | REQUESTED-TRANSPORT | 0x0019 | A new HIP parameter | | REQUESTED-IP | 0x0022 | A new HIP parameter | | TIMER-VAL | 0x0021 | For further study | Nikander, et al. Expires May 22, 2008 [Page 6] Internet-Draft Mapping STUN and TURN messages on HIP November 2007 | CONNECT_STAT | 0x0023 | For further study | +----------------------+-----------+--------------------------------+ Table 3: Type mapping 4.1. Mapping of TURN error codes +------------------------+----------------------------------+ | TURN error code | HIP error type | +------------------------+----------------------------------+ | 437 (No binding) | Mapped to the HIP ICMP mechanism | | 439, 442-446, 486, 507 | Mapped to a new HIP error type | +------------------------+----------------------------------+ 5. Mapping STUN attribute Types defined in the ICE specification TBD. +-----------------+-----------+-------------------------------------+ | STUN Type | STUN | HIP Encoding | | | Encoding | | +-----------------+-----------+-------------------------------------+ | PRIORITY | 0x0024 | Mapped to existing HIP LOCATOR as a | | | | new locator type | | USE-CANDIDATE | 0x0025 | Not needed in HIP | | ICE-CONTROLLING | 0x8029 | Not needed in HIP | | ICE-CONTROLLED | 0x802a | Not needed in HIP | +-----------------+-----------+-------------------------------------+ Table 5: Type mapping 5.1. Mapping of ICE error codes +---------------------+-------------------+ | STUN error code | HIP error type | +---------------------+-------------------+ | 487 (Role Conflict) | Not needed in HIP | +---------------------+-------------------+ 5.2. Mapping of PRIORITY attribute The PRIORITY is included in to a new locator type to be defined for the exchange of candidates. The candidates are carried in the LOCATOR parameter as defined in [2]. Nikander, et al. Expires May 22, 2008 [Page 7] Internet-Draft Mapping STUN and TURN messages on HIP November 2007 5.3. Mapping of USE-CANDIDATE attribute Explicit indication of the address pair to be used as ICE implements with USE-CANDIDATE option is not needed in HIP. In HIP the ESP payload after Base Exchange or after mobility update function's as an implicit indication of the selected candidate pair. HIP return routability check used with mobility and multihoming uses the ESP similarly as a implicit indication of completion of mobility UPDATE as defined in [2]. 5.4. Mapping of ICE-CONTROLLING and ICE-CONTROLLED attributes The ICE-CONTROLLING and ICE-CONTROLLED attributes are not needed because the HIP has already resolving mechanism for handling simultaneous start of Base Exchange. The same mechanism can be used to elect the controlling and controlled role. The host having the smaller HIT MUST become the controlled host (For detailed description of HIT comparison see HIP Base Protocol specification section 6.5 [1]). 6. Mapping STUN protocol operations to HIP TBD. 6.1. Forming a Request or an Indication and sending it When an implementation would create a STUN Request or a STUN Indication, the corresponding HIP-mapped mechanism would create a HIP message. Depending on the state of the HIP base protocol, the underlying HIP message may be a R1, an I2, a R2, an UPDATE, or a NOTIFY; see below. Note that in all cases the HIP message may carry also other parameters than the mapped STUN payloads. The message types are mapped as follows: A STUN Request is mapped into a HIP packet that carries a REG_REQUEST payloads, where the REG_REQUEST payload indicates that the client wants to register to the correspondingly-mapped service(s). If the STUN message carries attributes, corresponding HIP parameters are added to the message. If the packet is an UPDATE or an R2 packet, the packet MUST also carry a SEQ payload; see below A STUN Indications are mapped into a HIP NOTIFY packets that carry the corresponding mapped parameters. Nikander, et al. Expires May 22, 2008 [Page 8] Internet-Draft Mapping STUN and TURN messages on HIP November 2007 A STUN Response is mapped into a HIP packet that carries an REG_RESPONSE payload, possible together with a number of other payloads, corresponding to the STUN attributes. If the request packet carried a SEQ, the response must carry a corresponding ACK. The STUN transaction ID is replaced by the HIP SEQ and ACK parameters, or implicitly by the R1/I2 or I2/R2 pair. Once the corresponding HIP message has been formed, it is sent normally, either in the HIP protocol or as UDP encapsulated as specified in [4]. 7. Mapping TURN protocol operations to HIP TBD. 7.1. Allocate If a HIP host wants to communicate with another HIP host through are relay, one of the hosts need to register for a generic (ESP) relay service, define a policy, and pass ESP packets (UDP encapsulated or not) through the server. The server indicates that it is willing to provide such relay service using REG_INFO. The client registers to the service using REG_REQUEST, and the server informs the client about the service using REG_RESPONSE. The relayed address is returned in a RLOCATOR parameter in the HIP packet that contains the REG_RESPONSE. The service semantics are basically defined in the TURN specification, suitably modified to apply to ESP and UDP- encapsulated-ESP. UDP encapsulation or plain ESP is indicated by the REQUESTED-TRANSPORT parameter; see above. If UDP encapsulation is used, the REQUESTED-PORT-PROPS may used to indicate the desired UDP port. Currently there is no way to specify a wanted ESP SPI number. Other transports but ESP and UDP-encapsulated-ESP are currently unsupported. When the server relays HIP control packets, it MUST add appropriate RVS_HMAC, FROM, and/or VIA_RVS parameters, as defined in [3]. 7.2. Set Active Destination, Connect, and Connect Status Indication The TURN Set Active Destination, Connect, and Connect Status Indication do not make sense in the HIP case, as HIP works on the layer below. Once a relay has been allocated at the server, it can be used for traffic in both directions. Any hosts that know the Nikander, et al. Expires May 22, 2008 [Page 9] Internet-Draft Mapping STUN and TURN messages on HIP November 2007 right IP address, UDP port number, SPI triple (or just address, SPI pair in the case of plain ESP) can send packets to the HIP host. Any traffic restrictions are up to a local policy between the HIP host and the relay. It is expected that there will be a generic HIP extension defining traffic filtering policies. 7.3. Send and Data indications The TURN Send and Data indications do not make sense in the HIP case, just as above. Payload data is simply sent as ESP or UDP- encapsulated-ESP messages. Other signaling data than HIP can be piggy backed on HIP control messages by using the "Next Header" field in the fixed HIP packet header. 8. Mapping ICE protocol operations to HIP TBD. 8.1. Connectivity checks When a host wants to find an address pair which it can use to communicate with the peer it has to send the address candidates either using HIP I2, R2 packets or HIP UPDATE packets. After exchanging the candidates both peers will start the return routability checks using UPDATE packets as defined in [2]. Once the controlling host has completed one or more successful checks, it will create a IPsec policy and security association for one of the pairs. As the ESP payload packet is then received on the controlled host it will be aware of the selected address pair. 8.2. Controlling and controlled host election In the ICE [7] specification the controlling role is given to the one generating the offer. In HIP case the controlling role should be given, not to the host that generates the offer, but to the node that generates answer. In this manner the connectivity checks are in line with the mobility and multihoming return routability checks defined in [2]. Resolving tie-breaker (both hosts starting connectivity checks simultaneously) should be done in the same way as simultaneous Base Exchange and mobility updates are resolved. The host having the smaller HIT MUST become as the controlled host. For detailed description of HIT comparison see HIP Base Protocol specification section 6.5 [1]. Nikander, et al. Expires May 22, 2008 [Page 10] Internet-Draft Mapping STUN and TURN messages on HIP November 2007 9. Security considerations TBD. Basically, HIP requires that there is an authenticated HIP association between the HIP client and the relay server, and the two communication HIP peers. Secondly, the HIP registration protocol explicitly requires that any HIP clients registering for services are authorized by the server. The danger of anyone being able to send data through the relay to the client is expected to be covered by a separate document defining a generic traffic filtering capacity for HIP. For example, such a capacity could, trust permitting, pass an ESP integrity key to the relay server, allowing it to verify that each arriving packet is coming from the right peer. Reflection attacks on HIP control traffic are taken care of in the way specified in [3]. Note, however, that the TURN-like relay defined in this document may relay also other HIP control packets but I1s. 10. IANA considerations IANA actions TBD. 11. Acknowledgments 12. Informative references [1] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", draft-ietf-hip-base-09 (work in progress), October 2007. [2] Henderson, T., "End-Host Mobility and Multihoming with the Host Identity Protocol", draft-ietf-hip-mm-05 (work in progress), March 2007. [3] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", draft-ietf-hip-rvs-05 (work in progress), June 2006. [4] Schmitt, V., "HIP Extensions for the Traversal of Network Address Translators", draft-ietf-hip-nat-traversal-02 (work in progress), July 2007. Nikander, et al. Expires May 22, 2008 [Page 11] Internet-Draft Mapping STUN and TURN messages on HIP November 2007 [5] Rosenberg, J., Huitema, C., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for (NAT) (STUN)", draft-ietf-behave-rfc3489bis-11 (work in progress), October 2007. [6] Rosenberg, J., "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", draft-ietf-behave-turn-04 (work in progress), July 2007. [7] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-19 (work in progress), October 2007. Authors' Addresses Pekka Nikander Ericsson Research Nomadic Lab JORVAS FIN-02420 FINLAND Phone: +358 9 299 1 Email: pekka.nikander@nomadiclab.com Jan Melen Ericsson Research Nomadic Lab JORVAS FIN-02420 FINLAND Phone: +358 9 299 1 Email: jan.melen@nomadiclab.com Miika Komu Helsinki Institute for Information Technology Metsanneidonkuja 4 Espoo FINLAND Phone: +358 50 3841531 Email: miika@iki.fi Nikander, et al. Expires May 22, 2008 [Page 12] Internet-Draft Mapping STUN and TURN messages on HIP November 2007 Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: +34 91 6249500 Email: marcelo@it.uc3m.es Nikander, et al. Expires May 22, 2008 [Page 13] Internet-Draft Mapping STUN and TURN messages on HIP November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Nikander, et al. Expires May 22, 2008 [Page 14]