Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-api-03.txt

From: Miika Komu <[email-masked]>
Date: Fri, 1 Feb 2008 12:35:43 +0200 (EET)

On Thu, 31 Jan 2008, Henderson, Thomas R wrote:

Hi Tom,

> Miika,
> I owe you some more specific text proposals, but I thought I'd respond
> to some points inline below.

thanks for your comments and I am looking forward for your contributions. 
Gonzalo, I hope it is ok to bend the deadline?

>>>>> In section 4.2 (resolver extensions), the description
>> implies that a
>>>>> resolver will have to do two queries (nodename to HITs and
>>>> nodename to
>>>>> IP addresses), and concatenate the results in the rres
>> field, before
>>>>> returning from getaddrinfo().  Shouldn't the application
>>>> instead issue
>>>>> two getaddrinfo's for each of the different queries?
>>>>
>>>> Why complicate things unnecessarily for the developer? The
>> current API
>>>> is designed so that it can be used in existing apps with minimal
>>>> changes (i.e. by adding some flags).
>>>
>>> This depends perhaps on the perception of what complicates
>> things for
>>> the developer.  I do not agree that trying to make the
>> native HIP API
>>> deviate as little as possible from the address-based API
>> should be the
>>> primary goal here.  Rather, the main goal should be to have
>> an API with
>>> clear semantics, which is somewhat in conflict with
>> aligning with the
>>> address-based API because functions and data structures get
>> overloaded.
>>
>> Have you thought about what the application would look like
>> when it is
>> going to do two resolver calls and can initiate both HIP and non-HIP
>> connections?
>
> I thought we were going down that path already with the DNS draft (see
> section 3.2).

There is no such section. If you mean section 4.2, could you be more 
specific because this section contains quite much information.

I don't have any objection if the application wants to resolve the HITs 
and address separately when it is handling everything manually. However, 
don't like the idea that application is enforced to do it always. If we do 
agree that both ways should be possible, please contribute some text to 
section 4.5 (manual handling of locators).

My justification for making double resolving optional is that there is 
plenty of c-based software out there which could use HIP explictly by just 
chaning just few lines of code. I think enforcing double resolving would 
result in an anomaly to the sockets API that would frighten developers 
away from HIP.

> I think that there may be cases where the application gathers the 
> information it wants through DNS or whatever means directly, and then 
> uses a low-level API, and cases where the application just wants to use 
> HITs alone and not have to worry about RVS and addresses. IMO, we should 
> strive for an API that allows either case, but to me, it is important to 
> get the first one done first.

I assume you mean refer to the low-level API with "first one" here. I 
think DNS interaction should be a part of the low-level API. I view a 
high-level API something that is wrapped around the sockets API. It inputs
an hostname and service string and outputs an object that can be 
receiving and sending data. To go even further, we the high-level API 
could input a search string for data and some ways to publish or subscribe 
the data. Such a high-level API is clearly out of scope of this work.

Well, the low-level API consists of sockaddr_hip structures, new PF/AF 
families, existing socket calls and some new socket options. I believe 
they are already specified in the two drafts, but they are not organized 
under one subsection "low-level API" as you seem to want. Could you 
explain why such editorial change would make the draft more readable and, 
more interestingly, to whom? I see the current version targeted to the 
people who are actually going to implement the extensions to libc or other 
similar libraries. It is not exactly targeted for developers, but I 
believe that should be handled in the man (or similar) pages.

I agree that the RVS part needs some further clarifications in section 
4.5. More specifically, determining whether address belongs to a RVS or 
end-host should be explained in the native API draft. We have agreed with 
the authors of multihoming API draft that it is going to contain only the 
parts that are common between HIP and SHIM6.

>>> The sockets API is already roundly criticized for its semantic
>>> ambiguity; I think we should not make things worse if we
>> can help it.
>>
>> Can you be more specific what parts of the sockets API have received
>> criticism? AFAIK, the main part I've heard of in the apps area is the
>> resolver part which has not met its promises in the real world.
>> Also, it was not originally designed with multihoming in mind.
>
> Plus, the mixture of stream and datagram semantics.

Excuse my ignorance but may I ask in which forum has this been critized?

>> I believe you are suggesting here effectively an additional deployment 
>> obstacle. Even my futile attempt to introduce an additional abstraction 
>> ("end-point descriptor") to the HIP sockets API extensions (in draft 02 
>> version) was shot down by the research, apps area and hip community. I 
>> have some serious doubts about the future of such an approach.
>>
>> I think we need to follow the narrow path of sockets API to its end for 
>> two reasons. First, to facilititate deployment of HIP-enabled 
>> applications by introducing minimal changes to the current 
>> applications. Second, to get experimental-driven feedback on where to 
>> improve when designing better APIs for the future. Either from the 
>> scratch, or as python/java/c-library/etc middleware on top of the 
>> sockets API (apps-area folks think that the latter will be the 
>> reality). This is getting a little-bit off topic...
>
> Well, if we announce "this is the native HIP API" and then change it a 
> few years later, apps developers will not be happy.  That is why I'd 
> prefer to have the raw low-level API done first (which shouldn't have to 
> change in the future) and then start to engineer abstractions and 
> performance improvements-- those should be more experimental.

