Subject: [Hipsec] Comment on draft-ietf-hip-nat-traversal-02-pre7: No controlling/controllled endpoints

From: Philip Matthews <[email-masked]>
Date: Fri, 29 Jun 2007 17:19:42 -0400

Miika:

In -02-pre7 it says:

    The conclusion of the connectivity checks, i.e., selection of the
    final address pair, differs the most as a result of fitting the ICE
    nomination algorithm to HIP mobility mechanisms.  There is no
    "controlling agent" even though it is the Initiator who triggers the
    connectivity tests by sending an UPDATE containing a LOCATOR
    parameter through the relay.  As there is no controlling agent, the
    end-hosts make a local decision on which locator pair to choose.
    This could lead to asymmetric address pairs, but the priority
    algorithm guarantees that the address pairs converge.

I am curious to know more why you think the concept of Controlling
vs. Controlled endpoints can be eliminated.

For those new to ICE, one endpoint is selected as the Controlling  
endpoint
and the other becomes the Controlled endpoint. The Controlling endpoint
is the one that makes the final section of the transmission path.

This feature was added to ICE recently for the following reasons:
a) It allows the Controlling endpoint to do extra, unspecified, tests to
select a transmission path. One example is to do RTT tests to select the
path with the lowest delay. With the concept of a Controlling endpoint,
there is no need to standardize these tests.
b) It gives ICE a high degree of future-proofing. Since the Controlling
endpoint makes the final selection, it can decide based on its own  
criteria,
which may be different than the other end which is running a different
ICE version.

Do you think these properties are not useful in ICE-for-HIP?
Or is there some other way to achieve them?

- Philip

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Miika Komu <[email-masked]>
Date: Sat, 30 Jun 2007 18:42:56 +0300 (EEST)

On Fri, 29 Jun 2007, Philip Matthews wrote:

Hi Philip,

> For those new to ICE, one endpoint is selected as the Controlling endpoint

I eliminated this feature because there was conflict in merging HIP and 
ICE together. I resolved the conflict in favour of HIP mobility 
mechanisms. According to the current HIP mobility draft, a host selects 
its own preferred locator independently of the peer.

You also mentioned that the Controller concept is not so important anymore 
because the checks are done in the same order at both sides.

> there is no need to standardize these tests.

There is nothing that prevents the peers of doing extra RTT tests 
separately from each other. If a host prefers, it can use another locator 
with smaller RTT when its connectivity was successfully tested.
It may result in asymmetric paths, but they are not strictly forbidden by 
the mobility draft.

> endpoint makes the final selection, it can decide based on its own criteria,

Is the Controller always the host with the higher ICE version?

> Do you think these properties are not useful in ICE-for-HIP? Or is there 
> some other way to achieve them?

Currently the draft specifies that the preferred bit should be always zero 
for transport locators. Maybe it was too quick decision.

I think we can achieve roughly the same functionality by doing an 
additional handover after the connectivity tests (that include RTT 
measurements). In the additional handover, we can set the preferred bit up 
for the locator with the best RTT. This would prioritize the locator to 
the highest numeric value, 127.

-- 
Miika Komu                                       http://www.iki.fi/miika/