Re: about Wedgelayer 3.5 / Fat IP approaches

El 30/06/2004, a las 16:15, Jukka Ylitalo escribió:

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

how this would differ from the cb64 draft by Erik?

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

yes, that is my conclusion so far, so you end up in cb64 or similar 
afaics

regards, marcelo

> [In any case, I try to finish the exercise with hash chains etc. 
> before my summer
> vacation starts :-)
>
> br, Jukka
>