Well, I think the bits for the raw-level API are already in the two 
drafts, particularly if you think there is something missing. Please 
be more explicit.

>>> Here are two main issues I have with the current draft:
>>>
>>> - it presumes that DNS is the entry point for applications
>> to use HIP.
>>> Personally, I suspect that HIP-based applications will more
>> often than
>>> not use something else like a DHT, or other things we
>> haven't thought of
>>> yet.  But the main issue is that this draft delegates
>> handling of the
>>> HIT/IP address bindings to an intermediate layer; i.e., it
>> is kind of a
>>> higher-level API.  This might be a nice eventual goal in
>> some cases but
>>> I think that introducing the abstraction immediately (that
>> applications
>>> never need to handle locators) might be taking too big of an initial
>>> step.
>>
>> I disagree about the DNS presumptions partially. There is one
>> section,
>> 4.5. Manual Handling of Locators, dedicated completely to non-lookup
>> environments. I agree that the draft has more focus on DNS,
>> but I believe
>> think this is acceptable since most of the current
>> applications rely on
>> DNS.
>
> As I commented previously, it requires reading/using the shim6 draft to
> really implement the section 4.5, and here it was ambiguous (at least to
> me) how these options might apply to HIP.
>
> For instance:
>
> "5.6.  SHIM_LOC_PEER_PREF
>
>   The SHIM_LOC_PEER_PREF option can be used to read or set preferred
>   locator on peer side within a given context.  Hence this option is
>   effective only when there is a shim context associated with the
>   socket."
>
> Does that apply to HIP?  When is there a HIP "shim context" present?  I
> don't think the use of these options is as clear as it could be,
> especially to people who do not know HIP and shim6.

Yes it does. Good point, I think "HIP context" should be clarified in the 
multihoming draft. The multihoming draft should also mention more clearly 
in the intro that everything in the draft should apply to both SHIM6 and 
HIP. Tom, we'd appreciate more detailed comments and corrections to the 
multihoming draft if you have some more.

>> I think this was a reasonable call for four reasons. First, the 
>> locators in sockaddr_hip structure can get depracated quite soon in 
>> mobile environments and it is easier for the application (developer) to 
>> misuse them. Second, sockaddr structures have size limits and can hold 
>> only a number of locators. Third, when the resolver resolves multiple 
>> HITs, it does not make sense to have the locators spread redundantly in 
>> multiple socket address structures. Fourth, I think the current version 
>> of the draft is more compatible with the multihoming draft this way.
>>
>> This design choice had a consequence on the opportunistic
>> mode. Namely, I
>> had to introduce the HIP_ADDR_ANY concept because there is no locator
>> structure in sockaddr_hip. I don't like it either, but that is rough
>> consensus ;)
>
> The option is to always allow for a (possibly wildcarded) locator
> structure.

How?

>>> The current draft covers a lot of ground; not only is the basic API
>>> (partially) covered but also resolver interactions and now (in the
>>> latest version) source HIT selection policy.  My preference
>> would be to
>>> focus first on the basic raw API and then move to the other
>> points.  I
>>> would like to suggest the following steps.
>>
>> I was working on the assumption that you were concurring with
>> Andrew on
>> the source HIT selection policy because you repeated his
>> request on your
>> comments:
>>
>> http://www1.ietf.org/mail-archive/web/hipsec/current/msg02323.html
>>
>> Hence, I included the source HIT selection policy to the API.
>
> Yes, I am just mentioning that you have recently added the equivalent of
> RFC 3484 and 5014, which makes it cover a lot of ground now.
>
> I have not carefully thought about the choices in Table 3, although it
> occurred to me that key (HI) length is not a criteria in the selection
> (should it be?).

Good point, but I don't know how to specify this as a list of rules with 
static prioritity values because the HI lenght is variable. Perhaps we 
could say that if there is a tie with two keys with same properties, the 
one with more bits has higher preference?

>> Agree that this should be added to the draft and should result in
>> EDESTADDRREQ error.
>
> Yes, this is the point that I am trying to make-- we should try to
> clarify these types of things now.

Looking forward for a more detailed feedback or contribution.

-- 
Miika Komu                                       http://www.iki.fi/miika/
_______________________________________________
Hipsec mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/hipsec

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 09 Feb 2008 15:04:40 +0200

Hi Miika,

> thanks for your comments and I am looking forward for your 
> contributions. Gonzalo, I hope it is ok to bend the deadline?

at this point it is more important to get a technically solid document 
than to meet the deadline (as long as the delay is not too high, of course).

Cheers,

Gonzalo