draft-ietf-hip-native-nat-traversal-18.txt   draft-ietf-hip-native-nat-traversal-19.txt 
HIP Working Group A. Keranen HIP Working Group A. Keranen
Internet-Draft J. Melen Internet-Draft J. Melen
Intended status: Standards Track M. Komu, Ed. Intended status: Standards Track M. Komu, Ed.
Expires: September 14, 2017 Ericsson Expires: September 28, 2017 Ericsson
March 13, 2017 March 27, 2017
Native NAT Traversal Mode for the Host Identity Protocol Native NAT Traversal Mode for the Host Identity Protocol
draft-ietf-hip-native-nat-traversal-18 draft-ietf-hip-native-nat-traversal-19
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 36 skipping to change at page 1, line 36
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 September 14, 2017. This Internet-Draft will expire on September 28, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
skipping to change at page 2, line 34 skipping to change at page 2, line 34
4.7.2. Base Exchange without Connectivity Checks . . . . . . 23 4.7.2. Base Exchange without Connectivity Checks . . . . . . 23
4.7.3. Initiating a Base Exchange both with and without UDP 4.7.3. Initiating a Base Exchange both with and without UDP
Encapsulation . . . . . . . . . . . . . . . . . . . . 24 Encapsulation . . . . . . . . . . . . . . . . . . . . 24
4.8. Sending Control Packets after the Base Exchange . . . . . 25 4.8. Sending Control Packets after the Base Exchange . . . . . 25
4.9. Mobility Handover Procedure . . . . . . . . . . . . . . . 26 4.9. Mobility Handover Procedure . . . . . . . . . . . . . . . 26
4.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 28 4.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 28
4.11. Closing Procedure . . . . . . . . . . . . . . . . . . . . 28 4.11. Closing Procedure . . . . . . . . . . . . . . . . . . . . 28
4.12. Relaying Considerations . . . . . . . . . . . . . . . . . 29 4.12. Relaying Considerations . . . . . . . . . . . . . . . . . 29
4.12.1. Forwarding Rules and Permissions . . . . . . . . . . 29 4.12.1. Forwarding Rules and Permissions . . . . . . . . . . 29
4.12.2. HIP Data Relay and Relaying of Control Packets . . . 30 4.12.2. HIP Data Relay and Relaying of Control Packets . . . 30
4.12.3. Handling Conflicting SPI Values . . . . . . . . . . 31 4.12.3. Handling Conflicting SPI Values . . . . . . . . . . 30
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 31 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 31
5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 32 5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 32
5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 32 5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 32
5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 33 5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 33
5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . 33 5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . 33
5.5. Connectivity Check Transaction Pacing Parameter . . . . . 34 5.5. Connectivity Check Transaction Pacing Parameter . . . . . 34
5.6. Relay and Registration Parameters . . . . . . . . . . . . 34 5.6. Relay and Registration Parameters . . . . . . . . . . . . 35
5.7. LOCATOR_SET Parameter . . . . . . . . . . . . . . . . . . 35 5.7. LOCATOR_SET Parameter . . . . . . . . . . . . . . . . . . 36
5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . 37 5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . 38
5.9. Registration Types . . . . . . . . . . . . . . . . . . . 38 5.9. Registration Types . . . . . . . . . . . . . . . . . . . 38
5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 38 5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 38
5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . 38 5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . 38
5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 39 5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 39
5.13. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 40 5.13. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 40
5.14. HIP Connectivity Check Packets . . . . . . . . . . . . . 41 5.14. HIP Connectivity Check Packets . . . . . . . . . . . . . 41
5.15. NOMINATE parameter . . . . . . . . . . . . . . . . . . . 41 5.15. NOMINATE parameter . . . . . . . . . . . . . . . . . . . 42
6. Security Considerations . . . . . . . . . . . . . . . . . . . 41 6. Security Considerations . . . . . . . . . . . . . . . . . . . 42
6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 42 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 42
6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . 42 6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . 43
6.3. Base Exchange Replay Protection for HIP Relay Server . . 42 6.3. Base Exchange Replay Protection for HIP Relay Server . . 43
6.4. Demultiplexing Different HIP Associations . . . . . . . . 43 6.4. Demultiplexing Different HIP Associations . . . . . . . . 43
6.5. Reuse of Ports at the Data Relay . . . . . . . . . . . . 43 6.5. Reuse of Ports at the Data Relay . . . . . . . . . . . . 44
6.6. Amplification attacks . . . . . . . . . . . . . . . . . . 43 6.6. Amplification attacks . . . . . . . . . . . . . . . . . . 44
6.7. Attacks against Connectivity Checks and Candidate 6.7. Attacks against Connectivity Checks and Candidate
Gathering . . . . . . . . . . . . . . . . . . . . . . . . 43 Gathering . . . . . . . . . . . . . . . . . . . . . . . . 44
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 45 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 45
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
10.1. Normative References . . . . . . . . . . . . . . . . . . 45 10.1. Normative References . . . . . . . . . . . . . . . . . . 46
10.2. Informative References . . . . . . . . . . . . . . . . . 46 10.2. Informative References . . . . . . . . . . . . . . . . . 47
Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 47 Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 48
Appendix B. Base Exchange through a Rendezvous Server . . . . . 48 Appendix B. Differences with respect to ICE . . . . . . . . . . 49
Appendix C. Differences with respect to ICE . . . . . . . . . . 48 Appendix C. Differences to Base Exchange and UPDATE procedures . 50
Appendix D. Differences to Base Exchange and UPDATE procedures . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction 1. Introduction
The Host Identity Protocol (HIP) [RFC7401] is specified to run The Host Identity Protocol (HIP) [RFC7401] is specified to run
directly on top of IPv4 or IPv6. However, many middleboxes found in directly on top of IPv4 or IPv6. However, many middleboxes found in
the Internet, such as NATs and firewalls, often allow only UDP or TCP the Internet, such as NATs and firewalls, often allow only UDP or TCP
traffic to pass [RFC5207]. Also, especially NATs usually require the traffic to pass [RFC5207]. Also, especially NATs usually require the
host behind a NAT to create a forwarding state in the NAT before host behind a NAT to create a forwarding state in the NAT before
other hosts outside of the NAT can contact the host behind the NAT. other hosts outside of the NAT can contact the host behind the NAT.
skipping to change at page 8, line 40 skipping to change at page 8, line 40
HIP HIP HIP HIP
Relay [Data] Relay Relay [Data] Relay
Client Server Client Server
| 1. UDP(I1) | | 1. UDP(I1) |
+---------------------------------------------------------------->| +---------------------------------------------------------------->|
| | | |
| 2. UDP(R1(REG_INFO(RELAY_UDP_HIP,[RELAY_UDP_ESP]))) | | 2. UDP(R1(REG_INFO(RELAY_UDP_HIP,[RELAY_UDP_ESP]))) |
|<----------------------------------------------------------------+ |<----------------------------------------------------------------+
| | | |
| 3. UDP(I2(REG_REQ(RELAY_UDP_HIP),[RELAY_UDP_ESP]))) | | 3. UDP(I2(REG_REQ(RELAY_UDP_HIP),[RELAY_UDP_ESP])) |
+---------------------------------------------------------------->| +---------------------------------------------------------------->|
| | | |
| 4. UDP(R2(REG_RES(RELAY_UDP_HIP,[RELAY_UDP_ESP]), REG_FROM, | | 4. UDP(R2(REG_RES(RELAY_UDP_HIP,[RELAY_UDP_ESP]), REG_FROM, |
| [RELAYED_ADDRESS])) | | [RELAYED_ADDRESS])) |
|<----------------------------------------------------------------+ |<----------------------------------------------------------------+
| | | |
Figure 2: Example Registration with a HIP Relay Figure 2: Example Registration with a HIP Relay
In step 1, the relay client (Initiator) starts the registration In step 1, the relay client (Initiator) starts the registration
skipping to change at page 19, line 34 skipping to change at page 19, line 34
Responder must acknowledge it using an ACK parameter. Also, the Responder must acknowledge it using an ACK parameter. Also, the
nonce contained in the echo request must be echoed back in an nonce contained in the echo request must be echoed back in an
ECHO_REQUEST_SIGNED (denoted ECHO_REQUEST_SIGN) parameter. The ECHO_REQUEST_SIGNED (denoted ECHO_REQUEST_SIGN) parameter. The
Responder includes also a MAPPED_ADDRESS parameter (denoted Responder includes also a MAPPED_ADDRESS parameter (denoted
MAPPED_ADDR in the figure) that contains the transport address of the MAPPED_ADDR in the figure) that contains the transport address of the
Initiator as observed by the Responder (i.e. peer reflexive Initiator as observed by the Responder (i.e. peer reflexive
candidate). This message is successfully delivered to the Initiator, candidate). This message is successfully delivered to the Initiator,
and upon reception the Initiator marks the candidate pair as valid. and upon reception the Initiator marks the candidate pair as valid.
In step 4, the Responder retransmits the connectivity check sent in In step 4, the Responder retransmits the connectivity check sent in
the first step since it was not acknowledged yet. the first step, since it was not acknowledged yet.
In step 5, the Initiator responds to the previous connectivity check In step 5, the Initiator responds to the previous connectivity check
message from the Responder. The Initiator acknowledges the SEQ message from the Responder. The Initiator acknowledges the SEQ
parameter from the previous message using ACK parameter and the parameter from the previous message using ACK parameter and the
ECHO_REQUEST_SIGN parameter with ECHO_RESPONSE_SIGNED. In addition, ECHO_REQUEST_SIGN parameter with ECHO_RESPONSE_SIGNED. In addition,
it includes MAPPED_ADDR parameter that includes the peer reflexive it includes MAPPED_ADDR parameter that includes the peer reflexive
candidate. This response message is successfully delivered to the candidate. This response message is successfully delivered to the
Responder, and upon reception the Initiator marks the candidate pair Responder, and upon reception the Initiator marks the candidate pair
as valid. as valid.
In step 6, despite the two hosts now having valid address candidates, In step 6, despite the two hosts now having valid address candidates,
the hosts still test the remaining address candidates in a similar the hosts still test the remaining address candidates in a similar
way as in the previous steps (due to the use of normal nomination). way as in the previous steps (due to the use of normal nomination).
It should be noted that each connectivity check has an unique It should be noted that each connectivity check has a unique sequence
sequence number in the SEQ parameter. number in the SEQ parameter.
In step 7, the Initiator has completed testing all address candidates In step 7, the Initiator has completed testing all address candidates
and nominates one address candidate to be used. It sends an UPDATE and nominates one address candidate to be used. It sends an UPDATE
message using the selected address candidates that includes a number message using the selected address candidates that includes a number
of parameters: SEQ, ECHO_REQUEST_SIGN, CANDIDATE_PRIORITY and the of parameters: SEQ, ECHO_REQUEST_SIGN, CANDIDATE_PRIORITY and the
NOMINATE parameter. NOMINATE parameter.
In step 8, the Responder receives the message with NOMINATE parameter In step 8, the Responder receives the message with NOMINATE parameter
from the Initiator. It sends a response that includes the NOMINATE from the Initiator. It sends a response that includes the NOMINATE
parameter in addition to a number of other parameters. The ACK and parameter in addition to a number of other parameters. The ACK and
skipping to change at page 20, line 34 skipping to change at page 20, line 34
It is worth noting that if either host has registered a relayed It is worth noting that if either host has registered a relayed
address candidate from a data relay, the host MUST activate the address candidate from a data relay, the host MUST activate the
address before connectivity checks by sending an UPDATE message address before connectivity checks by sending an UPDATE message
containing PEER_PERMISSION parameter as described in Section 4.12.1. containing PEER_PERMISSION parameter as described in Section 4.12.1.
Otherwise, the relay drops ESP packets using the relayed address. Otherwise, the relay drops ESP packets using the relayed address.
4.6.2. Rules for Connectivity Checks 4.6.2. Rules for Connectivity Checks
The HITs of the two communicating hosts MUST be used as credentials The HITs of the two communicating hosts MUST be used as credentials
in this protocol (in contrast to ICE that employs username-password in this protocol (in contrast to ICE which employs username-password
fragments). A HIT pair uniquely identifies the corresponding HIT fragments). A HIT pair uniquely identifies the corresponding HIT
association, and a SEQ number in an UPDATE message identifies a association, and a SEQ number in an UPDATE message identifies a
particular connectivity check. particular connectivity check.
All of the connectivity check packets MUST be protected with HMACs All of the connectivity check packets MUST be protected with HMACs
and signatures (even though the illustrations omitted them for and signatures (even though the illustrations omitted them for
simplicity). Each connectivity check sent by a host MUST include a simplicity). Each connectivity check sent by a host MUST include a
SEQ parameter and ECHO_REQUEST_SIGN parameter, and correspondingly SEQ parameter and ECHO_REQUEST_SIGN parameter, and correspondingly
the peer MUST respond to these using ACK and ECHO_RESPONSE_SIGNED the peer MUST respond to these using ACK and ECHO_RESPONSE_SIGNED
according to the rules specified in [RFC7401]. according to the rules specified in [RFC7401].
The host sending a connectivity check should check that the response The host sending a connectivity check MUST validate that the response
uses also the same pair of UDP ports. If the UDP ports do not match, uses the same pair of UDP ports, and drop the packet if this is not
the host MUST drop the packet. the case.
A host may receive a connectivity check before it has received the A host may receive a connectivity check before it has received the
candidates from its peer. In such a case, the host MUST immediately candidates from its peer. In such a case, the host MUST immediately
generate a response, and then continue waiting for the candidates. A generate a response, and then continue waiting for the candidates. A
host MUST NOT select a candidate pair until it has verified the pair host MUST NOT select a candidate pair until it has verified the pair
using a connectivity check as defined in section Section 4.6.1. using a connectivity check as defined in section Section 4.6.1.
[RFC7401] states that UPDATE packets have to include either a SEQ or [RFC7401] states that UPDATE packets have to include either a SEQ or
ACK parameter (or both). According to the RFC, each SEQ parameter ACK parameter (or both). According to the RFC, each SEQ parameter
should be acknowledged separately. In the context of NATs, this should be acknowledged separately. In the context of NATs, this
skipping to change at page 21, line 39 skipping to change at page 21, line 39
ICE procedures for prioritizing candidates, eliminating redundant ICE procedures for prioritizing candidates, eliminating redundant
candidates and forming check lists (including pruning) MUST be candidates and forming check lists (including pruning) MUST be
followed as specified in [I-D.ietf-ice-rfc5245bis], with the followed as specified in [I-D.ietf-ice-rfc5245bis], with the
exception that the foundation, frozen candidates and default exception that the foundation, frozen candidates and default
candidates are not used. From viewpoint of the ICE specification candidates are not used. From viewpoint of the ICE specification
[I-D.ietf-ice-rfc5245bis], the protocol specified in this document [I-D.ietf-ice-rfc5245bis], the protocol specified in this document
operates using Component ID of 1 on all candidates, and the operates using Component ID of 1 on all candidates, and the
foundation of all candidates is unique. This specification defines foundation of all candidates is unique. This specification defines
only "full ICE" mode, and the "lite ICE" is not supported. The only "full ICE" mode, and the "lite ICE" is not supported. The
reasoning behind for the missing features is described in Appendix C. reasoning behind the missing features is described in Appendix B.
The connectivity check messages MUST be paced by the Ta value The connectivity check messages MUST be paced by the Ta value
negotiated during the base exchange as described in Section 4.4. If negotiated during the base exchange as described in Section 4.4. If
neither one of the hosts announced a minimum pacing value, a value of neither one of the hosts announced a minimum pacing value, a value of
20 ms SHOULD be used. 20 ms SHOULD be used.
Both hosts MUST form a priority ordered checklist and start to check Both hosts MUST form a priority ordered checklist and begin to check
transactions every Ta milliseconds as long as the checks are running transactions every Ta milliseconds as long as the checks are running
and there are candidate pairs whose tests have not started. The and there are candidate pairs whose tests have not started. The
retransmission timeout (RTO) for the connectivity check UPDATE retransmission timeout (RTO) for the connectivity check UPDATE
packets SHOULD be calculated as follows: packets SHOULD be calculated as follows:
RTO = MAX (500ms, Ta * (Num-Waiting + Num-In-Progress)) RTO = MAX (500ms, Ta * (Num-Waiting + Num-In-Progress))
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, Num-Waiting is the number of pairs in the checklist in the pacing, Num-Waiting is the number of pairs in the checklist in the
"Waiting" state, and Num-In-Progress is the number of pairs in the "Waiting" state, and Num-In-Progress is the number of pairs in the
skipping to change at page 28, line 39 skipping to change at page 28, line 39
ESP packets using the relayed address. ESP packets using the relayed address.
4.10. NAT Keepalives 4.10. NAT Keepalives
To prevent NAT states from expiring, communicating hosts send To prevent NAT states from expiring, communicating hosts send
periodic keepalives to other hosts with which they have established a periodic keepalives to other hosts with which they have established a
host associating. Both a registered client and relay server SHOULD host associating. Both a registered client and relay server SHOULD
send HIP NOTIFY packets to each other every 15 seconds (the so called send HIP NOTIFY packets to each other every 15 seconds (the so called
Tr value in ICE) unless they have exchange some other traffic over Tr value in ICE) unless they have exchange some other traffic over
the used UDP ports. Other values MAY be used, but a Tr value smaller the used UDP ports. Other values MAY be used, but a Tr value smaller
than 15 seconds MUST NOT be used. Likewise, if a host has not sent than 15 seconds MUST NOT be used. The keepalive message encoding
any data to another host it has established a host association in the format is defined in Section 5.3. If the base exchange or mobility
ICE-HIP_UDP mode within 15 seconds, it MUST send either a HIP NOTIFY handover procedure occurs during an extremely slow path, a host MAY
packet or, alternatively, an ICMPv6 echo request inside the related also send HIP NOTIFY packet every 15 seconds to keep the path active
ESP tunnel. If the base exchange or mobility handover procedure with the recipient.
occurs during an extremely slow path, a host MAY also send HIP NOTIFY
packet every 15 seconds to keep the path active with the recipient.
4.11. Closing Procedure 4.11. Closing Procedure
The two-way procedure for closing a HIP association and the related The two-way procedure for closing a HIP association and the related
security associations is defined in [RFC7401]. One host initiates security associations is defined in [RFC7401]. One host initiates
the procedure by sending a CLOSE message and the recipient confirms the procedure by sending a CLOSE message and the recipient confirms
it with CLOSE_ACK. All packets are protected using HMACs and it with CLOSE_ACK. All packets are protected using HMACs and
signatures, and the CLOSE messages includes a ECHO_REQUEST_SIGNED signatures, and the CLOSE messages includes a ECHO_REQUEST_SIGNED
parameter to protect against replay attacks. parameter to protect against replay attacks.
skipping to change at page 33, line 7 skipping to change at page 33, line 7
some other port number is used, it needs to be known by potential some other port number is used, it needs to be known by potential
Initiators. Initiators.
5.2. Connectivity Checks 5.2. Connectivity Checks
HIP connectivity checks are HIP UPDATE packets. The format is HIP connectivity checks are HIP UPDATE packets. The format is
specified in [RFC7401]. specified in [RFC7401].
5.3. Keepalives 5.3. Keepalives
The keepalives are either HIP NOTIFY packets as specified in The RECOMMENDED encoding format for keepalives is HIP NOTIFY packets
[RFC7401] or ICMPv6 packets inside the ESP tunnel. as specified in [RFC7401] with Notify message type field set to
NAT_KEEPALIVE [TBD by IANA: 16384] and with an empty Notification
data field. It is worth noting that sending of such a HIP NOTIFY
message MAY be omitted if the host is actively (or passively) sending
other traffic to the peer host over the UDP tunnel associate with the
host association (and IPsec security associations since the same port
pair is reused) during the Tr period. For instance, the host MAY
actively send ICMPv6 requests (or respond with an ICMPv6 response)
inside the ESP tunnel to test the health of the associated IPsec
security associations. Alternatively, the host MAY use UPDATE
packets as a substitute. A minimal UPDATE packet would consist of a
SEQ and ECHO_REQ_SIGN parameters, and a more complex would involve
rekeying procedures as specified in section 6.8 in [RFC7402]. It is
worth noting that a host actively sending periodic UPDATE packets to
a busy server may increase the computational load of the server since
it has to verify HMACs and signatures in UPDATE messages.
5.4. NAT Traversal Mode Parameter 5.4. NAT Traversal Mode Parameter
The format of NAT traversal mode parameter is borrowed from The format of NAT traversal mode parameter is borrowed from
[RFC5770]. The format of the NAT_TRAVERSAL_MODE parameter is similar [RFC5770]. The format of the NAT_TRAVERSAL_MODE parameter is similar
to the format of the ESP_TRANSFORM parameter in [RFC7402] and is to the format of the ESP_TRANSFORM parameter in [RFC7402] and is
shown in Figure 8. This specification defines the traversal mode shown in Figure 8. This specification defines the traversal mode
identifier for ICE-HIP-UDP and reuses the UDP-ENCAPSULATION mode from identifier for ICE-HIP-UDP and reuses the UDP-ENCAPSULATION mode from
[RFC5770]. The identifier named RESERVED is reserved for future use. [RFC5770]. The identifier named RESERVED is reserved for future use.
Future specifications may define more traversal modes. Future specifications may define more traversal modes.
skipping to change at page 34, line 7 skipping to change at page 34, line 40
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. Conversely, a recipient MUST be prepared to handle parameter. Conversely, a recipient MUST be prepared to handle
received NAT traversal mode parameters that contain more than six received NAT traversal mode parameters that contain more than six
Mode IDs by accepting the first six Mode IDs and dropping the rest. 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 The limited number of Mode IDs sets the maximum size of the
NAT_TRAVERSAL_MODE parameter. The modes MUST be in preference order, NAT_TRAVERSAL_MODE parameter. The modes MUST be in preference order,
most preferred mode(s) first. most preferred mode(s) first.
Implementations conforming to this specification MUST implement both Implementations conforming to this specification MUST implement UDP-
UDP-ENCAPSULATION and ICE-HIP-UDP modes. ENCAPSULATION and SHOULD implement ICE-HIP-UDP modes.
5.5. Connectivity Check Transaction Pacing Parameter 5.5. Connectivity Check Transaction Pacing Parameter
The TRANSACTION_PACING is a new parameter, and it shown in Figure 9 The TRANSACTION_PACING is a new parameter, and it shown in Figure 9
contains only the connectivity check pacing value, expressed in contains only the connectivity check pacing value, expressed in
milliseconds, as a 32-bit unsigned integer. milliseconds, as a 32-bit 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 44, line 32 skipping to change at page 45, line 24
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
[RFC7401] by assigning new HIP Parameter Type values for the new HIP [RFC7401] by assigning new HIP Parameter Type values for the new HIP
Parameters: RELAYED_ADDRESS, MAPPED_ADDRESS (defined in Parameters: RELAYED_ADDRESS, MAPPED_ADDRESS (defined in
Section 5.12), and PEER_PERMISSION (defined in Section 5.13). Section 5.12), and PEER_PERMISSION (defined in Section 5.13).
This document also updates the IANA Registry for HIP NAT traversal This document updates the IANA Registry for HIP NAT traversal modes
modes [RFC5770] by assigning value for the NAT traversal mode ICE- [RFC5770] by assigning value for the NAT traversal mode ICE-HIP-UDP
HIP-UDP (defined in Section 5.4). (defined in Section 5.4) This specification introduces a new
keepalive Notify message type field NAT_KEEPALIVE.
This document defines additional registration types for the HIP This document defines additional registration types for the HIP
Registration Extension [RFC8003] that allow registering with a HIP Registration Extension [RFC8003] that allow registering with a HIP
relay server for ESP relaying service: RELAY_UDP_ESP (defined in relay server for ESP relaying service: RELAY_UDP_ESP (defined in
Section 4.1; and performing server reflexive candidate discovery: Section 4.1; and performing server reflexive candidate discovery:
CANDIDATE_DISCOVERY (defined in Section 4.2). CANDIDATE_DISCOVERY (defined in Section 4.2).
ICE specifications discuss "Unilateral Self-Address Fixing" in ICE specifications discuss "Unilateral Self-Address Fixing" in
section 17 in [I-D.ietf-ice-rfc5245bis]. This protocol is based on section 17 in [I-D.ietf-ice-rfc5245bis]. This protocol is based on
ICE, and thus the same considerations apply also here with one ICE, and thus the same considerations apply also here with one
skipping to change at page 45, line 20 skipping to change at page 46, line 7
9. Acknowledgments 9. Acknowledgments
Thanks to Jonathan Rosenberg and the rest of the MMUSIC WG folks for Thanks to Jonathan Rosenberg and the rest of the MMUSIC WG folks for
the excellent work on ICE. In addition, the authors would like to the excellent work on ICE. In addition, the authors would like to
thank Andrei Gurtov, Simon Schuetz, Martin Stiemerling, Lars Eggert, thank Andrei Gurtov, Simon Schuetz, Martin Stiemerling, Lars Eggert,
Vivien Schmitt, and Abhinav Pathak for their contributions and Tobias Vivien Schmitt, and 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, Tom Ylitalo, Juha Heinanen, Joakim Koskela, Samu Varjonen, Dan Wing, Tom
Henderson, and Jani Hautakorpi for their comments to [RFC5770], which Henderson, Alex Elsayed and Jani Hautakorpi for their comments to
is the basis for this document. [RFC5770], which is the basis for this document.
This work has been partially funded by CyberTrust programme by This work has been partially funded by CyberTrust programme by
Digile/Tekes in Finland. Digile/Tekes in Finland.
10. References 10. References
10.1. Normative References 10.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, Requirement Levels", BCP 14, RFC 2119,
skipping to change at page 46, line 37 skipping to change at page 47, line 26
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[I-D.ietf-ice-rfc5245bis] [I-D.ietf-ice-rfc5245bis]
Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", draft-ietf-ice- Address Translator (NAT) Traversal", draft-ietf-ice-
rfc5245bis-08 (work in progress), December 2016. rfc5245bis-08 (work in progress), December 2016.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<http://www.rfc-editor.org/info/rfc2475>.
10.2. Informative References 10.2. Informative References
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, DOI 10.17487/RFC4423, May (HIP) Architecture", RFC 4423, DOI 10.17487/RFC4423, May
2006, <http://www.rfc-editor.org/info/rfc4423>. 2006, <http://www.rfc-editor.org/info/rfc4423>.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
Henderson, "Host Identity Protocol", RFC 5201, Henderson, "Host Identity Protocol", RFC 5201,
DOI 10.17487/RFC5201, April 2008, DOI 10.17487/RFC5201, April 2008,
<http://www.rfc-editor.org/info/rfc5201>. <http://www.rfc-editor.org/info/rfc5201>.
skipping to change at page 48, line 12 skipping to change at page 49, line 5
Ta value so that only two connectivity check messages are sent on Ta value so that only two connectivity check messages are sent on
every RTT. every RTT.
One way to estimate the RTT is to use the time that it takes for the One way to estimate the RTT is to use the time that it takes for the
HIP relay server registration exchange to complete; this would give HIP relay server registration exchange to complete; this would give
an estimate on the registering host's access link's RTT. Also, the an 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 I1/R1 exchange could be used for estimating the RTT, but since the R1
can be cached in the network, or the relaying service can increase can be cached in the network, or the relaying service can increase
the delay notably, this is not recommended. the delay notably, this is not recommended.
Appendix B. Base Exchange through a Rendezvous Server Appendix B. Differences with respect to ICE
When the Initiator looks up the information of the Responder from
DNS, it is possible that it discovers a rendezvous server (RVS)
record [RFC8004]. In this case, if the Initiator uses NAT traversal
methods described in this document, it MAY use its own HIP relay
server to forward HIP traffic to the rendezvous server. The
Initiator will send the I1 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 field in the RELAY_TO parameter MUST
be IP since RVS does not support UDP-encapsulated base exchange
packets. The Responder will send 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.
In case the Initiator is not able to distinguish which records are
RVS address records and which are Responder's address records (e.g.,
if the DNS server did not support HIP extensions), the Initiator
SHOULD first try to contact the Responder directly, without using a
HIP relay server. If none of the addresses are reachable, it MAY try
them out using its own HIP relay server as described above.
Appendix C. Differences with respect to ICE
The protocol specified in this document follows the semantics of ICE The protocol specified in this document follows the semantics of ICE
as close as possible, and most of the differences are syntactical due as close as possible, and most of the differences are syntactical due
to the use of a different protocol. In this section, we describe the to the use of a different protocol. In this section, we describe the
differences to the ICE protocol. differences to the ICE protocol.
o ICE operates at the application layer, whereas this protocol o ICE operates at the application layer, whereas this protocol
operates between transport and network layers, thus hiding the operates between transport and network layers, thus hiding the
protocol details from the application. protocol details from the application.
skipping to change at page 50, line 9 skipping to change at page 50, line 28
exchange tunneled over UDP followed ESP traffic over the same exchange tunneled over UDP followed ESP traffic over the same
tunnel, without the connectivity check procedures defined in this tunnel, without the connectivity check procedures defined in this
document (in some sense, this mode corresponds to the case where document (in some sense, this mode corresponds to the case where
two ICE lite implementations connect since no connectivity checks two ICE lite implementations connect since no connectivity checks
are sent). are sent).
o As the "ICE lite" is not adopted here and both sides are capable o As the "ICE lite" is not adopted here and both sides are capable
of ICE-HIP-HIP mode (negotiated during the base exchange), default of ICE-HIP-HIP mode (negotiated during the base exchange), default
candidates are not employed here. candidates are not employed here.
o The considerations on Diffserv Codepoint markings in ICE are not o If the agent is using Diffserv Codepoint markings [RFC2475] in its
applicable to HIP since Diffserv is not used in HIP. media packets, it SHOULD apply those same markings to its
connectivity checks.
o Unlike in ICE, the addresses are not XOR-ed in this protocol in o Unlike in ICE, the addresses are not XOR-ed in this protocol in
order to avoid middlebox tampering. order to avoid middlebox tampering.
o This protocol does not employ the ICE related address and related o This protocol does not employ the ICE related address and related
port attributes (that are used for diagnostic or SIP purposes). port attributes (that are used for diagnostic or SIP purposes).
Appendix D. Differences to Base Exchange and UPDATE procedures Appendix C. Differences to Base Exchange and UPDATE procedures
This section gives some design guidance for implementers how the This section gives some design guidance for implementers how the
extensions in this protocol extends and differs from [RFC7401] and extensions in this protocol extends and differs from [RFC7401] and
[RFC8046]. [RFC8046].
o Both control and data plane are operated on top of UDP, not o Both control and data plane are operated on top of UDP, not
directly on IP. directly on IP.
o A minimal implementation would conform only to Section 4.7.1 or o A minimal implementation would conform only to Section 4.7.1 or
Section 4.7.2, thus merely tunneling HIP control and data traffic Section 4.7.2, thus merely tunneling HIP control and data traffic
 End of changes. 26 change blocks. 
75 lines changed or deleted 72 lines changed or added

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