draft-ietf-hip-nat-traversal-06.txt   draft-ietf-hip-nat-traversal-07.txt 
HIP Working Group M. Komu HIP Working Group M. Komu
Internet-Draft HIIT Internet-Draft HIIT
Intended status: Experimental T. Henderson Intended status: Experimental T. Henderson
Expires: September 10, 2009 The Boeing Company Expires: December 11, 2009 The Boeing Company
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
J. Melen J. Melen
A. Keranen, Ed. A. Keranen, Ed.
Ericsson Research Nomadiclab Ericsson Research Nomadiclab
March 9, 2009 June 9, 2009
Basic HIP Extensions for Traversal of Network Address Translators Basic HIP Extensions for Traversal of Network Address Translators
draft-ietf-hip-nat-traversal-06.txt draft-ietf-hip-nat-traversal-07.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 10, 2009. This Internet-Draft will expire on December 11, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Abstract Abstract
This document specifies extensions to the Host Identity Protocol This document specifies extensions to the Host Identity Protocol
(HIP) to facilitate Network Address Translator (NAT) traversal. The (HIP) to facilitate Network Address Translator (NAT) traversal. The
extensions are based on the use of the Interactive Connectivity extensions are based on the use of the Interactive Connectivity
Establishment (ICE) methodology to discover a working path between Establishment (ICE) methodology to discover a working path between
two end-hosts, and on standard techniques for encapsulating two end-hosts, and on standard techniques for encapsulating
Encapsulating Security Payload (ESP) packets within the User Datagram Encapsulating Security Payload (ESP) packets within the User Datagram
Protocol (UDP). This document also defines elements of procedure for Protocol (UDP). This document also defines elements of procedure for
NAT traversal, including the optional use of a HIP relay server. NAT traversal, including the optional use of a HIP relay server.
skipping to change at page 3, line 16 skipping to change at page 3, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7
4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8
4.1. Relay Registration . . . . . . . . . . . . . . . . . . . . 8 4.1. Relay Registration . . . . . . . . . . . . . . . . . . . . 8
4.2. ICE Candidate Gathering . . . . . . . . . . . . . . . . . 10 4.2. ICE Candidate Gathering . . . . . . . . . . . . . . . . . 10
4.3. NAT Traversal Mode Negotiation . . . . . . . . . . . . . . 10 4.3. NAT Traversal Mode Negotiation . . . . . . . . . . . . . . 10
4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 12 4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 12
4.5. Base Exchange via HIP Relay Server . . . . . . . . . . . . 12 4.5. Base Exchange via HIP Relay Server . . . . . . . . . . . . 12
4.6. ICE Connectivity Checks . . . . . . . . . . . . . . . . . 14 4.6. ICE Connectivity Checks . . . . . . . . . . . . . . . . . 15
4.7. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 15 4.7. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 15
4.8. Base Exchange without ICE Connectivity Checks . . . . . . 16 4.8. Base Exchange without ICE Connectivity Checks . . . . . . 16
4.9. Initiating a Base Exchange both with and without UDP 4.9. Initiating a Base Exchange both with and without UDP
Encapsulation . . . . . . . . . . . . . . . . . . . . . . 16 Encapsulation . . . . . . . . . . . . . . . . . . . . . . 17
4.10. Sending Control Messages after the Base Exchange . . . . . 17 4.10. Sending Control Packets after the Base Exchange . . . . . 18
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 18 5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 18
5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 18 5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 19
5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . 19 5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . 20
5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . . 20 5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . . 20
5.5. Connectivity Check Transaction Pacing Parameter . . . . . 20 5.5. Connectivity Check Transaction Pacing Parameter . . . . . 21
5.6. Relay and Registration Parameters . . . . . . . . . . . . 21 5.6. Relay and Registration Parameters . . . . . . . . . . . . 22
5.7. LOCATOR Parameter . . . . . . . . . . . . . . . . . . . . 22 5.7. LOCATOR Parameter . . . . . . . . . . . . . . . . . . . . 23
5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . . 23 5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . . 24
5.9. Registration Types . . . . . . . . . . . . . . . . . . . . 23 5.9. Registration Types . . . . . . . . . . . . . . . . . . . . 24
5.10. Notify Message Types . . . . . . . . . . . . . . . . . . . 24 5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 25
5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . . 24 5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26
6.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 24 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 26
6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . . 25 6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . . 26
6.3. Base Exchange Replay Protection for HIP Relay Server . . . 25 6.3. Base Exchange Replay Protection for HIP Relay Server . . . 26
6.4. Demuxing Different HIP Associations . . . . . . . . . . . 25 6.4. Demuxing Different HIP Associations . . . . . . . . . . . 27
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 10.1. Normative References . . . . . . . . . . . . . . . . . . . 28
10.2. Informative References . . . . . . . . . . . . . . . . . . 28 10.2. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 28 Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 30
Appendix B. IPv4-IPv6 Interoperability . . . . . . . . . . . . . 29 Appendix B. Base Exchange through a Rendezvous Server . . . . . . 31
Appendix C. Base Exchange through a Rendezvous Server . . . . . . 29 Appendix C. Document Revision History . . . . . . . . . . . . . . 31
Appendix D. Document Revision History . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
HIP [RFC5201] is defined as a protocol that runs directly over IPv4 HIP [RFC5201] is defined as a protocol that runs directly over IPv4
or IPv6, and HIP coordinates the setup of ESP security associations or IPv6, and HIP coordinates the setup of ESP security associations
[RFC5202] that are also specified to run over IPv4 or IPv6. This [RFC5202] that are also specified to run over IPv4 or IPv6. This
approach is known to have problems traversing NATs and other approach is known to have problems traversing NATs and other
middleboxes [RFC5207]. This document defines HIP extensions for the middleboxes [RFC5207]. This document defines HIP extensions for the
traversal of both Network Address Translator (NAT) and Network traversal of both Network Address Translator (NAT) and Network
Address and Port Translator (NAPT) middleboxes. The document Address and Port Translator (NAPT) middleboxes. The document
skipping to change at page 4, line 42 skipping to change at page 4, line 42
located behind NATs is not possible without relaying the traffic located behind NATs is not possible without relaying the traffic
through a relay, such as a TURN server [RFC5128]. Because relaying through a relay, such as a TURN server [RFC5128]. Because relaying
traffic increases the roundtrip delay and consumes resources from the traffic increases the roundtrip delay and consumes resources from the
relay, with the extensions described in this document, hosts try to relay, with the extensions described in this document, hosts try to
avoid using the TURN server whenever possible. avoid using the TURN server whenever possible.
HIP has defined a Rendezvous Server [RFC5204] to allow for mobile HIP HIP has defined a Rendezvous Server [RFC5204] to allow for mobile HIP
hosts to establish a stable point-of-contact in the Internet. This hosts to establish a stable point-of-contact in the Internet. This
document defines extensions to the Rendezvous Server that solve the document defines extensions to the Rendezvous Server that solve the
same problems but for both NATed and non-NATed networks. The same problems but for both NATed and non-NATed networks. The
extended Rendezvous Server, called a "HIP relay server," forwards all extended Rendezvous Server, called a "HIP relay server", forwards HIP
HIP control packets between an Initiator and Responder, allowing control packets between an Initiator and a Responder, allowing hosts
Responders to be located behind NATs. This behavior is in contrast to be located behind NATs. This behavior is in contrast to the HIP
to the HIP rendezvous service that forwards only the initial I1 rendezvous service that forwards only the initial I1 packet of the
packet of the base exchange, which is less likely to work in a NATed base exchange; an approach which is less likely to work in a NATed
environment [RFC5128]. Therefore, when using relays to traverse environment [RFC5128]. Therefore, when using relays to traverse
NATs, HIP uses a HIP relay server for the control traffic and a TURN NATs, HIP uses a HIP relay server for the control traffic and a TURN
server for the data traffic. server for the data traffic.
The basis for the connectivity checks is ICE [I-D.ietf-mmusic-ice]. The basis for the connectivity checks is ICE [I-D.ietf-mmusic-ice].
[I-D.ietf-mmusic-ice] describes ICE as follows: [I-D.ietf-mmusic-ice] describes ICE as follows:
"The Interactive Connectivity Establishment (ICE) methodology is a "The Interactive Connectivity Establishment (ICE) methodology is a
technique for NAT traversal for UDP-based media streams (though technique for NAT traversal for UDP-based media streams (though
ICE can be extended to handle other transport protocols, such as ICE can be extended to handle other transport protocols, such as
skipping to change at page 6, line 19 skipping to change at page 6, line 19
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document borrows terminology from [RFC5201], [RFC5206], This document borrows terminology from [RFC5201], [RFC5206],
[RFC4423], [I-D.ietf-mmusic-ice], and [RFC5389]. Additionally, the [RFC4423], [I-D.ietf-mmusic-ice], and [RFC5389]. Additionally, the
following terms are used: following terms are used:
Rendezvous server: Rendezvous server:
A host that forwards I1 packets to the Responder. A host that forwards I1 packets to the Responder.
HIP relay server: HIP relay server:
A host that forwards all HIP control packets between the Initiator A host that forwards any kind of HIP control packets between the
and the Responder. Initiator and the Responder.
TURN server: TURN server:
A server that forwards data traffic between two end-hosts as A server that forwards data traffic between two end-hosts as
defined in [I-D.ietf-behave-turn]. defined in [I-D.ietf-behave-turn].
Locator: Locator:
As defined in [RFC5206]: "A name that controls how the packet is As defined in [RFC5206]: "A name that controls how the packet is
routed through the network and demultiplexed by the end-host. It routed through the network and demultiplexed by the end-host. It
may include a concatenation of traditional network addresses such may include a concatenation of traditional network addresses such
as an IPv6 address and end-to-end identifiers such as an ESP SPI. as an IPv6 address and end-to-end identifiers such as an ESP SPI.
It may also include transport port numbers or IPv6 Flow Labels as It may also include transport port numbers or IPv6 Flow Labels as
demultiplexing context, or it may simply be a network address." demultiplexing context, or it may simply be a network address."
It should noted that "address" is used in this document as a
synonym for locator.
LOCATOR (written in capital letters): LOCATOR (written in capital letters):
Denotes a HIP control message parameter that bundles multiple Denotes a HIP control packet parameter that bundles multiple
locators together. locators together.
ICE offer: ICE offer:
The Initiator's LOCATOR parameter in a HIP I2 control message. The Initiator's LOCATOR parameter in a HIP I2 control packet.
ICE answer: ICE answer:
The Responder's LOCATOR parameter in a HIP R2 control message. The Responder's LOCATOR parameter in a HIP R2 control packet.
Transport address: Transport address:
Transport layer port and the corresponding IPv4/v6 address. Transport layer port and the corresponding IPv4/v6 address.
Candidate: Candidate:
A transport address that is a potential point of contact for A transport address that is a potential point of contact for
receiving data. receiving data.
Host candidate: Host candidate:
A candidate obtained by binding to a specific port from an IP A candidate obtained by binding to a specific port from an IP
skipping to change at page 8, line 10 skipping to change at page 8, line 10
connected to the public Internet. To be contacted from behind a NAT, connected to the public Internet. To be contacted from behind a NAT,
the Responder must be registered with a HIP relay server reachable on the Responder must be registered with a HIP relay server reachable on
the public Internet, and we assume as a starting point that the the public Internet, and we assume as a starting point that the
Initiator knows both the Responder's HIT and the address of one of Initiator knows both the Responder's HIT and the address of one of
its relay servers (how the Initiator learns of the Responder's relay its relay servers (how the Initiator learns of the Responder's relay
server is outside of the scope of this document, but may be through server is outside of the scope of this document, but may be through
DNS or another name service). DNS or another name service).
The first steps are for both the Initiator and Responder to register The first steps are for both the Initiator and Responder to register
with a relay server (need not be the same one) and gather a set of with a relay server (need not be the same one) and gather a set of
address candidates. Next, the HIP base exchange is carried out by address candidates. The hosts may use TURN and STUN servers for
encapsulating the HIP control packets in UDP datagrams and sending gathering the candidates. Next, the HIP base exchange is carried out
by encapsulating the HIP control packets in UDP datagrams and sending
them through the Responder's relay server. As part of the base them through the Responder's relay server. As part of the base
exchange, each HIP host learns of the peer's candidate addresses exchange, each HIP host learns of the peer's candidate addresses
through the ICE offer/answer procedure embedded in the base exchange. through the ICE offer/answer procedure embedded in the base exchange.
Once the base exchange is completed, HIP has established a working Once the base exchange is completed, HIP has established a working
communication session (for signaling) via a relay server, but the communication session (for signaling) via a relay server, but the
hosts still work to find a better path, preferably without a relay, hosts still work to find a better path, preferably without a relay,
for the ESP data flow. For this, ICE connectivity checks are carried for the ESP data flow. For this, ICE connectivity checks are carried
out until a working pair of addresses is discovered. At the end of out until a working pair of addresses is discovered. At the end of
the procedure, if successful, the hosts will have enabled a UDP-based the procedure, if successful, the hosts will have enabled a UDP-based
skipping to change at page 8, line 48 skipping to change at page 8, line 49
This section describes the normative behavior of the protocol This section describes the normative behavior of the protocol
extension. Examples of packet exchanges are provided for extension. Examples of packet exchanges are provided for
illustration purposes. illustration purposes.
4.1. Relay Registration 4.1. Relay Registration
HIP rendezvous servers operate in non-NATed environments and their HIP rendezvous servers operate in non-NATed environments and their
use is described in [RFC5204]. This section specifies a new use is described in [RFC5204]. This section specifies a new
middlebox extension, called the HIP relay server, for operating in middlebox extension, called the HIP relay server, for operating in
NATed environments. A HIP relay server forwards all HIP control NATed environments. A HIP relay server forwards HIP control packets
packets between the Initiator and the Responder. between the Initiator and the Responder.
End-hosts cannot use the HIP relay service for forwarding the ESP End-hosts cannot use the HIP relay service for forwarding the ESP
data plane. Instead, they use TURN servers [I-D.ietf-behave-turn] data plane. Instead, they use TURN servers [I-D.ietf-behave-turn]
for that. for that.
A HIP relay server MUST silently drop packets to a HIP relay client A HIP relay server MUST silently drop packets to a HIP relay client
that has not previously registered with the HIP relay. The that has not previously registered with the HIP relay. The
registration process follows the generic registration extensions registration process follows the generic registration extensions
defined in [RFC5203] and is illustrated in Figure 2. defined in [RFC5203] and is illustrated in Figure 2.
skipping to change at page 9, line 44 skipping to change at page 9, line 44
range 49152-65535 for initiating a base exchange. Alternatively, a range 49152-65535 for initiating a base exchange. Alternatively, a
host MAY also use a single fixed port for initiating all outgoing host MAY also use a single fixed port for initiating all outgoing
connections. However, the allocated port MUST be maintained until connections. However, the allocated port MUST be maintained until
all of the corresponding HIP Associations are closed. It is all of the corresponding HIP Associations are closed. It is
RECOMMENDED that the HIP relay server listens to incoming connections RECOMMENDED that the HIP relay server listens to incoming connections
at UDP port HIPPORT. If some other port number is used, it needs to at UDP port HIPPORT. If some other port number is used, it needs to
be communicated to possible Initiators. be communicated to possible Initiators.
In step 2, the HIP relay server (Responder) lists the services that In step 2, the HIP relay server (Responder) lists the services that
it supports in the R1 packet. The support for HIP-over-UDP relaying it supports in the R1 packet. The support for HIP-over-UDP relaying
is denoted by the Registration Type [RFC5203] value RELAY_UDP_HIP. is denoted by the Registration Type value RELAY_UDP_HIP (see
Section 5.9).
In step 3, the Initiator selects the services it registers for and In step 3, the Initiator selects the services it registers for and
lists them in the REG_REQ parameter. The Initiator registers for HIP lists them in the REG_REQ parameter. The Initiator registers for HIP
relay service by listing the RELAY_UDP_HIP value in the request relay service by listing the RELAY_UDP_HIP value in the request
parameter. parameter.
In step 4, the Responder concludes the registration procedure with an In step 4, the Responder concludes the registration procedure with an
R2 packet and acknowledges the registered services in the REG_RES R2 packet and acknowledges the registered services in the REG_RES
parameter. The Responder denotes unsuccessful registrations (if any) parameter. The Responder denotes unsuccessful registrations (if any)
in the REG_FAILED parameter of R2. The Responder also includes a in the REG_FAILED parameter of R2. The Responder also includes a
skipping to change at page 10, line 23 skipping to change at page 10, line 25
4.2. ICE Candidate Gathering 4.2. ICE Candidate Gathering
If a host is going to use ICE, it needs to gather a set of address If a host is going to use ICE, it needs to gather a set of address
candidates. The candidate gathering SHOULD be done as defined in candidates. The candidate gathering SHOULD be done as defined in
Section 4.1 of [I-D.ietf-mmusic-ice]. Candidates need to be gathered Section 4.1 of [I-D.ietf-mmusic-ice]. Candidates need to be gathered
for only one media stream and component. Component ID 1 should be for only one media stream and component. Component ID 1 should be
used for ICE processing, where needed. Initiator takes the role of used for ICE processing, where needed. Initiator takes the role of
the ICE controlling agent. the ICE controlling agent.
The candidate gathering can be done at any time, but it needs to be The candidate gathering can be done at any time, but it needs to be
done before sending an I2 or R2 in the end-to-end base exchange (not done before sending an I2 or R2 in the base exchange if ICE is to be
when registering to a relay) if ICE is used for the connectivity used for the connectivity checks. It is RECOMMENDED that all three
checks. It is RECOMMENDED that all three types of candidates (host, types of candidates (host, server reflexive and relayed) are gathered
server reflexive and relayed) are gathered to maximize the to maximize the probability of successful NAT traversal. However, if
probability of successful NAT traversal. However, if no TURN server no TURN server is used, and the host has only a single local IP
is used, and the host has only a single local IP address to use, the address to use, the host MAY use the local address as the only host
host MAY use the local address as the only host candidate and the candidate and the address from the REG_FROM parameter discovered
address from the REG_FROM parameter discovered during the relay during the relay registration as a server reflexive candidate. In
registration as a server reflexive candidate. In this case, no this case, no further candidate gathering is needed.
further candidate gathering is needed.
4.3. NAT Traversal Mode Negotiation 4.3. NAT Traversal Mode Negotiation
This section describes the usage of a new non-critical parameter This section describes the usage of a new non-critical parameter
type. The presence of the parameter in a HIP base exchange means type. The presence of the parameter in a HIP base exchange means
that the end-host supports NAT traversal extensions described in this that the end-host supports NAT traversal extensions described in this
document. As the parameter is non-critical, it can be ignored by an document. As the parameter is non-critical (as defined in Section
end-host which means that the host does not support or is not willing 5.2.1 of [RFC5201]), it can be ignored by an end-host which means
to use these extensions ("critical" parameters are defined in that the host does not support or is not willing to use these
[RFC5201]). extensions.
The NAT traversal mode parameter applies to a base exchange between With registration to a HIP relay it is usually sufficient to use UDP-
end-hosts, but does not apply to a registration with a HIP relay ENCAPSULATION mode of NAT traversal since the relay should not be
server, which always uses UDP-ENCAPSULATION mode. The NAT traversal behind a NAT. Thus, the relay SHOULD propose the UDP-ENCAPSULATION
mode negotiation in a HIP base exchange is illustrated in Figure 3. mode as the preferred or only mode. The NAT traversal mode
negotiation in a HIP base exchange is illustrated in Figure 3.
Initiator Responder Initiator Responder
| 1. UDP(I1) | | 1. UDP(I1) |
+------------------------------------------------------------->| +--------------------------------------------------------------->|
| | | |
| 2. UDP(R1(.., NAT_TRAVERSAL_MODE(list of modes), ..)) | | 2. UDP(R1(.., NAT_TRAVERSAL_MODE(list of modes), ..)) |
|<-------------------------------------------------------------+ |<---------------------------------------------------------------+
| | | |
| 3. UDP(I2(.., NAT_TRAVERSAL_MODE(selected mode), LOCATOR..)) | | 3. UDP(I2(.., NAT_TRAVERSAL_MODE(selected mode), LOCATOR, ..)) |
+------------------------------------------------------------->| +--------------------------------------------------------------->|
| | | |
| 4. UDP(R2(.., LOCATOR, ..)) | | 4. UDP(R2(.., LOCATOR, ..)) |
|<-------------------------------------------------------------+ |<---------------------------------------------------------------+
| .... | | |
Figure 3: Negotiation of NAT Traversal Mode Figure 3: Negotiation of NAT Traversal Mode
In step 1, the Initiator sends an I1 to the Responder. In step 2, In step 1, the Initiator sends an I1 to the Responder. In step 2,
the Responder responds with an R1. The R1 contains a list of NAT the Responder responds with an R1. The NAT_TRAVERSAL_MODE parameter
traversal modes the Responder supports in the NAT_TRAVERSAL_MODE in R1 contains a list of NAT traversal modes the Responder supports.
parameter as shown in Table 1. The modes specified in this document are shown in Table 1 and their
values in Section 5.4.
+-------------------+-----------------------------------------------+ +-------------------+-----------------------------------------------+
| Type | Purpose | | Type | Purpose |
+-------------------+-----------------------------------------------+ +-------------------+-----------------------------------------------+
| RESERVED | Reserved for future use | | RESERVED | Reserved for future use |
| UDP-ENCAPSULATION | Use only UDP encapsulation of the HIP | | UDP-ENCAPSULATION | Use only UDP encapsulation of the HIP |
| | signaling traffic and ESP (no ICE | | | signaling traffic and ESP (no ICE |
| | connectivity checks) | | | connectivity checks) |
| ICE-STUN-UDP | UDP encapsulated control and data traffic | | ICE-STUN-UDP | UDP-encapsulated control and data traffic |
| | with ICE-based connectivity checks using STUN | | | with ICE-based connectivity checks using STUN |
| | messages | | | messages |
+-------------------+-----------------------------------------------+ +-------------------+-----------------------------------------------+
Table 1: NAT Traversal Modes Table 1: NAT Traversal Modes
In step 3, the Initiator sends an I2 that includes a In step 3, the Initiator sends an I2 that includes a
NAT_TRAVERSAL_MODE parameter. It contains the mode selected by the NAT_TRAVERSAL_MODE parameter. It contains the mode selected by the
Initiator from the list of modes offered by the Responder. The I2 Initiator from the list of modes offered by the Responder. If ICE
also includes the locators of the Initiator in a LOCATOR parameter. mode was selected, the I2 also includes the "Transport address"
The locator parameter in I2 is the "ICE offer". locators (as defined in Section 5.7) of the Initiator in a LOCATOR
parameter. The locators in I2 are the "ICE offer".
In step 4, the Responder concludes the base exchange with an R2 In step 4, the Responder concludes the base exchange with an R2
packet. The Responder includes a LOCATOR parameter in the R2 packet. packet. If the Initiator chose ICE NAT traversal mode, the Responder
The locator parameter in R2 is the "ICE answer". includes a LOCATOR parameter in the R2 packet. The locators in R2,
encoded like the locators in I2, are the "ICE answer". If the NAT
traversal mode selected by the Initiator is not supported by the
Responder, the Responder SHOULD reply with NOTIFY packet with type
NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER and abort the base exchange.
4.4. Connectivity Check Pacing Negotiation 4.4. Connectivity Check Pacing Negotiation
As explained in [I-D.ietf-mmusic-ice], when a NAT traversal mode with As explained in [I-D.ietf-mmusic-ice], when a NAT traversal mode with
connectivity checks is used, new transactions should not be started connectivity checks is used, new transactions should not be started
too fast to avoid congestion and overwhelming the NATs. too fast to avoid congestion and overwhelming the NATs.
For this purpose, during the base exchange, hosts can negotiate a For this purpose, during the base exchange, hosts can negotiate a
transaction pacing value, Ta, using a TRANSACTION_PACING parameter in transaction pacing value, Ta, using a TRANSACTION_PACING parameter in
R1 and I2 messages. The parameter contains the minimum time R1 and I2 packets. The parameter contains the minimum time
(expressed in milliseconds) the host would wait between two NAT (expressed in milliseconds) the host would wait between two NAT
traversal transactions, such as starting a new connectivity check or traversal transactions, such as starting a new connectivity check or
retrying a previous check. If a host does not include this parameter retrying a previous check. If a host does not include this parameter
in the base exchange, a Ta value of 500ms MUST be used as that host's in the base exchange, a Ta value of 500ms MUST be used as that host's
minimum value. The value that is used by both of the hosts is the minimum value. The value that is used by both of the hosts is the
higher out of the two offered values. higher out of the two offered values.
Hosts SHOULD NOT use values smaller than 20ms for the minimum Ta, Hosts SHOULD NOT use values smaller than 20ms for the minimum Ta,
since such values may not work well with some NATs, as explained in since such values may not work well with some NATs, as explained in
[I-D.ietf-mmusic-ice]. The Initiator MUST NOT propose a smaller [I-D.ietf-mmusic-ice]. The Initiator MUST NOT propose a smaller
value than what the Responder offered. value than what the Responder offered.
The minimum Ta value SHOULD be configurable. Guidelines for The minimum Ta value SHOULD be configurable. Guidelines for
selecting a Ta value are given in Appendix A. Currently this feature selecting a Ta value are given in Appendix A. Currently this feature
applies only to the ICE-STUN-UDP NAT traversal mode. applies only to the ICE-STUN-UDP NAT traversal mode, but any other
mode using connectivity checks SHOULD utilize this feature.
4.5. Base Exchange via HIP Relay Server 4.5. Base Exchange via HIP Relay Server
This section describes how Initiator and Responder perform a base This section describes how Initiator and Responder perform a base
exchange through a HIP relay server. The NAT traversal mode exchange through a HIP relay server. The NAT traversal mode
negotiation (denoted as NAT_TM in the example) was described in the negotiation (denoted as NAT_TM in the example) was described in
previous section and shall not be repeated here. If a relay receives Section 4.3 and is not repeated here. If a relay receives an R1 or
an R1 or I2 packet without the NAT traversal mode parameter, it drops I2 packet without the NAT traversal mode parameter, it MUST drop it
it and sends a NOTIFY error message with type and SHOULD send a NOTIFY error packet with type
NO_NAT_TRAVERSAL_MODE_PARAMETER to the sender of the R1/I2. NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER to the sender of the R1/I2.
It is RECOMMENDED that the Initiator sends an I1 packet encapsulated It is RECOMMENDED that the Initiator sends an I1 packet encapsulated
in UDP when it is destined to an IPv4 address of the Responder. in UDP when it is destined to an IPv4 address of the Responder.
Respectively, the Responder MUST respond to such an I1 packet with a Respectively, the Responder MUST respond to such an I1 packet with a
UDP encapsulated R1 packet and the rest of the base exchange, I2 and UDP-encapsulated R1 packet and the rest of the base exchange, I2 and
R2, MUST also use UDP encapsulation. R2, MUST also use UDP encapsulation.
I HIP relay R I HIP relay R
| 1. UDP(I1) | | | 1. UDP(I1) | |
+----------------------------->| 2. UDP(I1(RELAY_FROM)) | +----------------------------->| 2. UDP(I1(RELAY_FROM)) |
| +------------------------------->| | +------------------------------->|
| | | | | |
| | 3. UDP(R1(RELAY_TO, NAT_TM)) | | | 3. UDP(R1(RELAY_TO, NAT_TM)) |
| 4. UDP(R1(RELAY_TO),NAT_TM ) |<-------------------------------+ | 4. UDP(R1(RELAY_TO, NAT_TM)) |<-------------------------------+
|<-----------------------------+ | |<-----------------------------+ |
| | | | | |
| 5. UDP(I2(LOCATOR),NAT_TM) | | | 5. UDP(I2(LOCATOR, NAT_TM)) | |
+----------------------------->| 6. UDP(I2(LOCATOR,RELAY_FROM),| +----------------------------->| 6. UDP(I2(LOCATOR, RELAY_FROM, |
| | NAT_TM) | | | NAT_TM)) |
| +------------------------------->| | +------------------------------->|
| | | | | |
| | 7. UDP(R2(LOCATOR,RELAY_TO)) | | | 7. UDP(R2(LOCATOR,RELAY_TO)) |
| 8. UDP(R2(LOCATOR,RELAY_TO)) |<-------------------------------+ | 8. UDP(R2(LOCATOR,RELAY_TO)) |<-------------------------------+
|<-----------------------------+ | |<-----------------------------+ |
| | | | | |
Figure 4: Base Exchange via a HIP Relay Server Figure 4: Base Exchange via a HIP Relay Server
In step 1 of Figure 4, the Initiator sends an I1 packet over the In step 1 of Figure 4, the Initiator sends an I1 packet over the
transport layer to the HIT of the Responder (and IP address of the transport layer to the HIT of the Responder and IP address and port
relay). The source address is one of the locators of the Initiator. of the HIP relay server. The source address is one of the locators
of the Initiator.
In step 2, the HIP relay server receives the I1 packet. If the In step 2, the HIP relay server receives the I1 packet. If the
destination HIT belongs to a registered Responder, the relay destination HIT belongs to a registered Responder, the relay
processes the packet. Otherwise, the relay MUST drop the packet processes the packet. Otherwise, the relay MUST drop the packet
silently. The relay appends a RELAY_FROM parameter to the I1 packet silently. The relay appends a RELAY_FROM parameter to the I1 packet
which contains the transport source address and port of the I1 as which contains the transport source address and port of the I1 as
observed by the relay. The relay protects the I1 packet with observed by the relay. The relay protects the I1 packet with
RELAY_HMAC as described in [RFC5204], except that the parameter type RELAY_HMAC as described in [RFC5204], except that the parameter type
is different (see Section 5.8). The relay changes the source and is different (see Section 5.8). The relay changes the source and
destination ports and IP addresses of the packet to match the values destination ports and IP addresses of the packet to match the values
the Responder used when registering to the relay, i.e., the reverse the Responder used when registering to the relay, i.e., the reverse
of the R2 used in the registration. The relay MUST recalculate the of the R2 used in the registration. The relay MUST recalculate the
transport checksum and forward the packet to the Responder. transport checksum and forward the packet to the Responder.
In step 3, the Responder receives the I1 packet. The Responder In step 3, the Responder receives the I1 packet. The Responder
processes it according to the rules in [RFC5201]. In addition, the processes it according to the rules in [RFC5201]. In addition, the
Responder validates the RELAY_HMAC according to [RFC5204] and Responder validates the RELAY_HMAC according to [RFC5204] and
silently drops the packet if the validation fails. The Responder silently drops the packet if the validation fails. The Responder
replies with an R1 packet to which it includes a RELAY_TO parameter. replies with an R1 packet to which it includes RELAY_TO and NAT
The RELAY_TO parameter MUST contain same information as the traversal mode parameters. The RELAY_TO parameter MUST contain same
RELAY_FROM parameter, i.e., the Initiator's transport address, but information as the RELAY_FROM parameter, i.e., the Initiator's
the type of the parameter is different. The RELAY_TO parameter is transport address, but the type of the parameter is different. The
not integrity protected by the signature of the R1 to allow pre- RELAY_TO parameter is not integrity protected by the signature of the
created R1 packets at the Responder. R1 to allow pre-created R1 packets at the Responder.
In step 4, the relay receives the R1 packet. The relay drops the In step 4, the relay receives the R1 packet. The relay drops the
packet silently if the source HIT belongs to an unregistered host. packet silently if the source HIT belongs to an unregistered host.
The relay MAY verify the signature of the R1 packet and drop it if The relay MAY verify the signature of the R1 packet and drop it if
the signature is invalid. Otherwise, the relay rewrites the source the signature is invalid. Otherwise, the relay rewrites the source
address and port, and changes the destination address and port to address and port, and changes the destination address and port to
match RELAY_TO information. Finally, the relay recalculates match RELAY_TO information. Finally, the relay recalculates
transport checksum and forwards the packet. transport checksum and forwards the packet.
In step 5, the Initiator receives the R1 packet and processes it In step 5, the Initiator receives the R1 packet and processes it
according to [RFC5201]. It replies with an I2 packet that uses the according to [RFC5201]. The Initiator MAY use the address in the
destination transport address of R1 as the source address and port. RELAY_TO parameter as a local peer-reflexive candidate for this HIP
The I2 contains a LOCATOR parameter that lists all the ICE candidates association if it is different from all known local candidates. The
Initiator replies with an I2 packet that uses the destination
transport address of R1 as the source address and port. The I2
packet contains a LOCATOR parameter that lists all the ICE candidates
(ICE offer) of the Initiator. The candidates are encoded using the (ICE offer) of the Initiator. The candidates are encoded using the
format defined in Section 5.7. The I2 packet MUST also contain the format defined in Section 5.7. The I2 packet MUST also contain a NAT
NAT traversal mode parameter with ICE-STUN-UDP or some other selected traversal mode parameter with the mode the Initiator selected.
mode.
In step 6, the relay receives the I2 packet. The relay appends a In step 6, the relay receives the I2 packet. The relay appends a
RELAY_FROM and a RELAY_HMAC to the I2 packet as explained in step 2. RELAY_FROM and a RELAY_HMAC to the I2 packet as explained in step 2.
In step 7, the Responder receives the I2 packet and processes it In step 7, the Responder receives the I2 packet and processes it
according to [RFC5201]. It replies with an R2 packet and includes a according to [RFC5201]. It replies with an R2 packet and includes a
RELAY_TO parameter as explained in step 3. The R2 packet includes a RELAY_TO parameter as explained in step 3. The R2 packet includes a
LOCATOR parameter that lists all the ICE candidates (ICE answer) of LOCATOR parameter that lists all the ICE candidates (ICE answer) of
the Responder. The RELAY_TO parameter is protected by the HMAC. the Responder. The RELAY_TO parameter is protected by the HMAC.
In step 8, the relay processes the R2 as described in step 4. The In step 8, the relay processes the R2 as described in step 4. The
relay forwards the packet to the Initiator. relay forwards the packet to the Initiator. After the Initiator has
received the R2 and processed it successfully, the base exchange is
completed.
Hosts MUST include the address of one or more HIP relay servers Hosts MUST include the address of one or more HIP relay servers
(including the one that is being used for the initial signaling) in (including the one that is being used for the initial signaling) in
the LOCATOR parameter in I2/R2 if they intend to use such servers for the LOCATOR parameter in I2/R2 if they intend to use such servers for
relaying HIP signaling after the base exchange completes. The relaying HIP signaling immediately after the base exchange completes.
traffic type of these addresses MUST be "HIP signaling" and they MUST The traffic type of these addresses MUST be "HIP signaling" and they
NOT be used as ICE candidates. If the HIP relay server locator used MUST NOT be used as ICE candidates. If the HIP relay server locator
for the base exchange is not included in I2/R2 LOCATOR parameters, it used for the base exchange is not included in I2/R2 LOCATOR
SHOULD NOT be used after the base exchange, but further HIP signaling parameters, it SHOULD NOT be used after the base exchange, but
SHOULD use the same path as the data traffic. further HIP signaling SHOULD use the same path as the data traffic.
4.6. ICE Connectivity Checks 4.6. ICE Connectivity Checks
If a HIP relay server was used, the Responder completes the base If a HIP relay server was used, the Responder completes the base
exchange with the R2 packet through the relay. However, the exchange with the R2 packet through the relay. However, the
destination address the Initiator and Responder used for delivering destination address the Initiator and Responder used for the base
base exchange packets belonged to the HIP relay server. Therefore, exchange packets belongs to the HIP relay server. Therefore, that
the address of the relay MUST NOT be used for sending ESP traffic. address MUST NOT be used as a destination for ESP traffic. Instead,
if a NAT traversal mode with ICE connectivity checks was selected,
Instead, if a NAT traversal mode with ICE connectivity checks was the Initiator and Responder MUST start the connectivity checks.
selected, the Initiator and Responder MUST start the connectivity
checks.
Creating the check list for the ICE connectivity checks should be Creating the check list for the ICE connectivity checks should be
performed as described in Section 5.7 of [I-D.ietf-mmusic-ice] performed as described in Section 5.7 of [I-D.ietf-mmusic-ice]
bearing in mind that only one media stream and component is needed bearing in mind that only one media stream and component is needed
(so there will be only a single checklist and all candidates should (so there will be only a single checklist and all candidates should
have the same component ID value). The actual connectivity checks have the same component ID value). The actual connectivity checks
MUST be performed as described in Section 7 of [I-D.ietf-mmusic-ice]. MUST be performed as described in Section 7 of [I-D.ietf-mmusic-ice].
Regular mode SHOULD be used for the candidate nomination. Regular mode SHOULD be used for the candidate nomination.
Section 5.2 defines the details of the STUN control packets. As a Section 5.2 defines the details of the STUN control packets. As a
result of the ICE connectivity checks, ICE nominates a single result of the ICE connectivity checks, ICE nominates a single
skipping to change at page 15, line 35 skipping to change at page 15, line 41
For retransmissions, the RTO value should be calculated as follows: For retransmissions, the RTO value should be calculated as follows:
RTO = MAX (500ms, Ta * P) RTO = MAX (500ms, Ta * P)
In the RTO formula, Ta is the value used for the connectivity check In the RTO formula, Ta is the value used for the connectivity check
pacing and P is the number of pairs in the checklist when the pacing and P is the number of pairs in the checklist when the
connectivity checks begin. This is identical to the formula in connectivity checks begin. This is identical to the formula in
[I-D.ietf-mmusic-ice] if there is only one checklist. [I-D.ietf-mmusic-ice] if there is only one checklist.
If the ICE connectivity checks failed, the hosts MUST NOT send ESP
traffic to each other but MAY continue communicating using HIP
packets and the locators used for the base exchange. Also, the hosts
SHOULD notify each other about the failure with a
CONNECTIVITY_CHECKS_FAILED NOTIFY packet (see Section 5.10).
4.7. NAT Keepalives 4.7. NAT Keepalives
To prevent NAT states from expiring, communicating hosts send To prevent NAT states from expiring, communicating hosts send
periodically keepalives to each other. HIP relay servers MAY refrain periodically keepalives to each other. HIP relay servers MAY refrain
from sending keepalives if it's known that they are not behind a from sending keepalives if it's known that they are not behind a
middlebox that requires keepalives. An end-host MUST send keepalives middlebox that requires keepalives. An end-host MUST send keepalives
every 15 seconds to refresh the UDP port mapping at the NAT(s) when every 15 seconds to refresh the UDP port mapping at the NAT(s) when
the control or data channel is idle. To implement failure tolerance, the control or data channel is idle. To implement failure tolerance,
an end-host SHOULD have shorter keepalive period. an end-host SHOULD have shorter keepalive period.
The keepalives are STUN Binding Indications if the hosts have agreed The keepalives are STUN Binding Indications if the hosts have agreed
on ICE-STUN-UDP NAT traversal mode during the base exchange. on ICE-STUN-UDP NAT traversal mode during the base exchange.
Otherwise, HIP NOTIFY messages MAY be used. A HIP relay server MUST Otherwise, HIP NOTIFY packets MAY be used as keepalives.
NOT forward the NOTIFY messages.
The communicating hosts MUST send keepalives to each other using the The communicating hosts MUST send keepalives to each other using the
transport locators they agreed to use for data and signaling when transport locators they agreed to use for data and signaling when
they are in ESTABLISHED state. Also, the Initiator MUST send a they are in ESTABLISHED state. Also, the Initiator MUST send a
NOTIFY message to the relay to keep the NAT states alive on the path NOTIFY packet to the relay to keep the NAT states alive on the path
between the Initiator and relay when the Initiator has not received between the Initiator and relay when the Initiator has not received
any response to its I1 or I2 from the Responder in 15 seconds. The any response to its I1 or I2 from the Responder in 15 seconds.
relay MUST NOT forward the NOTIFY messages.
4.8. Base Exchange without ICE Connectivity Checks 4.8. Base Exchange without ICE Connectivity Checks
In certain network environments, the ICE connectivity checks can be In certain network environments the ICE connectivity checks can be
omitted to reduce initial connection set up latency because base omitted to reduce initial connection set up latency because a base
exchange acts as an implicit connectivity test itself. There are exchange acts as an implicit connectivity test itself. For this to
three assumptions about such environments. First, the Responder work, the Initiator MUST be able to reach the Responder by simply UDP
should have a long-term, fixed locator in the network. Second, the encapsulating HIP and ESP packets sent to the Responder's address.
Responder should not have a HIP relay server configured for itself. Detecting and configuring this particular scenario is prone to
Third, the Initiator can reach the Responder by simply UDP failure unless carefully planned.
encapsulating HIP and ESP packets to the host. Detecting and
configuring this particular scenario is prone to failure unless
carefully planned.
In such a scenario, the Responder MAY include only the UDP- In such a scenario, the Responder MAY include UDP-ENCAPSULATION NAT
ENCAPSULATION NAT traversal mode in the R1 message. Likewise, if the traversal mode as one of the supported modes in the R1 packet. If
Initiator knows that it can receive ESP and HIP signaling traffic by the Responder has registered to a HIP relay server, it MUST also
using simply UDP encapsulation, it can choose the UDP-ENCAPSULATION include a LOCATOR parameter in R1 that contains a preferred address
mode in the I2 message, if the Responder listed it in the supported where the Responder is able to receive UDP-encapsulated ESP and HIP
modes. In both of these cases the locators from I2 and R2 packets packets. This locator MUST be of type "Transport address", its
will be used also for the UDP encapsulated ESP. Traffic type MUST be "both" and it MUST have the "Preferred bit" set
(see Table 2). If there is no such locator in R1, the source address
of R1 is used as the Responder's preferred address.
When no ICE connectivity checks are used, locator exchange and return The Initiator MAY choose the UDP-ENCAPSULATION mode if the Responder
routability tests for mobility and multihoming are done as specified listed it in the supported modes and the Initiator does not wish to
in [RFC5206] with the exception that UDP encapsulation is used. use ICE for searching for a more optimal path. In this case, the
Initiator sends the I2 with UDP-ENCAPSULATION mode in the NAT
traversal mode parameter directly to the Responder's preferred
address (i.e., to the preferred locator in R1 or to the address where
R1 was received from if there was no preferred locator in R1). The
Initiator MAY include locators in I2 but they MUST NOT be taken as
ICE candidates, since ICE will not be used for connections with UDP-
ENCAPSULATION NAT traversal mode. Instead, if R2 and I2 are received
and processed successfully, a security association can be created and
UDP-encapsulated ESP can be exchanged between the hosts after the
base exchange completes. However, the Responder SHOULD NOT send any
ESP to the Initiator's address before it has received data from the
Initiator, as specified in Sections 4.4.2. and 6.9 of [RFC5201] and
in Sections 3.2.9 and 5.4 of [RFC5206].
Since an I2 packet with UDP-ENCAPSULATION NAT traversal mode selected
MUST NOT be sent via a relay, the Responder SHOULD reject such I2
packets and reply with NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER NOTIFY
packet (see Section 5.10).
If there is no answer for the I2 packet sent directly to the
Responder's preferred address, the Initiator MAY send another I2 via
the HIP relay server, but it MUST NOT choose UDP-ENCAPSULATION NAT
traversal mode for that I2.
4.9. Initiating a Base Exchange both with and without UDP Encapsulation 4.9. Initiating a Base Exchange both with and without UDP Encapsulation
The Initiator MAY also try to simultaneously perform a base exchange The Initiator MAY also try to simultaneously perform a base exchange
with the Responder without UDP encapsulation. In such a case, the with the Responder without UDP encapsulation. In such a case, the
Initiator sends two I1 packets, one without and one with UDP Initiator sends two I1 packets, one without and one with UDP
encapsulation, to the Responder. The Initiator MAY wait for a while encapsulation, to the Responder. The Initiator MAY wait for a while
before sending the other I1. How long to wait and in which order to before sending the other I1. How long to wait and in which order to
send the I1 packets can be decided based on local policy. For send the I1 packets can be decided based on local policy. For
retransmissions, the procedure is repeated. retransmissions, the procedure is repeated.
The I1 packet without UDP encapsulation may arrive directly at the The I1 packet without UDP encapsulation may arrive directly, without
Responder. When the recipient is the Responder, the procedures in any relays, at the Responder. When this happens, the procedures in
[RFC5201] are followed for the rest of the base exchange. The [RFC5201] are followed for the rest of the base exchange. The
Initiator may receive multiple R1 messages, with and without UDP Initiator may receive multiple R1 packets, with and without UDP
encapsulation, from the Responder. However, after receiving a valid encapsulation, from the Responder. However, after receiving a valid
R1 and answering to it with an I2, further R1 messages that are not R1 and answering to it with an I2, further R1 packets that are not
retransmits of the original R1 MUST be ignored. retransmits of the original R1 MUST be ignored.
The I1 packet without UDP encapsulation may also arrive at a HIP- The I1 packet without UDP encapsulation may also arrive at a HIP-
capable middlebox. When the middlebox is a HIP rendezvous server and capable middlebox. When the middlebox is a HIP rendezvous server and
the Responder has successfully registered to the rendezvous service, the Responder has successfully registered to the rendezvous service,
the middlebox follows rendezvous procedures in [RFC5204]. the middlebox follows rendezvous procedures in [RFC5204].
If the Initiator receives a NAT traversal mode parameter in R1 If the Initiator receives a NAT traversal mode parameter in R1
without UDP encapsulation, the Initiator MAY ignore this parameter without UDP encapsulation, the Initiator MAY ignore this parameter
and send an I2 without UDP encapsulation and without any selected NAT and send an I2 without UDP encapsulation and without any selected NAT
traversal mode. When the Responder receives the I2 without UDP traversal mode. When the Responder receives the I2 without UDP
encapsulation and without NAT traversal mode, it will assume that no encapsulation and without NAT traversal mode, it will assume that no
NAT traversal mechanism is needed. The packet processing will be NAT traversal mechanism is needed. The packet processing will be
done as described in [RFC5201]. The Initiator MAY store the NAT done as described in [RFC5201]. The Initiator MAY store the NAT
traversal modes for future use e.g., to be used in case of mobility traversal modes for future use e.g., to be used in case of mobility
or multihoming event which causes NAT traversal to be taken in to use or multihoming event which causes NAT traversal to be taken in to use
during the lifetime of the HIP association. during the lifetime of the HIP association.
4.10. Sending Control Messages after the Base Exchange 4.10. Sending Control Packets after the Base Exchange
After the base exchange, the end-hosts MAY send HIP control messages After the base exchange, the end-hosts MAY send HIP control packets
directly to each other using the transport address pair established directly to each other using the transport address pair established
for data channel without sending the control packets through the HIP for data channel without sending the control packets through the HIP
relay server. When a host does not get acknowledgments, e.g., to an relay server. When a host does not get acknowledgments, e.g., to an
UPDATE or CLOSE message after a timeout based on local policies, the UPDATE or CLOSE packet after a timeout based on local policies, the
host SHOULD resend the packet through the relay, if it was listed in host SHOULD resend the packet through the relay, if it was listed in
the LOCATOR parameter in the base exchange. the LOCATOR parameter in the base exchange.
If control messages are sent through a HIP relay server, the sender If control packets are sent through a HIP relay server, the host
MUST include a RELAY_TO parameter to them. Also the HIP relay server registered to the relay MUST utilize the RELAY_TO parameter like in
MUST add a RELAY_FROM parameter to the control messages it relays. the base exchange. The HIP relay server SHOULD forward HIP packets
to the registered hosts and forward packets from a registered host to
the address in the RELAY_TO parameter. The relay MUST add a
RELAY_FROM parameter to the control packets it relays to the
registered hosts.
If the HIP relay server is not willing or able to relay a HIP packet,
it MAY notify the sender of the packet with MESSAGE_NOT_RELAYED error
notification (see Section 5.10).
5. Packet Formats 5. Packet Formats
The following subsections define the parameter and packet encodings The following subsections define the parameter and packet encodings
for the HIP, ESP and ICE connectivity check packets. All values MUST for the HIP, ESP and ICE connectivity check packets. All values MUST
be in network byte order. be in network byte order.
5.1. HIP Control Packets 5.1. HIP Control Packets
0 1 2 3 0 1 2 3
skipping to change at page 18, line 36 skipping to change at page 19, line 16
encapsulation. The UDP header is followed by 32 zero bits that can encapsulation. The UDP header is followed by 32 zero bits that can
be used to differentiate HIP control packets from ESP packets. The be used to differentiate HIP control packets from ESP packets. The
HIP header and parameters follow the conventions of [RFC5201] with HIP header and parameters follow the conventions of [RFC5201] with
the exception that the HIP header checksum MUST be zero. The HIP the exception that the HIP header checksum MUST be zero. The HIP
header checksum is zero for two reasons. First, the UDP header header checksum is zero for two reasons. First, the UDP header
contains already a checksum. Second, the checksum definition in contains already a checksum. Second, the checksum definition in
[RFC5201] includes the IP addresses in the checksum calculation. The [RFC5201] includes the IP addresses in the checksum calculation. The
NATs unaware of HIP cannot recompute the HIP checksum after changing NATs unaware of HIP cannot recompute the HIP checksum after changing
IP addresses. IP addresses.
A HIP relay server or a Responder without a relay MUST listen at UDP A HIP relay server or a Responder without a relay SHOULD listen at
port HIPPORT for incoming UDP encapsulated HIP control packets. UDP port HIPPORT for incoming UDP-encapsulated HIP control packets.
5.2. Connectivity Checks 5.2. Connectivity Checks
The connectivity checks are performed using STUN Binding Requests as The connectivity checks are performed using STUN Binding Requests as
defined in [I-D.ietf-mmusic-ice]. This section describes the details defined in [I-D.ietf-mmusic-ice]. This section describes the details
of the parameters in the STUN messages. of the parameters in the STUN messages.
The Binding Requests MUST use STUN short term credentials with last The Binding Requests MUST use STUN short term credentials with last
32 bits of the HITs of the Initiator and Responder as the username 32 bits of the HITs of the Initiator and Responder as the username
fragments. The username is formed from the username fragments as fragments. The username is formed from the username fragments as
skipping to change at page 19, line 27 skipping to change at page 20, line 9
message integrity of STUN messages. message integrity of STUN messages.
Both the username and password are expressed in ASCII hexadecimal Both the username and password are expressed in ASCII hexadecimal
format to prevent the need to run them through SASLPrep as defined in format to prevent the need to run them through SASLPrep as defined in
[RFC5389]. [RFC5389].
The connectivity checks MUST contain PRIORITY attribute. They MAY The connectivity checks MUST contain PRIORITY attribute. They MAY
contain USE-CANDIDATE attribute as defined in Section 7.1.1.1 of contain USE-CANDIDATE attribute as defined in Section 7.1.1.1 of
[I-D.ietf-mmusic-ice]. [I-D.ietf-mmusic-ice].
The Initiator is always in the controller role during a base The Initiator is always in the controlling role during a base
exchange. Hence, the ICE-CONTROLLED and ICE-CONTROLLING attributes exchange. When two hosts are initiating a connection to each other
are not needed and SHOULD NOT be used. When two hosts are initiating simultaneously, HIP state machine detects it and assigns the host
a connection to each other simultaneously, HIP state machine detects with the larger HIT as the Responder as explained in Sections 4.4.2
it and assigns the host with the larger HIT as the Responder as and 6.7 in [RFC5201]. Hence, the ICE-CONTROLLED and ICE-CONTROLLING
explained in Sections 4.4.2 and 6.7 in [RFC5201]. attributes are not needed to resolve role conflicts. However, the
attributes SHOULD be added to the connectivity check messages to
ensure interoperability with different ICE stacks and they can be
safely ignored on received connectivity checks.
5.3. Keepalives 5.3. Keepalives
The keepalives for HIP associations that are created with ICE are The keepalives for HIP associations that are created with ICE are
STUN Binding Indications, as defined in [RFC5389]. In contrast to STUN Binding Indications, as defined in [RFC5389]. In contrast to
the UDP encapsulated HIP header, the non-ESP-marker between the UDP the UDP-encapsulated HIP header, the non-ESP-marker between the UDP
header and the STUN header is excluded. Keepalives MUST contain the header and the STUN header is excluded. Keepalives MUST contain the
FINGERPRINT STUN attribute but SHOULD NOT contain any other STUN FINGERPRINT STUN attribute but SHOULD NOT contain any other STUN
attributes and SHOULD NOT utilize any authentication mechanism. STUN attributes and SHOULD NOT utilize any authentication mechanism. STUN
messages are demultiplexed from ESP and HIP control messages using messages are demultiplexed from ESP and HIP control packets using the
the STUN markers, such as the magic cookie value and the FINGERPRINT STUN markers, such as the magic cookie value and the FINGERPRINT
attribute. attribute.
Keepalives for HIP associations created without ICE are HIP control Keepalives for HIP associations created without ICE are HIP control
messages that have NOTIFY as the packet type. The NOTIFY messages do packets that have NOTIFY as the packet type. The keepalive NOTIFY
not contain any parameters. packets do not contain any parameters.
5.4. NAT Traversal Mode Parameter 5.4. NAT Traversal Mode Parameter
Format of the NAT_TRAVERSAL_MODE parameter is similar to the format Format of the NAT_TRAVERSAL_MODE parameter is similar to the format
of the ESP_TRANSFORM parameter in [RFC5202] and is shown in the of the ESP_TRANSFORM parameter in [RFC5202] and is shown in Figure 6.
Figure 6. This specification defines traversal mode identifiers UDP- This specification defines traversal mode identifiers UDP-
ENCAPSULATION and ICE-STUN-UDP. The identifier RESERVED is reserved ENCAPSULATION and ICE-STUN-UDP. The identifier RESERVED is reserved
for future use. Future specifications may define more traversal for future use. Future specifications may define more traversal
modes. modes.
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Mode ID #1 | | Reserved | Mode ID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode ID #2 | Mode ID #3 | | Mode ID #2 | Mode ID #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode ID #n | Padding | | Mode ID #n | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA: 608 ] Type [ TBD by IANA: 608 ]
Length length in octets, excluding Type, Length, and padding Length length in octets, excluding Type, Length, and padding
Reserved zero when sent, ignored when received Reserved zero when sent, ignored when received
Mode ID defines the NAT traversal mode to be used Mode ID defines the proposed or selected NAT traversal mode(s)
The following NAT traversal mode IDs are defined: The following NAT traversal mode IDs are defined:
ID Value ID name Value
RESERVED 0 RESERVED 0
UDP-ENCAPSULATION 1 UDP-ENCAPSULATION 1
ICE-STUN-UDP 2 ICE-STUN-UDP 2
Figure 6: Format of the NAT_TRAVERSAL_MODE parameter Figure 6: Format of the NAT_TRAVERSAL_MODE parameter
The sender of a NAT_TRAVERSAL_MODE parameter MUST make sure that The sender of a NAT_TRAVERSAL_MODE parameter MUST make sure that
there are no more than six (6) Mode IDs in one NAT_TRAVERSAL_MODE there are no more than six (6) Mode IDs in one NAT_TRAVERSAL_MODE
parameter. The limited number of Mode IDs sets the maximum size of parameter. Conversely, a recipient MUST be prepared to handle
the NAT_TRAVERSAL_MODE parameter. received NAT traversal mode parameters that contain more than six
Mode IDs by accepting the first six Mode IDs and dropping the rest.
The limited number of Mode IDs sets the maximum size of the
NAT_TRAVERSAL_MODE parameter. The modes MUST be in preference order,
most preferred mode(s) first.
5.5. Connectivity Check Transaction Pacing Parameter 5.5. Connectivity Check Transaction Pacing Parameter
The TRANSACTION_PACING parameter shown in Figure 7 contains only the The TRANSACTION_PACING parameter shown in Figure 7 contains only the
connectivity check pacing value, expressed in milliseconds, as 32 bit connectivity check pacing value, expressed in milliseconds, as 32 bit
unsigned integer. unsigned integer.
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Ta | | Min Ta |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA: 610 ] Type [ TBD by IANA: 610 ]
Length length in octets, excluding Type and Length Length 4
Min Ta the minimum connectivity check transaction pacing Min Ta the minimum connectivity check transaction pacing
value the host would use value the host would use
Figure 7: Format of the TRANSACTION_PACING parameter Figure 7: Format of the TRANSACTION_PACING parameter
5.6. Relay and Registration Parameters 5.6. Relay and Registration Parameters
Format of the REG_FROM, RELAY_FROM and RELAY_TO parameters is shown Format of the REG_FROM, RELAY_FROM and RELAY_TO parameters is shown
in Figure 8. All parameters are identical except for the type. in Figure 8. All parameters are identical except for the type.
REG_FROM is the only parameter covered with the signature. REG_FROM is the only parameter covered with the signature.
skipping to change at page 22, line 7 skipping to change at page 23, line 7
17 for UDP, 0 for plain IP. 17 for UDP, 0 for plain IP.
Reserved reserved for future use; zero when sent, ignored Reserved reserved for future use; zero when sent, ignored
when received when received
Address an IPv6 address or an IPv4 address in "IPv4-Mapped Address an IPv6 address or an IPv4 address in "IPv4-Mapped
IPv6 address" format IPv6 address" format
Figure 8: Format of the REG_FROM, RELAY_FROM and RELAY_TO parameters Figure 8: Format of the REG_FROM, RELAY_FROM and RELAY_TO parameters
REG_FROM contains the transport address and protocol where the HIP REG_FROM contains the transport address and protocol where the HIP
relay server sees the registration coming from. RELAY_FROM contains relay server sees the registration coming from. RELAY_FROM contains
the address where the relayed packet was received from by the relay the address where the relayed packet was received from by the relay
server and the protocol that was used. The RELAY_TO contains same server and the protocol that was used. RELAY_TO contains same
information about the address where a packet should be forwarded to. information about the address where a packet should be forwarded to.
5.7. LOCATOR Parameter 5.7. LOCATOR Parameter
The generic LOCATOR parameter format is the same as in [RFC5206]. The generic LOCATOR parameter format is the same as in [RFC5206].
However, presenting ICE candidates requires a new locator type. The However, presenting ICE candidates requires a new locator type. The
generic and NAT traversal specific locator parameters are illustrated generic and NAT traversal specific locator parameters are illustrated
in Figure 9. in Figure 9.
0 1 2 3 0 1 2 3
skipping to change at page 22, line 44 skipping to change at page 23, line 44
| Traffic Type | Loc Type = 2 | Locator Length| Reserved |P| | Traffic Type | Loc Type = 2 | Locator Length| Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Lifetime | | Locator Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Port | Transp. Proto| Kind | | Transport Port | Transp. Proto| Kind |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI | | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator | | Address |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: LOCATOR parameter Figure 9: LOCATOR parameter
The individual fields in the LOCATOR parameter are described in The individual fields in the LOCATOR parameter are described in
Table 2. Table 2.
+-----------+----------+--------------------------------------------+ +-----------+----------+--------------------------------------------+
skipping to change at page 23, line 20 skipping to change at page 24, line 20
| Type | 193 | Parameter type | | Type | 193 | Parameter type |
| Length | Variable | Length in octets, excluding Type and | | Length | Variable | Length in octets, excluding Type and |
| | | Length fields and padding | | | | Length fields and padding |
| Traffic | 0-2 | Is the locator for HIP signaling (1), for | | Traffic | 0-2 | Is the locator for HIP signaling (1), for |
| Type | | ESP (2), or for both (0) | | Type | | ESP (2), or for both (0) |
| Locator | 2 | "Transport address" locator type | | Locator | 2 | "Transport address" locator type |
| Type | | | | Type | | |
| Locator | 7 | Length of the fields after Locator | | Locator | 7 | Length of the fields after Locator |
| Length | | Lifetime in 4-octet units | | Length | | Lifetime in 4-octet units |
| Reserved | 0 | Reserved for future extensions | | Reserved | 0 | Reserved for future extensions |
| Preferred | 0 | Not used for transport address locators; | | Preferred | 0 or 1 | Set to 1 for a Locator in R1 if the |
| (P) bit | | MUST be ignored by the receiver. | | (P) bit | | Responder can use it for the rest of the |
| | | base exchange, otherwise set to zero |
| Locator | Variable | Locator lifetime in seconds | | Locator | Variable | Locator lifetime in seconds |
| Lifetime | | | | Lifetime | | |
| Transport | Variable | Transport layer port number | | Transport | Variable | Transport layer port number |
| Port | | | | Port | | |
| Transport | Variable | IANA Assigned, transport layer Internet | | Transport | Variable | IANA Assigned, transport layer Internet |
| Protocol | | Protocol number. Currently only UDP (17) | | Protocol | | Protocol number. Currently only UDP (17) |
| | | is supported. | | | | is supported. |
| Kind | Variable | 0 for host, 1 for server reflexive, 2 for | | Kind | Variable | 0 for host, 1 for server reflexive, 2 for |
| | | peer reflexive or 3 for relayed address | | | | peer reflexive or 3 for relayed address |
| Priority | Variable | Locator's priority as described in | | Priority | Variable | Locator's priority as described in |
| | | [I-D.ietf-mmusic-ice] | | | | [I-D.ietf-mmusic-ice] |
| SPI | Variable | SPI value which the host expects to see in | | SPI | Variable | SPI value which the host expects to see in |
| | | incoming ESP packets that use this locator | | | | incoming ESP packets that use this locator |
| Locator | Variable | IPv6 address or an "IPv4-Mapped IPv6 | | Address | Variable | IPv6 address or an "IPv4-Mapped IPv6 |
| | | address" format IPv4 address [RFC4291] | | | | address" format IPv4 address [RFC4291] |
+-----------+----------+--------------------------------------------+ +-----------+----------+--------------------------------------------+
Table 2: Fields of the LOCATOR parameter Table 2: Fields of the LOCATOR parameter
5.8. RELAY_HMAC Parameter 5.8. RELAY_HMAC Parameter
The RELAY_HMAC parameter value has the TLV type 65520 (2^16 - 2^5 + The RELAY_HMAC parameter value has the TLV type 65520 (2^16 - 2^5 +
2^4). It has the same semantics as RVS_HMAC [RFC5204]. 2^4). It has the same semantics as RVS_HMAC [RFC5204].
5.9. Registration Types 5.9. Registration Types
The REG_INFO, REG_REQ, REG_RESP and REG_FAILED parameters contain The REG_INFO, REG_REQ, REG_RESP and REG_FAILED parameters contain
Registration Type [RFC5203] values for HIP relay server registration. Registration Type [RFC5203] values for HIP relay server registration.
The value for RELAY_UDP_HIP is 2. The value for RELAY_UDP_HIP is 2.
5.10. Notify Message Types 5.10. Notify Packet Types
If the HIP relay server does not forward a base exchange message due A HIP relay server and end hosts can use NOTIFY packets to signal
to missing NAT traversal mode parameter, it sends back a NOTIFY error different error conditions. The new Notify Packet Types [RFC5201]
message with Notify Message Type [RFC5201] defined in this document are shown below [values TBD by IANA]. The
NO_NAT_TRAVERSAL_MODE_PARAMETER. The value for this type is 60. The Notification Data field for the error notifications SHOULD contain
Notification Data field for the error message MUST be empty. the HIP header of the rejected packet and SHOULD be empty for the
CONNECTIVITY_CHECKS_FAILED type.
NOTIFICATION PARAMETER - ERROR TYPES Value
------------------------------------ -----
NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER 60
If a HIP relay server does not forward a base exchange packet due
to missing NAT traversal mode parameter, or the Initiator selects
a NAT traversal mode that the Responder did not expect, the relay
or the Responder may send back a NOTIFY error packet with this
type.
CONNECTIVITY_CHECKS_FAILED 61
Used by the end hosts to signal that NAT traversal connectivity
checks failed and did not produce a working path.
MESSAGE_NOT_RELAYED 62
Used by a HIP relay server to signal that is was not able or
willing to relay a HIP packet.
5.11. ESP Data Packets 5.11. ESP Data Packets
[RFC3948] describes UDP encapsulation of the IPsec ESP transport and [RFC3948] describes UDP encapsulation of the IPsec ESP transport and
tunnel mode. On the wire, the HIP ESP packets do not differ from the tunnel mode. On the wire, the HIP ESP packets do not differ from the
transport mode ESP and thus the encapsulation of the HIP ESP packets transport mode ESP and thus the encapsulation of the HIP ESP packets
is same as the UDP encapsulation transport mode ESP. However, the is same as the UDP encapsulation transport mode ESP. However, the
(semantic) difference to BEET mode ESP packets used by HIP is that IP (semantic) difference to BEET mode ESP packets used by HIP is that IP
header is not used in BEET integrity protection calculation. header is not used in BEET integrity protection calculation.
skipping to change at page 24, line 39 skipping to change at page 26, line 14
defined in [RFC5202]. The UDP encapsulation format and processing of defined in [RFC5202]. The UDP encapsulation format and processing of
HIP ESP traffic is described in Section 6.1 of [RFC5202]. HIP ESP traffic is described in Section 6.1 of [RFC5202].
6. Security Considerations 6. Security Considerations
6.1. Privacy Considerations 6.1. Privacy Considerations
The locators are in plain text format in favor of inspection at HIP- The locators are in plain text format in favor of inspection at HIP-
aware middleboxes in the future. The current draft does not specify aware middleboxes in the future. The current draft does not specify
encrypted versions of LOCATORs even though it could be beneficial for encrypted versions of LOCATORs even though it could be beneficial for
privacy reasons. privacy reasons to avoid disclosing them to middleboxes.
It is possible that an Initiator or Responder may not want to reveal
all of its locators to its peer. For example, a host may not want to
reveal the internal topology of the private address realm and it
discards host addresses. Such behavior creates non-optimal paths
when the hosts are located behind the same NAT. Especially, this
could be a problem with a legacy NAT that does not support routing
from the private address realm back to itself through the outer
address of the NAT. This scenario is referred to as the hairpin
problem [RFC5128]. With such a legacy NAT, the only option left
would be to use a relayed transport address from a TURN server.
As a consequence, a host may support locator-based privacy by leaving It is also possible that end-users may not want to reveal all
out the reflexive candidates. However, the trade-off in using only locators to each other. For example, tracking the physical location
host candidates can produce suboptimal paths that can congest the of a multihoming end-host may become easier if it reveals all
TURN server. locators to its peer during a base exchange. Also, revealing host
addresses exposes information about the local topology which may not
be allowed in all corporate environments. For these two reasons, an
end-host may exclude certain host addresses from its LOCATOR
parameter. However, such behavior creates non-optimal paths when the
hosts are located behind the same NAT. Especially, this could be
problematic with a legacy NAT that does not support routing from the
private address realm back to itself through the outer address of the
NAT. This scenario is referred to as the hairpin problem [RFC5128].
With such a legacy NAT, the only option left would be to use a
relayed transport address from a TURN server.
The use of HIP relay servers or TURN relays can be also useful for The use of HIP relay servers and TURN relays can be also useful for
protection against Denial-of-Service attacks. If a Responder reveals privacy purposes. For example, a privacy concerned Responder may
only its HIP relay server addresses and Relayed candidates to reveal only its HIP relay server and Relayed candidates to
Initiators, the Initiators can only attack the relays. That does not Initiators. This same mechanism also protects the Responder against
prevent the Responder from initiating new outgoing connections if a Denial-of-Service attacks by allowing the Responder to initiate new
path around the relay exists. connections even if its relays would be unavailable due to a DoS
attack.
6.2. Opportunistic Mode 6.2. Opportunistic Mode
A HIP relay server should have one address per relay client when a A HIP relay server should have one address per relay client when a
HIP relay is serving more than one relay clients and supports HIP relay is serving more than one relay clients and supports
opportunistic mode. Otherwise, it cannot be guaranteed that the HIP opportunistic mode. Otherwise, it cannot be guaranteed that the HIP
relay server can deliver the I1 packet to the intended recipient. relay server can deliver the I1 packet to the intended recipient.
6.3. Base Exchange Replay Protection for HIP Relay Server 6.3. Base Exchange Replay Protection for HIP Relay Server
In certain scenarios, it is possible that an attacker, or two In certain scenarios, it is possible that an attacker, or two
attackers, can replay an earlier base exchange through a HIP relay attackers, can replay an earlier base exchange through a HIP relay
server by masquerading as the original Initiator and Responder. The server by masquerading as the original Initiator and Responder. The
attack does not require the attacker(s) to compromise the private attack does not require the attacker(s) to compromise the private
key(s) of the attacked host(s). However, for this attack to succeed, key(s) of the attacked host(s). However, for this attack to succeed,
the Responder has to be disconnected from the HIP relay server. the Responder has to be disconnected from the HIP relay server.
The relay can protect itself against replay attacks by involving in The relay can protect itself against replay attacks by involving in
the base exchange by introducing nonces that the end-hosts (Initiator the base exchange by introducing nonces that the end-hosts (Initiator
and Responder) have to sign. One way to do this is to add and Responder) have to sign. One way to do this is to add
ECHO_REQUEST_M parameters to the R1 and I2 messages as described in ECHO_REQUEST_M parameters to the R1 and I2 packets as described in
[I-D.heer-hip-middle-auth] and drop the I2 or R2 messages if the [I-D.heer-hip-middle-auth] and drop the I2 or R2 packets if the
corresponding ECHO_RESPONSE_M parameters are not present. corresponding ECHO_RESPONSE_M parameters are not present.
6.4. Demuxing Different HIP Associations 6.4. Demuxing Different HIP Associations
Section 5.1 of [RFC3948] describes a security issue for the UDP Section 5.1 of [RFC3948] describes a security issue for the UDP
encapsulation in the standard IP tunnel mode when two hosts behind encapsulation in the standard IP tunnel mode when two hosts behind
different NATs have the same private IP address and initiate different NATs have the same private IP address and initiate
communication to the same Responder in the public Internet. The communication to the same Responder in the public Internet. The
Responder cannot distinguish between two hosts, because security Responder cannot distinguish between two hosts, because security
associations are based on the same inner IP addresses. associations are based on the same inner IP addresses.
This issue does not exist with the UDP encapsulation of HIP ESP This issue does not exist with the UDP encapsulation of HIP ESP
transport format because the Responder uses HITs to distinguish transport format because the Responder uses HITs to distinguish
between different Initiators. between different Initiators.
7. IANA Considerations 7. IANA Considerations
This section is to be interpreted according to [RFC5226]. This section is to be interpreted according to [RFC5226].
This draft currently uses a UDP port in the "Dynamic and/or Private Upon publication of this document, IANA is requested to register a
Port" and HIPPORT. Upon publication of this document, IANA is UDP port and the RFC editor is requested to change all occurrences of
requested to register a UDP port and the RFC editor is requested to port HIPPORT to the port IANA has registered. The HIPPORT number
change all occurrences of port HIPPORT to the port IANA has 50500 should be used for initial experimentation.
registered. The HIPPORT number 50500 should be used for initial
experimentation.
This document updates the IANA Registry for HIP Parameter Types This document updates the IANA Registry for HIP Parameter Types
[RFC5201] by assigning new HIP Parameter Type values for the new HIP [RFC5201] by assigning new HIP Parameter Type values for the new HIP
Parameters: RELAY_FROM, RELAY_TO and REG_FROM (defined in Parameters: RELAY_FROM, RELAY_TO and REG_FROM (defined in
Section 5.6), RELAY_HMAC (defined in Section 5.8), TRANSACTION_PACING Section 5.6), RELAY_HMAC (defined in Section 5.8), TRANSACTION_PACING
(defined in Section 5.5), and NAT_TRAVERSAL_MODE (defined in (defined in Section 5.5), and NAT_TRAVERSAL_MODE (defined in
Section 5.4). Section 5.4).
This document defines an additional registration type for the HIP This document defines an additional registration type for the HIP
Registration Extension [RFC5203] that allows registering with a HIP Registration Extension [RFC5203] that allows registering with a HIP
relay server for relaying service: RELAY_UDP_HIP (defined in relay server for relaying service: RELAY_UDP_HIP (defined in
Section 5.9). Section 5.9).
This document also defines a NO_NAT_TRAVERSAL_MODE_PARAMETER Notify This document also defines NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER,
Message Type [RFC5201] in Section 5.10. CONNECTIVITY_CHECKS_FAILED and MESSAGE_NOT_RELAYED Notify Packet
Types [RFC5201] in Section 5.10.
The NAT_TRAVERSAL_MODE parameter has 8-bit unsigned integer fields
for different modes, for which IANA is to create and maintain a new
sub-registry entitled "HIP NAT traversal modes" under the "Host
Identity Protocol (HIP) Parameters". Initial values for the NAT
traversal mode registry are given in Section 5.4; future assignments
are to be made through IETF Review [RFC5226]. Assignments consist of
a NAT traversal mode identifier name and its associated value. [TO
BE REMOVED: This registration should take place at the following
location: http://www.iana.org/assignments/hip-parameters/]
8. Contributors 8. Contributors
This draft is a product of a design team which also included Marcelo This draft is a product of a design team which also included Marcelo
Bagnulo and Philip Matthews who both have made major contributions to Bagnulo and Philip Matthews who both have made major contributions to
this document. this document.
9. Acknowledgments 9. Acknowledgments
Thanks for Jonathan Rosenberg and the rest of the MMUSIC WG folks for Thanks for Jonathan Rosenberg and the rest of the MMUSIC WG folks for
skipping to change at page 27, line 4 skipping to change at page 28, line 36
thank Andrei Gurtov, Simon Schuetz, Martin Stiemerling, Lars Eggert, thank Andrei Gurtov, Simon Schuetz, Martin Stiemerling, Lars Eggert,
Vivien Schmitt, Abhinav Pathak for their contributions and Tobias Vivien Schmitt, Abhinav Pathak for their contributions and Tobias
Heer, Teemu Koponen, Juhana Mattila, Jeffrey M. Ahrenholz, Kristian Heer, Teemu Koponen, Juhana Mattila, Jeffrey M. Ahrenholz, Kristian
Slavov, Janne Lindqvist, Pekka Nikander, Lauri Silvennoinen, Jukka Slavov, Janne Lindqvist, Pekka Nikander, Lauri Silvennoinen, Jukka
Ylitalo, Juha Heinanen, Joakim Koskela, Samu Varjonen, Dan Wing and Ylitalo, Juha Heinanen, Joakim Koskela, Samu Varjonen, Dan Wing and
Jani Hautakorpi for their comments on this document. Jani Hautakorpi for their comments on this document.
Miika Komu is working in the Networking Research group at Helsinki Miika Komu is working in the Networking Research group at Helsinki
Institute for Information Technology (HIIT). The InfraHIP project Institute for Information Technology (HIIT). The InfraHIP project
was funded by Tekes, Telia-Sonera, Elisa, Nokia, the Finnish Defence was funded by Tekes, Telia-Sonera, Elisa, Nokia, the Finnish Defence
Forces, and Ericsson and Birdstep. Forces, Ericsson, and Birdstep.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-behave-turn] [I-D.ietf-behave-turn]
Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", Traversal Utilities for NAT (STUN)",
draft-ietf-behave-turn-13 (work in progress), draft-ietf-behave-turn-14 (work in progress), April 2009.
February 2009.
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007. draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 28, line 16 skipping to change at page 29, line 49
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
10.2. Informative References 10.2. Informative References
[I-D.heer-hip-middle-auth] [I-D.heer-hip-middle-auth]
Heer, T., Wehrle, K., and M. Komu, "End-Host Heer, T., Wehrle, K., and M. Komu, "End-Host
Authentication for HIP Middleboxes", Authentication for HIP Middleboxes",
draft-heer-hip-middle-auth-01 (work in progress), draft-heer-hip-middle-auth-02 (work in progress),
July 2008. February 2009.
[I-D.rosenberg-mmusic-ice-nonsip] [I-D.rosenberg-mmusic-ice-nonsip]
Rosenberg, J., "Guidelines for Usage of Interactive Rosenberg, J., "Guidelines for Usage of Interactive
Connectivity Establishment (ICE) by non Session Connectivity Establishment (ICE) by non Session
Initiation Protocol (SIP) Protocols", Initiation Protocol (SIP) Protocols",
draft-rosenberg-mmusic-ice-nonsip-01 (work in progress), draft-rosenberg-mmusic-ice-nonsip-01 (work in progress),
July 2008. July 2008.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", Stenberg, "UDP Encapsulation of IPsec ESP Packets",
skipping to change at page 29, line 19 skipping to change at page 31, line 5
estimate the RTT between them and set the minimum Ta value so that estimate the RTT between them and set the minimum Ta value so that
only two connectivity check messages are sent on every RTT. only two connectivity check messages are sent on every RTT.
One way to estimate the RTT is to use the time it takes for the HIP One way to estimate the RTT is to use the time it takes for the HIP
relay server registration exchange to complete; this would give an relay server registration exchange to complete; this would give an
estimate on the registering host's access link's RTT. Also the I1/R1 estimate on the registering host's access link's RTT. Also the I1/R1
exchange could be used for estimating the RTT, but since the R1 can exchange could be used for estimating the RTT, but since the R1 can
be cached in the network, or the relaying service can increase the be cached in the network, or the relaying service can increase the
delay notably, it is not recommended. delay notably, it is not recommended.
Appendix B. IPv4-IPv6 Interoperability Appendix B. Base Exchange through a Rendezvous Server
Currently relay client and server do not have to run any ICE
connectivity tests as described in Section 4.8. However, it could be
useful for IPv4-IPv6 interoperability when the HIP relay server
actually includes both the NAT traversal mode parameter and multiple
locators in R2. The interoperability benefit is that the relay could
support IPv4-based Initiators and IPv6-based Responders by converting
the network headers and recalculating UDP checksums.
Such an approach is underspecified in this document currently. It is
not yet recommended because it may consume resources at the relay and
requires also similar conversion support at the TURN relay for data
packets.
Appendix C. Base Exchange through a Rendezvous Server
When the Initiator looks up the information of the Responder from When the Initiator looks up the information of the Responder from
DNS, it's possible that it discovers an RVS record [RFC5204]. In DNS, it's possible that it discovers an RVS record [RFC5204]. In
this case, if the Initiator uses NAT traversal methods described in this case, if the Initiator uses NAT traversal methods described in
this document, it uses its own HIP relay server to forward HIP this document, it MAY use its own HIP relay server to forward HIP
traffic to the Rendezvous server. The Initiator will send the I1 traffic to the Rendezvous server. The Initiator will send the I1
message using its HIP relay server which will then forward it to the packet using its HIP relay server which will then forward it to the
RVS server of the Responder. In this case, the value of the protocol RVS server of the Responder. In this case, the value of the protocol
field in the RELAY_TO parameter MUST be IP since RVS does not support field in the RELAY_TO parameter MUST be IP since RVS does not support
UDP encapsulated base exchange packets. The Responder will send the UDP-encapsulated base exchange packets. The Responder will send the
R1 packet directly to the Initiator's HIP relay server and the R1 packet directly to the Initiator's HIP relay server and the
following I2 and R2 packets are also sent directly using the relay. following I2 and R2 packets are also sent directly using the relay.
In case the Initiator is not able to distinguish which records are In case the Initiator is not able to distinguish which records are
RVS address records and which are Responder's address records (e.g., RVS address records and which are Responder's address records (e.g.,
if the DNS server did not support HIP extensions), the Initiator if the DNS server did not support HIP extensions), the Initiator
SHOULD first try to contact the Responder directly, without using a SHOULD first try to contact the Responder directly, without using a
HIP relay server. If none of the addresses is reachable, it MAY try HIP relay server. If none of the addresses is reachable, it MAY try
out them using its own HIP relay server as described above. out them using its own HIP relay server as described above.
Appendix D. Document Revision History Appendix C. Document Revision History
To be removed upon publication To be removed upon publication
+-----------------------------+-------------------------------------+ +----------+--------------------------------------------------------+
| Revision | Comments | | Revision | Comments |
+-----------------------------+-------------------------------------+ +----------+--------------------------------------------------------+
| draft-ietf-nat-traversal-00 | Initial version. | | -00 | Initial version. |
| draft-ietf-nat-traversal-01 | Draft based on RVS. | | -01 | Draft based on RVS. |
| draft-ietf-nat-traversal-02 | Draft based on Relay proxies and | | -02 | Draft based on Relay proxies and ICE concepts. |
| | ICE concepts. | | -03 | Draft based on STUN/ICE formats. |
| draft-ietf-nat-traversal-03 | Draft based on STUN/ICE formats. | | -04 | Issues 25-27,29-36 |
| draft-ietf-nat-traversal-04 | Issues 25-27,29-36 | | -05 | Issues 28,40-43,47,49,51 |
| draft-ietf-nat-traversal-05 | Issues 28,40-43,47,49,51 | | -06 | New copyright boilerplate and STUN username encoding |
| draft-ietf-nat-traversal-06 | New copyright boilerplate and STUN | | -07 | New NOTIFY error packet parameters, changed handling |
| | username encoding | | | of I2/R2 via relay with UDP-ENCAPSULATION mode |
+-----------------------------+-------------------------------------+ +----------+--------------------------------------------------------+
Authors' Addresses Authors' Addresses
Miika Komu Miika Komu
Helsinki Institute for Information Technology Helsinki Institute for Information Technology
Metsanneidonkuja 4 Metsanneidonkuja 4
Espoo Espoo
Finland Finland
Phone: +358503841531 Phone: +358503841531
 End of changes. 89 change blocks. 
271 lines changed or deleted 335 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/