Network Working Group P. Nikander Internet-Draft J. Melen Intended status: Informational Ericsson Research Nomadic Lab Expires: May 15, 2008 M. Komu Helsinki Institute for Information Technology M. Bagnulo Universidad Carlos III de Madrid November 12, 2007 Mapping STUN and TURN messages on HIP draft-manyfolks-hip-sturn-00 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 15, 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 15, 2008 [Page 1] Internet-Draft Mapping STUN and TURN messages on HIP November 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Message foramts . . . . . . . . . . . . . . . . . . . . . . 3 2.1. HIP parameter format . . . . . . . . . . . . . . . . . . . . 3 2.2. STUN attribute format . . . . . . . . . . . . . . . . . . . 3 2.3. Mapping STUN attribute format to HIP parameter format . . . 4 2.4. Mapping STUN attribute Types to HIP parameter Types . . . . 4 2.5. Mapping of STUN MAPPED-ADDRESS and XOR-MAPPED-ADDRESS . . . 5 2.6. Mapping of STUN SERVER parameter . . . . . . . . . . . . . . 5 2.7. Mapping of STUN security mechanisms . . . . . . . . . . . . 5 2.8. Mapping of STUN error attributes . . . . . . . . . . . . . . 5 2.9. Mapping of STUN ALTERNATE-SERVER . . . . . . . . . . . . . . 6 3. Mapping STUN attribute Types defined in the TURN specification . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Mapping of TURN error codes . . . . . . . . . . . . . . . . 7 4. Mapping STUN protocol operations to HIP . . . . . . . . . . 7 4.1. Forming a Request or an Indication and sending it . . . . . 7 5. Mapping TURN protocol operations to HIP . . . . . . . . . . 8 5.1. Allocate . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Set Active Destination, Connect, and Connect Status Indication . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Send and Data indications . . . . . . . . . . . . . . . . . 8 6. Security considerations . . . . . . . . . . . . . . . . . . 9 7. IANA considerations . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 9 9. Informative references . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . 11 Nikander, et al. Expires May 15, 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 foramts 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 15, 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 attribute format to HIP parameter format 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 TURN 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 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 15, 2008 [Page 4] Internet-Draft Mapping STUN and TURN messages on HIP November 2007 +--------------------+---------------+------------------------------+ | 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 2.5. 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. 2.6. Mapping of STUN SERVER parameter The STUN SERVER parameter is mapped to a new HIP SERVER parameter. The syntax of the value is identical. 2.7. 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. 2.8. 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 corresponding HIP message may contain multiple parameters instead of one. Nikander, et al. Expires May 15, 2008 [Page 5] Internet-Draft Mapping STUN and TURN messages on HIP November 2007 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 2.9. 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. 3. Mapping STUN attribute Types defined in the TURN specification +----------------------+-----------+--------------------------------+ | 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 | | CONNECT_STAT | 0x0023 | For further study | +----------------------+-----------+--------------------------------+ Table 3: Type mapping Nikander, et al. Expires May 15, 2008 [Page 6] Internet-Draft Mapping STUN and TURN messages on HIP November 2007 3.1. Mapping of TURN error codes +------------------------+----------------------------------+ | STUN 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 | +------------------------+----------------------------------+ 4. Mapping STUN protocol operations to HIP TBD. 4.1. Forming a Request or an Indication and sending it When an implentation would create a STUN Request or a STUN Indication, the corresponding HIP-mapped machanism 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 packet, the packet MUST also carry a SEQ payload; see below A STUN Indiciations are mappend into a HIP NOTIFY packets that carry the corresponding mapped parameters. 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]. Nikander, et al. Expires May 15, 2008 [Page 7] Internet-Draft Mapping STUN and TURN messages on HIP November 2007 5. Mapping TURN protocol operations to HIP TBD. 5.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]. 5.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 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. 5.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 signalling data than HIP can be piggybacked on HIP control messages by using the "Next Header" field in the fixed HIP packet header. Nikander, et al. Expires May 15, 2008 [Page 8] Internet-Draft Mapping STUN and TURN messages on HIP November 2007 6. 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 authorised 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 capasity 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. 7. IANA considerations IANA actions TBD. 8. Acknowledgments 9. 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 15, 2008 [Page 9] 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. 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 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 15, 2008 [Page 10] 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 15, 2008 [Page 11]