Just back from vacation and trying to catch up on threads... > -----Original Message----- > From: behave-boun...@ietf.org [mailto:behave-boun...@ietf.org] On > Behalf Of Iljitsch van Beijnum > Sent: Tuesday, July 07, 2009 1:41 PM > To: Dave Thaler > Cc: Christian Huitema; Xing Li; 6man; Behave WG > Subject: Re: [BEHAVE] Perils of structured host identifiers > > 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.
Right > 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. Now you lost me. If a NAT64 (whether stateless or stateful) uses a CGA, then it can be validated as being the legitimate source of an IPv6 packet (that was translated from IPv4). Another IPv6 source cannot spoof such traffic. Again, I'm not sure this is a big deal since such traffic can still be spoofed on the IPv4 side, but preventing spoofing within one portion of the network doesn't have 0 worth. > 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. A low level of security means it's still susceptible to on-path attacks, whereas CGAs are a much stronger defense. Also for stateless (for which is still possible in theory, if not in practice, to use a CGA if you can get a short enough prefix like a /32), the session may not be initiated by an IPv6 host. > 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. > > >> 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. Right. BTW, that's how Windows 7 works (DNSSEC over IPsec). -Dave > _______________________________________________ > Behave mailing list > beh...@ietf.org > https://www.ietf.org/mailman/listinfo/behave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
