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

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

Miika Komu wrote:

Hi,

a new preversion:

http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-09-pre3.txt

Changes:

* changed future proofing approach 4.1 and 7 as discussed below
* hip_is_hit() operates now on hip_hit_t rather than sockaddr_hip based 
on the changes on future proofing approach

Question:

Should the wildcards be allocated by IANA?

Comments are welcome, thanks!

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