Subject: RE: [Hipsec] Re: API draft

From: Miika Komu <[email-masked]>
Date: Mon, 19 Nov 2007 17:46:43 +0200 (EET)

On Sat, 17 Nov 2007, Henderson, Thomas R wrote:

Tom,

thanks for your feedback. Your comments are included in the current 
version of the draft:

http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-03.txt

Unfortunately there was no time to iterate the issues more on the mailing 
list because the comments came on the cut-off day.

> - overall, I think it is improved without so much shim6 reliance, but
> perhaps more dependency needs to be removed?  (next comment)

I tried to remove some of the dependency by introducing some redundancy to 
the SHIM6 and also by including discussions about error handling.

> - referring to Figure 2, the biggest piece that seems to be missing in
> the draft is a discussion about step f (connect).  The draft basically
> implies that the application deals only with HITs, but I think that the
> API should also support passing locators along with HITs.  These
> locators need not be learned in the resolution step.  The draft needs to
> be extended to spell out the details (how are locators conveyed, and
> associated with a HIT, and what are semantics if the HIT is not
> reachable at those locators).

Added more text to section 3.2. "Interaction with the Resolver":

    The extensions in this document focus on the use of the resolver to
    map host names to HITs and locators in HIP-aware applications.  The
    resolver associates implicitly the the HIT with the locator(s).
    However, it is possible that an application operates directly with a
    peer HIT without interacting with the resolver.  In such a case, the
    application may resort to the system to map the peer HIT to an IP
    address.  Alternatively, the application can explicitly map the HIT
    to an IP address as specified in [I-D.ietf-shim6-multihome-shim-api].
    Both of these two approaches may be more prone to errors than the use
    resolver with host names.  Hence, HIP-aware applications should
    prefer to use the resolver with host names.

> It may be that you feel it is out of scope (section 2, para.3) but I
> think it needs to be in scope, or if you feel that it is in
> shim6-multihome, more of an overview presented here.

I think this is out of scope. The multihoming APIs are briefly introduced 
in the sixth paragraph and currently I don't see urgent need to go into 
more details. The main feature that this API needs from the multihoming 
APIs are socket options for getting and setting the locators. If you 
disagree, please suggest some text.

> - Also, what happens when the application has skipped the resolution
> step and passes a HIT that cannot be successfully resolved?

Added section 4.3. "Manual Handling of Locators" to the draft, see below.

> - step e, I think it is correct to pass back only HITs, but the draft
> ought to have more to say about how an application finds locator
> bindings that may have been in the DNS but hidden from the application.
> There is only a reference to shim6 that it can control the bindings with
> LOC_PEER_PREF.

More text now in section 4.3:

    The system resolver, or the HIP module, maps HITs to locators
    implicitly.  However, some applications may want to specify initial
    locator mappings explicitly.  In such a case, the application first
    creates a socket with PF_HIP as the domain argument.  Second, the
    application binds the socket to a local or peer locator with the
    setsockopt function with either SHIM_LOC_LOCAL_PREF or
    SHIM_LOC_PEER_PREF as the socket option name as defined in
    [I-D.ietf-shim6-multihome-shim-api].  Third, the application creates
    a valid sockaddr_hip structure.  Finally, the application associates
    the socket also with the sockaddr_hip structure by calling some
    socket-related function, such as connect or bind.  The function
    returns EINVALIDLOCATOR when the HIT is not reachable at the
    specified locator.

    It should be noticed that the application may just configure the HIT
    manually without setting the locator.  In this scenario, the
    application relies on the system to map the HIT to an IP address.
    When the system fails to provide the mapping, it returns
    EADDRNOTAVAIL in the called sockets API function to the application
    and sets errno to indicate the error.

> - section 4.2, I do not see why it is important to support non-ORCHID
> HITs for backward compatibility.  Maybe for forward compatibility?  I
> would just suggest to remove that paragraph, though.

I repharased the text:

    The HIP_HIT_ANY_ macros also allow non-ORCHID based communications.
    To distinguish between ORCHID [RFC4843] and non-ORCHID-based
    communications in the case of the HIP_HIT_ANY_ macros, the
    application calls getsockname() and getpeername() to discover the
    actual identifiers used for the communications and verifies orchid
    prefix with HIP_IS_IPV6_ADDR_ORCHID macro.  The macro inputs a
    pointer to an in6_addr structure and returns 1 when the address has
    orchid prefix and 0 otherwise.  Alternatively, the application can
    set the flag HIP_FLAG_ONLY_ORCHID in ship_flags to allow only ORCHID-
    based communications.

