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

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

Ahrenholz, Jeffrey M wrote:

Hi Jeff,

thanks for feedback! Let's iterate further.

> > we got an extra review to the native API from Stefan Götz. The new 
> > preversion is here:
> >
> > http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-09-pre1.txt
> >
> > The changes are editorial readability changes throughout the 
> > document. Especially section 4.1 contains now more clarifications on 
> > the fields of sockaddr_hip structure and wildcards
>
> I read the new preversion and it looks pretty good. Only this minor editorial nits below:
> Sect 3.1 Interaction with the Resolver
> s/should be noticed/should be noted/

thanks.

> > We'd like to move on with the document, but we have two questions for 
> > the working group:
> >
> > #1 How to future proof HITs in case we need 256 bit HITs? This is 
> > important also from the view point of comparison of HITs (currently 
> > draft suggests memcmp() in section 4.1. Unless, there's other 
> > suggestions, I'd go for alternative (i):
> >
> >      * Alternative (i): separate sockaddr_hip structure for 
> > larger HITs
> >      * Alternative (ii): make larger HIT structure in 
> > sockaddr_hip with 
> > zero padding for 128 bit HITs
>
> yes I like alternative (i) better than (ii); 

Ok. Notice that this option would need also flag in the resolver call to 
force the resolve to return larger HITs.

> maybe you could make use of ship_flags to indicate new ship_hit bit 
sizes in the future

Your comment is related to option ii.

There is a 128-bit reserved field after the HIT in the sockaddr_hip 
structure, so this is possible even now. However, the problem is with 
existing applications because they will hard-code ACL checks with 
sizeof(128 bits), so we'd really need an union or something to force the 
sizeof to be always 256 bits. Otherwise, the application compares only 
128 bits of the HIT. Setting HIP_HIT_ANY_* will also become more tricky 
with the union and we'd need to specify explicitly where to fill them in 
(since the resolver is not currently specified to fill them in 
automatically). 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?

Jeff, what do you think about this? Are the associate problems now more 
clear? I think it's important to get this right.

> note that in section 4.1.1 you also describe storing IPv6 and IPv4-mapped addresses in the ship_hit field; (should the ship_flags indicate these locator types?) in the future you would need to come up with new mappings, such as IPv4/IPv6-mapped to a 256 bit HIT.

It's redundant information because the HIT has always a separate prefix. 
sockaddr_is_srcaddr() can be used to verify local HITs, but not peer. 
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?

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

> > #2 How should the socket calls react to only-hip wildcard. Currently 
> > section 4.1.1 describes:
> >
> >     With the HIP_HIT_ANY address,
> >     the underlying system allows only HIP-based data flows with the
> >     corresponding socket.  For incoming packets, the system 
> > transparently
> >     discards all other traffic arriving at the socket than 
> > HIP related.
> >     For outgoing packets, the system returns -1 in the socket call and
> >     sets errno to ECOMM when the system failed to deliver the 
> > packet over
> >     a HIP-based data channel.
>
> maybe you are asking if the text is enough?

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

> it seems fairly clear to me:
> - bind() to HIP_HIT_ANY and the socket provides you only with HIP data
> - connect() to HIP_HIT_ANY and you are required to specify a locator (sect 4.6) (and I assume it would establish an association w/anonymous I1)
> - error under other circumstances

There is a separate error message when there is no locator with 
connect() in section 4.2.1:

   When the system fails to
   provide the mapping, it returns -1 in the called sockets API function
   to the application and sets errno to EADDRNOTAVAIL.