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]