My point is that HIP_HIT_ANY macros would accept also normal TCP/IP 
communications by default. I hope my point is now more understandable?

> section 1:
>
> s/by introducing a new "SHIM" layer to the TCP/IP stack/by introducing a
> new namespace to the TCP/IP stack.
>
> s/underlying the HIP/the underlying HIP

Fixed.

> section 3:
>
> Figure 1 is a bit simplistic.  It is below IPsec which is in the network
> layer.  I do not see why this Layering overview needs to be in the draft
> anyway.  It would suffice IMO if the draft were just a black box look at
> the stack from an API perspective and did not go into these issues such
> as Figure 1 and Table 2.

Removed the section with figure 1. I kept table 2 because I think the 
identifiers and naming should be somehow still introduced in the text.

> s/datagrams... are intercepted by the HIP layer../are intercepted by the
> system/

Fixed.

> Section 4:
>
> would it be a more faithful syntactical alignment to avoid "ship" and
> just say:
>
> sockaddr_hip.sa_len
> sockaddr_hip.sa_family  (where "sa" stands for sockaddr and not for
> sock...hip)

I don't like the "ship" either but it is the standard sockets API style 
and I don't see why HIP should make an exception.

> I think you should clarify that anonymous identifiers may be designated
> by the system as metadata associated with a HIT regarding whether it has
> been published or not, but that from the HIP protocol perspective, there
> is no difference in the classes of HITs.

Added roughly the text that you proposed:

    The system may designate anonymous identifiers as meta data associated
    with a HIT regarding whether it has been published or not, but that
    from the HIP protocol perspective, there is no difference in the
    classes of HITs.

> application can use macro/application can use the macro

Fixed.

> Why is HIP_IS_IPV6_ADDR_ANON_HIT including the "IPV6_ADDR" portion of
> the string?

For two reasons of which are not very strong reasons IMHO. First, the 
other macro, HIP_IS_IPV6_ADDR_ORCHID, includes it and it would be nice if 
both of the accessor macros share the same prefix. Second, the naming of 
the macro indicates that the macro checks an ipv6 address. In later 
extensions, we could have a macro that does the same for a public key.

Would you still prefer e.g. HIP_IS_ANON_HIT?

> Section 4.2:
> s/must be set to the ai_flags/must be set in the ai_flags/
>
> s/locators bindings/locator bindings

Fixed.

> I-D.henderson-hip-applications is now ietf-hip-applications

Ah, forgot to change this from the submitted version. I included in my 
version control and this will be visible in the next (pre?) version.

-- 
Miika Komu                                       http://www.iki.fi/miika/

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

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 23 Nov 2007 10:33:43 -0800

>     prefer to use the resolver with host names.

Can you specify which errors the resolver-less approach is more prone
to?

> disagree, please suggest some text.

I will look at this issue some more and perhaps propose something if it
cannot be covered adequately by the shim6 multihome API draft.  It may
need to be more clearly stated that this draft is only a subset of the
complete picture and that portions of the shim6 draft must also be
implemented for completeness.
 
> communications by default. I hope my point is now more understandable?

OK, I didn't understand that you meant non-ORCHID to mean IP addresses.
I think this section is still not clear with regard to what is passed in
the connect() if HIP_HIT_ANY is the HIT (i.e., how is a locator
passed?).

> and I don't see why HIP should make an exception.

OK, I agree now ("sa" is generic to sockaddr).

> Would you still prefer e.g. HIP_IS_ANON_HIT?

I do not see why HIP_IS_IPV6_ADDR_ORCHID needs it either, and yes, I
would still prefer to drop it.  The macro is checking a 128-bit quantity
that is not necessarily an address.

Tom

---

From: Miika Komu <[email-masked]>
Date: Thu, 29 Nov 2007 01:23:09 +0200 (EET)

On Fri, 23 Nov 2007, Henderson, Thomas R wrote:

Hi Tom,

and sorry for the late response.

