Before we get carried away with what looks like a convergence of "HIP-
proxy and LISP", tell me what HIP offers to a LISP router that the
LISP architecture does not already provide?
If is solely a add a pure definition to IDs and RLOCs, then I think
it's not worth the cost of deployment to do so.
Dino
On Jan 5, 2009, at 1:27 PM, Templin, Fred L wrote:
-----Original Message-----
From: Fleischman, Eric
Sent: Monday, January 05, 2009 12:13 PM
To: Dino Farinacci; Pekka Nikander
Cc: RRG; Robin Whittle
Subject: Re: [rrg] Rejecting all but Strategy A
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.
Pekka, is "HIP-proxy" and "HIP mobile router" one and the
same thing? If so, IMHO it is absolutely realistic that the
HIP-proxy and xTR could occur on exactly the same platform.
Note that they are complementary functions, however; not
competing ones. I think this also goes with what Eric was
saying below?
Fred
[email protected]
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.
LISP, by contrast, is a map-and-encaps solution to the RRG problem.
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.
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
* 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.
* 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
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
