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

[Miika Komu <miika.komu at hiit.fi>]

Miika Komu wrote:

Hi,

> > 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?

Actually, sockaddr_un is variable length, but getaddrinfo() returns only 
fixed sized identifiers. Anyway, this is what a fixed size structure 
would look like:

struct sockaddr_hip {
	sa_family_t    ship_family;
	in_port_t      ship_port;
	uint32_t       ship_pad;
	uint64_t       ship_flags;
	union {
		hip_hit_t      ship_hit;
		uint8_t        ship_reserved[MAX];
	} ship_id;
};

According to some quick compilation testing, the implementation size of 
MAX in linux is:

  * 112 in the above definition
  * 122 if we get rid of the pad field and changes flags to 16 bits

Size of sockaddr_storage is 128 on linux which should determine the 
maximum size of sockaddr_hip.

Comments?