Fred Baker wrote: > ... > I understand your viewpoint. That is in fact part of why I specified > the BUPT prototyping effort the way I did - to force a worst case > oscillation in addressing and drive the test crazy. > > ftp://ftpeng.cisco.com/fred/gse/nat66-gse.html > > That said, I rather strongly suspect that your view of the end user > doesn't work in the Internet even without NATs. Let's imagine that one > has two addresses and a target system/service has one addresses, and > both ends are using shim6. Let's further assume that the two systems > are respectively in Singapore and Canberra, and that the two ISPs in > Singapore have different contracts with the ISP in Canberra; one > routing traffic directly, and the other via an intermediate Tier 1. > Yes, I'm referring to the little routing test Geoff conducted and > reported to the IAB perhaps ten years ago. By choice of address pair, > one had the opportunity of using an 80 ms RTT or one that was over 600 > ms. And let's note that since these are three different ISPs with > three different prefixes, no static rule on source or destination > address choice can be guaranteed to work. > > What is the user's intention? I will give strong odds that it is to > "access the peer machine for some particular transaction in the manner > that completes the transaction in the least wall clock time". It might > be to download a picture or html file, send an email, or etc. And the > only way that it will make the right choice is by either (a) monkeying > with DNS to only present the address that has a relatively short RTT > or (b) monkey with routing to send the datagram on the short delay > path. But standard routing is not about delay (I was at the time > arguing that expected path delay should be available in routing to > enable such decisions), it is about contracts. >
It might be, or it might be that one transaction has little impact on another. Consider the case where one isp provides low-latency modest bandwidth, while another provides high-bandwidth with moderate-jitter. The end user would clearly want voice traffic to go over the low-latency path, and would also clearly want a streaming video feed to avoid that path due to the marginal bandwidth and its likely impact on the voice traffic. The omniscient routing system you propose would 'help' the end user by directing the video stream due to contractual arrangements between the ISPs, and the end user would have no say in the matter so they would always get crappy voice, or always have the voice drop out when a video stream is running. > Now, if I am allowed to, I can force such things to work right in > routing, and in so doing GSE would select the corresponding address > pair. shim6 lacks the information, apart from some form of history or > reputation mechanism. > > So in that case, GSE has a hope of serving the user's intent, and > shim6 gets it right some percentage of the time. > Shim6 was DOA, because it inherently breaks what little security architecture there is, and GSE has the same problem because edge firewall rules can't be informed in real-time in a trusted manner about the header changes that the omniscient routing system is making. Assuming that the only place that rewrites a header is an enterprise firewall is naive at best ... > > > Believe it or not, I am also a strong supporter of the end to end > principle. What I believe, that you apparently don't, is that there is > value in the network helping the user achieve his intended goals. I > also believe that there is a fair bit of state and intelligence in > routing that the user's administration uses to meet its goals, which > is valid and relevant and may be at odds with the actual user - if the > "user" is a virus, we usually prefer that the user loses that > particular battle. The difference in our viewpoints is that I recognize that there are multiple administrations with conflicting goals along the path, where maybe one of them actually cares about the end user, just maybe. The issue is that the network 'intelligence' requires input from the user to even attempt to meet their goal, but historically has refused to accept that input as 'too much state'. > > So please don't be knee-jerk here. The NAT66 proposal (and the one > like it but without the checksum offset mechanism that GSE originally > proposed) don't have the same effect as NAT44; they don't prevent > access. What they do is create a situation in which a host that thinks > it has one address on a given interface in fact has several, which a > peer should choose among and might change its mind concerning as it > interacts with routing. If it were the peer getting to choose I would have fewer problems. GSE is about letting every administration along the path arbitrarily rewrite the header to meet its goals, not any other ISP's goals, and certainly not either endpoint's goals. Since there is no secure communication between the arbitrary ISP rewrite and the firewalls near the endpoints, there is no way to establish state that is meaningful beyond the syn packet. > But the user's intent rarely has anything to > do with the value of the address - let me ask, when you ask google > where to find content and you click on a link, do you even know what > the address was, and if you did would it affect you in any way? The > user's intent has far more to do with the behavior of the application > he has chosen. So I will argue that a technology that enables the > routing system to have a number of prefixes comparable to the number > of transit networks in the world and enables any system to address a > peer anywhere else achieves the user's probable intent regardless of > whether the technology in question rewrites the locator. It can't be open-loop, so if rewriting is supposed to occur it would make more sense for the network to inform the end system to send the packet that way to begin with using SCTP's multiple address capability. At least with that approach, SCTP-aware firewalls would have a chance of keeping up. Tony _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