> Can you specify which errors the resolver-less approach is more prone

The main concern is wow to map a HIT to an IP address in the current state 
of HIP deployment in DNS. Do you suggest to move the last two sentences?

> implemented for completeness.

Is it ok if I reference the needed SHIM6 draft functionality in "5. 
Summary of New Definitions" ?

> OK, I didn't understand that you meant non-ORCHID to mean IP addresses.

We could also just use IN6ADDR_ANY if it would make things more clear? 
Unfortunately, this would mean that we'd discard the anon vs. public 
separation.

> the connect() if HIP_HIT_ANY is the HIT (i.e., how is a locator

Good catch. I was thinking about setsockopt with SHIM_LOC_PEER_PREF but I 
missed it in the text. The resolver cannot really do this on the behalf of 
the application because it does not have the socket.

The thing that I don't like about this is that setsockopt introduces 
manual operation for opportunistic connections. The resolver is there 
to automatize things but I don't really see a clean solution for 
this in the resolver.

Tom, are you ok with adding a sentence about the setsockopt?

> that is not necessarily an address.

THIP_IS_IPV6_ADDR_ORCHID was suggested by Julien. Anyway, this is a minor 
issue and I can drop the IPV6_ADDR prefix from both the macros.

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 29 Nov 2007 13:42:30 -0800

Miika, responses inline 

> -----Original Message-----
> From: Miika Komu [mailto:[email-masked]] 
> Sent: Wednesday, November 28, 2007 3:23 PM
> To: Henderson, Thomas R
> Cc: [email-masked]
> Subject: RE: [Hipsec] Re: API draft
> 

I just want to understand what the assumed error risk is.  You seem to
be saying that indirecting through the DNS is less error prone than
directly providing the HIT to IP address binding at the API.  Is that
because you are assuming that handling HITs is an error prone operation
(as compared with DNS names) for either applications or users?  

I think it should either be more specified to state what the presumed
error is, or else remove the last two sentences.

> Summary of New Definitions" ?

That would be fine for now.  It should be clearly stated that to
completely implement this native API, you need to implement this draft
plus sections of another draft.

> Unfortunately, this would mean that we'd discard the anon vs. public 

Can you specify one or more use cases where HIP_HIT_ANY macro would be
used to allow TCP/IP communications (what would be the sequence of calls
and setting of the sockaddr_hip fields)?  The phrase "backward
compatibility" is a bit too vague.

> Tom, are you ok with adding a sentence about the setsockopt?

Yes, I think that it needs to be there, since there are no locators in
the proposed sockaddr_hip structure.

> issue and I can drop the IPV6_ADDR prefix from both the macros.

OK, I would be in favor of that.

Tom

---

From: Miika Komu <[email-masked]>
Date: Sat, 1 Dec 2007 02:13:24 +0200 (EET)

On Thu, 29 Nov 2007, Henderson, Thomas R wrote:

Hi,

> error is, or else remove the last two sentences.

Will remove them.

> plus sections of another draft.

Ok.

> and setting of the sockaddr_hip fields)?

Well the use case is that you want to run e.g. http server in a port that 
serves both HIP and non-HIP-based communications.

1) Via resolver

struct addrinfo hints, *res;
struct sockaddr_hip *ship;
int sock;

hints.ai_flags = AI_HIP
hints.ai_socktype = SOCK_STREAM;
getaddrinfo(NULL, "http", &hints, &res);
ship = (struct sockaddr_hip *) (*res)->ai_addr;
sock = socket((*res)->ai_family, (*res)->ai_socktype, 0);
bind((sock, (*res)->ai_addr, (*res)->ai_addrlen,);
listen(..);
accept(..)

2) Manually

struct sockaddr_hip ship;
memset(&ship, 0, sizeof(ship));
ship.ship_len = sizeof(ship));
ship.ship_family = PF_HIP;
ship.ship_port = htons(80);
ship_hit.hit = { HIP_HIT_ANY };
bind((sock, &ship, sizeof(ship));
listen(..);
accept(..)

> The phrase "backward compatibility" is a bit too vague.

I removed the prase it from the rephrased text above.

> the proposed sockaddr_hip structure.

Ok.

> OK, I would be in favor of that.

Ok.

The changes that you suggested can be found from the next preversion:

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