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

[Miika Komu <[e-mail]>]

Miika Komu wrote:

Hi,

> Miika Komu wrote:
> 
> Hi,
> 
> a new preversion is here:
> 
> http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-09-pre2.txt
> 
> it includes the future proofing changes in the sockaddr_hip structure in 
> section 4.1. I also wrote the ship_len explicitly to the structure since 
> we were discussing on size issues.

sorry for the delay, we have been discussing this offline with Jeff, 
Stefan, Andrew and Thomas. IMHO, I think the extension fields to the 
existing sockaddr_hip structure do not bring much easier upgrade 
benefits when you think about how they would be used in practice. So, I 
think sockaddr_hip2 structure and a new flag for getaddrinfo() seems 
like a better future proofing approach. Below is my attempt to recap the 
discussion.

I am going to remove the extra fields unless anyone finds a convincing 
story why having some extra fields in the structure is beneficial for 
future proofing of HITs. I'd like to post a new final version by the end 
of this week.

<snip>
Miika: seems to me that sockaddr_hip with some extra fields gives the 
following advantages:

* always fixed memory size due to maximum size (struct sockaddr_hip
my_hip; works)
* somewhat easier upgrade of the software to use longer HITs
* < more here? >

At the same time it is somewhat disappointing in the following things:

* transparent migration from shorter to longer HITs
* interoperability (memcmp etc) between shorter and longer HITs
* logging and storing in ACLs

There's also some uncertainty factors that need to be considered:

* do we really need longer HITs in the future (elliptic curves)
* getaddrinfo() is already becoming antique

So, is extending the existing sockaddr_hip structure worth the extra
complexity? Or should we just suggest sockaddr_hip2 structure and an
extra flag for the resolver as the future proofing approach?

</snip>