Re: about Wedgelayer 3.5 / Fat IP approaches

[Jukka Ylitalo <jukka.ylitalo@nomadiclab.com>]

Erik Nordmark wrote:

> What I'm about to write might make things more confusing, but hopefully
> also more clear.
>
> I think conceptually we are using identifiers for two different purposes,
> but in many (not all) cases the same bit strings serve both purposes.
> 1. A handle passed to the applications that can be used for things like
>    - comparisons
>    - callbacks and referrals
> 2. A thing used inside the multi6 (sub)layer as part of preventing redirection
>   attacks.
>
>  
I agree. I would like to speak about the 'context ownership problem' in
the second case. For example,

- HIP has two different kind of application identifiers: Local Scope 
Identifiers
for IPv4 sockets, and HITs for IPv6. In both case, the HIP layer uses
public key crypto to prove the ownership of the same context.

- WIMP uses ephemeral identifiers and hashes of FQDN at application layer.
However, it uses hash chains to prove the context ownership.

> A current case where they are not the same is in the (now expired) cb64 draft,
> where the application sees a 128-bit handle with IP address semantics,
> but the multi6 layer uses the 64 last bits as a hash of a public key.
> In Santa Monica after the meeting Jukka Ylitalo brought up another interesting 
> thing to try; using NOID-style AIDs with WIMP ephemeral IDs underneath.
> (Sounds a bit complex to me, but well worth exploring to further our 
> understanding in this space.)
>
>  
Thanks for bringing this out. Yes, the initiator would use, WIMP kind of,
ephemeral identifiers (random numbers), and the responder,
NOID kind of, routable IP-addresses at the application layer.

> Furthermore, we definitely need to be concerned about #1 for existing 
> applications. But it migth also make sense to think about applications
> that have been modified to be multi6-aware.
>  
I feel that we should use routable identifiers with the connect()
and sento() kind of function calls in any case. This makes it possible 
to be
backward compatible with existing applications. However, the client
side may use non-routable application identifiers. (Thus, the context
establishment is asymmetric process, and two host may finally have two
diferent context-pairs with them.)

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.

Finally, the application identifier type is related to security 
properties of
any Multi6 protocol. As Marcelo wrote, we should  analyze those
properties of different AIDs better and apply them with context
ownership properties.

> For instance, calling the getpeername() API might return what is essentially
> a designated locator for the peer, which provides support for unmodified
> applications. But we could decide to crate getpeerid() and getpeerlocators()
> which would return more information to modified applications.
> This might mean that unmodified applications would receive limited 
> support for callbacks and referrals when a locator becomes unreachable,
> but the modified applications would be robust against such failures.
>
>   Erik
>
>
>
>
>  
-- Jukka