draft-ietf-hip-native-nat-traversal-07.txt   draft-ietf-hip-native-nat-traversal-08.txt 
HIP Working Group A. Keranen HIP Working Group A. Keranen
Internet-Draft J. Melen Internet-Draft J. Melen
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: December 25, 2014 June 23, 2014 Expires: July 26, 2015 January 22, 2015
Native NAT Traversal Mode for the Host Identity Protocol Native NAT Traversal Mode for the Host Identity Protocol
draft-ietf-hip-native-nat-traversal-07 draft-ietf-hip-native-nat-traversal-08
Abstract Abstract
This document specifies a new Network Address Translator (NAT) This document specifies a new Network Address Translator (NAT)
traversal mode for the Host Identity Protocol (HIP). The new mode is traversal mode for the Host Identity Protocol (HIP). The new mode is
based on the Interactive Connectivity Establishment (ICE) methodology based on the Interactive Connectivity Establishment (ICE) methodology
and UDP encapsulation of data and signaling traffic. The main and UDP encapsulation of data and signaling traffic. The main
difference from the previously specified modes is the use of HIP difference from the previously specified modes is the use of HIP
messages for all NAT traversal procedures. messages for all NAT traversal procedures.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 25, 2014. This Internet-Draft will expire on July 26, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Description . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Description . . . . . . . . . . . . . . . . . . . . 3
3.1. Relay Registration . . . . . . . . . . . . . . . . . . . 4 3.1. Relay Registration . . . . . . . . . . . . . . . . . . . 3
3.2. Registration Authentication . . . . . . . . . . . . . . . 4 3.2. Forwarding Rules and Permissions . . . . . . . . . . . . 4
3.3. Forwarding Rules and Permissions . . . . . . . . . . . . 5 3.3. Relaying UDP Encapsulated Data and Control Packets . . . 5
3.4. Relaying UDP Encapsulated Data and Control Packets . . . 6 3.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 5
3.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 6 3.5. Base Exchange via HIP Relay Server . . . . . . . . . . . 6
3.6. Base Exchange via HIP Relay Server . . . . . . . . . . . 7 3.6. Native NAT Traversal Mode Negotiation . . . . . . . . . . 6
3.7. Native NAT Traversal Mode Negotiation . . . . . . . . . . 7 3.7. Connectivity Check Pacing Negotiation . . . . . . . . . . 6
3.8. Connectivity Check Pacing Negotiation . . . . . . . . . . 7 3.8. Connectivity Checks . . . . . . . . . . . . . . . . . . . 6
3.9. Connectivity Checks . . . . . . . . . . . . . . . . . . . 7 3.9. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 7
3.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 8 3.10. Handling Conflicting SPI Values . . . . . . . . . . . . . 7
3.11. Handling Conflicting SPI Values . . . . . . . . . . . . . 8 4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 8
4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 8
4.1. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 9 4.2. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 9
4.2. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 10 4.3. HIP Connectivity Check Packets . . . . . . . . . . . . . 10
4.3. HIP Connectivity Check Packets . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The Host Identity Protocol (HIP) [I-D.ietf-hip-rfc5201-bis] is The Host Identity Protocol (HIP) [I-D.ietf-hip-rfc5201-bis] is
specified to run directly on top of IPv4 or IPv6. However, many specified to run directly on top of IPv4 or IPv6. However, many
middleboxes found in the Internet, such as NATs and firewalls, often middleboxes found in the Internet, such as NATs and firewalls, often
allow only UDP or TCP traffic to pass [RFC5207]. Also, especially allow only UDP or TCP traffic to pass [RFC5207]. Also, especially
NATs usually require the host behind a NAT to create a forwarding NATs usually require the host behind a NAT to create a forwarding
state in the NAT before other hosts outside of the NAT can contact state in the NAT before other hosts outside of the NAT can contact
the host behind the NAT. To overcome this problem, different the host behind the NAT. To overcome this problem, different
skipping to change at page 3, line 22 skipping to change at page 3, line 19
for NAT traversal. However, implementing a full ICE/STUN/TURN for NAT traversal. However, implementing a full ICE/STUN/TURN
protocol stack results in a considerable amount of effort and code protocol stack results in a considerable amount of effort and code
which could be avoided by re-using and extending HIP messages and which could be avoided by re-using and extending HIP messages and
state machines for the same purpose. Thus, this document specifies a state machines for the same purpose. Thus, this document specifies a
new NAT traversal mode that uses HIP messages instead of STUN for the new NAT traversal mode that uses HIP messages instead of STUN for the
connectivity checks, keepalives, and data relaying. connectivity checks, keepalives, and data relaying.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119].
This document uses the same terminology as [RFC5770] and the This document uses the same terminology as [RFC5770] and the
following: following:
HIP data relay: HIP data relay:
A host that forwards HIP data packets, such as Encapsulating A host that forwards HIP data packets, such as Encapsulating
Security Payload (ESP) [I-D.ietf-hip-rfc5202-bis], between two Security Payload (ESP) [I-D.ietf-hip-rfc5202-bis], between two
hosts. hosts.
Registered host: Registered host:
skipping to change at page 4, line 13 skipping to change at page 4, line 6
is expected to be used with this NAT traversal mode. is expected to be used with this NAT traversal mode.
3.1. Relay Registration 3.1. Relay Registration
Relay registration procedure for HIP signaling is identical to the Relay registration procedure for HIP signaling is identical to the
one specified in Section 4.1 of [RFC5770]. However, a host MAY also one specified in Section 4.1 of [RFC5770]. However, a host MAY also
register for UDP encapsulated ESP relaying using Registration Type register for UDP encapsulated ESP relaying using Registration Type
RELAY_UDP_ESP (value [TBD by IANA: 3]). RELAY_UDP_ESP (value [TBD by IANA: 3]).
If the HIP relay server supports relaying of UDP encapsulated ESP, If the HIP relay server supports relaying of UDP encapsulated ESP,
the host is allowed to register for data relaying service (see the host is allowed to register for a data relaying service (see
Section 3.2), and the relay has relaying resources (free port Section 3.3 at [I-D.ietf-hip-rfc5203-bis]), and the relay has
numbers, bandwidth, etc.) available, the relay opens a UDP port on sufficient relaying resources (free port numbers, bandwidth, etc.)
one of its addresses and signals the address and port to the available, the relay opens a UDP port on one of its addresses and
registering host using the RELAYED_ADDRESS parameter (see Section 4.1 signals the address and port to the registering host using the
for details). If the relay would accept the data relaying request RELAYED_ADDRESS parameter (see Section 4.1 for details). If the
but does not have enough resources to provide data relaying service, relay would accept the data relaying request but does not currently
it MUST reject the request with Failure Type [TBD by IANA: 2] have enough resources to provide data relaying service, it MUST
(Insufficient resources). reject the request with Failure Type "Insufficient resources"
[I-D.ietf-hip-rfc5203-bis].
The registered host MUST maintain an active HIP association with the The registered host MUST maintain an active HIP association with the
data relay as long as it requires the data relaying service. When data relay as long as it requires the data relaying service. When
the HIP association is closed (or times out), or the registration the HIP association is closed (or times out), or the registration
lifetime passes without the registered host refreshing the lifetime passes without the registered host refreshing the
registration, the data relay MUST stop relaying packets for that host registration, the data relay MUST stop relaying packets for that host
and close the corresponding UDP port (unless other registered hosts and close the corresponding UDP port (unless other registered hosts
are still using it). are still using it).
The data relay MAY use the same relayed address and port for multiple The data relay MAY use the same relayed address and port for multiple
registered hosts, but since this can cause problems with stateful registered hosts, but since this can cause problems with stateful
firewalls (see Section 5) it is NOT RECOMMENDED. firewalls (see Section 5) it is NOT RECOMMENDED.
3.2. Registration Authentication 3.2. Forwarding Rules and Permissions
If the HIP data relay knows the Host Identities (HIs) of all the
hosts that are allowed to use the relaying service, it SHOULD reject
registrations from unknown hosts. However, since it may be
unfeasible to pre-configure the relay with all the HIs, the relay
SHOULD also support HIP certificates [RFC6253] to allow for
certificate based authentication.
When a host wants to register with a HIP data relay, it SHOULD check
if it has a suitable certificate for authenticating with the relay.
How the suitability is determined and how the certificates are
obtained is out of scope for this document. If the host has one or
more suitable certificates, the host SHOULD include them (or just the
most suitable one) in a CERT parameter to the HIP packet along with
the REG_REQUEST parameter. If the host does not have any suitable
certificates, it SHOULD send the registration request without the
CERT parameter to test whether the relay accepts the request based on
the host's identity.
When a relay receives a HIP packet with a REG_REQUEST parameter, and
it requires authentication for at least one of the Registration Types
listed in the REG_REQUEST parameter, it MUST first check whether the
HI of the registering host is in the allowed list for all the
Registration Types in the REG_REQUEST parameter. If the host is in
the allowed list (or the relay does not require any authentication),
the relay MUST proceed with the registration.
If the host was not in the allowed list and the relay requires the
host to authenticate, the relay MUST check whether the packet also
contains a CERT parameter. If the packet does not contain a CERT
parameter, the server MUST reject the registrations requiring
authentication with Failure Type 0 (Registration requires additional
credentials) [I-D.ietf-hip-rfc5203-bis]. If the certificate is valid
and accepted (issued for the registering host and signed by a trusted
issuer), the relay MUST proceed with the registration. If the
certificate in the parameter is not accepted, the relay MUST reject
the corresponding registrations with Failure Type [TBD by IANA: 3]
(Invalid certificate).
3.3. Forwarding Rules and Permissions
The HIP data relay uses a similar permission model as a TURN server: The HIP data relay uses a similar permission model as a TURN server:
before any ESP data packets sent by a peer are forwarded, a before any ESP data packets sent by a peer are forwarded, a
permission MUST be set for the peer's address. The permissions also permission MUST be set for the peer's address. The permissions also
install a forwarding rule, similar to TURN's channels, based on the install a forwarding rule, similar to TURN's channels, based on the
Security Parameter Index (SPI) values in the ESP packets. Security Parameter Index (SPI) values in the ESP packets.
Permissions are not required for the connectivity checks, but if a Permissions are not required for the connectivity checks, but if a
relayed address is selected to be used for data, the registered host relayed address is selected to be used for data, the registered host
MUST send an UPDATE message [I-D.ietf-hip-rfc5201-bis] with a MUST send an UPDATE message [I-D.ietf-hip-rfc5201-bis] with a
skipping to change at page 6, line 7 skipping to change at page 5, line 7
for data relaying service, and drop the UPDATE if the host was not for data relaying service, and drop the UPDATE if the host was not
registered. If the host was registered, the relay checks if there is registered. If the host was registered, the relay checks if there is
a permission with matching information (address, protocol, port and a permission with matching information (address, protocol, port and
SPI values). If there is no such permission, a new permission MUST SPI values). If there is no such permission, a new permission MUST
be created and its lifetime MUST be set to 5 minutes. If an be created and its lifetime MUST be set to 5 minutes. If an
identical permission already existed, it MUST be refreshed by setting identical permission already existed, it MUST be refreshed by setting
the lifetime to 5 minutes. A registered host SHOULD refresh the lifetime to 5 minutes. A registered host SHOULD refresh
permissions roughly 1 minute before the expiration if the permission permissions roughly 1 minute before the expiration if the permission
is still needed. is still needed.
3.4. Relaying UDP Encapsulated Data and Control Packets 3.3. Relaying UDP Encapsulated Data and Control Packets
When a HIP data relay accepts to relay UDP encapsulated data, it When a HIP data relay accepts to relay UDP encapsulated data, it
opens a UDP port (relayed address) for this purpose as described in opens a UDP port (relayed address) for this purpose as described in
Section 3.1. If the data relay receives a UDP encapsulated HIP Section 3.1. If the data relay receives a UDP encapsulated HIP
control packet on that port, it MUST forward the packet to the control packet on that port, it MUST forward the packet to the
registered host and add a RELAY_FROM parameter to the packet as if registered host and add a RELAY_FROM parameter to the packet as if
the data relay was acting as a HIP relay server [RFC5770]. the data relay was acting as a HIP relay server [RFC5770].
When a host wants to send a HIP control packet (such as a When a host wants to send a HIP control packet (such as a
connectivity check packet) to a peer via the data relay, it MUST add connectivity check packet) to a peer via the data relay, it MUST add
skipping to change at page 6, line 41 skipping to change at page 5, line 41
the data relay, it MUST have an active permission at the data relay the data relay, it MUST have an active permission at the data relay
for the peer with the outbound SPI value it is using. The host MUST for the peer with the outbound SPI value it is using. The host MUST
send the UDP encapsulated ESP packet to the data relay's address. send the UDP encapsulated ESP packet to the data relay's address.
When the data relay receives a UDP encapsulated ESP packet from a When the data relay receives a UDP encapsulated ESP packet from a
registered host, it MUST check whether there exists a permission for registered host, it MUST check whether there exists a permission for
that outbound SPI value. If such permission exists, the packet MUST that outbound SPI value. If such permission exists, the packet MUST
be forwarded to the address that was registered for the SPI value. be forwarded to the address that was registered for the SPI value.
If no permission exists, the packet is dropped. If no permission exists, the packet is dropped.
3.5. Candidate Gathering 3.4. Candidate Gathering
A host needs to gather a set of address candidates before starting A host needs to gather a set of address candidates before starting
the connectivity checks. One server reflexive candidate can be the connectivity checks. One server reflexive candidate can be
discovered during the registration with the HIP relay server from the discovered during the registration with the HIP relay server from the
REG_FROM parameter. REG_FROM parameter.
If a host has more than one network interface, additional server If a host has more than one network interface, additional server
reflexive candidates can be discovered by sending registration reflexive candidates can be discovered by sending registration
requests with Registration Type CANDIDATE_DISCOVERY (value [TBD by requests with Registration Type CANDIDATE_DISCOVERY (value [TBD by
IANA: 4]) from each of the interfaces to a HIP relay server. When a IANA: 4]) from each of the interfaces to a HIP relay server. When a
skipping to change at page 7, line 18 skipping to change at page 6, line 18
the HIP relay server. the HIP relay server.
It is RECOMMENDED that the host also obtains a relayed candidate from It is RECOMMENDED that the host also obtains a relayed candidate from
a HIP data relay as described in Section 3.1. a HIP data relay as described in Section 3.1.
Gathering of candidates MAY also be performed like specified in Gathering of candidates MAY also be performed like specified in
Section 4.2 of [RFC5770] if STUN and TURN servers are available, or Section 4.2 of [RFC5770] if STUN and TURN servers are available, or
if the host has just a single interface and there are no TURN or HIP if the host has just a single interface and there are no TURN or HIP
data relay servers available. data relay servers available.
3.6. Base Exchange via HIP Relay Server 3.5. Base Exchange via HIP Relay Server
The Base Exchange is performed as described in Section 4.5 of The Base Exchange is performed as described in Section 4.5 of
[RFC5770], except that "ICE candidates" are replaced by the [RFC5770], except that "ICE candidates" are replaced by the
candidates gathered using procedures described in Section 3.5 candidates gathered using procedures described in Section 3.4
3.7. Native NAT Traversal Mode Negotiation 3.6. Native NAT Traversal Mode Negotiation
A host implementing this specification SHOULD signal the support for A host implementing this specification SHOULD signal the support for
the native HIP NAT traversal mode by adding ICE-HIP-UDP NAT traversal the native HIP NAT traversal mode by adding ICE-HIP-UDP NAT traversal
mode (value [TBD by IANA: 3]) in the NAT_TRAVERSAL_MODE [RFC5770] mode (value [TBD by IANA: 3]) in the NAT_TRAVERSAL_MODE [RFC5770]
parameter. If this mode is supported by both endpoints, and is the parameter. If this mode is supported by both endpoints, and is the
most preferred mode out of the all supported modes, further NAT most preferred mode out of the all supported modes, further NAT
traversal procedures are performed as specified in this document. traversal procedures are performed as specified in this document.
Note that the results of the previously described methods, candidate Note that the results of the previously described methods, candidate
gathering and HIP data relay registration with HIP messages, can be gathering and HIP data relay registration with HIP messages, can be
used also with the ICE-STUN-UDP NAT traversal mode. used also with the ICE-STUN-UDP NAT traversal mode.
3.8. Connectivity Check Pacing Negotiation 3.7. Connectivity Check Pacing Negotiation
Since the NAT traversal mode specified in this document utilizes Since the NAT traversal mode specified in this document utilizes
connectivity checks, the check pacing negotiation MUST be performed connectivity checks, the check pacing negotiation MUST be performed
as specified in Section 4.4 of [RFC5770]. New connectivity check as specified in Section 4.4 of [RFC5770]. New connectivity check
transactions MUST NOT be started faster than once every Ta (the value transactions MUST NOT be started faster than once every Ta (the value
negotiated with the TRANSACTION_PACING parameter). negotiated with the TRANSACTION_PACING parameter).
3.9. Connectivity Checks 3.8. Connectivity Checks
The connectivity checks are performed as described in Section 4.6 of The connectivity checks are performed as described in Section 4.6 of
[RFC5770] but instead of STUN packets, the connectivity checks are [RFC5770] but instead of STUN packets, the connectivity checks are
HIP UPDATE packets. See Section 4.3 for parameter details. HIP UPDATE packets. See Section 4.3 for parameter details.
As defined in [RFC5770], both hosts MUST form a priority ordered As defined in [RFC5770], both hosts MUST form a priority ordered
checklist and start check transactions every Ta milliseconds as long checklist and start check transactions every Ta milliseconds as long
as the checks are running and there are candidate pairs whose tests as the checks are running and there are candidate pairs whose tests
have not started. The retransmission timeout (RTO) for the have not started. The retransmission timeout (RTO) for the
connectivity check UPDATE packets MUST be calculated as defined in connectivity check UPDATE packets MUST be calculated as defined in
skipping to change at page 8, line 33 skipping to change at page 7, line 33
priority candidate pair for use. The pair MUST be nominated by priority candidate pair for use. The pair MUST be nominated by
sending an ESP packet on the selected pair. If the controlling host sending an ESP packet on the selected pair. If the controlling host
does not have any data to send, it SHOULD send an ICMP echo request does not have any data to send, it SHOULD send an ICMP echo request
using the nominated pair to signal to the controlled host that it can using the nominated pair to signal to the controlled host that it can
stop checks and start using the nominated pair. stop checks and start using the nominated pair.
If the connectivity checks failed the hosts SHOULD notify each other If the connectivity checks failed the hosts SHOULD notify each other
about the failure with a CONNECTIVITY_CHECKS_FAILED Notify Message about the failure with a CONNECTIVITY_CHECKS_FAILED Notify Message
Type [RFC5770]. Type [RFC5770].
3.10. NAT Keepalives 3.9. NAT Keepalives
To keep the NAT bindings towards the HIP relay server and the HIP To keep the NAT bindings towards the HIP relay server and the HIP
data relay alive, if a registered host has not sent any data or data relay alive, if a registered host has not sent any data or
control messages to the relay for 15 seconds, it MUST send a HIP control messages to the relay for 15 seconds, it MUST send a HIP
NOTIFY packet to the relay. Likewise, if the host has not sent any NOTIFY packet to the relay. Likewise, if the host has not sent any
data to a host it has security association and has run connectivity data to a host it has security association and has run connectivity
checks with, it MUST send either a HIP NOTIFY packet or an ICMP echo checks with, it MUST send either a HIP NOTIFY packet or an ICMP echo
request using the same locators as the security association is using. request using the same locators as the security association is using.
3.11. Handling Conflicting SPI Values 3.10. Handling Conflicting SPI Values
Since the HIP data relay determines from the SPI value to which peer Since the HIP data relay determines from the SPI value to which peer
an ESP packet should be forwarded, the outbound SPI values need to be an ESP packet should be forwarded, the outbound SPI values need to be
unique for each relayed address registration. Thus, if a registered unique for each relayed address registration. Thus, if a registered
host detects that a peer would use an SPI value that is already used host detects that a peer would use an SPI value that is already used
with another peer via the relay, it MUST NOT select the relayed with another peer via the relay, it MUST NOT select the relayed
address for use. The host MAY restart the base exchange to avoid a address for use. The host MAY restart the base exchange to avoid a
conflict or it MAY refrain from using the relayed candidate for the conflict or it MAY refrain from using the relayed candidate for the
connectivity checks. connectivity checks.
skipping to change at page 11, line 28 skipping to change at page 10, line 28
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ISPI | | ISPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| ... | | ... |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [TBD by IANA; 4680] Type [TBD by IANA; 4680]
Length length in octets, excluding Type and Length Length length in octets, excluding Type and Length
Port the transport layer (UDP) port number Port the transport layer (UDP) port number of the peer
Protocol IANA assigned, Internet Protocol number (17 for UDP) Protocol IANA assigned, Internet Protocol number (17 for UDP)
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, of the peer IPv6 address" format, of the peer
OSPI the outbound SPI value the registered host is using for OSPI the outbound SPI value the registered host is using for
the peer with the Address and Port the peer with the Address and Port
ISPI the inbound SPI value the registered host is using for ISPI the inbound SPI value the registered host is using for
the peer with the Address and Port the peer with the Address and Port
skipping to change at page 12, line 33 skipping to change at page 11, line 33
If the data relay uses the same relayed address and port for multiple If the data relay uses the same relayed address and port for multiple
registered hosts, it appears to all the peers, and their firewalls, registered hosts, it appears to all the peers, and their firewalls,
that all the registered hosts using the relay are at the same that all the registered hosts using the relay are at the same
address. Thus, a stateful firewall may allow packets pass from hosts address. Thus, a stateful firewall may allow packets pass from hosts
that would not normally be able to send packets to a peer behind the that would not normally be able to send packets to a peer behind the
firewall. Therefore, a HIP data relay SHOULD NOT re-use the port firewall. Therefore, a HIP data relay SHOULD NOT re-use the port
numbers. If port numbers need to be re-used, the relay SHOULD have a numbers. If port numbers need to be re-used, the relay SHOULD have a
sufficiently large pool of port numbers and select ports from the sufficiently large pool of port numbers and select ports from the
pool randomly to decrease the chances of a registered host obtaining pool randomly to decrease the chances of a registered host obtaining
the same address that a certain other host is using. the same address that a another host behind the same firewall is
using.
6. Acknowledgements 6. Acknowledgements
This document re-uses many of the ideas proposed in various earlier This document re-uses many of the ideas proposed in various earlier
HIP NAT traversal related drafts by Miika Komu, Simon Schuetz, Martin HIP NAT traversal related drafts by Miika Komu, Simon Schuetz, Martin
Stiemerling, Pekka Nikander, Marcelo Bagnulo, Vivien Schmitt, Abhinav Stiemerling, Pekka Nikander, Marcelo Bagnulo, Vivien Schmitt, Abhinav
Pathak, Lars Eggert, Thomas Henderson, Hannes Tschofenig, and Philip Pathak, Lars Eggert, Thomas Henderson, Hannes Tschofenig, and Philip
Matthews. Matthews.
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 document updates the IANA Registry for HIP Parameter Types This document updates the IANA Registry for HIP Parameter Types
[I-D.ietf-hip-rfc5201-bis] by assigning new HIP Parameter Type values [I-D.ietf-hip-rfc5201-bis] by assigning new HIP Parameter Type values
for the new HIP Parameters: RELAYED_ADDRESS, MAPPED_ADDRESS (defined for the new HIP Parameters: RELAYED_ADDRESS, MAPPED_ADDRESS (defined
in Section 4.1), and PEER_PERMISSION (defined in Section 4.2). in Section 4.1), and PEER_PERMISSION (defined in Section 4.2).
This document also updates the IANA Registry for HIP NAT traversal This document also updates the IANA Registry for HIP NAT traversal
modes [RFC5770] by assigning value for the NAT traversal mode ICE- modes [RFC5770] by assigning value for the NAT traversal mode ICE-
HIP-UDP (defined in Section 3.7). HIP-UDP (defined in Section 3.6).
This document defines additional registration types for the HIP This document defines additional registration types for the HIP
Registration Extension [I-D.ietf-hip-rfc5203-bis] that allow Registration Extension [I-D.ietf-hip-rfc5203-bis] that allow
registering with a HIP relay server for ESP relaying service: registering with a HIP relay server for ESP relaying service:
RELAY_UDP_ESP (defined in Section 3.1); and performing server RELAY_UDP_ESP (defined in Section 3.1); and performing server
reflexive candidate discovery: CANDIDATE_DISCOVERY (defined in reflexive candidate discovery: CANDIDATE_DISCOVERY (defined in
Section 3.5). Section 3.4).
The IANA Registry for HIP Registration Failure Types is updated with
new Failure Types "Insufficient resources" (defined in Section 3.1)
and "Invalid certificate" (defined in Section 3.2).
8. References 8. References
8.1. Normative References 8.1. Normative References
[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.
[I-D.ietf-hip-rfc5201-bis] [I-D.ietf-hip-rfc5201-bis]
Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, Moskowitz, R., Heer, T., Jokela, P., and T. Henderson,
"Host Identity Protocol Version 2 (HIPv2)", draft-ietf- "Host Identity Protocol Version 2 (HIPv2)", draft-ietf-
hip-rfc5201-bis-14 (work in progress), October 2013. hip-rfc5201-bis-20 (work in progress), October 2014.
[I-D.ietf-hip-rfc5202-bis] [I-D.ietf-hip-rfc5202-bis]
Jokela, P., Moskowitz, R., and J. Melen, "Using the Jokela, P., Moskowitz, R., and J. Melen, "Using the
Encapsulating Security Payload (ESP) Transport Format with Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", draft-ietf-hip- the Host Identity Protocol (HIP)", draft-ietf-hip-
rfc5202-bis-05 (work in progress), November 2013. rfc5202-bis-07 (work in progress), September 2014.
[I-D.ietf-hip-rfc5203-bis] [I-D.ietf-hip-rfc5203-bis]
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Registration Extension", draft-ietf-hip-rfc5203-bis-05 Registration Extension", draft-ietf-hip-rfc5203-bis-06
(work in progress), March 2014. (work in progress), September 2014.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] 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", RFC 5245, April Traversal for Offer/Answer Protocols", RFC 5245, April
2010. 2010.
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
Keranen, "Basic Host Identity Protocol (HIP) Extensions Keranen, "Basic Host Identity Protocol (HIP) Extensions
for Traversal of Network Address Translators", RFC 5770, for Traversal of Network Address Translators", RFC 5770,
April 2010. April 2010.
[RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol
Certificates", RFC 6253, May 2011.
8.2. Informative References 8.2. Informative References
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", RFC 5201, April 2008. "Host Identity Protocol", RFC 5201, April 2008.
[RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and
Firewall Traversal Issues of Host Identity Protocol (HIP) Firewall Traversal Issues of Host Identity Protocol (HIP)
Communication", RFC 5207, April 2008. Communication", RFC 5207, April 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
skipping to change at page 14, line 38 skipping to change at page 13, line 30
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
Authors' Addresses Authors' Addresses
Ari Keranen Ari Keranen
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
02420 Jorvas 02420 Jorvas
Finland Finland
Email: Ari.Keranen@ericsson.com Email: ari.keranen@ericsson.com
Jan Melen Jan Melen
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
02420 Jorvas 02420 Jorvas
Finland Finland
Email: Jan.Melen@ericsson.com Email: jan.melen@ericsson.com
 End of changes. 27 change blocks. 
103 lines changed or deleted 58 lines changed or added

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