[...] HIP-proxy and xTR are not the same thing. xTR tunnels,
mapping entries, cache entries can cover aggregates of hosts, while
HIP-proxy has per-host granularity. xTR doesn't claim to represent
any host from a security point of view, while HIP-proxy seems to.
While certainly so at the architectural level, the difference at the
practical level does not need to be that big. Everything depends on
the details, which we obviously do not have. (Shun me for empty talk,
if you want.)
First, the packets between xTRs do have per-host granularity, as the
EIDs are preserved in the inner header. Hence, conceptually, if you
want to look at the xTRs from this point of view, you could consider
each pair of EIDs as a separate "state". Those states are then
aggregated to the per-site granularity.
Almost the same thing *could* be done with a HIP proxy, too. The
forwarding state could be at a per-site granularity. (I go into very
convoluted architectural thinking next, but bear with me to see the
result). The ideas is that the HIs representing proxied hosts would
be expressed only as aggregated delegated state. That is, from the
HIP architecture point of view there would be a "virtual" HI for each
proxied host, as well as for each proxied host at a remote site.
However, each of the local "virtual" HIs would be "virtually"
delegated to the HI of the local HIP-proxy; likewise for each remote
site. As a result, the HI of the HIP-proxy would represent all the
"virtual" HIs of the hosts behind it. In reality, no such "virtual"
HIs would exist at all, the delegation being fully virtual (or even
imaginary). Then, I think, the state at the HIP-proxy would match, in
terms of granularity, the state at an xTR.
The next obvious question is what's the point? Why to have such
virtual, ephemeral, opportunistic HIs for each host if they don't
exist at all in practise? The reason is that the architecture could,
trivially, also allow real, non-virtual, HIs. That is, in addition to
representing the legacy hosts at the site through virtual delegation,
the HIP-proxy could represent real HIP-enabled (mobile) hosts and
subnetworks through real delegation.
To summarise the above: In an imaginary world, there would be a HI
for each legacy host at a site, all those HIs being delegated to the
HI of the HIP-proxy. In the real world, there would be only the HI of
the HIP-proxy, representing the whole legacy site through the
imaginary delegation. For HIP-enabled hosts and subnetworks, there
would of course be actual HIs and real delegation from the HIP-enabled
host or subnetwork to the HIP-proxy.
I don't see any problem at all in installing a HIP proxy and xTR at
the same box -- they could even use the same mapping infrastructure
to find out the RLOC of the peer HIP proxy/xTR, and then in
parallel send an opportunistic HIP I1 and whatever LISP sends when
an xTR contacts another xTR that it has no prior association with.
But that would be a (minor) waste of resources as two packets would
be sent in parallel.
This would probably increase the load on the mapping system and xTRs
considerably, because of the per-host granularity.
It does not necessarily increase the load, as should be obvious from
the above. First, even if the end-host HIs were real ones and not
imaginary ones, there is no need to store them to the mapping system.
Second, if they are imaginary ones, they don't even exist elsewhere
but as a concept. So, there is no operational cost and there are
benefits you get if HIP becomes more common.
I'm not sure how it would work for multiple ITRs and ETRs, are there
multiple proxy host identities, one for each xTR? How is that
handled with mobility or path unavailability events?
As long as you speak about mobility of the mobility HIP-proxy or path
unavailability between HIP-proxies, it works just as if the proxies
were individual HIP hosts hosting multiple HIs. If you speak about
legacy host mobility, obviously it doesn't work. For the details of
mobile HIP hosts moving from one HIP-proxy to another HIP-proxy, I
don't know if anyone has written down the details.
It changes the security model for HIP-- when I move behind some ITR,
am
I going to want my packets to flow unprotected between my host
interface
and the ITR?
If you are a legacy host, what else could you do? If you are a HIP
host, the ITR would look like a HIP MR to you.
Am I going to trust arbitrary ITRs to proxy for my host?
That is an operational choice that you have to make.
Also, are ITRs going to have any incentives to give me good (or any)
HIP service?
What incentive do they to give you any service in the first place?
Initially, what I think would be interesting to understand is the
possibility of two additional designs:
1. One where the LISP xTR-xTR protocol is replaced with the HIP
protocol (providing the additional mobility and security features
HIP provides).
2. One where the initial xTR->xTR opening message is a hybrid that
indicates that the sender understands both LISP and HIP, allowing
the receiver to pick which one to use.
And then I could imagine a few designs beyond either...
Are you instead suggesting above to look at combining HIP with LISP,
or HIP-proxy with LISP?
I'm suggesting them as potential starting points for looking at how to
combine HIP-proxy with LISP.
I see the distinction being that HIP with LISP means that HIP keys
are used to name xTRs and to secure the xTR to xTR communications
(and possibly communications with the mapping system), but otherwise
LISP works as described. Proxy-HIP keys would name individual hosts
and would play more of a role as an EID in the system.
I see. However, I don't see there a big difference, due to the
imaginary HIs and imaginary delegation making the difference, well,
imaginary. :-)
--Pekka
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
