Subject: [Hipsec] [Hipsec-rg] additional text to HIP legacy apps draft

From: Miika Komu <[email-masked]>
Date: Wed, 17 May 2006 00:44:59 +0300 (EEST)

(Apologies for double copies, used the old list address by accident)

Earlier I left the topic "RE: feedback from draft-hip-applications-02"
dangling on hipsec-rg list. Let me now return to that topic by providing
some more concrete text to the draft. Sorry for crossposting both to WG
and RG lists, but the draft is now an official WG item.

Comments are welcome, as always. Thomas, feel free modify and adapt the
text to the draft.

3.2.  Using DNS

..

New paragraph: "Return HIP HITs instead of IP addresses":

For legacy applications that are not hard coded using IPv4 addresses, it
is also possible to return HITs in resolver calls. An advantage of
returning a HIT in comparison to returning an LSI is that a HIT is not
only a locally created identifier but rather has a global meaning. The
drawbacks are mostly related to referrals which are discussed in detail in
section <3.4>. Additionally, the resolver implementation has to be careful
to return the HITs only when the application requests AF_ANY or AF_INET6
type of addresses. A HIP enabled resolver is expected to return first the
HITs and only after that a list of IPv6 addresses, unless the AI_HIP flag
is set, as descibed in more detail in section <3.5>.

Suggest adding new section 3.4: Referral issues

A referral is the case when three or more instances of an application
interacts and the first instance communicates with the second instance,
and then communicates with the third instances and wishes to tell the
third instance how to contact the second instance [B]. In order to
maximize backwards compatibility with legacy applications, it is important
to consider the type of referrals that applications use. However,
maximizing backwards compatibility may have some negative impacts that
need to be considered. In this section, we consider four types of
referrals: end-point identifiers (HITs), end-point locators (IP addresses)
and middlebox locators (rendezvous).

Using HITs as referrals may not work with legacy hosts that are not HIP
capable as the HITs are not routable. Having routable HITs requires
additional infrastructure, such as overlays [C]. In addition, resolving
HITs to IP addresses in HIP aware applications requires also extra
infrastructure such as DHTs because HITs contain no hierarchical
information, which is really required by DNS. A benefit of using HITs at
the application layer is that they have a longer expected lifetime than IP
addresses in mobile environments. However, there may be middleboxes, such
as NATs between the end-points. As a HIT denotes an end-point rather than
"middle-point", HITs might be more useful than locators with NATted
environments, especially when end-points are mobile and when both
communicating end-points are behind NATs.

On the other hand, the use of end-point IP addresses as referrals has the
quite the opposite benefits and drawbacks to HITs. One benefit of using
end-point IP addresses as referrals is that they are backwards compatible
even with legacy hosts that are not HIP capable. In addition, they do not
require any new infrastructure. As a drawback, the expected lifetime of IP
addresses in mobile environments is lower than HITs. Another drawback is
that it may be more difficult to disambiquite whether a given IP address
belongs to the end-point host or e.g. a NAT middle-box.

Using rendezvous IP addresses as referrals does not work with legacy hosts
that are not HIP capable. In addition, the rendezvous servers themselves
are required as an additional infrastructure. As a benefit, the expected
lifetime of this type of referrals is also longer than for end-point
addresses in mobile environments. As a second benefit, this case might be
useful for establishing opportunistic HIP connection between HIP capable
hosts assuming that the rendezvous server has a sufficient supply of
locators (one dedicated locator per one responder). When a single
rendezvous address is dedicated for a single responder, using rendezvous
addresses as referrals may be less ambigious than when using end-point
addresses, but more ambiguous than when using HITs.

New section "3.5 Enforcing the use of HIP in legacy applications"

In general, legacy applications are expected to be HIP unaware. In
practice, this means that the source code of the actual application
remains unmodified. However, there might be cases when the use of HIP is
being enforced by either very minimal changes to the application source
code or to the underlying, dynamically loadable resolver libraries. The
motivation for doing this is to force the application to establish
connections using HIP, or to not to establish them at all [A].

When the application source code can be modified, AI_HIP flag can set to
getaddrinfo() resolver call. This way, the application either gets
LSIs/HITs or nothing at all. Alternatively, the resolver library can be
configured to force the resolver to enforce system specific behaviour when
the source code of the application cannot be modified. In this case, the
resolver can return either LSIs/HITs or nothing at all.

[A] Applying a cryptographic namespace to applications
http://portal.acm.org/ft_gateway.cfm?id=1080786&type=pdf&coll=portal&dl=ACM&CFID=76024067&CFTOKEN=9663775
[B] http://www.ietf.org/internet-drafts/draft-nordmark-shim6-esd-00.txt
[C] http://www.ambient-networks.org/docs/Host_Identity_Indirection_Infrastructure_Hi3.pdf

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/
_______________________________________________
Hipsec-rg mailing list
[email-masked]
https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg

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

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 17 May 2006 11:56:25 -0700

(posting only to hipsec)

> -----Original Message-----
> From: Miika Komu [mailto:[email-masked]] 
> Sent: Tuesday, May 16, 2006 2:45 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Hipsec] [Hipsec-rg] additional text to HIP legacy apps draft
> 

(snip)

> but the draft is now an official WG item.

Results of rechartering discussions have not been announced to the list,
AFAIK.

