Hi Christian,
On Oct 29, 2010, at 8:13 PM, Christian Huitema wrote:
The current proposal is interesting precisely because it is a subset
of the entire universe of NAT66: it is stateless, and it does not
include port mapping. At some level, if you hold your nose long
enough, it feels like some kind of tunnel.
Exactly, it is more like a tunnel that avoids MTU/fragmentation issues
than a NAT.
For that, I wonder whether we should include some form of topology
hiding in the solution, or at least topology obfuscation. I know
that it can be done, e.g. using some form of encryption of the EID
during translation, with the effect of obfuscating the subnet mapping.
Of course, if we did include topology obfuscation, we would lose the
simple "prefix mapping" property. So we would probably leave that as
an option.
I had a topology hiding option in the first version of NAT66, where a
reversible (with the key) cryptographic transform was performed on the
subnet bits and IID before the checksum correction was performed. I
was pretty excited about that option, but all it turned into in the
end was a lengthy presentation by someone from the security area about
how obscuring the subnet and IID fields doesn't give you _true_
topology hiding, because it doesn't hide things like TCP inter-packet
timing, or whatever.
So, I took the topology hiding mechanism out, because it seemed like
something that would stand in the way of getting IETF consensus on the
basic NAT66 mechanism. But, if we can agree to a basic NAT66
mechanism, it should be fairly easy to augment it with a topology
hiding option.
Margaret
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
