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]