From: Dino Farinacci [mailto:[email protected]]
From: Pekka Nikander
What comes to HIP and RRG, I do believe that HIP *could* help in
solving the RRG problem. It *could* form a core for what people now
call "Strategy B" solutions, and a HIP-proxy based solution *could*
be
deployed as a "Strategy A" solution. I don't know the details of
LISP, but the recent discussion between Dino and me seem to indicate
that HIP proxy and LISP xTRs are functionally close enough so that a
HIP proxy could be "plugged in" to the LISP architecture, yielding a
"Strategy A" HIP-based network-level solution that could eventually
lead to full HIP deployment at all hosts, which *could* lead to an
architecture where renumbering is never needed due to full
transparent
support of multiple IP addresses at all hosts.
And since I don't know the details of HIP-proxy, saying LISP and HIP-
proxy are functionally equivalent only occurs at a conversational
level.
The devil is in the details of course.
I strongly resonate with Pekka's posting.
Speaking solely for myself, I view LISP's original claims to be a
locator-identifier split to be a redefinition of what those terms have
historically meant (i.e., to be marketing -- not reality). By
contrast,
HIP is a true locator-identifier split technology in every sense of
the
historic meaning.
Well IDs are used for TCP/UDP socket endpoint demuxing. And RLOCs are
according to the original definition. But we extended to have IDs
*also* be routable inside of a site. We had to for incremental
deployability. We don't want to force renumbering of all site-based
hosts, switches, routers, firewall devices, etc.
LISP, by contrast, is a map-and-encaps solution to the RRG problem.
With LISP, you can move a host to a new RLOC while keeping a TCP
connection up. That is the EID does not have to change for the host.
There is no necessary relationship between HIP (or any other
locator-identifier split) and LISP (or any other map-and-encaps).
Specifically, I believe that locator-identifier splits are a session
layer concept and therefore are primarily host-related. I believe that
map-and-encaps is primarily a network layer concept.
Definitely agree on session-layer concept.
By combining a true locator-identifier split (i.e., HIP) with a
map-and-encaps (e.g., LISP) one gets the combined benefits of both
approaches. Those benefits are
But you add another layer of addressing that is probably more than the
user wants. It could get this bad:
HIT -> EID -> private-RLOC -> public-RLOC when behind a NAT
or
HIT -> private-EID -> public-EID -> RLOC when behind a NAT
2-levels of mapping is plenty, adding 2 more probably is a non-
starter. Remember folks, we have to incrementally deploy this with
minimal cost, see Yakov's post early today, he makes good points.
* For HIP-based applications (i.e., hosts) this creates a full
decoupling of application issues from network issues. This
simultaneously solves many different problems including the
following: a
transparent solution to application multihoming; complete agnosticism
concerning network issues including IPv4 or IPv6; strong session
coherence in the face of substantial mobility; solution to the "IP
identity problem", thereby solving a great many festering security
issues including a clean integration with IPsec, providing
best-current-practice Denial-of-service (DoS) attack resistance,
exponentially increasing the ability to identify and defend against
spoofing attacks, substantially increased protection against session
hijacking, and (by solving the identity problem) making existing
application authentication and authorization systems become more
viable.
And it cleans your dirty dishes as well. ;-)
Eric, care to quantify the cost of deploying all this machinery?
Dino
* HIP also provides a formal (secure) delegation capability that
permits HIP users (e.g., hosts) to delegate authority to other
entities
to act on their behalf. This would, for instance, allow a host that
wants to hide its current location to use network proxies to forward
its
traffic. For example, DoS attacks could also be deflected to network
proxies.
* For map-and-encaps based systems this provides a scalable network
integration capability to resolve a wide variety of different network
scalability and integration challenges including:
1) IPv4-IPv6 coexistence: ISATAP, Teredo, IPvLX, etc.
2) Military Communications Security (COMSEC)
3) IPsec's ESP in tunnel mode
4) L3VPN (including how my employer relates to our ISPs (please note
the
plural))
5) ecommerce
6) ARINC 664 enclave protections
7) Architectures that leverage IP to join together distributed legacy
(i.e., non-IP) protocol systems. It is also used to merge legacy
populations into IP networks (e.g., RFC 1006).
--Eric
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