> section <3.4>. 

I think the best way to handle the above suggestion is to add HITs as an
alternative to LSI in the existing paragraph and in this section in
general.  The advantage of using a HIT is that it may be resolvable or
routable by a third-party (referral) HIP-aware system in some cases.  

For that matter, IP addresses should also be mentioned as a candidate
local scope identifier, especially ULIDs.

> Additionally, the resolver implementation has 
> to be careful
> type of addresses. 

I'm not familiar with the AF_ANY family and doubt that many legacy apps
use it presently.  Do you mean AF_UNSPEC?

> A HIP enabled resolver is expected to 
> return first the

I am not sure about requiring this particular behavior (vs. just
returning a HIT and no other IP addresses).  

> Suggest adding new section 3.4: Referral issues

I am not sure I want to go so deeply in the direction you are asking.  I
think that referrals are already adequately discussed, but perhaps could
be enhanced by a reference to shim6 draft on referrals (you mentioned as
[C] below)?

Perhaps also mention in 3.3 that the use of HITs in referrals may be
advantageous to LSIs in that HIP-aware hosts may be able to resolve them
in a referral situation.

> additional infrastructure, such as overlays [C]. 

It is not just routability, it is also possibly resolution (i.e., early-
vs. late-binding of HIT to IP address).

> In addition, 
> resolving
> HITs to IP addresses in HIP aware applications 

If the application is HIP aware, why does it (vs. the stack) need to do
resolution?  Do HIP-aware apps in your view still use connect(AF_INET6)?

>requires also extra

As stated above, I am not sure I'd like to digress so much on the topic
of referrals.
 
> connections using HIP, or to not to establish them at all [A].

I think it is worthwhile to mention somewhere that a dynamically loaded
HIP-aware resolver is one way to control the granularity of using HIP on
a system; I will do so in the next revision.  I don't think a new
section is necessarily needed.

> getaddrinfo() resolver call. 

Modifying application code is out of scope for this draft.

> This way, the application either gets
> http://portal.acm.org/ft_gateway.cfm?id=1080786&type=pdf&coll=
> portal&dl=ACM&CFID=76024067&CFTOKEN=9663775
> [B] 
> http://www.ietf.org/internet-drafts/draft-nordmark-shim6-esd-00.txt
> [C] 
> http://www.ambient-networks.org/docs/Host_Identity_Indirection
_Infrastructure_Hi3.pdf

Thanks,
Tom

---

From: Miika Komu <[email-masked]>
Date: Thu, 18 May 2006 15:37:28 +0300 (EEST)

> use it presently.  Do you mean AF_UNSPEC?

Yes.

> advantageous to LSIs in that HIP-aware hosts may be able to resolve them

Ok.

>> In addition, resolving HITs to IP addresses in HIP aware applications
>

In addition, resolving HITs to IP addresses in HIP aware applications 
requires also extra infrastructure such as DHTs because HITs contain no 
hierarchical information, which is really required by DNS.

->

In addition, resolving HIT referrals to to routable IP addresses requires 
also extra infrastructure such as DHTs because HITs contain no 
hierarchical information, which is really required by DNS.

> As stated above, I am not sure I'd like to digress so much on the topic

It is a concern especially in legacy applications based on HITs and 
non-routable LSIs because they have no idea how to deal with the 
non-routability issues. Basically, applications running into non-routable 
HIT or LSI referrals will just fail with mysterious error messages. At 
least I believe that the non-routable referrals are the main problem of 
the legacy API.

The text I proposed just described the pros and cons, and does not make 
any strong recommendations. I though this is was requested by in the 
earlier email thread.

> section is necessarily needed.

Fine.

> Modifying application code is out of scope for this draft.

Fine.

Cheers,

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 19 May 2006 00:00:01 -0700

> any strong recommendations. I though this is was requested by in the 

I think we may disagree on the emphasis required for this topic, and I
guess I don't agree with everything implied in the text that you
proposed about how it would all work (or at least the need to mention
those things such as overlay routing, NATted environments, and
rendezvous server addresses).  The draft already says:

   Since the LSI or HIT is non-routable, a couple of potential hazards
   arise, in the case of referrals, callbacks, and long-lived
   application associations.  First, applications that perform referrals
   may pass the LSI to another system that has no system context to
   resolve the LSI back to a host identity or an IP address.  Note that
   these are the same type of applications that will likely break if
   used over certain types of NATs.

I actually think that the odds of a referral occuring for HIP are lower
than that of shim6 because shim6 uses delayed context establishment,
while HIP requires the use case that a third party gets the HIT or LSI
somehow while not using HIP (which is presumably in use by the first two
parties).  I think that application caching is bound to be a more
prevalent problem.  I also don't know how often the referral problem
happens in practice; we haven't observed it when using LSIs, and the
OCALA project (UC Berkeley project also using LSIs) has not reported
such problems.

Tom

---

From: Miika Komu <[email-masked]>
Date: Fri, 19 May 2006 15:35:21 +0300 (EEST)

On Fri, 19 May 2006, Henderson, Thomas R wrote:

>> non-routability issues. Basically, applications running into 
>> non-routable HIT or LSI referrals will just fail with mysterious error 
>> messages. At least I believe that the non-routable referrals are the 
>> main problem of the legacy API.
>>

Ok, fine.