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

[Miika Komu <[e-mail]>]

Ahrenholz, Jeffrey M wrote:

Hi,

thanks Jeff for feedback!

>> So, the 128-bit reserved field cannot really be used for 
>> extending the size of the HIT and we really need a completely new 
>> structure for them?
> 
> OK, I overlooked the 128-bit ship_reserved field. Yes it seems like we
> need a new structure; right now we're considering 256-bit HITs but what
> about 512, 1024, etc.?

Good point. The maximum size for a socket address structure is 255 
octets. Unfortunately, the old "endpoint descriptor" concept was voted 
out (at apps and hip area) and it would have been nice for this purpose. 
It proposed basically a handle that could hide an identifier of any size.

>> Jeff, what do you think about this? Are the associate 
>> problems now more 
>> clear? I think it's important to get this right.
> 
> will larger HITs share the same prefix as existing 128-bit HITs? 

Good question and we probably don't have a good answer for this now.

> if we have different prefixes, API calls can use sockaddr with
> sa_family=AF_HIP and we can inspect the prefix to determine the bitsize;
> this is a departure from the sa_family alone determining the size of the
> structure

The sockets API basically gives constant size data structures for 
applications. I think we shouldn't break this design pattern. So 
reserving a constant size extension field is ok, but variable size 
structure (with the same name) is probably not a good idea.

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?

>> Should we actually have a function/macro called HIP_IS_HIT()? Or just 
>> add a flag as you suggested to avoid each application to 
>> hard-code their own macros for this? What do you think?
> 
> Yes I think this HIP_IS_HIT() macro would be helpful.

Ok. Then we'll have one function for testing the local HITs and a second 
one for testing both local and peer HITs. Is this ok or should they be 
unified?

>>> why is HIP_HIT_ANY_TMP used for anonymous identifiers? 
>> maybe it should be named HIP_HIT_ANY_ANON or HIP_HIT_ANY_NOPUB?
>>
>> To align it with RFC5014 constants. Do you think ANON would 
>> be more clear?
> 
> The _TMP is OK, makes sense to align with RFC 5014 terminology.

Ok.

>> Yes and I was asking also what should the actual error value be (pick 
>> one from /usr/include/asm-generic/errno.h)? It could be also 
>> ETIMEDOUT 
>> because the peer failed to respond with an R1. Or in the case of 
>> hiccups, there was no response from the transport layer...
>>
>> In comparison, it seems like SCTP API just typically ignores errno 
>> issues with "the variable errno is then set appropriately":
>>
>> http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-19
> 
> I think that Tom's suggested text addresses this with the "set errno
> appropriately" language.

Agreed.