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

["Henderson, Thomas R" <[e-mail]>]

(posting only to hipsec)

> -----Original Message-----
> From: Miika Komu [mailto:[e-mail]] 
> Sent: Tuesday, May 16, 2006 2:45 PM
> To: [e-mail]
> Cc: [e-mail]
> 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.

> 
> 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>. 

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
> to return the HITs only when the application requests AF_ANY 
> or AF_INET6
> 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
> 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>.
> 

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.

> 
> 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]. 

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
> 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.
>

As stated above, I am not sure I'd like to digress so much on the topic
of referrals.
 
> 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].
> 

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.

> When the application source code can be modified, AI_HIP flag 
> can set to
> getaddrinfo() resolver call. 

Modifying application code is out of scope for this draft.

> 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
> 

Thanks,
Tom

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