Re: [Hipsec] draft-ietf-hip-native-api-09-pre

[Miika Komu <[e-mail]>]

Andrew McGregor wrote:

Hi,

> On 25/08/2009, at 10:24 AM, Ahrenholz, Jeffrey M wrote:
> 
>>>> Based on this discussion, it appears that the best way for future
>>>> proofing is to include a flag for getaddrinfo() in the hints
>>>> arguments that will result in sockaddr_hip_long structures instead
>>>> of sockaddr_hip. This way, applications get exactly what they want
>>>> and can store the HITs easily in their ACLs. I'd also remove the
>>>> extra space reserved space because it seems that it's not very
>>>> usable for future proofing as it is now.
>>>>
>>>> Jeff, how do you feel about this or do you have a better suggestion?
>>>
>>> I think you'd be better to define more than a flag... an
>>> explicit size
>>> (or enum) would be better.  That way if some other odd size
>>> becomes a
>>> requirement later, it's not such an annoyance to fit in to the API
>>
>> yes, a size or flag makes sense; looks like struct addrinfo already has
>> "size_t ai_addrlen;" but that field must be zero when used as hints
>> (looking at getaddrinfo(3) man)
>>
>> other calls such as connect(), bind(), and sendto() already take a
>> "socklen_t addrlen" argument

the socket address structure already contains the size of the socket 
within the first field. Having yet another size within the structure or 
a variable length socket address structure is confusing for people used 
to constant size structures such as sockaddr_in, sockaddr_in6 and 
sockaddr_storage.

Have a look at section "EXAMPLES" on getaddrinfo() FreeBSD man pages:

http://www.gsp.com/cgi-bin/man.cgi?section=3&topic=getaddrinfo

If there is an additional length field and it must be used in socket 
calls, it disrupts the flow of the client side example.

> Ah, in that case... getaddrinfo should return whatever it can, and 
> applications should be required to check lengths if they care.  That 
> avoids coding in bugs early.

The problem is that they do have check lengths when the applications 
fill in the socket address structures by themselves. I think it also a 
show stopper for allocations from the heap (struct addrinfo foo;). 
Dynamic allocations get somewhat tricky because defining the allocated 
size is not trivial.

A way to avoid the memory-related problem and "client flow" problem 
would be to define sockaddr_hip to contain the maximum number of bytes 
similarly as sockaddr_storage does. Would that work for you?

We would still need the actual HIT field to be defined as an union to 
facilitate naming of larger HITs withing the structure in a backwards 
compatible way. Right?