Subject: [Hipsec] review of draft-ietf-hip-native-api-02

From: Jari Arkko <[email-masked]>
Date: Mon, 17 Sep 2007 13:46:17 +0300

I happened to read this draft. A few comments:

In general, I'd like to see work like this move forward.

The main question mark that I had relates to the
positioning of this work as a generic Shim layer
API vs. HIP-only API. I think a generic API would
be useful, but I'm uncertain if the API as defined
is a good fit for non-HIP designs, most notably the
Shim6 design.

But I'm sure you have talked about this in the past.
Can you post pointers to such discussion?

Anyway, what I see problematic from the point of
using for Shim6 is the following:

- The resolution step does not distinguish ULIDs
  from locators.

- Section 4.1 ULID comparison for Shim6 may
  produce surprising results, given that
  different connection attempts may result
  in different ULIDs.

- I'm not sure how the deferred context creation
  approach in Shim6 fits with this API.

What's the role of this spec vs. the shim6 draft that you
have?

Other comments:

>    | Locator | Non-routable IPv4 or IPv6 address used at the lower     |
>    |         | layers                                                  |
I'm pretty sure you meant routable.

>    In practise, the resolver functionality can implemented in different

s/can/can be/

> They denote an ULID value associated with a wildcard
>    ULID of any, public, or anonymous type.
I do not understand the difference. Please elaborate.

>    In both client and server based applications, the use of the
>    SHIM_ANY* macro accepts also non-SHIM based communications to
>    maximize backwards compatibility.  When the application wants
>    enforces the use of SHIM-based communications with ORCHID prefix
>    [RFC4843], it sets the flag SHIM_FLAG_ONLY_ORCHID in sins_flags.
>    Alternatively, the application accepts both ORCHID and non-ORCHID-
>    based communications, but informs the difference e.g. to the user.
>    In this case, the application calls SHIM_IPV6_ADDR_IS_ORCHID macro
>    which inputs a pointer to a in6_addr and returns 1 when the address
>    has orchid prefix and 0 otherwise.

Is the use of Orchids the same or different issue from using
a Shim? I.e., do all Shims employ an Orchid? And if not, wouldn't
you want to enable/disable the use of non-shim communications
and Orchids separately?

Jari

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

---

From: Miika Komu <[email-masked]>
Date: Mon, 17 Sep 2007 15:07:40 +0300 (EEST)

On Mon, 17 Sep 2007, Jari Arkko wrote:

Hi Jari,

thanks for the feedback, comments below.

> Can you post pointers to such discussion?

Not really because it has been just non-electoric discussions.

> - The resolution step does not distinguish ULIDs

ULIDs and locators have separate field in the sockaddr_shim structure. 
Please clarify?

>  different connection attempts may result

This applies also to HITs as the application may receive multiple HITs. 
Please suggest text?

> What's the role of this spec vs. the shim6 draft that you

Is this "rough" categorization helpful and should it be included in the 
draft?

http://www1.ietf.org/mail-archive/web/hipsec/current/msg02222.html

>>    In practise, the resolver functionality can implemented in different

Yes, thanks.

> I do not understand the difference. Please elaborate.

Any means public or anonymous (perhaps this should be clarified?). Public 
and anonymous are described in the 03-pre2-version of the draft already:

"In the case of HIP, anonymous identifiers refer to the anonymous 
identities in [RFC4423].  In the case of SHIM6, anonymous identifiers 
refer to the use of temporary IPv6 addresses as specified in [RFC3041]."

> you want to enable/disable the use of non-shim communications

SHIM and Orchid are decoupled issues. The 03-pre2-version of the draft 
mentions:

a) The flag AI_SHIM must be set, or otherwise the resolver does not
    return sockaddr_shim data structures.
b) To distinguish between ORCHID [RFC4843] and non-ORCHID-based
    communications, it can call SHIM_IS_IPV6_ADDR_ORCHID macro.
c) Alternatively, the application can set the flag SHIM_FLAG_ONLY_ORCHID
    in sshim_flags to allow only ORCHID-based communications.

Should this be clarified? Suggest some text?

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

---

From: Jari Arkko <[email-masked]>
Date: Mon, 17 Sep 2007 15:38:15 +0300

Miika,

> Not really because it has been just non-electoric discussions.

Ok. Can you summarize then?

> ULIDs and locators have separate field in the sockaddr_shim structure.

Yes, in your API. But in Shim6 there is no distinction.

> This applies also to HITs as the application may receive multiple
> HITs. Please suggest text?

I don't have a good suggestion. You may end up just
having to document the issue.

> Is this "rough" categorization helpful and should it be included in
> the draft?
>

I think you said something along these lines in the draft already.
But I would like to see the current explanation expanded.

> Any means public or anonymous (perhaps this should be clarified?).
> Public and anonymous are described in the 03-pre2-version of the draft
> already:
>

Ok, I think.

> Should this be clarified? Suggest some text?
This is better, but let me ask a further question: how do
you control whether you want to talk to non-shim capable
hosts? Or is that in the draft-ietf-shim6-multihoming-api
draft?

Jari

---

From: Miika Komu <[email-masked]>
Date: Tue, 18 Sep 2007 15:42:44 +0300 (EEST)

Hi Jari,

> Ok. Can you summarize then?

Marcelo and Shinta, please correct me but I think that discussion has been 
never truly concluded. I recall that I suggested that the endpoint 
descriptor in 01 version draft might be useful for SHIM6 context forking. 
However, this debate is unnecessary now since I removed the whole concept 
of endpoint descriptors from the draft.

> Yes, in your API. But in Shim6 there is no distinction.

Of course. What do you think the proposal from Jan, i.e. having only the 
ULID field in the structure and no locator?

> having to document the issue.

Ok.

> But I would like to see the current explanation expanded.

Ok.

>> refer to the use of temporary IPv6 addresses as specified in [RFC3041]."

Ok.

> hosts? Or is that in the draft-ietf-shim6-multihoming-api

SHIM6 draft offers a "SHIM_DONTSHIM" socket option in section 5.2. We can 
use the same option for HIP.

If AI_SHIM is not used, the extensions in the draft are not offered to the 
application. This situation is defined in the legacy HIP apps draft.

The other way is to explicitly set the protocol either to IPPROTO_HIP or 
IPPROTO_SHIM6 in the resolver hints. With "0" protocol in the hints, I am 
not sure what to fill in the protocol field in the resolver output. 
Looking forward for some feedback on this issue. Particularly: is the 
IPPROTO_SHIM6 useful for SHIM6 at all?