Re: Question re HIP dependency & some architectural considerations

[Pekka Nikander <pekka.nikander@nomadiclab.com>]

> > To me, it remains an interesting question how to support API 
> > evolution.
> > One architectural possibility would be to use HIP as an example:
> >  - convert AIDs into EIDs at the API level
> >  - use EIDs to establish the end-to-end context
> >  - map EIDs to IP addresses when sending packets out
>
> This is how hip works today, right?

Yes, more or less.  However, the details in various implementations
are different.

> i mean in the HIP case:
> AID==HIT
> EID==HI

Yes, with the addition that the AID can also be an LSI instead of a HIT,
and there has been some discussions of allowing the AID to be a
routable IP address of the peer host.

> I guess that what it seems that we need is to support routable AIDs,
> and provide the means to securely bind them to the corresponding EID,
> right?

Well, I think so.  But, at least for the time being, I remain puzzled
about what does the "secure binding" mean, exactly.  Anyway, the AID
is primarily a thing that is internal to the host.  For simple
applications, the AID never leaves the host since the IP address in
the wire is conceptually different from the AID, even if they happen
to have the same binary value.

The problems are created by the desire to be backwards compatible
with referrals and with non-RFC1958-conformant applications.  For them,
the AID needs to be a routable IP address that can be used to reach
the peer.  Hence, for them the AID does appear outside of the host, both
conceptually and in practise.

The security problem is created when the host that uses the AID does
not have a corresponding EID-level association with the peer identified
with the AID.  One needs to have a secure enough way to tell whether the
peer has an EID or not, and if it does, what its EID is.  There are
obviously various approaches in providing assurance, such as using CGA
(and some bit in the address to indicate whether CGA is used or not),
using WIMP, using opportunistic HIP, etc.

I tend to believe that just using some end-to-end protocol might be
secure enough.  That would obviously be vulnerable to man-in-the-middle
attackers, but so is current IP.  However, I am worried about the case
where a MitM attacker hands over a different EID to the initiating host,
thereby creating a false AID-to-EID mapping at that host, and then using
the multi6 protocol to claim that the AID-IP-address is no longer 
reachable.
Such an attack can potentially cause quite a lot of harm, but of course
only if the host can be lured to try to make a contact to the AID.
However, that is easy enough in many cases.

Using CGA based AIDs seems to provide enough security.  However, if
we want to pursue that further, we would have to consider the IPR.

--Pekka Nikander