On Jan 27, 2009, at 10:11 PM, Tony Hain wrote:
It looks like the only cure for this nat66 nonsense is to mandate AH
everywhere...
In which case we will once again find out just exactly how much power
a statement by the IETF requiring network administrators to do
something has. All point to point interfaces default to PPP, right?
Every implementation where the network presumes omniscient knowledge
about what the end user intended is inherently broken. GSE is not
only doing that, it is saying that 'it doesn't matter what the end
user wanted, the network admin for the router currently holding the
packet gets to do whatever they want to the header'. There will be
no way to diagnose what is going on, because every packet could take
a very different path as each hop along the way distorts reality
with its own nat66 policy, which might include load-balancing.
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.
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.
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.
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. 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.
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66