[Hipsec-rg] RE: feedback from draft-hip-applications-02

> -----Original Message-----
> From: Miika Komu [mailto:miika@iki.fi]
> Sent: Thursday, March 02, 2006 7:50 AM
> To: Henderson, Thomas R
> Subject: feedback from draft-hip-applications-02
>
> Nice to have the HIP legacy apps draft back alive again. I
> was missing it
> already :) May I ask you what has been actually changed in
> the draft since
> 01?

Very little has changed-- the reference to the KHI draft has been added.

>
> I have also three comments/ideas/problems related to LSIs and
> referrals.
> Perhaps you can add the directly to the next version of apps draft or
> invoke discussion on the RG mailing list. The thoughts in
> this email are
> based on discussions with a number of people.
>
> The term LSI is not described in ESP or BEET drafts, yet we found few
> undocumented problems/features related to LSI and the drafts. I have
> discussed with Jan and Petri, and agreed on not documenting the LSI
> problems on ESP and BEET drafts as they seemed not to belong there. I
> think your draft perhaps fits best the problems.
>
> The first problem with LSIs is related to IPv4-IPv6 interoperability.
> Consider a server application (or two server applications)
> that binds both
> to an LSI and HIT at the application layer. The LSI and HIT
> point to the
> same public key. In this case, the networking stack of the
> server host is
> pretty dumbfounded upon receiving an BEET ESP packet and trying to
> determine which socket (LSI or HIT based) to deliver the data
> to. The root
> of the problem is that BEET mode packets do not carry any the inner IP
> header and therefore it is impossible to determine the
> ultimate recipient
> of the data.
>
> There are two choices to overcome the first problem. Either you prefer
> some inner family (like IPv6) or you allow only one binding
> for the public
> key in the specific protocol port. Jan convinced me that the latter
> alternative sounds better, just in case we want to make a
> recommendation
> on which way to go.

Another way to possibly handle this is to tag the mbuf with the address family of the outer header, and use this information if the conflict arises further up the stack.

>
> The second problem with use LSIs is that the underlying
> implementation has
> to manipulate transport layer checksums to be calculated
> based on LSIs.
> This is vaguely mentioned in either BEET or ESP drafts, and
> it is mostly
> an implementation issue. I don't know if you would want to
> describe also
> this in more detail in the apps draft as it is not really described
> anywhere decently.

My understanding is that transport layer checksums are always computed using HITs and IPv6 pseudoheader, regardless of whether LSIs are used at the socket API.

>
> The third problem is about referrals, a topic which you
> slightly touch in
> the draft also. The idea is that for legacy environments,
> HITs are bad as
> referrals because there is no guarantee that they can be mapped to
> locators. LSIs are also bad because they are not valid
> outside of the host
> and cannot be used as referrals at all.
>
> As a consequence, it seems like opportunistic HIP is perhaps
> the best way
> of dealing with legacy environments as it does not require any
> infrastructure and it can also support referrels better. The
> reason why it
> can support referrals better is that opportunistic HIP can be
> implemented
> based on IP addresses at the application layer (for example,
> connect(IP)).
> IP addresses, in turn, seem to be the best kind of referrals
> for legacy
> systems as they work also with hosts that do not support HIP.

Do you need help?
In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related honor.cybertrust.com Links hipsec-rg Request more information about Pantek

I am not willing to go so far as to say that legacy apps require opportunistic HIP. It depends on the use case and application (whether it makes referrals, whether the user cares if so, etc.).

Anyway, I think that we discuss this issue sufficiently without making a recommendation on whether to use LSI/HITs or not-- do you have a specific text change proposal?

> Passing an
> IP address as a referral can be made also mobility resistant,
> if you pass
> a RVS address instead of an address of an end-host.
>

But we're talking about referrals to non-HIP hosts, right? (RVS forwards only the base exchange).

Tom