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

[miika at iki.fi (Miika Komu)]

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              miika at iki.fi          http://www.iki.fi/miika/