Iljitsch van Beijnum escribió:
On 7 jul 2009, at 22:21, Dave Thaler wrote:
CGAs are only useful when they're assigned to a host, not in the
address space of protocol A that represents the address space of
protocol B.
Disagree. I'm not sure it's a big deal, but I disagree it has
0 worth. CGAs are useful to prevent spoofing. If a translator
chooses to use a CGA to represent an IPv4 host, then spoofing
it is _extremely_ difficult.
A CGA ties a public key to an address. This is useful if you have
people sending you packets with a source address that may or may not
belong to them. In the NAT64 case that would mean that a fake NAT64
tries to spoof the source addresses (that encode IPv4 addresses) of
the real NAT64. But since the IPv6 host sets up the session in the
first place, all of this is taken care of (for a low level of
security) by return routability. Sessions can also be protected by SSL
through the NAT64 directly to the IPv4 destination or with IPsec
between the host and the NAT64. Both of these are much more useful
than CGA if a high level of security is required. But I don't see how
it would be, at some point you have to assume that if you give people
packets they will take care of them.
for example, suppose you want to run shim6 on the nat64 box, how would
you do it if you cannot use the lower 64 bits to store crypto info?
(what i mean is that the IPv6 host talks shim6 with its peer, which in
this case i behind the nat64 box, so the shim6 protocol runs between the
IPv6 node and the nat64)
Regards, marcelo
Sorry, but the idea that privacy should apply to NAT64 is stupid.
Disagree. People already (whether we like it or not) associate
a certain degree of privacy with NATs.
In this regard, a NAT64 is no different from a NAT44 in principle.
Of course the fact that a NAT64 will most likely be deployed in the
ISP network renders the issue largely moot.
What you would have to do is _encrypt_ the destination address to hide
it from prying eyes. Guess what, we have a protocol for that: IPsec
tunnel mode. Encrypts the rest of the packet, too.
I would worry more about the DNS, though. Not only is it easily
spoofable, it also leaks not only addresses but FQDNs. So at the very
least you'd want DNSSEC and probably also talk to the DNS over IPsec.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
