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

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

Miika Komu wrote:

Hi,

I posted the final 09 version:

http://tools.ietf.org/html/draft-ietf-hip-native-api-09

I'd hope we could put it to the last call.

Thanks for Stefan, Jeff, Thomas and Andrew for their comments on this 
version!

> 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>
>
> _______________________________________________
> Hipsec mailing list
> Hipsec at ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec