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

[Miika Komu <[e-mail]>]

(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              [e-mail]          http://www.iki.fi/miika/
_______________________________________________
Hipsec-rg mailing list
[e-mail]
https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg

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