Subject: [Hipsec] comments on draft-ietf-hip-native-api-02.txt

From: Shinta Sugimoto <[email-masked]>
Date: Wed, 03 Oct 2007 21:40:34 +0900

Hi Miika and all,

Let me send my comments on draft-ietf-hip-native-api-02.txt.
I amware that there have been many discussions about the draft
and I went through the all emails posted on the ML.  Hope that
I am not writing things that have already been discussed/
resolved.

At first, I'd like to mention that I am the editor of another
API draft which is being worked in the SHIM6 WG:
draft-ietf-shim6-multihome-shim-api-03 (hereafter, I call this
draft "multihome shim API").  The multihome shim API draft
aims to define a common set of socket API extensions that are
useful for applications that run in a multihomed environment.
So, the scope of the draft ranges in multihoming capability
of HIP and SHIM6.  More specifically, the common set are about
locator management and control of failure detection.  To put
it in the other way, anything specific to each protocol should
be eliminated from the multihome shim API draft.

In the light of this, we should try to align the two API
documents (Miika's draft and multihome shim API draft) each
other.  At least, the two documents should not be contradicting
each other.  Duplication should be avoided.

My comments:

- To me, the goals and objectives of the document were not clear.
I mean, I could not understand what are unique properties of HIP
aware application from the document.  Maybe I am missing something
but I think it should be quite easy for reader to understand.
My suggestion is to put a new section between Section 2 and 3,
stating the goals and objectives of the draft.

- As Thomas suggested, I think it would be better to design the
API specific to HIP.  To me, the scope of the draft seems to be
too broad.  I don't think the newly defined API is useful for
SHIM6 scenario because the design of SHIM6 is based on the
assumption that the identifier is chosen from locator, i.e.,
the namespace of identifier is identical to that of locator.

- Section 4.1:
I found it difficult to understand the reason behind the design
of the sockaddr_shim data structure.  More specifically, I could
not see why identifier and locator need to be packed in a single
data structure. (I realized that this issue has been resolved)

- Section 4.2:
I have some detailed comments. Please find them inline:

> 4.2.  Resolver
> 
>    The SHIM API uses the getaddrinfo resolver function which the
>    application uses to query both ULIDs and locators.  The resolver
>    introduces a new data structure, which is used both as the input and
>    output argument for the resolver.

The addrinfo data structure is not new, so the above sentence
sounds misleading.

>  The data structure is illustrated
>    in Figure 4.
> 
>           struct addrinfo {
>               int    ai_flags;          /* e.g. AI_SHIM */
>               int    ai_family;         /* e.g. PF_SHIM */
>               int    ai_socktype;       /* e.g. SOCK_STREAM */
>               int    ai_protocol;       /* 0 or IPPROTO_HIP */
>               size_t ai_addrlen;        /* length of the endpoint */
>               struct sockaddr *ai_addr; /* socket address */
>               char   *ai_canonname;     /* canon. name of the host */
>               struct addrinfo *ai_next; /* next endpoint */
>           };
> 
>                                  Figure 4
> 
>    In addrinfo structures, the family field is set to PF_SHIM when the
>    socket address structure contains an ULID that refers to ULID, such
>    as HIT.
> 
>    The flag AI_SHIM must be set, or otherwise the resolver does not
>    return sockaddr_shim data structures to guarantee that legacy
>    applications do not break.   Some applications may prefer configuring
>    the locators manually and can set the AI_SHIM_NOLOCATORS flag to
>    prohibit the getaddrinfo from resolving any locators.
> 
>    The ai_family field is PF_SHIM with SHIM-specific addrinfo data
>    structures.
 >
>    The protocol field is 0 when the getaddrinfo caller does not care
>    about the specific SHIM protocol to be used.  The caller (or the
>    resolver) can set this field also to IPPROTO_HIP.

The document should specify what error (EAI_???) should be
returned if a requested protocol is not available on the
system.

> 
>    ai_addrlen is the size of the structure pointed by ai_addr.
> 
>    The ai_addr points to a sockaddr_shim structure when the value of
>    ai_family is PF_SHIM.  The resolver sets SHIM_RVS in sins_flags of
>    the when the locator belongs to a rendezvous server
>    [I-D.ietf-hip-dns].
> 
> 
> 
> Komu                     Expires January 8, 2008                [Page 8]
> 
> Internet-Draft              Native SHIM APIs                   July 2007
> 
> 
>    The SHIM API does not introduce changes to the interface syntax of
>    the existing sockets API functions, such as bind(), connect(),
>    send(), sendto(), sendmsg(), recv(), recvfrom(), and recvmsg().

What about gethostbyname() and getservbyname()?

>    However, the SHIM-aware application usually passes the functions a
>    sockaddr_shim structure instead of a sockaddr_in or sockaddr_in6
>    structure.  A SHIM-aware application either creates the sockaddr_shim
>    structures manually or obtains them from the resolver.  The
>    getaddrinfo resolver [RFC3493] is shown in Figure 5.
> 
>            int getaddrinfo(const char *nodename,
>                            const char *servname,
>                            const struct addrinfo *hints,
>                            struct addrinfo **res)
>            void free_addrinfo(struct addrinfo *res)
> 
>                                  Figure 5
> 
>    As described in [RFC3493], the getaddrinfo function takes the
>    nodename, servname, and hints as its input arguments.  It places the
>    result of the query into the res argument.  The return value is zero
>    on success, or a non-zero error value on error.  The nodename
>    argument specifies the host name to be resolved; a NULL argument
>    denotes the local host.  The servname parameter declares the port
>    number to be set in the socket addresses in the res output argument.
>    Both the nodename and servname cannot be NULL.

The above paragraph gives general explanation of getaddrinfo.
Maybe it would be more helpful to provide implications of the
use of getaddrinfo by the HIP aware application.

For instance, suppose a server program calls getaddrinfo.
To my knowledge, typical server program specifies AI_PASSIVE
flag in hints->ai_flags, and the returned values will be the
unspecified addresses (e.g. 0.0.0.0 in IPv4 case).  But in
a HIP aware server case, what should be the result of
getaddrinfo?  I suppose only HIT(s) should be returned even
if AI_PASSIVE is specified.  Or simultaneous use of
AI_PASSIVE and AI_SHIM is prohibited?

>    The input argument hints acts like a filter that defines the
>    attributes required from the resolved endpoints.  For example, the
>    resolver returns only anonymous endpoints in the output argument res
>    when the application sets the ai_addr pointer of hints to point to a
>    sockaddr_shim structure with sins_ulid filled with SHIM_ANY_ANON.  A
>    NULL hints argument indicates that any kind of endpoints are
>    acceptable.

Wouldn't it be more efficient to introduce a new flag in ai_flags
rather than setting SHIM_ANY_ANON flag in a sockaddr_shim data
structure?

> 
>    The output argument res is dynamically allocated by the resolver.
>    The application must free res argument with the free_addrinfo
>    function.  The res argument contains a linked list of the resolved
>    endpoints.  The linked list contains sockaddr_shim structures only
>    when the input argument has the AI_SHIM flag set.  When the resolver
>    finds SHIM identifiers, it inserts them to the front of the list.
> 
>    Resolving of a hostname may result in multiple locators associated to
>    a single ULID, but the sockaddr_shim structure contains only a single
>    ULID-locator pair.  The resolver handles this by repeating the ULD as
>    many time as needed.  For example, let us consider a case where the
>    resolver finds an ULID that is associated to two locators.  In such a
>    case, the resolver outputs two sockaddr_shim structures with the same
>    ULID but different locators.

(the rest of the draft is snipped)

Regards,
Shinta

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec