Tony, Thank you for this wonderful summary. I am greatly relieved that the objections to map-and-encaps are based upon well-reasoned technical insights because we as a community can build a consensus together by examining contributions of this quality.
I resonate with these objections, particularly the first one (i.e., locator-identifier split), because the organization in which I work has found considerable power by implementing HIP to solve a variety of issues. Two examples are that (1) we cofounded the Secure Mobile Architecture (SMA) work within the Open Group which leverages HIP as a foundation for mobile security. We have applied SMA within our factories and have found that it is an outstanding technique to secure SCADA-based machine controllers -- by far the best alternative that we are aware of. (2) We've done applied research using HIP as a basis for maintaining streaming multimedia sessions within extremely mobile MANET networking environments. HIP is an effective technique for minimizing the impact of signal intermittence and mobility upon applications. However, I believe that resisting map-and-encaps is like resisting NATs -- doing so is like "spitting into the wind" because it is already ubiquitous, so what's the point? More accurately, when I first read Fred Templin's VET-RANGER-SEAL trilogy, my reaction was that he had finally fingered what the Internet architecture has become. Many of you know that I have been concerned about the viability of the IETF's work ever since we abandoned our historical architectural foundations in the mid- to late-90s (e.g., the rise of middleboxes, the fattening of the middle of the hour glass, the confusion between core and edge). I don't object to modifying or changing architectures but I do object to having no architecture foundation at all, which is what we did in the IETF (in my personal opinion). Regardless, reading Fred's work was an epiphany for me because I realized that regardless of whether I liked it or not, the IETF indeed has finally created an architecture foundation again: map-and-encaps. Everywhere I look I see coherent evidence that the IETF and industry has ubiquitously embraced map-and-encaps as our current Internet Architecture foundation. Witness: 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). I've largely dropped out of IETF discussions since 2001 because I can't talk about what I do anymore. However, in all of the many topics that I have worked during that time I repeatedly see map-and-encaps based solutions. One example that I can share is that in 2006 I did a study on the safety and security of LAN-attached airborne avionics for the US Federal Aviation Authority (FAA). (Note: two of my books (DOT/FAA/AR-08/31 and DOT/FAA/AR-08-35) are now available on the FAA web site dealing with this topic.) I believe that the foundational issue of this problem devolves down to how to viably extend ARP 4754-based partitions into ARINC 664 enclaves. There are two basic technologies used for that approach: firewalls and VPNs. Local issues will determine which is preferable, though I argue that future airspace requirements (e.g., Eurocontrol's Single Sky, NASA's NextGen) imply using both and coupling VPNs with the Biba Security Model to create assurable distributed network deployments. My point is that wherever one discusses either "assurable networks" or "distributed networks" map-and-encaps is usually involved. Changing topics, in industry (e.g., ecommerce) firewalls have become increasingly passé because the majority of our internal network users, for example, are not our employees, but rather are our suppliers and customers. We call this de-parameterization. De-parameterization is a fact of life for most very large industrial companies. This is another type of problem which map-and-encaps is increasingly being used to solve. My point is that wherever one discusses distributed enclaves map-and-encaps is usually involved. --Eric >From: Tony Li [mailto:[EMAIL PROTECTED] >Eric, > >|My personal belief is that I'd like us to converge soon on a >|routing-only solution. I think that it is time to begin to wrap the >|theoretical discussions up and proceed to modeling and simulation and >|limited deployment experimentation. >| >|Failing that, I would like to better understand why the RRG community >|hasn't yet converged on the desirability of map-and-encaps as a >|desirable RRG vector. >There is a portion of the community (significant, IMHO) that feels >that there are significant drawbacks to the map-&-encap strategy. >While I can't claim to represent all of them or even a significant >breadth of their opinions, there are some issues that have been raised. >- Map-&-encap doesn't solve the problem where it truly occurs: at the >host. The convolution of locator and identifier happens precisely >because the transport layer has reused the address as part of the >connection identifier. Until we change this, we're simply band-aiding >around the problem. And band-aids really aren't the way to create a >lasting architecture. Please note that this also implies that >routing-only solutions aren't the correct direction. >- Map-&-encap comes with significant overhead. It adds another network >layer header, and some additional per packet overhead. In changing the >MTU, it requires additional mechanisms that some (tho I appear to be >alone in this ;-) find concerning. >- Map-&-encap creates some attack vectors. If an attacker sends you >a packet from a forged (and possibly random) EID, and that causes >you to respond and perform a mapping lookup on the forged EID, then >the attacker can cause you to fill your mapping cache and thus create >a significant performance issue. While it's already difficult in the >Internet today to trace forged source addresses, it would seem like >tracking forged EIDs will be even harder, as they are likely to come >with addresses from forged ITR addresses. There are probably ways >to address this, but they would seem to come with Even More Mechanisms. >- Is virtualization really the right approach? It's been noted that >map-&-encap is basically equivalent to running the entire Internet >inside of a VPN, where the mapping function conveys the edge of the >'primary' infrastructure that terminates the VPN tunnels. Some find >it architecturally disquieting to run our most essential function >virtually when we find that we cannot run it natively. > >There are probably many other issues, but these are some of the ones >that have been raised. > >Regards, >Tony _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
