By contrast, the more significant issue in civil aviation is whether
the
aeronautical air-to-ground and air-to-air networking will occur within
the context of VPNs (i.e., hierarchical routing/addressing systems
perhaps resembling military COMSEC; e.g., each VPN domain perhaps
associated with a specific ARINC 664 intra-aircraft partition) or
whether the civil aviation addressing/routing will alternatively be a
common (flat) system with the intra-aircraft partitions accomplished
by
air-gaps and firewalls.
--Eric
-----Original Message-----
From: Dino Farinacci [mailto:[email protected]]
Sent: Monday, January 05, 2009 2:12 PM
To: Fleischman, Eric
Cc: Pekka Nikander; 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.
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
