draft-ietf-hip-native-nat-traversal-14.txt   draft-ietf-hip-native-nat-traversal-15.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: May 28, 2017 Ericsson Expires: August 5, 2017 Ericsson
November 24, 2016 February 1, 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-14 draft-ietf-hip-native-nat-traversal-15
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 May 28, 2017. This Internet-Draft will expire on August 5, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6
4. Protocol Description . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 7
4.1. Relay Registration . . . . . . . . . . . . . . . . . . . 7 4.1. Relay Registration . . . . . . . . . . . . . . . . . . . 7
4.2. Transport Address Candidate Gathering . . . . . . . . . . 10 4.2. Transport Address Candidate Gathering . . . . . . . . . . 10
4.3. NAT Traversal Mode Negotiation . . . . . . . . . . . . . 11 4.3. NAT Traversal Mode Negotiation . . . . . . . . . . . . . 12
4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 12 4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 13
4.5. Base Exchange via HIP Relay Server . . . . . . . . . . . 13 4.5. Base Exchange via HIP Relay Server . . . . . . . . . . . 14
4.6. Connectivity Checks . . . . . . . . . . . . . . . . . . . 16 4.6. Connectivity Checks . . . . . . . . . . . . . . . . . . . 17
4.6.1. Connectivity Check Procedure . . . . . . . . . . . . 16 4.6.1. Connectivity Check Procedure . . . . . . . . . . . . 17
4.6.2. Rules for Connectivity Checks . . . . . . . . . . . . 19 4.6.2. Rules for Connectivity Checks . . . . . . . . . . . . 20
4.6.3. Rules for Concluding Connectivity Checks . . . . . . 21 4.6.3. Rules for Concluding Connectivity Checks . . . . . . 22
4.7. NAT Traversal Alternatives . . . . . . . . . . . . . . . 22 4.7. NAT Traversal Alternatives . . . . . . . . . . . . . . . 23
4.7.1. Minimal NAT Traversal Support . . . . . . . . . . . . 22 4.7.1. Minimal NAT Traversal Support . . . . . . . . . . . . 23
4.7.2. Base Exchange without Connectivity Checks . . . . . . 22 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 . . . . . . . . . . . . . . . . . . . . 23 Encapsulation . . . . . . . . . . . . . . . . . . . . 24
4.8. Sending Control Packets after the Base Exchange . . . . . 24 4.8. Sending Control Packets after the Base Exchange . . . . . 25
4.9. Mobility Handover Procedure . . . . . . . . . . . . . . . 25 4.9. Mobility Handover Procedure . . . . . . . . . . . . . . . 26
4.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 27 4.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 28
4.11. Closing Procedure . . . . . . . . . . . . . . . . . . . . 28 4.11. Closing Procedure . . . . . . . . . . . . . . . . . . . . 29
4.12. Relaying Considerations . . . . . . . . . . . . . . . . . 28 4.12. Relaying Considerations . . . . . . . . . . . . . . . . . 29
4.12.1. Forwarding Rules and Permissions . . . . . . . . . . 28 4.12.1. Forwarding Rules and Permissions . . . . . . . . . . 29
4.12.2. HIP Data Relay and Relaying of Control Packets . . . 29 4.12.2. HIP Data Relay and Relaying of Control Packets . . . 30
4.12.3. Handling Conflicting SPI Values . . . . . . . . . . 30 4.12.3. Handling Conflicting SPI Values . . . . . . . . . . 31
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 30 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 31
5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 31 5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 32
5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 31 5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 32
5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 32 5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 33
5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . 32 5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . 33
5.5. Connectivity Check Transaction Pacing Parameter . . . . . 33 5.5. Connectivity Check Transaction Pacing Parameter . . . . . 34
5.6. Relay and Registration Parameters . . . . . . . . . . . . 33 5.6. Relay and Registration Parameters . . . . . . . . . . . . 34
5.7. LOCATOR_SET Parameter . . . . . . . . . . . . . . . . . . 34 5.7. LOCATOR_SET Parameter . . . . . . . . . . . . . . . . . . 35
5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . 36 5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . 37
5.9. Registration Types . . . . . . . . . . . . . . . . . . . 37 5.9. Registration Types . . . . . . . . . . . . . . . . . . . 38
5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 37 5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 38
5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . 37 5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . 38
5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 38 5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 39
5.13. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 39 5.13. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 40
5.14. HIP Connectivity Check Packets . . . . . . . . . . . . . 40 5.14. HIP Connectivity Check Packets . . . . . . . . . . . . . 41
5.15. NOMINATE parameter . . . . . . . . . . . . . . . . . . . 40 5.15. NOMINATE parameter . . . . . . . . . . . . . . . . . . . 41
6. Security Considerations . . . . . . . . . . . . . . . . . . . 40 6. Security Considerations . . . . . . . . . . . . . . . . . . . 41
6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 41 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 42
6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . 41 6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . 42
6.3. Base Exchange Replay Protection for HIP Relay Server . . 41 6.3. Base Exchange Replay Protection for HIP Relay Server . . 42
6.4. Demuxing Different HIP Associations . . . . . . . . . . . 42 6.4. Demultiplexing Different HIP Associations . . . . . . . . 43
6.5. Reuse of Ports at the Data Relay . . . . . . . . . . . . 42 6.5. Reuse of Ports at the Data Relay . . . . . . . . . . . . 43
6.6. Amplification attacks . . . . . . . . . . . . . . . . . . 42 6.6. Amplification attacks . . . . . . . . . . . . . . . . . . 43
6.7. Attacks against Connectivity Checks and Candidate 6.7. Attacks against Connectivity Checks and Candidate
Gathering . . . . . . . . . . . . . . . . . . . . . . . . 42 Gathering . . . . . . . . . . . . . . . . . . . . . . . . 43
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 44 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 45
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
10.1. Normative References . . . . . . . . . . . . . . . . . . 44 10.1. Normative References . . . . . . . . . . . . . . . . . . 45
10.2. Informative References . . . . . . . . . . . . . . . . . 45 10.2. Informative References . . . . . . . . . . . . . . . . . 46
Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 46 Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 47
Appendix B. Base Exchange through a Rendezvous Server . . . . . 47 Appendix B. Base Exchange through a Rendezvous Server . . . . . 48
Appendix C. Differences to ICE . . . . . . . . . . . . . . . . . 47 Appendix C. Differences to ICE . . . . . . . . . . . . . . . . . 48
Appendix D. Differences to Base Exchange and UPDATE procedures . 49 Appendix D. Differences to Base Exchange and UPDATE procedures . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 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.
To overcome this problem, different methods, commonly referred to as To overcome this problem, different methods, commonly referred to as
skipping to change at page 5, line 14 skipping to change at page 5, line 14
The Responder's LOCATOR_SET parameter in a HIP R2 control packet. The Responder's LOCATOR_SET parameter in a HIP R2 control packet.
Corresponds to the ICE answer parameter, but is HIP specific. Corresponds to the ICE answer parameter, but is HIP specific.
HIP connectivity checks: HIP connectivity checks:
In order to obtain a non-relayed communication path, two In order to obtain a non-relayed communication path, two
communicating HIP hosts try to "punch holes" through their NAT communicating HIP hosts try to "punch holes" through their NAT
boxes using this mechanism. Similar to the ICE connectivity boxes using this mechanism. Similar to the ICE connectivity
checks, but implemented using HIP return routability checks. checks, but implemented using HIP return routability checks.
Controlling host : Controlling host:
The controlling host nominates the candidate pair to be used with The controlling host nominates the candidate pair to be used with
the controlled host. the controlled host.
Controlled host : Controlled host:
The controlled host waits for the controlling to nominate an The controlled host waits for the controlling to nominate an
address candidate pair. address candidate pair.
Checklist: Checklist:
A list of address candidate pairs that need to be tested for A list of address candidate pairs that need to be tested for
connectivity. connectivity.
Transport address: Transport address:
Transport layer port and the corresponding IPv4/v6 address. Transport layer port and the corresponding IPv4/v6 address.
skipping to change at page 11, line 34 skipping to change at page 11, line 34
LSIs and by IPv6 based applications using HITs. The LSIs and HITs of LSIs and by IPv6 based applications using HITs. The LSIs and HITs of
the local virtual interfaces MUST be excluded in the candidate the local virtual interfaces MUST be excluded in the candidate
gathering phase as well to avoid creating unnecessary loopback gathering phase as well to avoid creating unnecessary loopback
connectivity tests. connectivity tests.
Gathering of candidates MAY also be performed as specified in Gathering of candidates MAY also be performed as specified in
Section 4.2 of [RFC5770] if STUN servers are available, or if the Section 4.2 of [RFC5770] if STUN servers are available, or if the
host has just a single interface and no STUN or HIP data relay host has just a single interface and no STUN or HIP data relay
servers are available. servers are available.
Eeach local address candidate MUST be assigned a priority. The
recommended formula in [I-D.ietf-ice-rfc5245bis] SHOULD be used:
priority = (2^24)*(type preference) + (2^8)*(local preference) +
(2^0)*(256 - component ID)
In the formula, type preference follows the ICE specification section
4.1.2.2 guidelines: the RECOMMENDED values are 126 for host
candidates, 100 for server reflexive candidates, 110 for peer
reflexive candidates, and 0 for relayed candidates. The highest
value is 126 (the most preferred) and lowest is 0 (last resort). For
all candidates of the same type, the preference type value MUST be
identical, and, correspondingly, the value MUST be different for
different types. For peer reflexive values, the type preference
value MUST be higher than for server reflexive types. It should be
noted that peer reflexive values are learned later during
connectivity checks, so a host cannot employ it during candidate
gathering stage yet.
Following the ICE specification, the local preference MUST be an
integer from 0 (lowest preference) to 65535 (highest preference)
inclusive. In the case the host has only a single address candidate,
the value SHOULD be 65535. In the case of multiple candidates, each
local preference value MUST be unique. Dual-stack considerations for
IPv6 in section 4.1.2.2 in ICE apply also here.
Unlike ICE, this protocol only creates a single UDP flow between the
two communicating hosts, so only a single component exists. Hence,
the component ID value MUST always be set to 1.
As defined in ICE (in section 11.3), the retransmission timeout (RTO)
for address gathering from a relay SHOULD be calculated as follows:
RTO = MAX (500ms, Ta * (Num-Of-Pairs))
where Ta is the value used for Ta is the value used for the
connectivity check pacing and Num-Of-Pairs is number of pairs of
candidates with relay servers (e.g. in the case of a single relay
server, it would be 1). A smaller value than 500 ms for the RTO MUST
NOT be used.
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 (as defined in document. As the parameter is non-critical (as defined in
Section 5.2.1 of [RFC7401]), it can be ignored by an end-host, which Section 5.2.1 of [RFC7401]), it can be ignored by an end-host, which
means that the host does not support or is not willing to use these means that the host does not support or is not willing to use these
extensions. extensions.
skipping to change at page 20, line 50 skipping to change at page 21, line 50
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 start 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 MUST 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
"In-Progress" state. This is identical to the formula in "In-Progress" state. This is identical to the formula in
[I-D.ietf-ice-rfc5245bis] when there is only one checklist. A [I-D.ietf-ice-rfc5245bis] when there is only one checklist. A
smaller value than 500 ms for the RTO MUST NOT be used. smaller value than 500 ms for the RTO MUST NOT be used.
skipping to change at page 42, line 9 skipping to change at page 43, line 9
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 becoming The relay can protect itself against replay attacks by becoming
involved in the base exchange by introducing nonces that the end- involved in the base exchange by introducing nonces that the end-
hosts (Initiator and Responder) are required to sign. One way to do hosts (Initiator and Responder) are required to sign. One way to do
this is to add ECHO_REQUEST_M parameters to the R1 and I2 packets as this is to add ECHO_REQUEST_M parameters to the R1 and I2 packets as
described in [HIP-MIDDLE] and drop the I2 or R2 packets if the described in [HIP-MIDDLE] 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. Demultiplexing 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
skipping to change at page 45, line 35 skipping to change at page 46, line 35
[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,
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-05 (work in progress), October 2016. rfc5245bis-08 (work in progress), December 2016.
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,
skipping to change at page 48, line 21 skipping to change at page 49, line 21
o Instead of the ICE username fragment and password mechanism for o Instead of the ICE username fragment and password mechanism for
credentials, this protocol uses the public key derived HIT for the credentials, this protocol uses the public key derived HIT for the
same purpose. The username fragments are "transient host same purpose. The username fragments are "transient host
identifiers, bound to a particular session established as part of identifiers, bound to a particular session established as part of
the candidate exchange" [I-D.ietf-ice-rfc5245bis]. In HIP, a the candidate exchange" [I-D.ietf-ice-rfc5245bis]. In HIP, a
local public key and the derived HIT are considered long-term local public key and the derived HIT are considered long-term
identifiers, and invariant across different host associations and identifiers, and invariant across different host associations and
different transport-layer flows. different transport-layer flows.
o In ICE, the conflict when two communicating end-points take the o In ICE, the conflict when two communicating end-points take the
same controlling role is solved using random values (co called same controlling role is solved using random values (so called
tie-breaker value). In this protocol, the conflict is solved by tie-breaker value). In this protocol, the conflict is solved by
the standard HIP base exchange procedure, where the host with the the standard HIP base exchange procedure, where the host with the
"larger" HIT switches to Responder role, thus changing also to "larger" HIT switches to Responder role, thus changing also to
controlled role. controlled role.
o The ICE-CONTROLLED and ICE-CONTROLLING attributes are not included o The ICE-CONTROLLED and ICE-CONTROLLING attributes are not included
in the connectivity checks. in the connectivity checks.
o The foundation concept is unnecessary in this protocol because o The foundation concept is unnecessary in this protocol because
only a single UDP flow for the IPsec tunnel will be negotiated. only a single UDP flow for the IPsec tunnel will be negotiated.
 End of changes. 14 change blocks. 
65 lines changed or deleted 106 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/