[rrg] Rejecting all but Strategy A

[Dino Farinacci]

> I myself am not aware of the NAT impacts to HIP though I have noted  
> (but
> not yet read) the existence of a HIP I-D on that topic (see
> http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-05.txt)
> . I suspect that you are overstating the problems with NATs because  
> HIP
> has proven to be surprisingly clean and the HIP proxy capability is
> powerful. However, I myself have not envisioned using HIP in
> environments having NATs except for the narrow context of overcoming
> ARINC 664-based limitations impacting aircraft's generic (public) IP
> addresses.

I am not making a claim or judgement call about HIP with NATs. I was  
making a statement about HIP coupled with a map-n-encap scheme with  
NATs.

Dino

> 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:dino at cisco.com]
> 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:dino at cisco.com]
>>>> 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
>