Subject: RE: about Wedgelayer 3.5 / Fat IP approaches

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 29 Jun 2004 17:49:51 -0700

> -----Original Message-----
> From: Jukka Ylitalo [mailto:[email-masked]] 
> Sent: Monday, June 28, 2004 1:09 AM
> To: Erik Nordmark
> Cc: marcelo bagnulo braun; Multi6 List
> Subject: Re: about Wedgelayer 3.5 / Fat IP approaches
> 
> It would be also possible to change HIP in a way that the applications
> were to see routable IP-addresses, instead of HITs.  
> Basically, the Multi6
> enhanced HIP would implement a NOID kind of AID-locator 
> split. In this way,
> it would be possible to use HIP in an opportunistic mode, like SSH.
> I believ that the application layer will be the key element when 
> combining different
> wedge3.5 proposals.

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.

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

---

From: Jukka Ylitalo <[email-masked]>
Date: Wed, 30 Jun 2004 17:15:42 +0300

Hi,

>DNSSEC.  I agree that HIP opportunistic mode should be able to 
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.

>or other lighter-weight m6 identifier, as you and Erik suggest.
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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 30 Jun 2004 16:41:35 +0200

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

>> DNSSEC.  I agree that HIP opportunistic mode should be able to deal 
>> with it.
>>

how this would differ from the cb64 draft by Erik?

> to rely on the DNS.  The properties are based on the public key 

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
>