Re: [MULTIMOBSEC-API] feedback from shim-api-00.txt

On Tue, 16 May 2006, marcelo bagnulo braun wrote:

> El 16/05/2006, a las 0:01, Miika Komu escribió:
>
>> On Mon, 15 May 2006, Shinta Sugimoto wrote:
>> 
>>> Mm, I am not sure if I want to be so specific at the beginning of
>>> the document.  Wouldn't it be fine just to say "Socket API" ?
>> 
>> According to the literature, it is "sockets API" with an "s".
>> 
>> Maybe you can say in intro that the draft is illustrated using C language. 
>> It is not a bad choice because the API bindings for other languages are 
>> based on C anyway.
>> 
>>> Ok, I will use 'event based'.  Does following sound better ?
>>> 
>>> <t>Notification from application to shim layer about outage.
>>> Application should be able to inform shim layer about outage
>>> in its communication.  Note that the notification is made
>>> in event based manner.  The cause of outage could be for instance
>>> a problem of network interface, congestions on the path and so on.
>>> ICMP error messages delievered to the upper layer protocol is
>>> normally clue for application to detect outgae.  REAP module
>>> may be triggered by this indication to invoke procedure of
>>> path exploration.</t>
>> 
>> s/outgae/outage/. Again, it is undefined what kind of outage is in 
>> question. Otherwise it is fine.
>
> i guess that it is any kind of outage that makes that an address pair is 
> no longer working. And an address pair is said to be working is packet 
> containing the first address from the pair as source address and the 
> second address from the pair as destiantion address can safely travel 
> from the source to the destiantion.

Something like this should be also in the text.

(Maybe I am getting too detailed already now in the beginning)

>>>>> However, this approach does not help the case where ID is not in form of
>>>>> IP address (e.g.  HIT in HIP case).
>>>> 
>>>> In HIP, a HIP enabled resolver can be used for setting up context prior 
>>>> to
>>>> the actual connection to HIT. Alternatively, DHTs support look-up of
>>>> non-hierarchical identifiers, such as HITs.
>>> 
>>> Yes.  But I think those (HIP enabled resolver and the DHT support) are
>>> still in some HIP implementation or HIP experts' mind, aren't they ?
>>> (I may be wrong, correct me if so)
>>> So I was not sure if we could give conclusive statements about
>>> these problems.
>> 
>> I don't understand. HIP enabled resolvers and DHT support are mostly 
>> supported by all of the three public implementations
>
> interesting.... which implementations are those?

http://infrahip.hiit.fi/
http://www.hip4inter.net/
http://www.openhip.org/

(I am not sure about the DHT support for Ericsson, you can ask Kristian 
for details)

>>> As for me, I am not sure if DHT based name resolution service could be 
>>> easily done.
>> 
>> It has been already done, but not really deployed in a large scale. And 
>> also it has not been standardized in the IETF, but neither has been e.g. 
>> skype :)
>> 
>
> i am not really following what comments you think there should be included 
> about DHT?... could you send text so we can understand more precisely what 
> you mean?

I believe I misunderstood the context term. In HIP and BTNS, the context 
really is a pair of IPsec SPs and the associated SAs, not a "mapping" like 
I described earlier. The mapping I was referring to means a HIT-to-IP 
mapping for the host.

So, in section "6.1.  Initial Contact", please remove the last sentence 
about HIP to avoid confusing things. Let's add a separate, new paragraph 
after that:

---text begins

In HIP, resolving HITs to IP addresses using DNS is not feasible because 
HITs do not contain any hierarchical information. To migitate this 
problem, there are few alternatives. First, resolver library on end-host 
can modified to communication HIT-to-IP mappings with HIP software module. 
Second, a distibuted hash table (DHT) service can be used for storing and 
looking up the the mappings because it supports non-hierarchical 
identifiers, such as HITs [*]. Third, it is possible to use IP addresses 
in legacy applications as described in [**].

[*] http://www.ietf.org/internet-drafts/draft-ietf-hip-arch-03.txt
[**] http://www.ietf.org/internet-drafts/draft-henderson-hip-applications-02.txt

---text ends

We should not really argue in the draft what approach is good and what is 
bad, at least when it comes to HITs and DHT. Let's just list the 
alternatives and give references, otherwise the discussion is just getting 
into a sidetrack.

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