Re: about Wedgelayer 3.5 / Fat IP approaches

Hi,

Henderson, Thomas R wrote:

>
>Rather than NOID kind of split, maybe CB64-like split is preferable?
>(where lower bits of AID match the HIT and upper bits the prefix,
>rather than having the AID be unrelated to the HIT)?  It wouldn't
>have to be a /64 split necessarily-- just reverse mappable with
>DNSSEC.  I agree that HIP opportunistic mode should be able to 
>deal with it.
>  
>
CB64 -like split sounds good.  Right, there arises some AID
ownership problems if it is not bound to the HIT.
It would be nice to have a new version of Multi6 HIP draft that
describes how HIP could be used with CB64 -like AIDs.

>Already in HIP there has been some struggle with what AID to pass
>to applications, and some level of discomfort with passing non
>routable values posing as IP addresses to legacy apps, for many of 
>the reasons cited in the previous posts (see also Appendix A of
>the draft HIP base spec).  For legacy APIs and legacy apps, then, 
>maybe this kind of AID/m6 identifier split could satisfy
>the referral issue, or perhaps instead being underpinned by WIMP
>or other lighter-weight m6 identifier, as you and Erik suggest.
>
>Tom
>
>
>  
>
I have concentrated on the ephemeral identifiers concept and
tried to figure out their properties in different scenarios.
The ephemeral identifiers are useful with one-way
hash chain authentication, when establishing a state.
An attacker cannot easily steal a context identifier in this way.

However, because the presented ephemeral namespace is flat
and not routable from its nature, it does not solve the referral
problem. Now, if we conceptually separate AIDs from wedge 3.5
layer Context Identifiers (let them be called as CIDs), we still end
up with AID ownership problems. The security problems related
to wedge layer context theft and application layer identifier theft
are slightly different, but they are mostly similar with each other.

What comes to the current WIMP work, is that we are making
an exercise to understand the relationship between routable AIDs,
ephemeral CIDs, and hash chains. I like to notice that the work is
not the final editorial effort to combine group-F protocols as requested
by co-chairs. Before that, we should start naming the different components
in different group-F proposals, and evaluate the components against the
things-to-think-about and security-threats drafts, if possible.

At this point of time, while our exercise is still under work, I have
a feeling that a routable AID should have cryptographical properties
that can be used to prove the ownership of that AID; if we do not want
to rely on the DNS.  The properties are based on the public key 
cryptography.
[In any case, I try to finish the exercise with hash chains etc. before 
my summer
vacation starts :-)

br, Jukka